Content for  TS 24.229  Word version:  19.4.1

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.

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

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 and modified accordingly.

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).

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.

mech-parameters =/ mediasec-param
mediasec-param = "mediasec"

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.

The operation of the additional parameters for the Security-Client, Security-Server and Security-Verify header fields is defined in Annex H of TS 33.203. 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, but in order to protect any cryptographic key carried in SDP signalling plane security as defined in RFC 3329 SHOULD be used. Each media security mechanism can be supported independently. The message flow is identical to the flow in RFC 3329, 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.

The ICSI is defined to fulfil the requirements as stated in TS 23.228. 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.

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, in which case those characters of the URN that are not part of the tag-value definition in RFC 3840 shall be represented in the percent encoding as defined in RFC 3986;
• a feature cap value within the "g.3gpp.icsi-ref" feature-capability indicator, as defined in subclause 7.9A.1 and RFC 6809, 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; or
• as a value of the P-Preferred-Service or P-Asserted-Service header fields as defined RFC 6050.

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

The IARI is defined to fulfil the requirements as stated in TS 23.228.

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, in which case those characters of the URN that are not part of the tag-value definition in RFC 3840 shall be represented in the percent encoding as defined in RFC 3986. 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:

When the request-URI contains a local number, then a phone-context tel URI parameter as described in RFC 3966 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.

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

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.
   1. if all characters of the SSID are allowed by domainlabel syntax definition of Section 3 of RFC 3966, 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
   2. 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.
   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 TS 23.003 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.

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

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:

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: test: operator: payphone: unknown: mobile-hplmn: mobile-vplmn: emergency: The two digit OLI values are decimal codes assigned and administered by North American Numbering Plan Administration.

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).

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.

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

uri-parameter =/ sos-param
sos-param = "sos"

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

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 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.

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

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:

par =/ premrate
premrate = premrate-tag "=" premrate-value 
premrate-tag = "premium-rate" 
premrate-value = "information" / "entertainment"

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.

This parameter needs to be defined in the sub-registry under the tel URI parameters. Contact name, email address, and telephone number: Name of the parameter: Whether the parameter only accepts a set of predefined values: Reference to the RFC or other permanent and readily available public specification defining the parameter and new values: Description:

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

The syntax of the Reason header field is described in RFC 3326. Table 7.2A.18 describes 3GPP-specific extension to the 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.

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

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

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

The following entry is added to the Reason Protocols table within the Session Initiation Protocol (SIP) Parameters. Protocol value: Protocol cause: Reference: Contact:

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.

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; 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>

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

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:

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

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:

This parameter needs to be defined in the sub-registry under the tel URI parameters. Contact name, email address, and telephone number: Name of the parameter Whether the parameter only accepts a set of predefined values Reference to the RFC or other permanent and readily available public specification defining the parameter and new values Description:

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

The syntax for the "isub-encoding" tel URI parameter is defined in RFC 4715. 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.

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

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

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.

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

uri-parameter =/ scscf-reselection
scscf-reselection = "scscf-reselection"

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

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 TS 29.562, so the change of S-CSCF is accepted by the HSS.

This extension defines the "rcd-np" parameter used in the Call-Info header field in a SIP request.

The status of the RCD verification performed by the home network is represented as the "rcd-np" parameter. The ABNF syntax is as specified in Table 7.2A.23.2-1 and extends the formal syntax for the Call-Info header field as specified in RFC 3261 and RFC 9796:

info-param       =/ rcd-np-param
rcd-np-param         = "rcd-np"

The Call-Info header field parameter "rcd-np" may be supported by IM CN subsystem entities that provide the AS role and by IM CN subsystem entities that provide the IBCF role and acting as an exit point. The "rcd-np" parameter is inserted by the AS in the Call-Info header field of an initial INVITE request or standalone MESSAGE request and indicates that the RCD information contained in that Call-Info header field has been verified by the home network. The "rcd-np" parameter is removed from the Call-Info header field by the IBCF acting as an exit point.

The "rcd-np" parameter needs to be defined in the sub-registry under the Header Field Parameters and Parameter Values. This parameter is the Call-Info header field parameter. Contact name, email address, and telephone number: Name of the parameter Whether the parameter only accepts a set of predefined values Reference to the RFC or other permanent and readily available public specification defining the parameter and new values Description: