Content for TS 24.229 Word version: 18.4.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… 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 document 7.4 Status-codes defined within the present document 7.5 Session description types defined within the present document 7.5.1 General 7.5.2 End-to-access-edge media plane security 7.5.3 Optimal Media Routeing (OMR) attributes 7.5.4 Media plane optimization for WebRTC 7.5.6 SDP content attribute values 7.6 3GPP IM CN subsystem XML body 7.7 SIP timers 7.8 IM CN subsystem timers 7.9 Media feature tags defined within the current document
...

7.3 Option-tags defined within the present document p. 461

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 document p. 462

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 document p. 462

7.5.1 General |R9| p. 462

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

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 Syntax p. 462

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.

Table 7.5.1: ABNF syntax of 3ge2ae attribute

3ge2ae-attribute = "a=3ge2ae:" indicator
indicator = "requested" / "applied" / token

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

7.5.2.3 IANA registration p. 462

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.

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

7.5.3.1 General p. 463

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 Semantics p. 463

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.

7.5.3.3 Syntax p. 463

The syntax specified in Table 7.5.2 uses the augmented Backus-Naur Form as described in RFC 2234.

Table 7.5.2: Syntax OMR attributes

visited-realm =
  "visited-realm" ":" instance-number SP
  realm SP
  nettype SP             ;from RFC 4566 [39]
  addrtype SP            ;from RFC 4566 [39]
  connection-address SP  ;from RFC 4566 [39]
  port                   ;from RFC 4566 [39]
  [SP rtcp-port [SP rtcp-address]]
  *(SP extension-name SP extension-value)
secondary-realm =
  "secondary-realm" ":" instance-number SP
  realm SP
  nettype SP             ;from RFC 4566 [39]
  addrtype SP            ;from RFC 4566 [39]
  connection-address SP  ;from RFC 4566 [39]
  port                   ;from RFC 4566 [39]
  [SP rtcp-port [SP rtcp-address]]
  *(SP extension-name SP extension-value)
instance-number    = 1*DIGIT
realm              = non-ws-string  ;from RFC 4566 [39]
rtcp-port          = "rtcp-port" SP port
rtcp-address       = "rtcp-address" SP connection-address
extension-name     = token
 ; shall be different to existing tokens "previsous-fmt",
 ; "rtcp-port" and "rtcp-address".
extension-value  = non-ws-string
omr-m-cksum = "omr-m-cksum"
              ":" 1*HEXDIG
omr-s-cksum = "omr-s-cksum"
              ":" 1*HEXDIG
omr-codecs  = "omr-codecs"
              ":" instance-number SP proto 1*(SP fmt)
              ;from RFC 4566 [39]
omr-m-att   = "omr-m-att"
              ":" instance-number SP attribute
              ;from RFC 4566 [39]
omr-s-att   = "omr-s-att"
              ":" instance-number SP attribute
              ;from RFC 4566 [39]
omr-m-bw    = "omr-m-bw"
              ":" instance-number SP bwtype ":" bandwidth
              ;from RFC 4566 [39]
omr-s-bw    = "omr-s-bw"
              ":" instance-number SP bwtype ":" bandwidth
              ;from RFC 4566 [39]

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.

7.5.3.4 IANA registration p. 465

7.5.3.4.1 visited-realm attribute p. 465

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:

See Table 7.5.2.

7.5.3.4.2 secondary-realm attribute p. 466

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:

See Table 7.5.2.

7.5.3.4.3 omr-s-cksum attribute p. 466

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:

See Table 7.5.2.

7.5.3.4.4 omr-m-cksum attribute p. 466

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:

See Table 7.5.2.

7.5.3.4.5 omr-codecs attribute p. 467

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:

See Table 7.5.2.

7.5.3.4.6 omr-m-att attribute p. 467

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:

See Table 7.5.2.

7.5.3.4.7 omr-s-att attribute p. 467

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:

See Table 7.5.2.

