Content for TS 24.229 Word version: 17.1.0

1… 3… 4… 4.5… 5… 5.1.1.4… 5.1.2… 5.1.4… 5.2… 5.2.3… 5.2.6… 5.2.7… 5.3… 5.4… 5.4.1.2.2… 5.4.1.3… 5.4.2 5.4.3… 5.4.3.3… 5.4.4… 5.5… 5.7… 5.7.2… 5.8… 5.11… 6… 6.6… 7… 7.2A… 7.2A.6… 7.3… 7.9A… 8… A… B… C… E… F… H… I… K… L… L.2A… M… N… O… Q… R… S… U… U.2A… V… W…

7.2A.6 Orig parameter definition 7.2A.7 Extension to Security-Client, Security-Server and Security-Verify header fields 7.2A.8 IMS Communication Service Identifier (ICSI) 7.2A.9 IMS Application Reference Identifier (IARI) 7.2A.10 "phone-context" tel URI parameter 7.2A.12 CPC and OLI tel URI parameter definition 7.2A.13 "sos" SIP URI parameter 7.2A.14 P-Associated-URI header field 7.2A.17 "premium-rate" tel URI parameter definition 7.2A.18 Reason header field 7.2A.19 Thig-path 7.2A.20 "verstat" tel URI parameter definition 7.2A.21 Extension to "isub-encoding" tel URI parameter
...

7.2A.6 Orig parameter definition |R6|

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

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

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

This specification reuses Security-Client, Security-Server and Security-Verify defined in RFC 3329 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 |R9| Word‑p. 431

The "mediasec" header field parameter may be used in the Security- Client, Security-Server, or Security-Verify header fields defined in RFC 3329 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 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 / 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.

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

7.2A.7.4 IANA registration |R9| Word‑p. 432

7.2A.7.4.1 "mediasec" 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

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

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 |R12| Word‑p. 433

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

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.8 IMS Communication Service Identifier (ICSI) |R7| Word‑p. 434

7.2A.8.1 Introduction

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.

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

7.2A.9 IMS Application Reference Identifier (IARI) |R7|

7.2A.9.1 Introduction

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

7.2A.9.2 Coding of the IARI Word‑p. 435

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:

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

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

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

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'.
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 clause 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.
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".
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;
if the IP-CAN is DOCSIS, then the "phone-context" tel URI parameter is based on data configured locally in the UE;
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;
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;
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;
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;
if the IP-CAN is DVB-RCS2, then the "phone-context" tel URI parameter is based on data configured locally in the UE; and
if the IP-CAN is 5GS via 3GPP access, 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.

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.

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 |R7| Word‑p. 436

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:

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.

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

7.2A.12.3 Operation Word‑p. 437

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

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 Word‑p. 438

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

Procedures of RFC 7315 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 |R12|

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:

Table 7.2A.17

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

7.2A.17.3 Operation Word‑p. 439

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

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

7.2A.18.1 Introduction

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

7.2A.18.2 Syntax

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.

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"

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

7.2A.18.3 IANA registration of EMM protocol value Word‑p. 440

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, subclause 9.9.3.9

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, subclause 9.9.4.4

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

User ends call

RELEASE_CAUSE

RTP/RTCP time-out

RELEASE_CAUSE

Media bearer loss

RELEASE_CAUSE

SIP timeout - no ACK

RELEASE_CAUSE

SIP response time-out

RELEASE_CAUSE

Call-setup time-out

RELEASE_CAUSE

Redirection failure

7.2A.18.12 IANA registration of FAILURE_CAUSE protocol value |R14| Word‑p. 443

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

7.2A.19 Thig-path |R13|

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; 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 |R14| Word‑p. 444

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:

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.

7.2A.20.4 IANA registration

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 TS 23.228 and 3GPP TS 24.229.

7.2A.21 Extension to "isub-encoding" tel URI parameter |R15| Word‑p. 445

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

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.

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