7.2A Extensions to SIP header fields defined within the present document

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.2A.1 Extension to WWW-Authenticate header field

7.2A.1.1 Introduction

This extension defines a new authentication parameter (auth-param) for the WWW-Authenticate header field used in a 401 (Unauthorized) response to the REGISTER request. For more information, see RFC 7235 [285] subclause 2.1 and clause C.

7.2A.1.2 Syntax

The syntax for for auth-param is specified in table 7.2A.1.

Table 7.2A.1: Syntax of auth-param

auth-param = 1#( integrity-key / cipher-key )

integrity-key = "ik" EQUAL ik-value

cipher-key = "ck" EQUAL ck-value

ik-value = LDQUOT *(HEXDIG) RDQUOT

ck-value = LDQUOT *(HEXDIG) RDQUOT

7.2A.1.3 Operation

This authentication parameter will be used in a 401 (Unauthorized) response in the WWW-Authenticate header field during UE authentication procedure as specified in subclause 5.4.1.

The S-CSCF appends the integrity-key parameter (directive) to the WWW.-Authenticate header field in a 401 (Unauthorized) response. The P-CSCF stores the integrity-key value and removes the integrity-key parameter from the header field prior to forwarding the response to the UE.

The S-CSCF appends the cipher-key parameter (directive) to the WWW-Authenticate header field in a 401 (Unauthorized) response. The P-CSCF removes the cipher-key parameter from the header field prior to forwarding the response to the UE. In the case ciphering is used, the P-CSCF stores the cipher-key value.

7.2A.2 Extension to Authorization header field

7.2A.2.1 Introduction

This extension defines new dig-resp parameters for the Authorization header field used in REGISTER requests. For more information, see RFC 7235 [285] subclause 2.1 and clause C.

7.2A.2.2 Syntax

7.2A.2.2.1 integrity-protected

The syntax of integrity-protected for the Authorization header field is specified in table 7.2A.2.

Table 7.2A.2: Syntax of integrity-protected for Authorization header field

dig-resp =/ "integrity-protected" EQUAL ("yes" / "no" / "tls-pending" / "tls-yes" / "ip-assoc-pending" / "ip-assoc-yes" / "auth-done" / "tls-connected")

7.2A.2.3 Operation

This authentication parameter is inserted in the Authorization header field of all the REGISTER requests. The value of the "integrity-protected" header field parameter in the auth-param parameter is set as specified in subclause 5.2.2. This information is used by S-CSCF to decide whether to challenge the REGISTER request or not, as specified in subclause 5.4.1.

The values in the "integrity-protected" header field field are defined as follows:

"yes": indicates that a REGISTER request received in the P-CSCF is protected using an IPsec security association and IMS AKA is used as authentication scheme.

"no": indicates that a REGISTER request received in the P-CSCF is not protected using an IPsec security association and IMS AKA is used as authentication scheme, i.e. this is an initial REGISTER request with the Authorization header field not containing a challenge response.

"tls-yes": indicates that a REGISTER request is received in the P-CSCF protected over a TLS connection and the Session ID, IP address and port for the TLS connection are already bound to a private user identity. The S-CSCF will decide whether or not to challenge such a REGISTER request based on its policy. This is used in case of SIP digest with TLS.

"tls-pending": indicates that a REGISTER request is received in the P-CSCF protected over a TLS connection and the Session ID, IP address and port for the TLS connection are not yet bound to a private user identity. The S-CSCF shall challenge such a REGISTER request if it does not contain an Authorization header field with a challenge response or if the verification of the challenge response fails. This is used in case of SIP digest with TLS.

"ip-assoc-yes": indicates that a REGISTER request received in the P-CSCF does map to an existing IP association in case SIP digest without TLS is used.

"ip-assoc-pending": indicates that a REGISTER request received in the P-CSCF does not map to an existing IP association, and does contain a challenge response in case SIP digest without TLS is used.

"auth-done": indicates that a REGISTER request is sent from an entity that is trusted and has authenticated the identities used in the REGISTER request. An example for such an entity is the MSC server enhanced for IMS centralized services. The S-CSCF shall skip authentication.

"tls-connected": indicates that a REGISTER request received in the eP-CSCF is issued by a UE over a TLS session established prior to the registration and IMS AKAv2 is used as authentication scheme. This integrity-protected flag value is used for example in case of WebRTC over IMS when the Authentication is IMS-AKA as defined in 3GPP TS 24.371 [8Z].

NOTE 1: In case of SIP digest with TLS is used, but the REGISTER request was not received over TLS, the P-CSCF does not include an "integrity-protected" header field parameter in the auth-param to indicate that an initial REGISTER request was not received over an existing TLS session. The S-CSCF will always challenge such a REGISTER request.

NOTE 2: In case of SIP digest without TLS is used, but the REGISTER request was not received over TLS, the P-CSCF does not include an "integrity-protected" header field parameter in the auth-param to indicate that the REGISTER request does not map to an existing IP association, and does not contain a challenge response. The S-CSCF will always challenge such a REGISTER request.

NOTE 3: The value "yes" is also used when an initial REGISTER request contains an Authorization header field with a challenge response as in this case the IPsec association is already in use, and its use by the UE implicitly authenticates the UE. This is a difference to TLS case where the use of TLS alone does not yet implicitly authenticates the UE. Hence in the TLS case, for an initial REGISTER request containing an Authorization header field with a challenge response the value "tls-pending" and not "tls-yes" is used.

7.2A.3 Tokenized-by header field parameter definition (various header fields)

7.2A.3.1 Introduction

The "tokenized-by" header field parameter is an extension parameter appended to encrypted entries in various SIP header fields as defined in subclause 5.10.4.

7.2A.3.2 Syntax

The syntax for the "tokenized-by" header field parameter is specified in table 7.2A.3:

Table 7.2A.3: Syntax of tokenized-by-param

rr-param = tokenized-by-param / generic-param

via-params = via-ttl / via-maddr

/ via-received / via-branch

/ tokenized-by-param / via-extension

tokenized-by-param = "tokenized-by" EQUAL hostname

The BNF for rr-param and via-params is taken from RFC 3261 [26] and modified accordingly.

7.2A.3.3 Operation

The "tokenized-by" header field parameter is appended by IBCF (THIG) after all encrypted strings within SIP header fields when network configuration hiding is active. The value of the header field parameter is the domain name of the network which encrypts the information.

7.2A.4 P-Access-Network-Info header field

7.2A.4.1 Introduction

The P-Access-Network-Info header field is extended to include specific information relating to particular access technologies.

7.2A.4.2 Syntax

The syntax of the P-Access-Network-Info header field is described in RFC 7315 [52] and RFC 7913 [234]. There are additional coding rules for this header field depending on the type of IP-CAN, according to access technology specific descriptions.

Table 7.2A.4 describes the 3GPP-specific extended syntax of the P-Access-Network-Info header field defined in RFC 7315 [52] and RFC 7913 [234].

Table 7.2A.4: Syntax of extended P-Access-Network-Info header field

daylight-saving-time = "daylight-saving-time" EQUAL quoted-string

UE-local-IP-address = "UE-local-IP-address" EQUAL DQUOTE ( IPv4address / IPv6reference ) DQUOTE

UDP-source-port = "UDP-source-port" EQUAL port

TCP-source-port = "TCP-source-port" EQUAL port

ePDG-IP-address = "ePDG-IP-address" EQUAL DQUOTE ( IPv4address / IPv6reference ) DQUOTE

access-class =/ "untrusted-non-3GPP-VIRTUAL-EPC" / "VIRTUAL-no-PS" / "WLAN-no-PS" /

"3GPP-NR" / "3GPP-NR-U" / "3GPP-NR-SAT"

access-type =/ "3GPP-E-UTRAN-ProSe-UNR" / "xDSL" / "3GPP-NR-FDD" / "3GPP-NR-TDD" /

"IEEE-802.11ac" / "3GPP-NR-U-FDD" / "3GPP-NR-U-TDD" / "3GPP-NR-SAT" / "3GPP-NR-ProSe-L2UNR" / "3GPP-NR-ProSe-L3UNR"

eps-fb = "eps-fallback" EQUAL "0" / "1"

The daylight-saving-time and the UE-local-IP-address are instances of generic-param from the current extension-access-info component of the P-Access-Network-Info header field defined in RFC 7315 [52] and RFC 7913 [234].

The presence of the "network-provided" header field parameter defined in RFC 7315 [52] indicates a P-Access-Network-Info header field is provided by the P-CSCF, S-CSCF, the AS, the MSC server enhanced for ICS, the MSC server enhanced for SRVCC using SIP interface, the MSC server enhanced for DRVCC using SIP interface or by the MGCF. The content can differ from a P-Access-Network-Info header field without this parameter which is provided by the UE.

The "network-provided" header field parameter can be used with both "access-type" and "access-class" constructs. The "access-class" construct is provided for use where the value is not known to be specific to a particular "access-type" value, e.g. in the case of some values delivered from the PCRF. The "access-class" field can be set only by the P-CSCF, the MSC server enhanced for ICS, the MSC server enhanced for SRVCC using SIP interface, the MSC server enhanced for DRVCC using SIP interface or by the AS. The "network-provided" header field parameter can be set only by the P-CSCF, S-CSCF, the AS, the MSC server enhanced for ICS, the MSC server enhanced for SRVCC using SIP interface, the MSC server enhanced for DRVCC using SIP interface or by the MGCF. The "local-time-zone" parameter, the "daylight-saving-time" parameter, the "gstn-location" parameter, the "GSTN" value of access-type field and the "untrusted-non-3GPP-VIRTUAL-EPC" value of access-class field shall not be inserted by the UE.

The "local-time-zone" parameter defined in RFC 7315 [52] indicates the time difference between local time and UTC of day. For 3GPP accesses, the "local-time-zone" parameter represents the time zone allocated to the routing area or traffic area which the UE is currently using. As the edge of such areas may overlap, there can be some discrepancy with the actual time zone of the UE where the UE is in the near proximity to a time zone boundary.

The "daylight-saving-time" parameter indicates by how much the local time of the UE has been adjusted due to the use of daylight saving time. Providing the "daylight-saving-time" parameter is optional.

The "UE-local-IP-address" parameter indicates the UE local IP address.

NOTE: The UE local IP address is the source address on the outer header of the IPsec tunnel packets received by the ePDG on the S2b interface.

The "UDP-source-port" parameter indicates that the IKEv2 messages exchanged between the UE and the ePDG are encapsulated in the UDP messages according to IETF RFC 3948 [63A]. The value of the "UDP-source-port" parameter is the UDP source port of the UDP messages:

– received by the ePDG; and

– encapsulating the IKEv2 messages.

The "TCP-source-port" parameter indicates that the IKEv2 messages exchanged between the UE and the ePDG are transported using the firewall traversal tunnel as described in 3GPP TS 24.302 [8U]. The value of the "TCP-source-port" parameter is the TCP source port of the TCP messages:

– received by the ePDG; and

– of the firewall traversal tunnel transporting the IKEv2 messages.

The "ePDG-IP-address" parameter indicates the ePDG IP address used as IKEv2 tunnel endpoint with the UE.

The "eps-fallback" header field parameter is used to indicate that the current access technology is used as a result of EPS fallback. The value "1" indicates that EPS fallback has occurred, the value "0" that EPS fallback has not occurred. The parameter can be set only by the P-CSCF.

7.2A.4.3 Additional coding rules for P-Access-Network-Info header field

The P-Access-Network-Info header field is populated with the following contents:

1) the access-type field set to one of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E-UTRAN-FDD", "3GPP-E-UTRAN-TDD", "3GPP-E-UTRAN-ProSe-UNR", "3GPP-NR-FDD", "3GPP-NR-TDD", "3GPP-NR-U-FDD", "3GPP-NR-U-TDD", "3GPP-NR-SAT", "3GPP-NR-ProSe-L2UNR", "3GPP-NR-ProSe-L3UNR", "3GPP2-1X", "3GPP2-1X-HRPD", "3GPP2-UMB", "3GPP2-1X-Femto", "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b", "IEEE-802.11g", "IEEE-802.11n", "IEEE-802.11ac", "ADSL", "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", "xDSL", "DOCSIS", "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3j", "IEEE-802.3u", "IEEE-802.3ab", "IEEE-802.3ae", "IEEE-802.3ah", "IEEE-802.3ak", "IEEE-802.3aq", "IEEE-802.3an", "IEEE-802.3y", "IEEE-802.3z", or "DVB-RCS2" as appropriate to the access technology in use.

1A) the access-class field set to one of "3GPP-GERAN", "3GPP-UTRAN", "3GPP-E-UTRAN", "3GPP-NR", "3GPP-NR-U", "3GPP-NR-SAT", "3GPP-WLAN", "3GPP-GAN", "3GPP-HSPA", "3GPP2", "untrusted-non-3GPP-VIRTUAL-EPC", "VIRTUAL-no-PS", or "WLAN-no-PS" as appropriate to the technology in use. The access-class field set to "untrusted-non-3GPP-VIRTUAL-EPC" indicates the IP-CAN associated with an EPC based untrusted non-3GPP access with unknown radio access technology. The access-class field set to "VIRTUAL-no-PS" indicates an IP-CAN associated with an unknown radio access technology, such that the IP-CAN is not provided by the packet switched domain of the PLMN of the P-CSCF. The access-class field set to "WLAN-no-PS" indicates an IP-CAN associated with WLAN, such that the IP-CAN is not provided by the packet switched domain of the PLMN of the P-CSCF. The access-class field set to "3GPP-NR-SAT " indicates an IP-CAN associated with satellite NG-RAN.

2) if the access-type field or the access-class field is set to "3GPP-GERAN", a cgi-3gpp parameter set to the Cell Global Identity obtained from lower layers of the UE. The Cell Global Identity is a concatenation of MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadeciaml digits) and CI (as described in 3GPP TS 23.003 [3]. The "cgi-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212];

3) if the access-type field is equal to "3GPP-UTRAN-FDD", or "3GPP-UTRAN-TDD", and a UE provides the P-Acces-Network-Info header field, a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadecimal digits) as described in 3GPP TS 23.003 [3] and the UMTS Cell Identity (7 hexadecimal digits) as described in 3GPP TS 25.331 [9A]), obtained from lower layers of the UE. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212];

3A) if the access-type field is equal to "3GPP-UTRAN-FDD", or "3GPP-UTRAN-TDD", and an entitiy that can use the "network-provided" header field parameter provides the P-Access-Network-Info header field, if available a "utran-sai-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadecimal digits) as described in 3GPP TS 23.003 [3] and SAC (4 hexadecimal digits) as described in 3GPP TS 23.003 [3]. The "utran-sai-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212];

3B) if the access-class field is equal to "3GPP-UTRAN", or "3GPP-HSPA", if available a "utran-sai-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), LAC (4 hexadecimal digits) as described in 3GPP TS 23.003 [3] and SAC (4 hexadecimal digits) as described in 3GPP TS 23.003 [3]. The "utran-sai-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212];

4) void

5) if the access-type field is set to "3GPP2-1X", a ci-3gpp2 parameter set to the ASCII representation of the hexadecimal value of the string obtained by the concatenation of SID (16 bits), NID (16 bits), PZID (8 bits) and BASE_ID (16 bits) (see 3GPP2 C.S0005-D [85]) in the specified order. The length of the ci-3gpp2 parameter shall be 14 hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII characters. If the UE does not know the values for any of the above parameters, the UE shall use the value of 0 for that parameter. For example, if the SID is unknown, the UE shall represent the SID as 0x0000;

NOTE 1: The SID value is represented using 16 bits as supposed to 15 bits as specified in 3GPP2 C.S0005-D [85].

EXAMPLE: If SID = 0x1234, NID = 0x5678, PZID = 0x12, BASE_ID = 0xFFFF, the ci-3gpp2 value is set to the string "1234567812FFFF".

6) if the access-type field is set to "3GPP2-1X-HRPD", a ci-3gpp2 parameter set to the ASCII representation of the hexadecimal value of the string obtained by the concatenation of Sector ID (128 bits) and Subnet length (8 bits) (see 3GPP2 C.S0024-B [86]) and Carrier-ID, if available, (see 3GPP2 X.S0060 [86B])in the specified order. The length of the ci-3gpp2 parameter shall be 34 or 40 hexadecimal characters depending on whether the Carrier-ID is included. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII characters;

EXAMPLE: If the Sector ID = 0x12341234123412341234123412341234, Subnet length = 0x11, and the Carrier-ID=0x555444, the ci-3gpp2 value is set to the string "1234123412341234123412341234123411555444".

7) if the access-type field is set to "3GPP2-UMB" 3GPP2 C.S0084-000 [86A], a ci-3gpp2 parameter is set to the ASCII representation of the hexadecimal value of the Sector ID (128 bits) defined in 3GPP2 C.S0084-000 [86A]. The length of the ci-3gpp2 parameter shall be 32 hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII characters;

EXAMPLE: If the Sector ID = 0x12341234123412341234123412341234, the ci-3gpp2 value is set to the string "12341234123412341234123412341234".

8) if the access-type field set to one of "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b", "IEEE-802.11g", "IEEE-802.11n", or "IEEE-802.11ac", an "i-wlan-node-id" parameter is set to the ASCII representation of the hexadecimal value of the AP’s MAC address without any delimiting characters;

NOTE 2: The AP’s MAC address is provided in the BSSID information element.

EXAMPLE: If the AP’s MAC address = 00-0C-F1-12-60-28, then i-wlan-node-id is set to the string "000cf1126028".

NOTE 3: "i-wlan-node-id" parameter is not restricted to I-WLAN. "i-wlan-node-id" parameter can be inserted for a WLAN which is not an I-WLAN.

9) if the access-type field is set to "3GPP2-1X-Femto", a ci-3gpp2-femto parameter set to the ASCII representation of the hexadecimal value of the string obtained by the concatenation of femto MSCID (24 bit), femto CellID (16 bit), FEID (64bit), macro MSCID (24 bits) and macro CellID (16 bits) (3GPP2 X.P0059-200 [86E]) in the specified order. The length of the ci-3gpp2-femto parameter is 36 hexadecimal characters. The hexadecimal characters (A through F) are coded using the uppercase ASCII characters.

10) if the access-type field is set to one of "ADSL", "ADSL2", "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL", or "xDSL", the access-info field shall contain a dsl-location parameter obtained from the CLF (see NASS functional architecture);

11) if the access-type field set to "DOCSIS", the access info parameter is not inserted. This release of this specification does not define values for use in this parameter;

12) if the access-type field is equal to "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value) which should be obtained from the E-UTRAN Cell Global Identifier (ECGI), Tracking Area Code (4 hexadecimal digits when accessing to EPC and 6 hexadecimal digits when accessing to 5GCN) as described in 3GPP TS 23.003 [3] and the E-UTRAN Cell Identity (ECI) (7 hexadecimal digits) as described in 3GPP TS 23.003 [3]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212];

EXAMPLE: If MCC is 111, MNC is 22, TAC is 33C4 and ECI is 76B4321, then P-Access-Network-Info header field looks like follows: P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1112233C476B4321;network-provided

NOTE 4: The total length of the "utran-cell-id-3gpp" parameter depends on the various combinations of MNC and TAC possible sizes. The actual length of MNC and TAC parts can be unambiguously deduced from the total length.

NOTE 5: The P-CSCF obtains the ECGI in the 3GPP-User-Location-Info AVP received from the PCRF, while the UE obtains the ECGI from RAN. In roaming scenarios with P-GW in the HPLMN, the MCC-MNC contained in the ECGI retrieved by the P-CSCF can differ from that contained in the ECGI retrieved by the UE. Using MNC and MCC from a different source than ECGI can lead to collision between cell-id values which makes the determination of the UE location not possible or incorrect and disables routing of emergency calls based on location information.

