Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  19.0.0

Top   Top   Up   Prev   Next
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…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

7.3  Option-tags defined within the present documentp. 465

There are no option-tags defined within the present document over and above those defined in the referenced IETF specifications.

7.4  Status-codes defined within the present documentp. 465

There are no status-codes defined within the present document over and above those defined in the referenced IETF specifications.

7.5  Session description types defined within the present documentp. 466

7.5.1  General |R9|p. 466

This subclause contains definitions for SDP parameters that are specific to SDP usage in the 3GPP IM CN Subsystem and therefore are not described in an RFC.

7.5.2  End-to-access-edge media plane security |R9|p. 466

7.5.2.1  Generalp. 466

The end-to-access-edge media security-indicator is used to indicate that a UE requests a P-CSCF to apply media plane security or to indicate that a P-CSCF has applied end-to-access-edge media security as defined in TS 33.328.

7.5.2.2  Syntaxp. 466

3GPP end-to-access-edge media security indicator is a value attribute which is encoded as a media-level SDP attribute with the ABNF syntax defined in Table 7.5.1. ABNF is defined in RFC 2234.
"requested":
the sender indicates its wish that end-to-access-edge media security is applied.
"applied":
the sender indicates that it has applied end-to-access-edge media security.
This version of the specification only defines usage of the "requested" and "applied" attribute values. Other values shall be ignored.
The "3ge2ae" attribute is charset-independent.
Up

7.5.2.3  IANA registrationp. 466

Contact name, email address, and telephone number:
3GPP Specifications Manager
3gppContact@etsi.org
+33 (0)492944200
Attribute Name (as it will appear in SDP)
3ge2ae
Long-form Attribute Name in English:
3GPP_e2ae-security-indicator
Type of Attribute
Media level
Is Attribute Value subject to the Charset Attribute?
This Attribute is not dependent on charset.
Purpose of the attribute:
This attribute specifies the end-to-access-edge security-indicator as used for IMS media plane security
Appropriate Attribute Values for this Attribute:
The attribute is a value attribute. The values "requested" and "applied" are defined.
Up

7.5.3  Optimal Media Routeing (OMR) attributes |R10|p. 467

7.5.3.1  Generalp. 467

The SDP attributes associated with OMR are used to identify and select alternative media plane paths for the purpose of bypassing unneeded media functions in the network, as described in TS 29.079.

7.5.3.2  Semanticsp. 467

The visited-realm attribute contains an IP realm identifier and transport address for a media function in the media plane that can potentially be used to bypass other allocated media functions.
The secondary-realm attribute contains an IP realm identifier and transport address for an alternate media function in the media plane that can potentially be used to bypass other allocated media functions.
The omr-s-cksum and omr-m-cksum attributes includes checksums for session level information and media level information to identify if the SDP was altered by intermediaries in such a way as to invalidate OMR information present in the SDP.
The "omr-codecs", "omr-m-att" and "omr-s-att" attributes contain codec-related SDP offer information encapsulated by a SIP-ALG in the signalling path that has modified codec related information.
The "omr-m-bw" and "omr-s-bw" attributes contain bandwidth-related SDP offer information encapsulated by a SIP-ALG in the signalling path that has modified codec related information.
Each group of zero or more versions of each of the "omr-codecs", "omr-m-att", "omr-s-att", "omr-m-bw" and "omr-s-bw" attributes for a media line with the same instance number is associated with the visited-realm instance for the modified media line and represents the version of the SDP information for the media line before modifications.
Up

7.5.3.3  Syntaxp. 467

