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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 <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:
the first child element of the <alternative-service> element; or
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.
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.
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:
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.
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.
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
0s for TCP/SCTP
0s for TCP/SCTP
0s for TCP/SCTP
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
0s for TCP/SCTP
0s for TCP/SCTP
0s for TCP/SCTP
Timer J
64*T1 for UDP
64*T1 for UDP
64*T1 for UDP
Wait time for non-INVITE request retransmits
0s for TCP/SCTP
0s for TCP/SCTP
0s for TCP/SCTP
Timer K
T4 for UDP
T4 for UDP
T4 for UDP
Wait time for response retransmits
0s for TCP/SCTP
0s for TCP/SCTP
0s for TCP/SCTP
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.
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-reg-retry
Configurable value between 3 seconds and 5 seconds
not applicable
not applicable
The 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-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.
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)
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"
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:
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:
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.
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:
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"