7.5.3.4.8 omr-m-bw attribute p. 467

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:

See Table 7.5.2.

7.5.3.4.9 omr-s-bw attribute p. 468

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:

See Table 7.5.2.

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

7.5.4.1 General p. 468

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 Semantics p. 468

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.

7.5.4.3 Syntax p. 469

The syntax specified in Table 7.5.4.3-1 uses the augmented Backus-Naur Form as described in RFC 2234.

Table 7.5.4.3-1: Syntax of media plane optimization for WebRTC related SDP attributes

tra-contact =
  "tra-contact" ":" nettype SP addrtype SP connection-address
  ; from RFC 4566 [39]
tra-m-line =
  "tra-m-line" ":" media SP port ["/" integer] proto 1*(SP fmt)
  ; from RFC 4566 [39]
tra-att =
  "tra-att" ":" attribute
  ; from RFC 4566 [39]
tra-bw  =
  "tra-bw" ":" bwtype ":" bandwidth
  ; from RFC 4566 [39]
tra-SCTP-association =
  "tra-SCTP-association" ":" SCTP-association-number
tra-media-line-number =
  "media-line-number" ":" m-line-number
SCTP-association-number = integer
m-line-number           = integer

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.

7.5.4.4 IANA registration p. 469

7.5.4.4.1 tra-contact p. 469

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:

See Table 7.5.4.3-1.

7.5.4.4.2 tra-m-line p. 470

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:

See Table 7.5.4.3-1.

7.5.4.4.3 tra-att p. 470

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:

See Table 7.5.4.3-1.

7.5.4.4.4 tra-bw p. 470

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:

See Table 7.5.4.3-1.

7.5.4.4.5 tra-SCTP-association p. 471

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:

See Table 7.5.4.3-1.

7.5.4.4.6 tra- media-line-number p. 471

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:

See Table 7.5.4.3-1.

7.5.5 Void

7.5.6 SDP content attribute values |R17| p. 471

7.5.6.1 General p. 471

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" value p. 471

7.5.6.2.1 General p. 471

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.

7.5.6.2.2 IANA registration for values of "a=content" attribute p. 472

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:

3GPP TS 24.229, http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/.

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

7.6.1 General p. 472

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.

7.6.2 Document Type Definition p. 472

The XML Schema, is defined in Table 7.6.1.

Table 7.6.1: IM CN subsystem XML body, XML Schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1">
   <xs:complexType name="tIMS3GPP">
      <xs:sequence>
         <xs:choice>
            <xs:element name="alternative-service" type="tAlternativeService"/>
            <xs:element name="service-info" type="xs:string"/>
         </xs:choice>
         <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="version" type="xs:decimal" use="required"/>
      <xs:anyAttribute/>
   </xs:complexType>
   <xs:complexType name="tAlternativeService">
      <xs:sequence>
         <xs:element ref="type"/>
         <xs:element name="reason" type="xs:string"/>
         <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute/>
   </xs:complexType>
   <!-- root element -->
   <xs:element name="ims-3gpp" type="tIMS3GPP"/>
   <xs:element name="type" type="xs:string"/>
   <!-- action element for //ims-3gpp//alternative-service -->
   <xs:element name="action" type="xs:string"/>
</xs:schema>

7.6.3 XML Schema description p. 472

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.

Table 7.6.2: ABNF syntax of values of the <type> element

emergency-value = %x65.6D.65.72.67.65.6E.63.79 ; "emergency"
restoration-value = %x72.65.73.74.6F.72.61.74.69.6F.6E ; "restoration"

The <action> element contains only the values specified in Table 7.6.3 in the present document.

Table 7.6.3: ABNF syntax of values of the <action> element