The syntax specified in Table 7.5.2 uses the augmented Backus-Naur Form as described in RFC 2234.
This grammar encodes the primary media level information about each visited-realm and secondary-realm instance: the sequence in which the realm was visited, the realm identity, its IP address and port:
<instance-number>:
instance-number is a positive decimal integer which identifies the sequence in which this visited-realm was added during the forwarding of an SDP offer. If an IMS-ALG adds second-realm attribute(s), omr-codecs attribute(s), omr-m-att attribute(s), omr-s-att attribute(s), omr-m-bw attribute(s) and/or the omr-s-bw attribute(s) to an SDP offer it will assign the same instance number as assigned to the visited-realm attribute for the forwarded SDP offer. When used in the SDP answer, the instance-number, realm, nettype and addrtype uniquely identify the corresponding visited-realm or secondary-realm instance from the SDP offer.
<realm>:
identifies a set of mutually reachable IP endpoints that share a common IP addressing scheme.
Effective application of OMR depends on the scope of each realm being determined by reachability and not by administrative domain. A public IPv4 or IPv6 address reachable from the open internet shall be associated with the special realm "IN". For application to OMR in IPv6 networks, a realm corresponds to an IPv6 autonomous system.
Entity operators must adhere to the following guidelines for creation of an OMR realm string to ensure the integrity of the visited-realm and secondary-realm instance information for their realm(s): 1) Realm strings must be globally unique. It is recommended that a realm string contain a hostname or domain name, following the recommendation in Section 3.3 of RFC 7616, 2) Realm strings should present a human-readable identifier that can be rendered to a user.
<nettype>, <addrtype> and <connection-address>:
are taken from the connection-field (c= line) of RFC 4566. They describe the IP address associated with the visited-realm or secondary-realm instance, allowing for IPv4 addresses, IPv6 addresses and FQDNs. The connection-address can be either an IP address or an FQDN.
<port>:
It is the port associated with the visited-realm or secondary-realm instance as taken from RFC 4566. Its meaning depends on the network being used for the connection-address, and on the transport protocol selected for the corresponding media line, e.g., UDP or TCP.
<rtcp-port> and <rtcp-address>:
taken together are semantically equivalent to the rtcp attribute defined in RFC 3605. They optionally encode the RTCP port and address information when the RTCP port number is not exactly one greater than the port for an RTP stream at the same address.
The previous-fmt-list may be supplied within the visited-realm if this attribute is included in an SDP offer and shall not be supplied if this attribute is included in an SDP answer.
The visited-realm and secondary-realm attributes can be extended via <extension-name> and <extension-value>. The grammar allows for new name/value pairs to be added at the end of the attribute.
<omr-m-cksum>:
is a hex value calculated on the contents of the media level information per media line.
<omr-s-cksum>:
is a hex value calculated on the contents of the session level information.
<omr-codecs>
provides the transport format <proto> and list of media formats (e.g., payload type numbers) <fmt> supported by the visited-realm instance immediately preceding the instance identified by <instance-number>. Transport format <proto> and media format <fmt> are defined in RFC 4566 for the SDP m-line.
<omr-m-att>
provides a media level SDP attribute <attribute> supported by the visited-realm instance immediately preceding the instance identified by <instance-number>. Attribute <attribute> is defined in RFC 4566 for the SDP a-line.
<omr-s-att>
provides a session level SDP attribute <attribute> supported by the visited-realm instance immediately preceding the instance identified by <instance-number>. Attribute <attribute> is defined in RFC 4566 for the SDP a-line.
<omr-m-bw>
provides a media level SDP bandwidth described by <bwtype> and <bandwidth> supported by the visited-realm instance immediately preceding the instance identified by <instance-number>. <bwtype> and <bandwidth> are defined in RFC 4566 for the SDP b-line.
<omr-s-bw>
provides a session level SDP bandwidth described by <bwtype> and <bandwidth> supported by the visited-realm instance immediately preceding the instance identified by <instance-number>. <bwtype> and <bandwidth> are defined in RFC 4566 for the SDP b-line.
The "visited-realm", "secondary-realm", "omr-m-cksum", "omr-s-cksum", "omr-codecs", "omr-m-att", "omr-s-att" "omr-m-bw" and "omr-s-bw" SDP attributes are media-level attributes.
Up

7.5.3.4  IANA registrationp. 469