12A) if the access-class field is equal to "3GPP-E-UTRAN", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value) which should be obtained from the E-UTRAN Cell Global Identifier (ECGI), Tracking Area Code (4 hexadecimal digits when accessing to EPC and 6 hexadecimal digits when accessing to 5GCN) as described in 3GPP TS 23.003 [3] and the E-UTRAN Cell Identity (ECI) (7 hexadecimal digits) as described in 3GPP TS 23.003 [3]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212];

12B) if the access-type field is equal to "3GPP-E-UTRAN-ProSe-UNR", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value) which should be obtained from the E-UTRAN Cell Global Identifier (ECGI) and the E-UTRAN Cell Identity (ECI) (7 hexadecimal digits) as described in 3GPP TS 23.003 [3] obtained from the ProSe-UE-to-network relay that the UE is connected to as specified in 3GPP TS 24.334 [8ZD]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in in RFC 20 [212];

EXAMPLE: If MCC is 111, MNC is 22 and ECI is 76B4321, then P-Access-Network-Info header field looks like follows: P-Access-Network-Info: 3GPP-E-UTRAN-ProSe-UNR;utran-cell-id-3gpp=1112276B4321.

12C) if the access-type field is equal to "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", an "eps-fallback" header field parameter set to an appropriate value;

12D) if the access-class field is equal to "3GPP-E-UTRAN", an "eps-fallback" header field parameter set to an appropriate value;

13) if the access-type field is set to one of "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-802.3j", "IEEE-802.3u", "IEEE-802.3ab", "IEEE-802.3ae", IEEE-802.3ak", IEEE-802.3aq", IEEE-802.3an", "IEEE-802.3y" or "IEEE-802.3z" and NASS subsystem is used, the access-info field shall contain an eth-location parameter obtained from the CLF (see NASS functional architecture);

14) if the access-type field is set to one of "GPON", "XGPON1" or "IEEE-802.3ah" and NASS is used, the access-info field shall contain an fiber-location parameter obtained from the CLF (see NASS functional architecture);

15) if the access-type field is set to "GSTN", the access-info field may contain a gstn-location parameter if received from the GSTN;

NOTE 6: The "cgi-3gpp", the "utran-cell-id-3gpp", the "ci-3gpp2", the "ci-3gpp2-femto", the "i-wlan-node-id", eth-location, and the "dsl-location" parameters described above among other usage also constitute the location identifiers that are used for emergency services.

16) if the access-type field is set to "DVB-RCS2", the access-info field shall contain a "dvb-rcs2-node-id" parameter which consists of comma-separated list consisting of NCC_ID, satellite_ID, beam_ID, and SVN-MAC as specified in ETSI TS 101 545-2 [194], ETSI TS 101 545-3 [195]; the NCC_ID shall be represented as two digit hexadecimal value, the satellite_ID shall be represented as a two digit hexadecimal value, the beam_ID shall be respresented as a four digit hexadecimal value, and the SVN-MAC shall be represented as six digit hexadecimal value;

EXAMPLE: If the (8 bit) NCC_ID = 0x3A, the (8 bit) satellite_ID = 0xF5, the (16 bit) beam_ID = 0xEA23, and the (24 bit) SVN-MAC = 0xE40AB9, then the "dvb-rcs2-node-id" is set to the string "3A,F5,EA23,E40AB9".

17) the "local-time-zone" parameter in the access-info field is coded as a text string as follows:

UTC±[hh]:[mm]. [hh] is two digits, and [mm] is two digits from four values: "00", "15", "30" or "45", see ISO 8601 [203];

EXAMPLE: "UTC+01:00" indicates that the time difference between local time and UTC of day is one hour.

18) the "daylight-saving-time" parameter in the access-info field is coded as a text string as follows:

[hh]. [hh] is a two digits value from three values "00", "01" or "02" indicating the positive adjustment in hours;

19) void;

20) the operator-specific-GI in the access-info field is coded as a text string and conveys an operator-specifc geographical identifier;

21) if

a) the access-class field is set to "untrusted-non-3GPP-VIRTUAL-EPC"; or

b) the access-class field is set to "3GPP-WLAN" and the WLAN is an untrusted WLAN;

then:

a) if a UE local IP address is available, then a "UE-local-IP-address" parameter set to the UE local IP address;

b) if the IKEv2 messages exchanged between the UE and the ePDG are encapsulated in the UDP messages according to IETF RFC 3948 [63A] and the UDP source port of the UDP messages received by ePDG is available, then a "UDP-source-port" parameter set to the UDP source port of the UDP messages:

– received by the ePDG; and

– encapsulating the IKEv2 messages;

c) if the IKEv2 messages exchanged between the UE and the ePDG are transported using the firewall traversal tunnel as described in 3GPP TS 24.302 [8U] and the TCP source port of the TCP messages of the firewall traversal tunnel received by ePDG is available, then a "TCP-source-port" parameter set to the TCP source port of the TCP messages:

– received by the ePDG; and

– of the firewall traversal tunnel transporting the IKEv2 messages; and

d) if an ePDG IP address used as IKEv2 tunnel endpoint with the UE is available, then an "ePDG-IP-address" parameter set to the ePDG IP address used as IKEv2 tunnel endpoint with the UE;

22) if the access-type field is equal to "3GPP-NR-FDD" or "3GPP-NR-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in 3GPP TS 23.003 [3], the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the Network Identifier (NID) (11 hexadecimal digits) as specified in 3GPP TS 23.003 [3]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212]; and

NOTE 7: NID is included only if a serving network is a Stand-alone Non-Public Network (SNPN) identified by a combination of NID, MCC and MNC. The serving network type can be unambiguously deduced from the total length of the "utran-cell-id-3gpp" parameter.

22A) if the access-class field is equal to "3GPP-NR", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in 3GPP TS 23.003 [3], the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in 3GPP TS 23.003 [3]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212].

23) if the access-type field is equal to "3GPP-NR-U-FDD" or "3GPP-NR-U-TDD", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in 3GPP TS 23.003 [3], the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in 3GPP TS 23.003 [3]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212];

23A) if the access-class field is equal to "3GPP-NR-U", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in 3GPP TS 23.003 [3], the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in 3GPP TS 23.003 [3]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212 ];

24) if the access-type field is equal to "3GPP-NR-SAT", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in 3GPP TS 23.003 [3], the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in 3GPP TS 23.003 [3]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212];

25) if the access-class field is equal to "3GPP-NR-SAT", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in 3GPP TS 23.003 [3], the NR Cell Identity (NCI) (9 hexadecimal digits) and optionally, the NID (11 hexadecimal digits) as specified in 3GPP TS 23.003 [3]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212]; and

26) if the access-type field is equal to "3GPP-NR-ProSe-L2UNR" or "3GPP-NR-ProSe-L3UNR", a "utran-cell-id-3gpp" parameter set to a concatenation of the MCC (3 decimal digits), MNC (2 or 3 decimal digits depending on MCC value), Tracking Area Code (6 hexadecimal digits) as described in 3GPP TS 23.003 [3], and the NR Cell Identity (NCI) (9 hexadecimal digits) obtained from the 5G ProSe UE-to-network relay UE that the UE is connected to as specified in 3GPP TS 24.554 [8ZI]. The "utran-cell-id-3gpp" parameter is encoded in ASCII as defined in RFC 20 [212].

7.2A.5 P-Charging-Vector header field

7.2A.5.1 Introduction

The P-Charging-Vector header field is extended to include specific charging correlation information needed for IM CN subsystem functional entities.

7.2A.5.2 Syntax

7.2A.5.2.1 General

The syntax of the P-Charging-Vector header field is described in RFC 7315 [52]. There may be additional coding rules for this header field depending on the type of IP-CAN, according to access technology specific descriptions.

Table 7.2A.5 describes 3GPP-specific extensions to the P-Charging-Vector header field defined in RFC 7315 [52].

Table 7.2A.5: Syntax of extensions to P-Charging-Vector header field

access-network-charging-info = (gprs-charging-info / i-wlan-charging-info / xdsl-charging-info / packetcable-charging-info / icn-charging-info / eps-charging-info / eth-charging-info/ loopback-indication / 5gs-charging-info / generic-param)

gprs-charging-info = ggsn SEMI auth-token [SEMI pdp-info-hierarchy] *(SEMI extension-param)

ggsn = "ggsn" EQUAL gen-value

pdp-info-hierarchy = "pdp-info" EQUAL LDQUOT pdp-info *(COMMA pdp-info) RDQUOT

pdp-info = pdp-item SEMI pdp-sig SEMI gcid [SEMI flow-id]

pdp-item = "pdp-item" EQUAL DIGIT

pdp-sig = "pdp-sig" EQUAL ("yes" / "no")

gcid = "gcid" EQUAL 1*HEXDIG

auth-token = "auth-token" EQUAL 1*HEXDIG

flow-id = "flow-id" EQUAL "(" "{" 1*DIGIT COMMA 1*DIGIT "}" *(COMMA "{" 1*DIGIT COMMA 1*DIGIT "}")")"

i-wlan-charging-info = "pdg"

xdsl-charging-info = bras SEMI auth-token [SEMI xDSL-bearer-info] *(SEMI extension-param)

bras = "bras" EQUAL gen-value

xDSL-bearer-info = "dsl-bearer-info" EQUAL LDQUOT dsl-bearer-info *(COMMA dsl-bearer-info) RDQUOT

dsl-bearer-info = dsl-bearer-item SEMI dsl-bearer-sig SEMI dslcid [SEMI flow-id]

dsl-bearer-item = "dsl-bearer-item" EQUAL DIGIT

dsl-bearer-sig = "dsl-bearer-sig" EQUAL ("yes" / "no")

dslcid = "dslcid" EQUAL 1*HEXDIG

packetcable-charging-info = packetcable [SEMI bcid]

packetcable = "packetcable-multimedia"

bcid = "bcid" EQUAL 1*48(HEXDIG)

icn-charging-info = icn-bcp *(SEMI itid) [SEMI extension-param]

icn-bcp = "icn-bcp" EQUAL gen-value

itid = itc-sig SEMI itc-id SEMI *(flow-id2)

itc-sig = "itc-sig" EQUAL ("yes" / "no")

itc-id = "itc-id" EQUAL gen-value

flow-id2 = "flow-id" EQUAL gen-value