emergency-registration-value = %x65.6D.65.72.67.65.6E.63.79.2D.72.65.67.69.73.74.72.61.74.69.6F.6E ; "emergency-registration"
initial-registration-value = %x69.6E.69.74.69.61.6C.2D.72.65.67.69.73.74.72.61.74.69.6F.6E ; "initial-registration"
anonymous-emergencycall-value = %x61.6E.6F.6E.79.6D.6F.75.73.2D.65.6D.65.72.67.65.6E.63.79.63.61.6C.6C ; "anonymous-emergencycall"

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:

the <type> element with the value "emergency" is included as the first child element of the <alternative-service> element;
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;
the <action> element with the value "emergency-registration" is includes as the third child element of the <alternative-service> element;
the <action> element with value "initial-registration" is included as the third or later child element of the <alternative-service> element; and
the <action> element with value "anonymous-emergencycall" is included as the third or later child element of the <alternative-service> element.

7.6.4 MIME type definition |R8| p. 474

7.6.4.1 Introduction p. 474

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 Syntax p. 474

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:

Table 7.6.4: Syntax of the "sv" or "schemaversion" parameter

m-parameter    =/ ("sv" / "schemaversion") EQUAL LDQUOT [ sv-value-list ] RDQUOT
sv-value-list  =  sv-value-range *( "," sv-value )
sv-value-range =  sv-value [ "-" sv-value ]
sv-value       =  number / token
number         =  1*DIGIT [ "." 1*DIGIT ]

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

7.6.4.3 Operation p. 474

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.

7.6.5 IANA Registration |R8| p. 474

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

<http://www.3gpp.org/specs/numbering.htm>.

Applications which use this media:

Applications that use the 3GPP IM CN Subsystem as defined by 3GPP.

Intended usage:

COMMON

Additional information:

Magic number(s): none
File extension(s): none
Macintosh file type code: none
Object Identifiers: none

7.7 SIP timers p. 475

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

Table 7.7.1: SIP timers

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
T1	500ms default (see NOTE)	2s default	2s default	RTT estimate
T2	4s (see NOTE)	16s	16s	The maximum retransmit interval for non-INVITE requests and INVITE responses
T4	5s (see NOTE)	17s	17s	Maximum duration a message will remain in the network
Timer A	initially T1	initially T1	initially T1	INVITE request retransmit interval, for UDP only
Timer B	64*T1	64*T1	64*T1	INVITE transaction timeout timer
Timer C	> 3min	> 3 min	> 3 min	proxy INVITE transaction timeout
Timer D	> 32s for UDP	>128s	>128s	Wait time for response retransmits
Timer D	0s for TCP/SCTP	0s for TCP/SCTP	0s for TCP/SCTP	Wait time for response retransmits
Timer E	initially T1	initially T1	initially T1	non-INVITE request retransmit interval, UDP only
Timer F	64*T1	64*T1	64*T1	non-INVITE transaction timeout timer
Timer G	initially T1	initially T1	initially T1	INVITE response retransmit interval
Timer H	64*T1	64*T1	64*T1	Wait time for ACK receipt.
Timer I	T4 for UDP	T4 for UDP	T4 for UDP	Wait time for ACK retransmits
Timer I	0s for TCP/SCTP	0s for TCP/SCTP	0s for TCP/SCTP	Wait time for ACK retransmits
Timer J	64*T1 for UDP	64*T1 for UDP	64*T1 for UDP	Wait time for non-INVITE request retransmits
Timer J	0s for TCP/SCTP	0s for TCP/SCTP	0s for TCP/SCTP	Wait time for non-INVITE request retransmits
Timer K	T4 for UDP	T4 for UDP	T4 for UDP	Wait time for response retransmits
Timer K	0s for TCP/SCTP	0s for TCP/SCTP	0s for TCP/SCTP	Wait time for response retransmits
Timer L	64*T1	64*T1	64*T1	Wait time for accepted INVITE request retransmits
Timer M	64*T1	64*T1	64*T1	Wait time for retransmission of 2xx to INVITE or additional 2xx from other branches of a forked INVITE
Timer N	64*T1	64*T1	64*T1	Wait 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.