7.5.3.4.1  visited-realm attributep. 469
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
visited-realm
Long Form:
visited-realm
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks employing OMR procedures allowing to bypass border gateways in configurations in which IP realms are re-entered when establishing an end-to-end multimedia session. This attribute is used to identify configurations in which IP realms are re-entered when establishing an end-to-end multimedia session, so that border gateways can be bypassed without compromising their role in securing access to the networks. The attribute provides a means to identify connection information for visited IP realms to help select the most optimal available path.
Appropriate Values:
Up
7.5.3.4.2  secondary-realm attributep. 470
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
secondary-realm
Long Form:
secondary-realm
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks employing OMR procedures allowing to bypass border gateways in configurations in which IP realms are re-entered when establishing an end-to-end multimedia session. This attribute is used to identify configurations in which secondary IP realms are available to establish an end-to-end multimedia session, so that border gateways can be bypassed without compromising their role in securing access to the networks. The attribute provides a means to identify connection information for secondary IP realms to help select the most optimal available path.
Appropriate Values:
Up
7.5.3.4.3  omr-s-cksum attributep. 470
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
omr-s-cksum
Long Form:
omr-s-cksum
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks employing OMR procedures allowing to bypass border gateways in configurations in which IP realms are re-entered when establishing an end-to-end multimedia session. This attribute is used to provide a means to verify that session level SDP information has not been modified by intermediate SIP nodes not supporting the OMR procedures. The attribute provides a checksum calculated value against the session level information. Any OMR information associated with unexpectedly modified media information will be discarded.
Appropriate Values:
Up
7.5.3.4.4  omr-m-cksum attributep. 470
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
omr-m-cksum
Long Form:
omr-m-cksum
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks employing OMR procedures allowing to bypass border gateways in configurations in which IP realms are re-entered when establishing an end-to-end multimedia session. This attribute is used to provide a means to verify that media level SDP information has not been modified by intermediate SIP nodes not supporting the OMR procedures. The attribute provides a checksum calculated value against the media level information associated with the media stream for which the checksum is provided. Any OMR information associated with unexpectedly modified media information will be discarded.
Appropriate Values:
Up
7.5.3.4.5  omr-codecs attributep. 471
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
omr-codecs
Long Form:
omr-codecs
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks employing OMR procedures allowing to bypass border gateways in configurations in which IP realms are re-entered when establishing an end-to-end multimedia session. The attribute provides a means to encapsulate codec related SDP information transport format and list of media formats that are applicable if a particular border gateway is bypassed.
Appropriate Values:
Up
7.5.3.4.6  omr-m-att attributep. 471
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
omr-m-att
Long Form:
omr-m-att
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks employing OMR procedures allowing to bypass border gateways in configurations in which IP realms are re-entered when establishing an end-to-end multimedia session. The attribute provides means to encapsulate a media-level SDP attribute that is applicable if a particular border gateway is bypassed.
Appropriate Values:
7.5.3.4.7  omr-s-att attributep. 471
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
omr-s-att
Long Form:
omr-s-att
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks employing OMR procedures allowing to bypass border gateways in configurations in which IP realms are re-entered when establishing an end-to-end multimedia session. The attribute provides means to encapsulate a session-level SDP attribute that is applicable if a particular border gateway is bypassed.
Appropriate Values:
Up
7.5.3.4.8  omr-m-bw attributep. 471
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
omr-m-bw
Long Form:
omr-m-bw
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks employing OMR procedures allowing to bypass border gateways in configurations in which IP realms are re-entered when establishing an end-to-end multimedia session. The attribute provides means to encapsulate a media-level SDP bandwidth that is applicable if a particular border gateway is bypassed.
Appropriate Values:
7.5.3.4.9  omr-s-bw attributep. 472
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
omr-s-bw
Long Form:
omr-s-bw
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks employing OMR procedures allowing to bypass border gateways in configurations in which IP realms are re-entered when establishing an end-to-end multimedia session. The attribute provides means to encapsulate a session-level SDP bandwidth that is applicable if a particular border gateway is bypassed.
Appropriate Values:

7.5.4  Media plane optimization for WebRTC |R13|p. 472

7.5.4.1  Generalp. 472

The SDP attributes associated with media plane optimization procedures for WebRTC are used to encapsulate an SDP offer or SDP answer received from a WIC, as described in TS 23.228, Annex U.2.4.

7.5.4.2  Semanticsp. 472

The "tra-m-line" and "tra-att" SDP attributes contain media-related SDP information which is applicable if optimized transparent media between WICs are selected. In the SDP offer, the attributes describe the offered transparent media which can be selected. In the SDP answer, the presence of the attributes indicates that the transparent media have been selected and the attributes which have been selected.
The "tra-SCTP-association" SDP attribute indicates for a media line that the related optimized transparent media are transported in the indicated SCTP association. The optimized transparent media related to several media lines can be transported in the same SCTP association.
The "tra-bw" SDP attribute contains bandwidth-related SDP information which is applicable if the optimized transparent media between WICs are selected. In the SDP offer, the attributes describe the bandwidths the offerer wants to receive for transparent media. In the SDP answer, the attributes describe the bandwidths the answerer wants to receive for transparent media.
The "tra-contact" SDP attribute in the SDP offer encapsulate address information which is compared with the address information in contact by the receiving eP-CSCF to detect whether intermediates that do not support switching to transparent media between WICs are in the path.
The "tra-media-line-number" SDP attribute provides the total number of media lines in the SDP, excluding any media lines with port zero, which is compared with the real number of media lines in the SDP, excluding any media lines with port zero, by the receiving eP-CSCF to detect whether intermediates have removed or dissabled media lines.
Up

7.5.4.3  Syntaxp. 473

The syntax specified in Table 7.5.4.3-1 uses the augmented Backus-Naur Form as described in RFC 2234.
This grammar encodes the media level information received in an initial SDP offer from a WIC.
<tra-contact>:
It is the contact used in the outgoing SDP offer which contains encapsulated media information. It contains nettype, addrtype and connection-address. Nettype, addrtype and connection-address are defined in RFC 4566 [39].
<tra-m-line>:
provides the media <media>, port <port>, transport format <proto> and list of media formats (e.g., payload type numbers) <fmt> in the received SDP offer. Media <media>, port <port>, transport format <proto> and media format <fmt> are defined in RFC 4566 [39] for the SDP m-line.
<tra- att>
provides an encapsulated SDP attribute <attribute> supported by the sender of the offer. Attribute <attribute> is defined in RFC 4566 [39] for the SDP a-line.
<tra- bw> provides an SDP bandwidth described by <bwtype> and <bandwidth> supported by the sender of the offer. <bwtype> and <bandwidth> are defined in RFC 4566 [39] for the SDP b-line.
<tra-SCTP-association>
provides the number <SCTP-association-number> of an SCTP association a media line relates to. If optimized media are selected, the media related to a media line with an "a= tra-SCTP-association" SDP attribute will be transported in that SCTP association, possibly together with media relating to other media lines with "a= tra-SCTP-association" SDP attributes with the same <SCTP-association-number>. For a WIC terminating call, the eP-CSCF receiving an offer from the core network containg m-lines with "a= tra-SCTP-association" SDP attributes with the same <SCTP-association-number> will construct a single m-line related to that SCTP association in the offer towards the served WIC.
<tra-media-line-number>
provides the total number <m-line-number> of media lines in the SDP, excluding any media lines with port zero.
The "tra-contact", "tra- att", "tra-bw", SDP attributes are session and media-level attributes.
The "tra-m-line" and "tra-SCTPassociation" SDP attributes are media level attributes.
The "tra-media-line-number" SDP attribute is a session level attribute.
Up

7.5.4.4  IANA registrationp. 473

7.5.4.4.1  tra-contactp. 473
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
tra-contact
Long Form:
tra-contact
Type of Attribute:
session and media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks supporting WebRTC-IMS interworking. This attribute is used to encapsulate contact information received from gateways in the SDP offers and SDP answers when setting up a session that supports media plane optimization feature as specified in TS 23.228 and TS 24.371.
Appropriate Values:
7.5.4.4.2  tra-m-linep. 474
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
tra-m-line
Long Form:
tra-m-line
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks supporting WebRTC-IMS interworking. This attribute is used to encapsulate an m-line received in an SDP offer or SDP answer into an attribute in an outgoing SDP offer or SDP answer when setting up a session that supports media plane optimization feature as specified in TS 23.228 and TS 24.371.
Appropriate Values:
7.5.4.4.3  tra-attp. 474
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
tra-att
Long Form:
tra-att
Type of Attribute:
session and media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks supporting WebRTC-IMS interworking. This attribute is used to encapsulate an attribute received in an SDP offer or SDP answer into an attribute in an outgoing SDP offer or SDP answer when setting up a session that supports media plane optimization feature as specified in TS 23.228 and TS 24.371.
Appropriate Values:
7.5.4.4.4  tra-bwp. 474
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
tra-bw
Long Form:
tra-bw
Type of Attribute:
session and media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks supporting WebRTC-IMS interworking. This attribute is used to encapsulate bandwidth information received in the SDP offers and SDP answers when setting up a session that supports media plane optimization feature as specified in TS 23.228 and TS 24.371.
Appropriate Values:
7.5.4.4.5  tra-SCTP-associationp. 475
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
tra-SCTP-association
Long Form:
tra-SCTP-association
Type of Attribute:
media level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks supporting WebRTC-IMS interworking. This attribute is used to indicate that a media line relates to an SCTP association received in the SDP offers and SDP answers when setting up a session that supports media plane optimization feature as specified in TS 23.228 and TS 24.371.
Appropriate Values:
7.5.4.4.6  tra- media-line-numberp. 475
Contact Name:
3GPP Specifications Manager, 3gppContact@etsi.org, +33 (0)492944200
Attribute Name:
tra-media-line-number
Long Form:
tra-media-line-number
Type of Attribute:
session level
Charset Considerations:
The attribute is not subject to the charset attribute.
Purpose:
This attribute is used in networks supporting WebRTC-IMS interworking. This attribute is used to encapsulate the total number of media lines in the SDP, excluding any media lines with port zero, to detect a removal or dissabling of media lines by intermediate nodes when setting up a session that supports media plane optimization feature as specified in TS 23.228 and TS 24.371.
Appropriate Values:
Up

7.5.5Void

7.5.6  SDP content attribute values |R17|p. 475

7.5.6.1  Generalp. 475

As defined in RFC 4796, the "a=content" attribute is a media level attribute in SDP.

7.5.6.2  SDP "a=content" attribute "g.3gpp.announcement-no-confirmation" valuep. 475