extension-param = token [EQUAL (token | quoted-string)]

eps-charging-info = pdngw [SEMI eps-bearer-hierarchy] *(SEMI extension-param)

pdngw = "pdngw" EQUAL gen-value

eps-bearer-hierarchy = "eps-info" EQUAL LDQUOT eps-info *(COMMA eps-info) RDQUOT

eps-info = eps-item SEMI eps-sig SEMI ecid [SEMI flow-id]

eps-item = "eps-item" EQUAL DIGIT

eps-sig = "eps-sig" EQUAL ("yes" / "no")

ecid = "ecid" EQUAL 1*HEXDIG

eth-charging-info = ip-edge *(SEMI extension-param)

fiber-charging-info = ip-edge *(SEMI extension-param)

ip-edge = "ip-edge" EQUAL gen-value

loopback-indication = "loopback"

fe-identifier = "fe-identifier" EQUAL fe-id-list fe-id-list = DQUOTE fe-id-param *(COMMA fe-id-param) DQUOTE

fe-id-param = fe-addr/as-addr

fe-addr = "fe-addr" EQUAL gen-value

as-addr = "as-addr" EQUAL gen-value "-" ap-id

ap-id = "ap-id" EQUAL gen-value

5gs-charging-info = smf [SEMI 5gs-pdu-session-hierarchy] *(SEMI extension-param)

smf = "smf" EQUAL gen-value

5gs-pdu-session-hierarchy = "5gs-info" EQUAL LDQUOT 5gs-info *(COMMA 5gs-info) RDQUOT

5gs-info = 5gs-item SEMI 5gscid [SEMI flow-id]

5gs-item = "5gs-item" EQUAL DIGIT

5gscid = "5gscid" EQUAL 1*HEXDIG

NOTE: The syntax above is not aligned with the rules for defining new P-Charging-Vector header field parameters as defined in RFC 7315 [52]. Entities that perform syntax check (even if they are not interested in specific header field parameter values) of the header field need to follow the explicit syntax above, as using the rules in RFC 7315 [52] would trigger a parser error.

The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field.

The access-network-charging-info parameter includes alternative definitions for different types access networks. The description of these parameters are given in the subsequent subclauses.

The "access-network-charging-info" header field parameter is not included in the P-Charging-Vector for SIP signalling that is not associated with a session.

When the "access-network-charging-info" is included in the P-Charging-Vector and necessary information is not available from the IP-CAN (e.g. via Gx/Rx interface) reference points then null or zero values are included.

For type 1 and type 3 IOIs, the generating SIP entity shall express the "orig-ioi" and "term-ioi" header field parameters in the format of a quoted string as specified in RFC 7315 [52].

If an IOI is a type 1 IOI, the content of the quoted string consists of the "Type 1" string prefix followed by the IOI value. The "Type 1" string prefix is the type-1-prefix value specified in the table 7.2A.5A.

If an IOI is a type 3 IOI, the content of the quoted string consists of the "Type 3" string prefix followed by the IOI value. The "Type 3" string prefix is the type-3-prefix value specified in the table 7.2A.5A.

Table 7.2A.5A: String prefixes

type-1-prefix = %x54.79.70.65.20.31 ; "Type 1"

type-3-prefix = %x54.79.70.65.20.33 ; "Type 3"

If an IOI is a type 2 IOI, the value of the "orig-ioi" and "term-ioi" header field parameters is set to the IOI value. No string prefix is used.

The receiving SIP entity does not perform syntactic checking of the contents of the IOI parameter (the IOI parameter is passed unmodified to charging entities).

The "loopback" parameter is provided to the charging system of other entities in the signalling path to indicate that loopback has been applied and entities of the IM CN subsystem involved in the loopback, e.g. TRF, can have generated CDRs in their own right.

The "fe-identifier" header field parameter is an instance of generic-param from the current charge-params component of the P-Charging-Vector header field. This header field parameter contains one or more IM CN subsystem functional entity addresses ("fe-addr") and/or AS addresses ("as-addr") and application identifiers ("ap-id") where the IM CN subsystem functional entity does create charging information for the related CDR of this IM CN subsystem functional entity. For AS hosting several applications the AS address can appear several times, each accompanied with a different application identifier based on the application executed by the AS.

7.2A.5.2.2 GPRS as IP-CAN

GPRS is a supported access network (gprs-charging-info parameter). For GPRS there are the following components to track: GGSN address (ggsn parameter), media authorization token (auth token parameter), and a pdp-info parameter that contains the information for one or more PDP contexts. In this release the media authorization token is set to zero. The pdp-info contains one or more pdp-item values followed by a collection of parameters (pdp-sig, gcid, and flow-id). The value of the pdp-item is a unique number that identifies each of the PDP-related charging information within the P-Charging-Vector header field. Each PDP context has an indicator if it is an IM CN subsystem signalling PDP context (pdp-sig parameter), an associated GPRS Charging Identifier (gcid parameter), and a identifier (flow-id parameter). The flow-id parameter contains a sequence of curly bracket delimited flow identifier tuples that identify associated m-lines and relative order of port numbers in an m-line within the SDP from the SIP signalling to which the PDP context charging information applies. For a complete description of the semantics of the flow-id parameter see 3GPP TS 29.214 [13D] Annex B. The gcid, ggsn address and flow-id parameters are transferred from the GGSN to the P-CSCF via the PCRF over the Rx interface (see 3GPP TS 29.214 [13D] and Gx interface (see 3GPP TS 29.212 [13B]).

The gcid value is received in binary format at the P-CSCF (see 3GPP TS 29.214 [13D]). The P-CSCF shall encode it in hexadecimal format before include it into the gcid parameter. On receipt of this header field, a node receiving a gcid shall decode from hexadecimal into binary format.

The "access-network-charging-info" is not included in the P-Charging-Vector for SIP signalling that is not associated with a multimedia session. The access network charging information may be unavailable for sessions that use a general purpose PDP context (for both SIP signalling and media) or that do not require media authorisation.

7.2A.5.2.3 Evolved Packet Core (EPC) via WLAN as IP-CAN

The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field.

This version of the specification defines the use of "pdg" for inclusion in the P-Charging-Vector header field. No other extensions are defined for use in I-WLAN in this version of the specification.

Editor’s note: WI: TEI12: CR5046: The application of the ABNF element relating to "pdg" to EPS needs to be clarified.

7.2A.5.2.4 xDSL as IP-CAN

The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field. The access-network-charging-info parameter includes alternative definitions for different types of access networks. This subclause defines the components of the xDSL instance of the access-network-charging-info.

For xDSL, there are the following components to track: BRAS address (bras parameter), media authorization token (auth-token parameter), and a set of dsl-bearer-info parameters that contains the information for one or more xDSL bearers.

The dsl-bearer-info contains one or more dsl-bearer-item values followed by a collection of parameters (dsl-bearer-sig, dslcid, and flow-id). The value of the dsl-bearer-item is a unique number that identifies each of the dsl-bearer-related charging information within the P-Charging-Vector header field. Each dsl-bearer-info has an indicator if it is an IM CN subsystem signalling dsl-bearer (dsl-bearer-sig parameter), an associated DSL Charging Identifier (dslcid parameter), and a identifier (flow-id parameter). The flow-id parameter contains a sequence of curly bracket delimited flow identifier tuples that identify associated m-lines and relative order of port numbers in an m-line within the SDP from the SIP signalling to which the dsl-bearer charging information applies. For a complete description of the semantics of the flow-id parameter see 3GPP TS 29.214 [13D].

The format of the dslcid parameter is identical to that of ggsn parameter. On receipt of this header field, a node receiving a dslcid shall decode from hexadecimal into binary format.

For a dedicated dsl-bearer for SIP signalling, i.e. no media stream requested for a session, then there is no authorisation activity or information exchange over the Rx and Gx interfaces. Since there are no dslcid, media authorization token or flow identifiers in this case, the dslcid and media authorization token are set to zero and no flow identifier parameters are constructed by the PCRF.

7.2A.5.2.5 DOCSIS as IP-CAN

The billing correlation identifier (bcid) uniquely identifies the PacketCable DOCSIS bearer resources associated with the session within the cable operator’s network for the purposes of billing correlation. To facilitate the correlation of session and bearer accounting events, a correlation ID that uniquely identifies the resources associated with a session is needed. This is accomplished through the use of the bcid as generated by the PacketCable Multimedia network. This bcid is returned to the P-CSCF within the response to a successful resource request.

The bcid is specified in RFC 3603 [74A]. This identifier is chosen to be globally unique within the system for a window of several months. Consistent with RFC 3603 [74A], the BCID must be encoded as a hexadecimal string of up to 48 characters. Leading zeroes may be suppressed.

If the bcid value is received in binary format by the P-CSCF from the IP-CAN, the P-CSCF shall encode it in hexadecimal format before including it into the bcid parameter. On receipt of this header field, a node using a bcid will normally decode from hexadecimal into binary format.

7.2A.5.2.6 cdma2000^® packet data subsystem as IP-CAN

The specific extensions to the P-Charging-Vector header field defined in RFC 7315 [52] when the access network is cdma2000^® packet data subsystem are: the icn-charging-info parameter contains one icn-bcp child parameter and one or more child itid parameters. The icn-bcp parameter, identifies the point of attachment where UE has attached itself to the cdma2000^® packet data subsystem. The icn-bcp parameter is conveyed to the P-CSCF by the cdma2000^® packet data subsystem. Each itid child parameter within icn-charging-info corresponds to one IP-CAN bearer that was established by the cdma2000^® packet data subsystem for the UE. Each itid parameter contains an indicator if it is an IP-CAN subsystem signalling IP-CAN bearer (itc-sig parameter), an associated IP-CAN charging identifier (itc-id parameter), and one or more flow identifiers (flow-id parameter) that identify associated m-lines within the SDP from the SIP signalling. These parameters are transferred from the cdma2000^® packet data subsystem to the P-CSCF over the respective interface.

For an IP-CAN bearer that is only used for SIP signalling, i.e. no media stream requested for a session, then there is no authorisation activity or information exchange with the P-CSCF over the respective cdma2000^® interfaces. Since there is no itc-id, or flow identifiers in this case, the itc-id is set to zero and no flow identifier parameters are constructed by the P-CSCF.

7.2A.5.2.7 EPS as IP-CAN

For EPS there are the following components to track: P-GW address (pdngw parameter), and a eps-info parameter that contains the information for one or more EPS bearers. The eps-info contains one or more eps-item values followed by a collection of parameters (eps-sig, ecid, and flow-id). The value of the eps-item is a unique number that identifies each of the EPS-bearer-related charging information within the P-Charging-Vector header field. Each EPS bearer context has an associated QCI indicating if it is an IM CN subsystem signalling EPs bearer context (eps-sig parameter), an associated EPS Charging Identifier (ecid parameter), and a identifier (flow-id parameter). The flow-id parameter contains a sequence of curly bracket delimited flow identifier tuples that identify associated m-lines and relative order of port numbers in an m-line within the SDP from the SIP signalling to which the EPS bearer charging information applies. For a complete description of the semantics of the flow-id parameter see 3GPP TS 29.214 [13D] Annex B. The ecid, pdngw address and flow-id parameters are transferred from the P-GW to the P-CSCF via the PCRF over the Rx interface (see 3GPP TS 29.214 [13D] and Gx interface (see 3GPP TS 29.212 [13B]).

The ecid value is received in binary format at the P-CSCF (see 3GPP TS 29.214 [13D]). The P-CSCF shall encode it in hexadecimal format before include it into the ecid parameter. On receipt of this header field, a node receiving a gcid shall decode from hexadecimal into binary format.

The "access-network-charging-info" header field parameter is not included in the P-Charging-Vector for SIP signalling that is not associated with a multimedia session. The access network charging information may be unavailable for sessions that use a general purpose EPS bearer context (for both SIP signalling and media).

7.2A.5.2.8 Ethernet as IP-CAN

The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field. For Ethernet accesses, the IP Edge Node address (ip-edge parameter) is tracked. The IP Edge Node is defined in ETSI ES 282 001 [138].

7.2A.5.2.9 Fiber as IP-CAN

The access-network-charging-info parameter is an instance of generic-param from the current charge-params component of P-Charging-Vector header field. For Fiber accesses, the IP Edge Node address (ip-edge parameter) is tracked. The IP Edge Node is defined in ETSI ES 282 001 [138].

7.2A.5.2.10 5GS as IP-CAN

For 5GS there are the following components to track: SMF address (SMF parameter) and a 5gs-info parameter that contains the information for one or more 5GS PDU sessions. The 5gs-info contains one or more 5gs-item values followed by a collection of parameters (5gscid and flow-id). The value of the 5gs-item is a unique number that identifies each of the 5GS PDU session charging information within the P-Charging-Vector header field.

Each 5GS PDU session has an associated 5GS Charging Identifier (5gscid parameter), and an additional information (flow-id parameter). The flow-id parameter contains a sequence of curly bracket delimited parameter tuples that identify associated m-lines and relative order of port numbers in an m-line within the SDP from the SIP signalling to which the 5GS PDU session charging information applies. For a complete description of the semantics of the flow-id parameter see 3GPP TS 29.214 [13D]. The smf address, 5gscid and flow-id parameters are transported to the P-CSCF via the PCRF over the Rx interface (see 3GPP TS 29.214 [13D].

The 5gscid value is received in binary format at the P-CSCF (see 3GPP TS 29.214 [13D]). The P-CSCF shall encode it in hexadecimal format before include it into the 5gscid parameter. On receipt of this header field, a node receiving a 5gscid shall decode from hexadecimal into binary format.

The "access-network-charging-info" header field parameter is not included in the P-Charging-Vector for SIP signalling that is not associated with a multimedia session.

7.2A.5.3 Operation

The operation of this header field is described in subclauses 5.2, 5.3, 5.4, 5.5, 5.6, 5.7 and 5.8.

7.2A.6 Orig parameter definition

7.2A.6.1 Introduction

The "orig" parameter is a uri-parameter intended to:

– tell the S-CSCF that it has to perform the originating services instead of terminating services;

– tell the I-CSCF that it has to perform originating procedures.

7.2A.6.2 Syntax

The syntax for the orig parameter is specified in table 7.2A.6:

Table 7.2A.6: Syntax of orig parameter

uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / orig / other-param

orig = "orig"

The BNF for uri-parameter is taken from RFC 3261 [26] and modified accordingly.

7.2A.6.3 Operation

The orig parameter is appended to the address of the S-CSCF, I-CSCF or IBCF by the ASs, when those initiate requests on behalf of the user, or to the address of the S-CSCF or I-CSCF by an IBCF acting as entry point, if the network is performing originating service to another network. The S-CSCF will run originating services whenever the orig parameter is present next to its address. The I-CSCF will run originating procedures whenever the orig parameter is present next to its address. The IBCF will preserve the "orig" parameter in the topmost Route header field if received, or it may append the "orig" parameter to the URI in the topmost Route header field (see subclause 5.10.2.3).

7.2A.7 Extension to Security-Client, Security-Server and Security-Verify header fields

7.2A.7.1 Introduction

This extension defines new parameters for the Security-Client, Security-Server and Security-Verify header fields.

This subclause defines the "mediasec" header field parameter that labels any of the Security-Client:, Security-Server, or Security-Verify: header fields as applicable to the media plane and not the signalling plane.

7.2A.7.2 Syntax

7.2A.7.2.1 General

The syntax for the Security-Client, Security-Server and Security-Verify header fields is defined in RFC 3329 [48]. The additional syntax is defined in Annex H of 3GPP TS 33.203 [19].

This specification reuses Security-Client, Security-Server and Security-Verify defined in RFC 3329 [48] and defines the mechanism listed in table 7.2A.7.2.2-2 and the header field parameter "mediasec".

Security mechanisms that apply to the media plane only shall not have the same name as any signalling plane mechanism. If a signalling plane security mechanism name is re-used for the media plane and distinguished only by the "mediasec" parameter, then implementations that do not recognize the "mediasec" parameter may incorrectly use that security mechanism for the signalling plane.

7.2A.7.2.2 "mediasec" header field parameter

The "mediasec" header field parameter may be used in the Security- Client, Security-Server, or Security-Verify header fields defined in RFC 3329 [48] to indicate that a header field applies to the media plane. Any one of the media plane security mechanisms supported by both client and server, if any, may be applied when a media stream is started. Or, a media stream may be set up without security.

Values in the Security-Client, Security-Server, or Security-Verify header fields labelled with the "mediasec" header field parameter are specific to the media plane and specific to the secure media transport protocol used on the media plane.

EXAMPLE: Security-Client: sdes-srtp;mediasec

Usage of the "mediasec" header field parameter in mech-parameters rule of RFC 3329 [48] and the syntax of the "mediasec" header field parameter is shown in table 7.2A.7.2.2-1.

Table 7.2A.7.2.2-1

mech-parameters =/ mediasec-param

mediasec-param = "mediasec"

The security mechanisms which can be labelled by the "mediasec" header field parameter are listed in the table 7.2A.7.2.2-2, where each line (other than the first line) indicates a token and a media security mechanism for which the token indicates support.

Table 7.2A.7.2.2-2

mechanism-name =/ ( sdes-srtp-name / msrp-tls-name / bfcp-tls-name / udptl-dtls-name /

dtls-srtp-name / token )

sdes-srtp-name = "sdes-srtp" ; End-to-access-edge media security using SDES.

msrp-tls-name = "msrp-tls" ; End-to-access-edge media security for MSRP using TLS and certificate fingerprints.

bfcp-tls-name = "bfcp-tls" ; End-to-access-edge media security for BFCP using TLS and certificate fingerprints.

udptl-dtls-name = "udptl-dtls" ; End-to-access-edge media security for UDPTL using DTLS and certificate fingerprints.

dtls-srtp-name = "dtls-srtp" ; End-to-access-edge media security for RTP using DTLS-SRTP and certificate fingerprints.

7.2A.7.3 Operation

The operation of the additional parameters for the Security-Client, Security-Server and Security-Verify header fields is defined in Annex H of 3GPP TS 33.203 [19].

Any one of the mechanisms listed in table 7.2A.7.2.2-2 and labelled with the "mediasec" header field parameter can be applied on-the-fly as a media stream is started, unlike mechanisms for signalling one of which is chosen and then applied throughout a session.

Media plane security can be supported independently of any signalling plane security defined in RFC 3329 [4], but in order to protect any cryptographic key carried in SDP signalling plane security as defined in RFC 3329 [4] SHOULD be used. Each media security mechanism can be supported independently.

The message flow is identical to the flow in RFC 3329 [48], but it is not mandatory for the user agent to apply media plane security immediately after it receives the list of supported media plane mechanisms from the server, or any timer after that, nor will the lack of a mutually supported media plane security mechanism prevent SIP session setup.

7.2A.7.4 IANA registration

7.2A.7.4.1 "mediasec" header field parameter

Editor’s note: [MEDIASEC_CORE, CR 4156] This subclause forms the basis for IANA registration of the mediasec header field parameter. Registration is intended to be created by an RFC that describes the mediasec header field parameter and creates an IANA registry for its values.

NOTE: This subclause contains information to be provided to IANA for the registration of the media plane security indicator header field parameter.

Contact name, email address, and telephone number:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

Header field in which the parameter can appear:

Security-Client, Security-Server and Security-Verify header fields.

Name of the header field parameter being registered:

mediasec

Whether the parameter only accepts a set of predefined values:

No value is defined for the parameter.

A reference to the RFC where the parameter is defined and to any RFC that defines new values for the parameter:

This parameter is defined in 3GPP TS 24.229.

7.2A.7.4.2 "sdes-srtp" security mechanism

Editor’s note: [MEDIASEC_CORE, CR 4156] This subclause forms the basis for IANA registration of the value for the mediasec header field parameter. The registration should be performed by MCC when the registry for mediasec parameter values has been created by IANA.

NOTE: This subclause contains information to be provided to IANA for the registration of the media plane security indicator header field parameter.

Contact name, email address, and telephone number:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

The mechanism-name token:

sdes-srtp

The published RFC describing the details of the corresponding security mechanism:

This mechanism is defined in 3GPP TS 24.229.

7.2A.7.4.3 "msrp-tls" security mechanism

Editor’s note: [WI: eMEDIASEC-CT, CR#4624] This subclause forms the basis for IANA registration of the value for the mediasec header field parameter. The registration should be performed by MCC when the registry for mediasec parameter values has been created by IANA.

NOTE: This subclause contains information to be provided to IANA for the registration of the media plane security indicator header field parameter.

Contact name, email address, and telephone number:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

The mechanism-name token:

msrp-tls

The published RFC describing the details of the corresponding security mechanism:

This mechanism is defined in 3GPP TS 24.229.

7.2A.7.4.4 "bfcp-tls" security mechanism

NOTE: This subclause contains information to be provided to IANA for the registration of the media plane security indicator header field parameter.

Contact name, email address, and telephone number:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

The mechanism-name token:

bfcp-tls

The published RFC describing the details of the corresponding security mechanism:

This mechanism is defined in 3GPP TS 24.229.

7.2A.7.4.5 "udptl-dtls" security mechanism

NOTE: This subclause contains information to be provided to IANA for the registration of the media plane security indicator header field parameter.

Contact name, email address, and telephone number:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

The mechanism-name token:

udptl-dtls

The published RFC describing the details of the corresponding security mechanism:

This mechanism is defined in 3GPP TS 24.229.

7.2A.7.4.6 " dtls-srtp" security mechanism

Editor’s note: [WI: eCryptPr, CR#6554] This subclause forms the basis for IANA registration of the value for the mediasec header field parameter. The registration should be performed by MCC when the registry for mediasec parameter values has been created by IANA.

NOTE: This subclause contains information to be provided to IANA for the registration of the media plane security indicator header field parameter.

Contact name, email address, and telephone number:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

The mechanism-name token:

dtls-srtp

The published RFC describing the details of the corresponding security mechanism:

This mechanism is defined in 3GPP TS 24.229.

7.2A.8 IMS Communication Service Identifier (ICSI)

7.2A.8.1 Introduction

The ICSI is defined to fulfil the requirements as stated in 3GPP TS 23.228 [7]. An ICSI may have specialisations which refine it by adding subclass identifiers separated by dots. Any specialisations of an ICSI shall have an "is a" relationship if the subclasses are removed. For example, a check for ICSI urn:urn-7:3gpp-service.ims.icsi.mmtel will return true when evaluating ICSI urn:urn-7:3gpp-service.ims.icsi.mmtel.hd-video.

7.2A.8.2 Coding of the ICSI

This parameter is coded as a URN. The ICSI URN may be included as:

– a tag-value within the g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 [62], in which case those characters of the URN that are not part of the tag-value definition in RFC 3840 [62] shall be represented in the percent encoding as defined in RFC 3986 [124];

– a feature cap value within the "g.3gpp.icsi-ref" feature-capability indicator, as defined in subclause 7.9A.1 and RFC 6809 [190], in which case those characters of the URN that are not part of the feature-capability indicator value definition syntax shall be represented in the percent encoding, as defined in RFC 3986 [124]; or

– as a value of the P-Preferred-Service or P-Asserted-Service header fields as defined RFC 6050 [121].

A list of the URNs containing ICSI values registered by 3GPP can be found at http://www.3gpp.org/specifications-groups/34-uniform-resource-name-urn-list

An example of an ICSI for a 3GPP defined IMS communication service is:

urn:urn-7:3gpp-service.ims.icsi.mmtel

An example of a g.3gpp.icsi-ref media feature tag containing an ICSI for a 3GPP defined IMS communication service is:

g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

An example of a g.3gpp.icsi-ref feature-capability indicator containing an ICSI for a 3GPP defined IMS communication service is:

g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

An example of an ICSI for a 3GPP defined IMS communication service in a P-Preferred-Service header field is

P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

An example of an ICSI for a 3GPP defined IMS communication service in a P-Asserted-Service header field is

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

An example of an ICSI for a defined IMS communication service with a specialisation is:

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel.game-v1

An example of an ICSI for a 3GPP defined IMS communication service with an organisation-y defined specialisation is:

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel.organisation-y.game-v2

7.2A.9 IMS Application Reference Identifier (IARI)

7.2A.9.1 Introduction

The IARI is defined to fulfil the requirements as stated in 3GPP TS 23.228 [7].

7.2A.9.2 Coding of the IARI

This parameter is coded as a URN. The IARI URN may be included as a tag-value within the g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62], in which case those characters of the URN that are not part of the tag-value definition in RFC 3840 [62] shall be represented in the percent encoding as defined in RFC 3986 [124].

A list of the URNs containing IARI values registered by 3GPP can be found at http://www.3gpp.org/specifications-groups/34-uniform-resource-name-urn-list

An example of a g.3gpp.iari-ref media feature tag containing an IARI is:

g.3gpp.iari-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.game-v1"

7.2A.10 "phone-context" tel URI parameter

7.2A.10.1 Introduction

When the request-URI contains a local number, then a phone-context tel URI parameter as described in RFC 3966 [22] shall be present to indicate the related numbering plan.

Procedures for using this parameter are given in subclause 5.1.2A.1.5 and additional coding rules are detailed in subclause 7.2A.10.3.

7.2A.10.2 Syntax

The syntax of the "phone-context" tel URI parameter is described in RFC 3966 [22]. There are additional coding rules for this parameter depending on the type of IP-CAN, according to access technology specific descriptions.

7.2A.10.3 Additional coding rules for "phone-context" tel URI parameter

In case the access network information is available, the entities inserting the "phone-context" tel URI parameter shall populate the "phone-context" tel URI parameter with the following contents:

1) if the IP-CAN is GPRS, then the "phone-context" tel URI parameter is a domain name. It is constructed from the MCC, the MNC and the home network domain name by concatenating the MCC, MNC, and the string "gprs" as domain labels before the home network domain name;

EXAMPLE: If MCC = 216, MNC = 01, then the "phone-context" tel URI parameter is set to ‘216.01.gprs.home1.net’.

2) if the IP-CAN is Evolved Packet Core (EPC) via WLAN or 5GCN via WLAN, then the "phone-context" tel URI parameter is a domain name.

a) if all characters of the SSID are allowed by domainlabel syntax definition of clause 3 of RFC 3966 [22], the domain name is constructed from the SSID, AP’s MAC address, and the home network domain name by concatenating the SSID, AP’s MAC address, and the string "i-wlan" as domain labels before the home network domain name; and

b) otherwise, the domain name is constructed from AP’s MAC address, and the home network domain name by concatenating AP’s MAC address, and the string "i-wlan" as domain labels before the home network domain name.

NOTE: The AP’s MAC address is provided in the BSSID information element.

EXAMPLE: If SSID = BU-Airport, AP’s MAC = 00-0C-F1-12-60-28, and home network domain name is "home1.net", then the "phone-context" tel URI parameter is set to the string "bu-airport.000cf1126028.i-wlan.home1.net".

EXAMPLE: If SSID = <BU Airport>, AP’s MAC = 00-0C-F1-12-60-28, and home network domain name is "home1.net", then the "phone-context" tel URI parameter is set to the string "000cf1126028.i-wlan.home1.net".

3) if the IP-CAN is xDSL, then the "phone-context" tel URI parameter is a domain name. It is constructed from the dsl-location (see subclause 7.2A.4) and the home network domain name by concatenating the dsl-location and the string "xdsl" as domain labels before the home network domain name;

4) if the IP-CAN is DOCSIS, then the "phone-context" tel URI parameter is based on data configured locally in the UE;

5) if the IP-CAN is EPS, then the "phone-context" tel URI parameter is a domain name. It is constructed from the MCC, the MNC and the home network domain name by concatenating the MCC, MNC, and the string "eps" as domain labels before the home network domain name;

6) if the IP-CAN is Ethernet, then the "phone-context" parameter is a domain name. It is constructed from the eth-location (see subclause 7.2A.4) and the home network domain name by concatenating the eth-location and the string "ethernet" as domain labels before the home network domain name;

7) if the IP-CAN is Fiber, then the "phone-context" parameter is a domain name. It is constructed from the fiber-location (see subclause 7.2A.4) and the home network domain name by concatenating the fiber-location and the string "fiber" as domain labels before the home network domain name;

8) if the IP-CAN is cdma2000®, then the "phone-context" parameter is a domain name. It is constructed from the subnet id and the home network domain name by concatenating the subnet id as the domain label before the home network domain name;

9) if the IP-CAN is DVB-RCS2, then the "phone-context" tel URI parameter is based on data configured locally in the UE;

10) if the IP-CAN is 5GS via 3GPP access and the serving network is a PLMN, then the "phone-context" tel URI parameter is a domain name. It is constructed from the MCC, the MNC and the home network domain name by concatenating the MCC, MNC, and the string "5gs" as domain labels before the home network domain name; and

11) if the IP-CAN is 5GS via 3GPP access and the serving network is an SNPN, then the "phone-context" tel URI parameter is a domain name. It is constructed from the MCC, the MNC, the NID and the home network domain name by concatenating the MCC, MNC, the SNPN Network Identifier (NID) (11 hexadecimal digits) as specified in 3GPP TS 23.003 [3] and the string "5gs-snpn" as domain labels before the home network domain name.

If the access network information is not available in the UE, then the "phone-context" tel URI parameter is set to the home network domain name preceded by the string "geo-local.".

In case the home domain is indicated in the "phone-context" tel URI parameter, the "phone-context" tel URI parameter is set to the home network domain name (as it is used to address the SIP REGISTER request, see subclause 5.1.1.1A or subclause 5.1.1.1B).

In case the "phone-context" tel URI parameter indicates a network other than the home network or the visited access network, the "phone-context" tel URI parameter is set according to RFC 3966 [22].

7.2A.11 Void

7.2A.11.1 Void

7.2A.11.2 Void

7.2A.11.3 Void

7.2A.12 CPC and OLI tel URI parameter definition

7.2A.12.1 Introduction