7.8 IM CN subsystem timers p. 477

Table 7.8.1 shows recommended values for timers specific to the IM CN subsystem.

Table 7.8.1: 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-auth	not applicable	not applicable	4 minutes	The 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-auth	not applicable	not applicable	4 minutes	The 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-reg	Configurable value between 8 seconds and 20 seconds	not applicable	not applicable	The 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-request	Configurable value between 5 seconds and 15 seconds	not applicable	not applicable	The 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-dereg	Configurable value between 0 seconds and 65535 seconds	not applicable	not 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-non3gpp	Configurable value between 5 seconds and 20 seconds	not applicable	not 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.

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

7.9.1 General p. 479

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-ref p. 479

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.

7.9.3 Definition of media feature tag g.3gpp.iari-ref p. 479

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.

7.9.4 Void

7.9.5 Void

7.9.6 Void

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

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.

Table 7.9.7-1: ABNF syntax of values of the g.3gpp.registration-token media feature tag

g-3gpp-registration-token = "<"qdtext">"

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.

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

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

Table 7.9.8-1: ABNF syntax of values of the g.3gpp.ps-data-off media feature tag

g-3gpp-ps-data-off = "active" / "inactive" / token

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.

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

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

Content for TS 24.229 Word version: 18.4.0

7.3 Option-tags defined within the present document p. 461

7.4 Status-codes defined within the present document p. 462

7.5 Session description types defined within the present document p. 462

7.5.1 General |R9| p. 462

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

7.5.2.1 General p. 462

7.5.2.2 Syntax p. 462

7.5.2.3 IANA registration p. 462

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

7.5.3.1 General p. 463

7.5.3.2 Semantics p. 463

7.5.3.3 Syntax p. 463

7.5.3.4 IANA registration p. 465

7.5.3.4.1 visited-realm attribute p. 465

7.5.3.4.2 secondary-realm attribute p. 466

7.5.3.4.3 omr-s-cksum attribute p. 466

7.5.3.4.4 omr-m-cksum attribute p. 466

7.5.3.4.5 omr-codecs attribute p. 467

7.5.3.4.6 omr-m-att attribute p. 467

7.5.3.4.7 omr-s-att attribute p. 467

7.5.3.4.8 omr-m-bw attribute p. 467

7.5.3.4.9 omr-s-bw attribute p. 468

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

7.5.4.1 General p. 468

7.5.4.2 Semantics p. 468

7.5.4.3 Syntax p. 469

7.5.4.4 IANA registration p. 469

7.5.4.4.1 tra-contact p. 469

7.5.4.4.2 tra-m-line p. 470

7.5.4.4.3 tra-att p. 470

7.5.4.4.4 tra-bw p. 470

7.5.4.4.5 tra-SCTP-association p. 471

7.5.4.4.6 tra- media-line-number p. 471

7.5.5 Void

7.5.6 SDP content attribute values |R17| p. 471

7.5.6.1 General p. 471

7.5.6.2 SDP "a=content" attribute "g.3gpp.announcement-no-confirmation" value p. 471

7.5.6.2.1 General p. 471

7.5.6.2.2 IANA registration for values of "a=content" attribute p. 472

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

7.6.1 General p. 472

7.6.2 Document Type Definition p. 472

7.6.3 XML Schema description p. 472

7.6.4 MIME type definition |R8| p. 474

7.6.4.1 Introduction p. 474

7.6.4.2 Syntax p. 474

7.6.4.3 Operation p. 474

7.6.5 IANA Registration |R8| p. 474

7.7 SIP timers p. 475

7.8 IM CN subsystem timers p. 477

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

7.9.1 General p. 479

7.9.2 Definition of media feature tag g.3gpp.icsi-ref p. 479

7.9.3 Definition of media feature tag g.3gpp.iari-ref p. 479

7.9.4 Void

7.9.5 Void

7.9.6 Void

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

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

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