7.5.6.2.1  Generalp. 475
The SDP "a=content" attribute "g.3gpp.announcement-no-confirmation" value is used only for informative purposes during an established session, to indicate an SDP media description is for the video announcement service and the operator wishes to play the announcement stream without user confirmation.
The AS may use this value, based on the operator policy, only for the video announcement which is important or needs to be seen by the user immediately.
The UE may accept to play the video announcement without user confirmation when received this value, based on UE's local policy (e.g., local configuration on the UE).
The use of the SDP "a=content" attribute "g.3gpp.announcement-no-confirmation" value shall conform to the procedure specified in TS 24.628.
Up
7.5.6.2.2  IANA registration for values of "a=content" attributep. 476
IANA registration table:
"content SDP Parameters" table of "Session Description Protocol (SDP) Parameters" registry.
IANA registry:
A new value "g.3gpp.announcement-no-confirmation" for the SDP a=content media-level attribute defined in RFC 4796.
Reference:

7.6  3GPP IM CN subsystem XML body |R14|p. 476

7.6.1  Generalp. 476

This subclause contains the 3GPP IM CN Subsystem XML body in XML format. The 3GPP IM CN Subsystem XML shall be valid against the 3GPP IM CN Subsystem XML schema defined in Table 7.6.1.
Any SIP User Agent or proxy may insert or remove the 3GPP IM CN subsystem XML body or parts of it, as required, in any SIP message. The 3GPP IM CN subsystem XML body shall not be forwarded outside a 3GPP network.
See subclause 7.6.4 and subclause 7.6.5 for the associated MIME type definition.
Up

7.6.2  Document Type Definitionp. 476

The XML Schema, is defined in Table 7.6.1.
Up

7.6.3  XML Schema descriptionp. 476

This subclause describes the elements of the IM CN subsystem XML Schema as defined in Table 7.6.1.
<ims-3gpp>:
The <ims-3gpp> element is the root element of the IM CN subsystem XML body. It is always present. XML instance documents of future versions of the XML Schema in Table 7.6.1 is valid against the XML Schema in Table 7.6.1 in this document. XML instance documents of the XML Schema in Table 7.6.1 in the present document have a version attribute value, part of the <ims-3gpp> element, that is equal to the value of the XML Schema version described in the present document.
<service-info>:
the transparent element received from the HSS for a particular trigger point are placed within this optional element.
<alternative-service>:
in the present document, the alternative service is used as a response for an attempt to establish an emergency session within the IM CN subsystem or as a response to initiate S-CSCF restoration procedures. The element describes an alternative service where the call should success. The alternative service is described by the type of service information. A possible reason cause why an alternative service is suggested may be included.
In the present document, the <alternative-service> element contains a <type> element, a <reason> element, and an optional <action> element.
The <type> element indicates the type of alternative service. The <type> element contains only the values specified in Table 7.6.2 in the present document.
The <action> element contains only the values specified in Table 7.6.3 in the present document.
The <reason> element contains an explanatory text with the reason why the session setup has been redirected. A UE may use this information to give an indication to the user.
If included in the IM CN subsystem XML body:
  1. the <type> element with the value "emergency" is included as the first child element of the <alternative-service> element;
  2. the <type> element with the value "restoration" is included as one of the following:
    1. the first child element of the <alternative-service> element; or
    2. the third or later child element of the <alternative-service> element;
  3. the <action> element with the value "emergency-registration" is includes as the third child element of the <alternative-service> element;
  4. the <action> element with value "initial-registration" is included as the third or later child element of the <alternative-service> element; and
  5. the <action> element with value "anonymous-emergencycall" is included as the third or later child element of the <alternative-service> element.
Up

7.6.4  MIME type definition |R8|p. 478

7.6.4.1  Introductionp. 478

This subclause defines the MIME type for "application/3gpp-ims+xml". A 3GPP IM CN subsystem XML Document can be identified with this media type.

7.6.4.2  Syntaxp. 478

The following optional parameters are defined:
  • "charset": the parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in RFC 3023.
  • "sv" or "schemaversion": the syntax for the "sv" or "schemaversion" parameter is specified in Table 7.6.4:
The BNF for m-parameter is taken from RFC 3261 and modified accordingly.
Up

7.6.4.3  Operationp. 478

The encoding considerations for "application/3gpp-ims+xml" are identical to those of "application/xml" as described in RFC 3023.
The "sv" or "schemaversion" parameter's value is used to indicate:
  • the versions of the 3GPP IM CN Subsystem XML schema that can be used to validate the 3GPP IM CN subsystem XML body (if the MIME type and parameter are present in the Content-Type header field); or
  • the accepted versions of the 3GPP IM CN Subsystem XML body (if the MIME type and parameter are present in the Accept header field).
If the "sv" and "schemaversion" parameter are absent, it shall be assumed that version 1 of the XML Schema for the IM CN subsystem XML body is supported.
Up

7.6.5  IANA Registration |R8|p. 478

MIME media type name:
application
MIME subtype name:
3gpp-ims+xml
Required parameters:
None
Optional parameters:
"charset"
the parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in RFC 3023.
"sv" or "schemaversion"
the parameter's value is used to indicate:
  • the versions of the 3GPP IP Multimedia (IM) Core Network (CN) subsystem XML schema that can be used to validate the 3GPP IM CN subsystem XML body (if the MIME type and parameter are present in the Content-Type header field); or
  • the accepted versions of the 3GPP IM CN Subsystem XML body (if the MIME type and parameter are present in the Accept header field).
If the "sv" and "schemaversion" parameter are absent, it shall be assumed that version 1 of the XML Schema for the IM CN subsystem XML body is supported.
Encoding considerations:
Same as encoding considerations of application/xml as specified in RFC 3023 [132]
Security considerations:
Same as general security considerations for application/xml as specified in Section 10 of RFC 3023.
In addition, this content type provides a format for exchanging information in SIP, so the security considerations from RFC 3261 apply.
Interoperability considerations:
Same as Interoperability considerations as specified in Section 3.1 of RFC 3023.
If both "sv" and "schemaversion" are specified, then the value of "schemaversion" is ignored
Published specification:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), stage 3", as published in subclause 7.6.5, version 8.9.0.
Available via
Applications which use this media:
Applications that use the 3GPP IM CN Subsystem as defined by 3GPP.
Intended usage:
COMMON
Additional information:
  1. Magic number(s): none
  2. File extension(s): none
  3. Macintosh file type code: none
  4. Object Identifiers: none
Up

7.7  SIP timersp. 479

The timers T1, T2, T4 A, B, C, D, E, F, G, H and I (defined in RFC 3261), timers L and M (defined in RFC 6026), and timer N (defined in RFC 6665) need modification in some cases to accommodate the delays introduced by the air interface processing and transmission delays. Table 7.7.1 shows recommended values for IM CN subsystem.
Table 7.7.1 lists in the first column, titled "SIP Timer" the timer names as defined in RFC 3261 and RFC 6026.
The second column, titled "value to be applied between IM CN subsystem elements" lists the values recommended for network elements e.g. P-CSCF, S-CSCF, MGCF, when communicating with each other i.e. when no air interface leg is included. These values are identical to those recommended by RFC 3261, RFC 6026, and RFC 6665.
The third column, titled "value to be applied at the UE" lists the values recommended for the UE, when in normal operation the UE generates requests or responses containing a P-Access-Network-Info header field which included a value 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", "3GPP-NR-REDCAP", "3GPP2-1X", "3GPP2-1X-HRPD", "3GPP2-UMB", "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b", "IEEE-802.11g", "IEEE-802.11n", "IEEE-802.11ac", or "DVB-RCS2". These are modified when compared to RFC 3261 and RFC 6026 to accommodate the air interface delays. In all other cases, the UE should use the values specified in RFC 3261 or RFC 6026 as indicated in the second column of Table 7.7.1.
The fourth column, titled "value to be applied at the P-CSCF toward a UE" lists the values recommended for the P-CSCF when an air interface leg is traversed, and which are used on all SIP transactions on a specific security association where the security association was established using a REGISTER request containing a P-Access-Network-Info header field provided by the UE which included a value 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", "3GPP-NR-REDCAP", "3GPP2-1X", "3GPP2-1X-HRPD", "3GPP2-UMB", "IEEE-802.11", "IEEE-802.11a", "IEEE-802.11b", "IEEE-802.11g", "IEEE-802.11n", "IEEE-802.11ac", or "DVB-RCS2". These are modified when compared to RFC 3261 and RFC 6026. In all other cases, the P-CSCF should use the values specified in RFC 3261 and RFC 6026 as indicated in the second column of Table 7.7.1.
The final column reflects the timer meaning as defined in RFC 3261, RFC 6026 or RFC 6665.
SIP Timer Value to be applied between IM CN subsystem elements Value to be applied at the UE Value to be applied at the P-CSCF toward a UE Meaning
T1500ms default (see NOTE)2s default2s defaultRTT estimate
T24s (see NOTE)16s16sThe maximum retransmit interval for non-INVITE requests and INVITE responses
T45s (see NOTE)17s17sMaximum duration a message will remain in the network
Timer Ainitially T1initially T1initially T1INVITE request retransmit interval, for UDP only
Timer B64*T164*T164*T1INVITE transaction timeout timer
Timer C> 3min> 3 min> 3 minproxy INVITE transaction timeout
Timer D> 32s for UDP>128s>128sWait time for response retransmits
0s for TCP/SCTP 0s for TCP/SCTP0s for TCP/SCTP
Timer Einitially T1initially T1initially T1non-INVITE request retransmit interval, UDP only
Timer F64*T164*T164*T1non-INVITE transaction timeout timer
Timer Ginitially T1initially T1initially T1INVITE response retransmit interval
Timer H64*T164*T164*T1Wait time for ACK receipt.
Timer IT4 for UDPT4 for UDPT4 for UDPWait time for ACK retransmits
0s for TCP/SCTP0s for TCP/SCTP0s for TCP/SCTP
Timer J64*T1 for UDP64*T1 for UDP64*T1 for UDPWait time for non-INVITE request retransmits
0s for TCP/SCTP0s for TCP/SCTP0s for TCP/SCTP
Timer KT4 for UDPT4 for UDPT4 for UDPWait time for response retransmits
0s for TCP/SCTP0s for TCP/SCTP 0s for TCP/SCTP
Timer L64*T164*T164*T1Wait time for accepted INVITE request retransmits
Timer M64*T164*T164*T1Wait time for retransmission of 2xx to INVITE or additional 2xx from other branches of a forked INVITE
Timer N64*T164*T164*T1Wait time for receipt of a NOTIFY request upon sending SUBSCRIBE
NOTE:
As a network option, SIP T1 Timer's value can be extended, along with the necessary modifications of T2 and T4 Timers' values, to take into account the specificities of the supported services when the MRFC and the controlling AS are under the control of the same operator and the controlling AS knows, based on local configuration, that the MRFC implements a longer value of SIP T1 Timer.
Up