The use of the "cpc" and "oli" URI parameters for use in the P-Asserted-Identity in SIP requests is defined.

7.2A.12.2 Syntax

The Calling Party’s Category and Originating Line Information are represented as URI parameters for the tel URI scheme and SIP URI representation of telephone numbers. The ABNF syntax is specified in table 7.2A.7 and extends the formal syntax for the tel URI as specified in RFC 3966 [22]:

Table 7.2A.7

par =/ cpc / oli

cpc = cpc-tag "=" cpc-value

oli = oli-tag "=" oli-value

cpc-tag = "cpc"

oli-tag = "oli"

cpc-value

= "ordinary" / "test" / "operator" /

"payphone" / "unknown" / "mobile-hplmn" / "mobile-vplmn" / "emergency" /

genvalue

oli-value = 2DIGIT

genvalue = 1*(alphanum / "-" / "." )

The Accept-Language header field shall be used to express the language of the operator.

The semantics of these Calling Party’s Category values are described below:

ordinary: The caller has been identified, and has no special features.

test: This is a test call that has been originated as part of a maintenance procedure.

operator: The call was generated by an operator position.

payphone: The calling station is a payphone.

unknown: The CPC could not be ascertained.

mobile-hplmn: The call was generated by a mobile device in its home PLMN.

mobile-vplmn: The call was generated by a mobile device in a vistited PLMN.

emergency: The call is an emergency service call.

NOTE 1: The choice of CPC and OLI values and their use are up to the Service Provider. CPC and OLI values can be exchanged across networks if specified in a bilateral agreement between the service providers.

NOTE 2: Additional national/regional CPC values can exist.

The two digit OLI values are decimal codes assigned and administered by North American Numbering Plan Administration.

7.2A.12.3 Operation

The "cpc" and "oli" URI parameters may be supported by IM CN subsystem entities that provide the UA role and by IM CN subsystem entities that provide the proxy role.

The "cpc" and "oli" URI parameters shall not be populated at the originating UE.

In case the "cpc" URI parameter is not included, the call is treated as if the "cpc" URI parameter is set to "ordinary".

Unless otherwise specified in this document, "cpc" and "oli" URI parameters are only passed on by IM CN subsystem entities (subject to trust domain considerations as specified in subclause 4.4.12).

7.2A.13 "sos" SIP URI parameter

7.2A.13.1 Introduction

The "sos" SIP URI parameter is intended to:

– indicate to the S-CSCF that a REGISTER request that includes the "sos" SIP URI parameter is for emergency registration purposes;

– tell the S-CSCF to not apply barring of the public user identity being registered; and

– tell the S-CSCF to not apply initial filter criteria to requests destined for an emergency registered contact.

7.2A.13.2 Syntax

The syntax for the "sos" SIP URI parameter is specified in table 7.2A.8.

Table 7.2A.8: Syntax of sos SIP URI parameter

uri-parameter =/ sos-param

sos-param = "sos"

The BNF for uri-parameter is taken from RFC 3261 [26] and modified accordingly.

7.2A.13.3 Operation

When a UE includes the "sos" SIP URI parameter in the URI included in the Contact header field of REGISTER request, the REGISTER request is intended for emergency registration.

When a S-CSCF receives a REGISTER request for emergency registration that includes the "sos" SIP URI parameter, the S-CSCF is required to preserve the previously registered contact address. This differs to the registrar operation as defined in RFC 3261 [26] in that the rules for URI comparison for the Contact header field shall not apply and thus, if the URI in the Contact header field matches a previously received URI, then the old contact address shall not be overwritten.

7.2A.14 P-Associated-URI header field

Procedures of RFC 7315 [52] are modified to allow a SIP proxy to remove URIs from the P-Associated-URI header field.

7.2A.15 Void

7.2A.16 Void

7.2A.16.1 Void

7.2A.16.2 Void

7.2A.16.3 Void

7.2A.17 "premium-rate" tel URI parameter definition

7.2A.17.1 Introduction

The use of the "premium-rate" URI parameters for use in the Request-URI in SIP requests is defined.

7.2A.17.2 Syntax

The premium-rate category that a called number belongs to is represented as a URI parameter for the tel URI scheme and SIP URI representation of telephone numbers. The ABNF syntax is as specified in Table 7.2A.17 and extends the formal syntax for the tel URI as specified in RFC 3966 [22]:

Table 7.2A.17

par =/ premrate

premrate = premrate-tag "=" premrate-value

premrate-tag = "premium-rate"

premrate-value = "information" / "entertainment"

7.2A.17.3 Operation

The "premium-rate" URI parameter may be supported by IM CN subsystem entities that provide the AS role and by IM CN subsystem entities that provide the proxy role.

7.2A.17.4 IANA registration

NOTE: This subclause contains information to be provided to IANA for the registration of the tel-URI parameter "premium-rate".

This parameter needs to be defined in the sub-registry under the tel URI parameters.

Contact name, email address, and telephone number:

3GPP Specifications Manager:

3gppContact@etsi.org

+33 (0)492944200

Name of the parameter:

"premium-rate"

Whether the parameter only accepts a set of predefined values:

"Constrained"

Reference to the RFC or other permanent and readily available public specification defining the parameter and new values:

This parameter and its values are defined in 3GPP TS 24.229.

Description:

This tel URI parameter is used in networks supporting roaming and operator determined barring feature. The tel URI parameter provides a means to identify that a number in a tel URI belongs to a premium rate category in the roaming network. SIP servers in the home network use this information to apply the operator determined barring functionality. An overview of the 3GPP IM CN subsystem can be found in RFC 4083.

7.2A.18 Reason header field

7.2A.18.1 Introduction

The Reason header field is extended to include the additional protocol values.