7.8  IM CN subsystem timersp. 481

Table 7.8.1 shows recommended values for timers specific to the IM CN subsystem.
Timer Value to be applied at the UE Value to be applied at the P-CSCF Value to be applied at the S-CSCF Meaning
reg-await-authnot applicablenot applicable4 minutesThe timer is used by the S-CSCF during the authentication procedure of the UE for registration. For detailed usage of the timer see subclause 5.4.1.2.
The authentication procedure may take in the worst case as long as 2 times Timer F. The IM CN subsystem value for Timer F is 128 seconds.
request-await-authnot applicablenot applicable4 minutesThe timer is used by the S-CSCF during the authentication procedure of the UE for requests different than REGISTER. For detailed usage of the timer see subclause 5.4.3.6.1.
The authentication procedure may take in the worst case as long as 2 times Timer F. The IM CN subsystem value for Timer F is 128 seconds.
emerg-regConfigurable value between 8 seconds and 20 seconds not applicablenot applicableThe timer is used by the UE to supervise the time from deciding that an emergency service is to be established via the IM CN subsystem until completion of the emergency registration procedure, including any required IP-CAN procedures. For detailed usage of the timer see subclause 5.1.6.1.
emerg-reg-retryConfigurable value between 3 seconds and 5 secondsnot applicablenot applicableThe timer is used by the UE to supervise the time from deciding that an emergency registration is to be attempted on a particular P-CSCF until success/failure of emergency procedure on that specific P-CSCF, including any required IP-CAN procedures. The detailed usage of the timer described in subclause 5.1.6.1 and the final value to be applied at UE for this timer is determined.
(see NOTE)
emerg-requestConfigurable value between 5 seconds and 15 seconds not applicablenot applicableThe timer is used by the UE during initial request for emergency service. For detailed usage of the timer see subclause 5.1.6.8.1.
NoVoPS-deregConfigurable value between 0 seconds and 65535 secondsnot applicablenot applicable The timer is used by the UE when the UE receives a VoPS not supported indication from the lower layers and indicates the time the UE needs to wait before the UE deregisters from IMS if the UE is configured with a policy to deregister, see subclause B.3.1.0a, L.3.1.0a, U.3.1.0A and W.3.1.0a.
emerg-non3gppConfigurable value between 5 seconds and 20 secondsnot applicablenot applicable The timer is used by the UE to supervise the time for searching usable 3GPP access to setup an emergency call before attempting the emergency call via non-3GPP access.
For detailed usage of the timer see subclauses R.2.2.6.1 and W.2.2.6.1.
NOTE:
The emerg-reg-retry timer value defines a minimum waiting time in seconds for the UE for a particular P-CSCF. The final value to be applied at UE for this timer is determined as described below using configured emerg-reg-retry timer value, emerg-reg timer value and number of P-CSCFs determined during session management procedures:
Final emerg-reg-retry timer value = Max (configured emerg-reg-retry timer value, configured emerg-reg timer value/number of P-CSCFs)
Up

7.9  Media feature tags defined within the current document |R7|p. 483

7.9.1  Generalp. 483

This subclause describes the media feature tag definitions that are applicable for the 3GPP IM CN subsystem.

7.9.2  Definition of media feature tag g.3gpp.icsi-refp. 483

Media feature-tag name:
g.3gpp.icsi-ref.
ASN.1 Identifier:
1.3.6.1.8.2.4
Summary of the media feature indicated by this tag:
Each value of the Service Reference media feature-tag indicates the software applications supported by the agent. The values for this tag equal the IMS communication Service Identifier (ICSI) values supported by the agent.
The Service Reference media feature tag is defined to fulfil the requirements for forking to an appropriate UE when multiple UEs are registered and dispatch to an appropriate application within the UE based upon the IMS communication Service Identifier (ICSI) values as stated in TS 23.228.
Multiple tag-values can be included in the Service Reference media feature-tag.
Values appropriate for use with this feature-tag:
Token with an equality relationship.
The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:
This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
Examples of typical use:
Routeing an IMS Communication Session to a device that supports a particular software application or understands a particular service.
Related standards or documents:
3GPP TS 24.229:
"IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), stage 3"
Security Considerations:
Security considerations for this media feature-tag are discussed in Section 11.1 of RFC 3840.
Up

7.9.3  Definition of media feature tag g.3gpp.iari-refp. 484

Media feature-tag name:
g.3gpp.iari-ref.
ASN.1 Identifier:
1.3.6.1.8.2.5
Summary of the media feature indicated by this tag:
Each value of the Application Reference media feature-tag indicates the software applications supported by the agent. The values for this tag equal IMS Application Reference Identifier (IARI) values supported by the agent
The Application Reference media feature tag is defined to fulfil the requirements for forking to an appropriate UE when multiple UEs are registered and dispatch to an appropriate application within the UE based upon and IMS Application Reference Identifier (IARI) values as stated in TS 23.228.
Multiple tag-values can be included in the Application Reference media feature-tag.
Values appropriate for use with this feature-tag: Token with an equality relationship.
The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:
This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
Examples of typical use:
Routeing an IMS Application Session to a device that supports a particular software application or understands a particular application.
Related standards or documents:
3GPP TS 24.229: "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), stage 3"
Security Considerations:
Security considerations for this media feature-tag are discussed in Section 11.1 of RFC 3840.
Up

7.9.4Void

7.9.5Void

7.9.6Void

7.9.7  Definition of media feature tag g.3gpp.registration-token |R12|p. 484

Media feature tag name:
g.3gpp.registration-token
ASN.1 Identifier:
1.3.6.1.8.2.27
Summary of the media feature indicated by this media feature tag:
This media feature tag, when included in a third party SIP REGISTER request, indicates the support of using a token to identify the registration used for the request. The mediafeature tag is assigned a value that can be used by the receiving AS to later identify the used registration for initial requests from an originating user or dialog forming responses from a terminating user.
Media feature tag specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this media feature tag:
String with an equality relationship.
The media feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This media feature tag is used to indicate support of using a token to identify the registration used for the current request or response among the set of registrations for the registered URI. As the token is unique per URI, different URIs for different users can have the same value of the token.
Examples of typical use:
The S-CSCF includes this media feature tag in a third-party REGISTER request to indicate support of this feature. The value is a unique value identifying this registration among the set of registrations for the registered URI. The S-CSCF includes a token with identical value in subsequent initial requests and responses. An AS supporting this feature can use the value of the token to identify the used registration.
Security Considerations:
Security considerations for this media feature-tag are discussed in Section 11.1 of RFC 3840.
Up

7.9.8  Definition of media feature tag g.3gpp.ps-data-off |R14|p. 485

Media feature tag name:
g.3gpp.ps-data-off.
ASN.1 Identifier:
1.3.6.1.8.2.35
Summary of the feature indicated by this media feature tage:
This media feature tag when included in a Contact header field in a REGISTER request indicates the status of the 3GPP PS data off for the registration time.
This media feature tag, when included in the Contact header field in a REGISTER request indicates that the UE supports the 3GPP PS data off. The g.3gpp.ps-data-off media feature tag can take a value that indicates whether the 3GPP PS data off has been activated or deactivated by the user at the UE.
Media feature tag specification reference:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3".
Values appropriate for use with this media feature tag:
String with an equality relationship
Examples of typical use:
Indicating support and activation status of the 3GPP PS data off function to IMS network entities.
Security Considerations:
Security considerations for this media feature tag are discussed in Section 9 of RFC 6809.
Up

7.9.9  Definition of media feature tag g.3gpp.rlos |R16|p. 485

Media feature-tag name:
g.3gpp.rlos
ASN.1 Identifier:
1.3.6.1.8.2.x
Summary of the media feature indicated by this tag:
This feature-tag when used in a SIP REGISTER request indicates that the function sending the SIP message supports restricted local operator service.
Values appropriate for use with this feature-tag:
Boolean
The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA.
Examples of typical use:
Indicating that a mobile phone supports the restricted local operator service
Related standards or documents:
3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3"
Security Considerations:
Security considerations for this media feature-tag are discussed in Section 12.1 of IETF RFC 3840.
Up

Up   Top   ToC