Editor’s note [CR#6558, WI TEI17]: Subclauses 7.2A.18.11, 7.2A.18.12, 7.2A.18.13, 7.2A.18.14, 7.2A.18.15, 7.2A.18.16, and 7.2A.18.17 form the basis for IANA registration of new protocol values. The registration should be performed once Rel-17 is complete.

7.2A.18.2 Syntax

The syntax of the Reason header field is described in RFC 3326 [34A].

Table 7.2A.18 describes 3GPP-specific extension to the Reason header field.

Table 7.2A.18: Syntax of extension to Reason header field

protocol /= "EMM" / "ESM" / "S1AP-RNL" / "S1AP-TL" / "S1AP-NAS" / "S1AP-MISC" /

"S1AP-PROT" / "DIAMETER" / "IKEV2" / "RELEASE_CAUSE" / "FAILURE_CAUSE" /

"5GMM" / "5GSM" / "NGAP-RNL" / "NGAP-TL" / "NGAP-NAS" / "NGAP-MISC" /

"NGAP-PROT"

For all the above protocols, the protocol cause is included.

7.2A.18.3 IANA registration of EMM protocol value

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters.

Protocol value: EMM

Protocol cause: Cause value in decimal representation (Note)

Reference: 3GPP TS 24.301 [8J] subclause 9.9.3.9

NOTE: This protocol value can also be used to represent MM cause from 3GPP TS 24.008 [8].

Contact:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

7.2A.18.4 IANA registration of ESM protocol value

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters.

Protocol value: ESM

Protocol cause: Cause value in decimal representation (Note)

Reference: 3GPP TS 24.301 [8J] subclause 9.9.4.4

NOTE: This protocol value can also be used to represent SM cause from 3GPP TS 24.008 [8].

Contact:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

7.2A.18.5 IANA registration of S1AP radio network layer protocol value

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters.

Protocol value: S1AP-RNL

Protocol cause: Radio network layer cause value in decimal representation

Reference: 3GPP TS 36.413

Contact:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

7.2A.18.6 IANA registration of S1AP transport layer protocol value

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters.

Protocol value: S1AP-TL

Protocol cause: Radio network layer cause value in decimal representation

Reference: 3GPP TS 36.413

Contact:

7.2A.18.11.1 Introduction

This subclause defines an extension to the SIP Reason header field enabling the UE to define release cause events. In a network it is useful for the UE to specify a release cause when sending a BYE request or a CANCEL request. This release cause is for information purpose and can be useful for the remote UE to display to the user. For a network explicit release causes makes it possible to distinguish reasons for releasing a call. The network can then log error cases more accurate.

7.2A.18.11.2 IANA considerations

This document adds to the existing IANA registry for the SIP Reason header field the following protocol value and protocol cause:

Table 7.2A.18.11-1: Addition to the IANA Registry for the SIP Reason header field

Protocol value	Protocol cause	Reference
RELEASE_CAUSE	Cause value in decimal	3GPP TS 24.229

This document adds to the existing IANA registry for SIP Reason header Reason-text strings associated with their respective protocol type and Reason- param cause values:

Table 7.2A.18.11-2: Cause values and Reason-text strings for the RELEASE_CAUSE protocol value

Protocol value	Cause value	Reason-text
RELEASE_CAUSE	1	User ends call
RELEASE_CAUSE	2	RTP/RTCP time-out
RELEASE_CAUSE	3	Media bearer loss
RELEASE_CAUSE	4	SIP timeout – no ACK
RELEASE_CAUSE	5	SIP response time-out
RELEASE_CAUSE	6	Call-setup time-out
RELEASE_CAUSE	7	Redirection failure

Editor’s Note: IANA registry needs to be updated to include "7" as a new cause value.

7.2A.18.12 IANA registration of FAILURE_CAUSE protocol value

7.2A.18.12.1 Introduction

This subclause defines an extension to the SIP Reason header field to indroduce a new protocol enabling the IMS network entities to define failure cause events. This new indication is intended to be included in SIP error responses with the appropriate cause value and reason text to provide a complementatry indication on the original reason for which this error response has been sent.

7.2A.18.12.2 IANA considerations

This document adds to the existing IANA registry for the SIP Reason header field the following protocol value and protocol cause:

Table 7.2A.18.12-1: Addition to the IANA Registry for the SIP Reason header field

Protocol value	Protocol cause	Reference
FAILURE_CAUSE	Cause value in decimal	3GPP TS 24.229

This document adds to the existing IANA registry for SIP Reason header field the new "FAILURE_CAUSE" protocol parameter value associated with their respective protocol-cause values and reason-text strings:

Table 7.2A.18.12-2: Cause values and Reason-text strings for the FAILURE_CAUSE protocol value

Cause value	Reason-text
1	Media bearer or QoS lost
2	Release of signalling bearer
3	Indication of failed resources allocation

7.2A.19 Thig-path

7.2A.19.1 Introduction

The thig-path header field parameter is defined to enable the P-CSCF which is located in the visited network to subscribe to user’s registration-state event package if topology hiding is done on the Path header field.

7.2A.19.2 Coding of the thig-path

The thig-path header field parameter is coded as a URI. The thig-path URI is a SIP URI of the visited network IBCF which applied topology hiding on the Path header field contained in the REGISTER request. The thig-path URI may be included as:

– a fcap-string-value within the "g.3gpp.thig-path" feature-capability indicator, as defined in subclause 7.9A.9 and RFC 6809 [190]; or

– as a value of the P-Asserted-Identity header field.

An example of a g.3gpp.thig-path feature-capability indicator containing thig-path URI is:

+g.3gpp.thig-path = "<sip:visit-abc@ibcf-vA1.visited-A.net:5070;lr>"

An example of a thig-path URI in a P-Asserted-Identity header field is:

P-Asserted-Identity: <sip:visit-abc@ibcf-vA1.visited-A.net:5070;lr>

7.2A.20 "verstat" tel URI parameter definition

7.2A.20.1 Introduction

This extension defines the "verstat" tel URI parameter used in the P-Asserted-Identity and the From header fields in a SIP request.

7.2A.20.2 Syntax

The status of the calling number verification performed by the home network is represented as a URI parameter for the tel URI scheme and SIP URI representation of telephone numbers. The ABNF syntax is as specified in Table 7.2A.20.2-1 and extends the formal syntax for the tel URI as specified in RFC 3966 [22]:

Table 7.2A.20.2-1

par =/ verstat

verstat = verstat-tag "=" verstat-value

verstat-tag = "verstat"

verstat-value = "TN-Validation-Passed" / "TN-Validation-Failed" / "No-TN-Validation" / other-value
other-value = token

7.2A.20.3 Operation

The "verstat" tel URI parameter may be supported by IM CN subsystem entities that provide the AS role and by IM CN subsystem entities that provide the proxy role.

The "verstat" tel URI parameter is inserted by an AS or a proxy in the IM CN subsystem to provide the UE with the calling identity number verification status in an initial INVITE request or when a standalone message is delivered.

Table 7.2A.20.3-1 shows the "verstat" parameter values that are currently defined:

Table 7.2A.20.3-1: Verstat values

Tel URI parameter value	Description
TN-Validation-Passed	The number passed the validation.
TN-Validation-Failed	The number failed the validation.
No-TN-Validation	No number validation was performed.

NOTE: There is no default value for the "verstat" parameter. If new values are defined, specifications need to describe the appropriate procedure if an endpoint receives a parameter value that it does not support.

7.2A.20.4 IANA registration

NOTE: This subclause contains information to be provided to IANA for the registration of the tel URI parameter "verstat".

This parameter needs to be defined in the sub-registry under the tel URI parameters.

Contact name, email address, and telephone number:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

Name of the parameter

"verstat"

Whether the parameter only accepts a set of predefined values

Constrained

Reference to the RFC or other permanent and readily available public specification defining the parameter and new values

This parameter and its values are defined in 3GPP TS 24.229.

Description:

This tel URI parameter is used in networks supporting calling number verification, as described in RFC 8224. The tel URI parameter provides a means to identify that a number in a tel URI or a SIP URI with the user=phone parameter has been verified (verification passed or failed) or to identify that verification was not performed for the number. SIP user agents can use this information to apply functionality based on the verification status. An overview of the 3GPP IM CN subsystem can be found in 3GPP TS 23.228 and 3GPP TS 24.229.

7.2A.21 Extension to "isub-encoding" tel URI parameter

7.2A.21.1 Introduction

This extension defines a new value "user-specified" for the "isub-encoding" tel URI parameter.

7.2A.21.2 Syntax

The syntax for the "isub-encoding" tel URI parameter is defined in IETF RFC 4715 [259].

This specification reuses the "isub-encoding" tel URI parameter and defines the new value "user-specified" as listed in table 7.2A.21.2-1.

Table 7.2A.21.2-1: Syntax of extension of "isub-encoding" tel URI parameter

isub-encoding-value =/ "user-specified"

The semantics of this "isub-encoding" value are described below:

user-specified: Indication that the "isub" parameter value needs to be encoded using a user-specified encoding type.

7.2A.21.3 IANA registration of "user-specified" tel URI parameter value

Editor’s Note [IMSProtoc9 CR#6056]: This extension requires an expert’s review to be IANA registered. The IANA registration shall be initiated when release 15 is closed.

7.2A.21.3.1 Introduction

This subclause defines an extension to the SIP "isub-encoding" tel URI parameter to introduce a new value "user-specified" enabling the IMS network entities to identify that the "isub" tel URI parameter has been encoded using a user specified format.

7.2A.21.3.2 IANA considerations

This document adds to the existing IANA registry for the SIP "isub-encoding" tel URI parameter the following value:

Table 7.2A.21.3.2-1: Addition to the IANA Registry for the "isub-encoding" SIP tel URI parameter

tel URI parameter	tel URI parameter value	Reference
isub-encoding	user-specified	3GPP TS 24.229

Contact:

3GPP Specifications Manager

3gppContact@etsi.org

+33 (0)492944200

7.2A.22 scscf-reselection parameter definition

7.2A.22.1 Introduction

The "scscf-reselection" parameter is a SIP URI parameter intended to:

– inform the S-CSCF it has been reselected due to failure of the previously assigned S-CSCF.

7.2A.22.2 Syntax

The syntax for the scscf-reselection parameter is specified in table 7.2A.22.2-1:

Table 7.2A.22.2-1: Syntax of scscf-reselection parameter

uri-parameter =/ scscf-reselection

scscf-reselection = "scscf-reselection"

The BNF for uri-parameter is taken from RFC 3261 [26] and extended accordingly.

7.2A.22.3 Operation

The "scscf-reselection" parameter is appended to the address of the S-CSCF by the I-CSCF, upon failed communication with the currently assigned S-CSCF. The S-CSCF receiving this parameter includes the S-CSCF reselection indicator set to "true" in the S-CSCF Registration procedure with the HSS, as described in 3GPP TS 29.562 [274], so the change of S-CSCF is accepted by the HSS.

7.2A.1 Extension to WWW-Authenticate header field

7.2A.1.1 Introduction

7.2A.1.2 Syntax

7.2A.1.3 Operation

7.2A.2 Extension to Authorization header field

7.2A.2.1 Introduction

7.2A.2.2 Syntax

7.2A.2.2.1 integrity-protected

7.2A.2.3 Operation

7.2A.3 Tokenized-by header field parameter definition (various header fields)

7.2A.3.1 Introduction

7.2A.3.2 Syntax

7.2A.3.3 Operation

7.2A.4 P-Access-Network-Info header field

7.2A.4.1 Introduction

7.2A.4.2 Syntax

7.2A.4.3 Additional coding rules for P-Access-Network-Info header field

7.2A.5 P-Charging-Vector header field

7.2A.5.1 Introduction

7.2A.5.2 Syntax

7.2A.5.2.1 General

7.2A.5.2.2 GPRS as IP-CAN

7.2A.5.2.3 Evolved Packet Core (EPC) via WLAN as IP-CAN

7.2A.5.2.4 xDSL as IP-CAN

7.2A.5.2.5 DOCSIS as IP-CAN

7.2A.5.2.6 cdma2000® packet data subsystem as IP-CAN

7.2A.5.2.7 EPS as IP-CAN

7.2A.5.2.8 Ethernet as IP-CAN

7.2A.5.2.9 Fiber as IP-CAN

7.2A.5.2.10 5GS as IP-CAN

7.2A.5.3 Operation

7.2A.6 Orig parameter definition

7.2A.6.1 Introduction

7.2A.6.2 Syntax

7.2A.6.3 Operation

7.2A.7 Extension to Security-Client, Security-Server and Security-Verify header fields

7.2A.7.1 Introduction

7.2A.7.2 Syntax

7.2A.7.2.1 General

7.2A.7.2.2 "mediasec" header field parameter

7.2A.7.3 Operation

7.2A.7.4 IANA registration

7.2A.7.4.1 "mediasec" header field parameter

7.2A.7.4.2 "sdes-srtp" security mechanism

7.2A.7.4.3 "msrp-tls" security mechanism

7.2A.7.4.4 "bfcp-tls" security mechanism

7.2A.7.4.5 "udptl-dtls" security mechanism

7.2A.7.4.6 " dtls-srtp" security mechanism

7.2A.8 IMS Communication Service Identifier (ICSI)

7.2A.8.1 Introduction

7.2A.8.2 Coding of the ICSI

7.2A.9 IMS Application Reference Identifier (IARI)

7.2A.9.1 Introduction

7.2A.9.2 Coding of the IARI

7.2A.10 "phone-context" tel URI parameter

7.2A.10.1 Introduction

7.2A.10.2 Syntax

7.2A.10.3 Additional coding rules for "phone-context" tel URI parameter

7.2A.11 Void

7.2A.11.1 Void

7.2A.11.2 Void

7.2A.11.3 Void

7.2A.12 CPC and OLI tel URI parameter definition

7.2A.12.1 Introduction

7.2A.12.2 Syntax

7.2A.12.3 Operation

7.2A.13 "sos" SIP URI parameter

7.2A.13.1 Introduction

7.2A.13.2 Syntax

7.2A.13.3 Operation

7.2A.14 P-Associated-URI header field

7.2A.15 Void

7.2A.16 Void

7.2A.16.1 Void

7.2A.16.2 Void

7.2A.16.3 Void

7.2A.17 "premium-rate" tel URI parameter definition

7.2A.17.1 Introduction

7.2A.17.2 Syntax

7.2A.17.3 Operation

7.2A.5.2.6 cdma2000^® packet data subsystem as IP-CAN