Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.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…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

8  SIP compressionWord‑p. 485

8.1  SIP compression procedures at the UE

8.1.1  SIP compression

If 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", "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", then the UE shall support:
  • SigComp as specified in RFC 3320 and as updated by RFC 4896; and
  • the additional requirements specified in RFC 5049, with the exception that the UE shall take a State Memory Size of at least 4096 bytes as a minimum value.
If 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", "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", then the UE may support:
  • the negative acknowledgement mechanism specified in RFC 4077.
When using SigComp the UE shall send compressed SIP messages in accordance with RFC 3486. When the UE will create the compartment is implementation specific, but the compartment shall not be created until a set of security associations or a TLS session is set up if signalling security is in use. The UE shall finish the compartment when the UE is deregistered. The UE shall alow state creations and announcements only for messages received in a security association.
If the UE supports SigComp:
  • the UE shall support the SIP dictionary specified in RFC 3485 and as updated by RFC 4896. If compression is enabled, the UE shall use the dictionary to compress the first message; and
  • if the UE supports the presence user agent or watcher roles as specified in table A.3A/2 and table A.3A/4, the UE may support the presence specific dictionary specified in RFC 5112.
The use of SigComp is not re-negotiated between initial registration and deregistration.
Up

8.1.2  Compression of SIP requests and responses transmitted to the P-CSCF

In normal operation the UE should send the generated requests and responses transmitted to the P-CSCF:
  • compressed according to subclause 8.1.1, if the P-Access-Network-Info header field of the initial registration message includes a value of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E-UTRAN-ProSe-UNR", "3GPP-NR-FDD", "3GPP-NR-TDD", "3GPP-NR-U-FDD", "3GPP-NR-U-TDD", "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";
  • uncompressed, if the P-Access-Network-Info header field of the initial registration message includes a value of "3GPP-E-UTRAN-FDD", "3GPP-E-UTRAN-TDD", "3GPP-E-UTRAN-ProSe-UNR", "3GPP-NR-FDD", "3GPP-NR-TDD","3GPP-NR-U-FDD" or "3GPP-NR-U-TDD".
In other cases where SigComp is supported, the UE need not compress the requests and responses.
Up

8.1.3  Decompression of SIP requests and responses received from the P-CSCFWord‑p. 486
If the UE supports SigComp, then the UE shall decompress the compressed requests and responses received from the P-CSCF according to subclause 8.1.1.
If the UE detects a decompression failure at the P-CSCF, the recovery mechanism is implementation specific.

8.2  SIP compression procedures at the P-CSCF

8.2.1  SIP compression

The P-CSCF shall support:
  • SigComp as specified in RFC 3320 and as updated by RFC 4896; and
  • the additional requirements specified in RFC 5049, with the exception that the P-CSCF shall take a State Memory Size of at least 4096 bytes as a minimum value.
The P-CSCF may support:
  • the negative acknowledgement mechanism specified in RFC 4077.
When using SigComp the P-CSCF shall send compressed SIP messages in accordance with RFC 3486. When the P-CSCF will create the compartment is implementation specific, but the compartment shall not be created until a set of security associations are set up. The P-CSCF shall finish the compartment when the UE is deregistered. The P-CSCF shall allow state creations and announcements only for messages received in a security association.
The P-CSCF:
  • shall support the SIP dictionary specified in RFC 3485 and as updated by RFC 4896. If compression is enabled, the P-CSCF shall use the dictionary to compress the first message; and
  • may support the presence specific dictionary specified in RFC 5112.
Up

8.2.2  Compression of SIP requests and responses transmitted to the UE

For all SIP transactions on a specific security association where the security association was established using a REGISTER request from the UE containing a P-Access-Network-Info header field which included a value of "3GPP-GERAN","3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E-UTRAN-ProSe-UNR", "3GPP-NR-FDD", "3GPP-NR-TDD","3GPP-NR-U-FDD", "3GPP-NR-U-TDD", "3GPP-E-UTRAN-FDD", "3GPP-E-UTRAN-TDD", "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", and the UE has indicated that it supports SigComp and is willing to receive compressed messages in accordance with RFC 3486, then the P-CSCF should compress the requests and responses transmitted to the UE according to subclause 8.2.1. In other cases where SigComp is supported, it need not.
Up

8.2.3  Decompression of SIP requests and responses received from the UEWord‑p. 487
The P-CSCF shall decompress the compressed requests and responses received from the UE according to subclause 8.2.1.
If the P-CSCF detects a decompression failure at the UE, the recovery mechanism is implementation specific.

9  IP-Connectivity Access Network aspects when connected to the IM CN subsystem

9.1  Introduction

A UE accessing the IM CN subsystem and the IM CN subsystem itself utilises the services supported by the IP-CAN to provide packet-mode communication between the UE and the IM CN subsystem. General requirements for the UE on the use of these packet-mode services are specified in this clause.
Possible aspects particular to each IP-CAN is described separately for each IP-CAN.

9.2  Procedures at the UE

9.2.1  Connecting to the IP-CAN and P-CSCF discovery

Prior to communication with the IM CN subsystem, the UE shall:
  1. establish a connection with the IP-CAN;
  2. obtain an IP address using either the standard IETF protocols (e.g., DHCP or IPCP) or a protocol that is particular to the IP-CAN technology that the UE is utilising. The UE shall fix the obtained IP address throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the last deregistration; and
  3. acquire a P-CSCF address(es).
    The UE may acquire an IP address via means other than the DHCP. In this case, upon acquiring an IP address, the UE shall request the configuration information (that includes the DNS and P-CSCF addresses) from the DHCP server.
    The methods for acquiring a P-CSCF address(es) are:
    1. Employ Dynamic Host Configuration Protocol for IPv4 RFC 2131 or for IPv6 (DHCPv6) RFC 3315. Employ the DHCP options for SIP servers RFC 3319 or, for IPv6, RFC 3361. Employ the DHCP options for Domain Name Servers (DNS) RFC 3646.
      The UE shall either:
      • in the DHCP query, request a list of SIP server domain names of P-CSCF(s) and the list of Domain Name Servers (DNS); or
      • request a list of SIP server IP addresses of P-CSCF(s).
    2. Obtain the P-CSCF address(es) by employing a procedure that the IP-CAN technology supports. (e.g. GPRS).
    3. The UE may use pre-configured P-CSCF address(es) (IP address or domain name). For example:
      1. The UE selects a P-CSCF from the list stored in ISIM or IMC;
      2. The UE selects a P-CSCF from the list in IMS management object.
      When acquiring a P-CSCF address(es), the UE can freely select either method I or II or III.
    The UE may also request a DNS Server IP address(es) as specified in RFC 3315 and RFC 3646 or RFC 2131.
When:
  • the UE obtains a connection with the IP-CAN by performing handover of the connection from another IP-CAN;
  • IP address of the UE is not changed during the handover; and
  • the UE already communicates with the IM CN subsystem via the connection with the other IP-CAN, e.g. the UE determines that its contact with host portion set to the UE IP address (or FQDN of the UE) associated with the connection with the other IP-CAN has been bound to a public user identity;
the UE shall continue using the P-CSCF address(es) acquired in the other IP-CAN.
Up

9.2.2  Handling of the IP-CANWord‑p. 488
The means to ensure that appropriate resources are available for the media flow(s) on the IP-CAN(s) related to a SIP session is dependant on the characteristics for each IP-CAN, and is described separately for each IP-CAN in question.
GPRS is described in Annex B. xDSL is described in Annex E. DOCSIS is described in Annex H. EPS is described in Annex L. cdma2000® packet data subsystem is described in Annex M. EPC via cdma2000® HRPD is described in Annex O. cdma2000® Femtocell network is described in Annex Q. Evolved Packet Core (EPC) via WLAN is described in Annex R. DVB-RCS2 is described in Annex S. 5GS is described in Annex U. If a particular handling of the IP-CAN is needed for emergency calls, this is described in the annex for each access technology.
Up

9.2.2A  P-CSCF restoration procedure |R9|

The UE may support P-CSCF restoration procedures.
An IP-CAN may provide means for detecting a P-CSCF failure.
An UE supporting the P-CSCF restoration procedure should either use the keep-alive procedures described in RFC 6223 or the procedure provided by a IP-CAN for monitoring the P-CSCF status.
Up

9.2.3  Special requirements applying to forked responses

Since the UE does not know that forking has occurred until a second provisional response arrives, the UE will request the radio/bearer resources as required by the first provisional response. For each subsequent provisional response that may be received, different alternative actions may be performed depending on the requirements in the SDP answer:
  • the UE has sufficient radio/bearer resources to handle the media specified in the SDP of the subsequent provisional response, or
  • the UE must request additional radio/bearer resources to accommodate the media specified in the SDP of the subsequent provisional response.
When an 199 (Early Dialog Terminated) response for the INVITE request is received for an early dialogue, the UE shall release reserved radio/bearer resources associated with that early dialogue.
When the first final 200 (OK) response for the INVITE request is received for one of the early dialogs, the UE proceeds to set up the SIP session using the radio/bearer resources required for this session. Upon the reception of the first final 200 (OK) response for the INVITE request, the UE shall release all unneeded radio/bearer resources.
Up

10  Media control |R8|Word‑p. 489

10.1  General

The choice of which media control methods below to use is service specific, it depends on the functionality required and physical deployment architectures.
Combinations of the capabilities below are supported by the use of the control channel framework RFC 6230 with associated media control packages.
For security, the principles and protocols described in TS 33.210 shall take precedence over those specified in the referenced specifications in this clause.
For codecs, those described in access specific specifications shall take precedence over those specified in the referenced specifications in this clause.
Up

10.2  Procedures at the AS

10.2.1  General

An AS requesting charging information and authorisation for specific media operations and media usage controlled by the MRFC shall use RFC 6230 together with appropriate packages.
An AS may support delegation of an XML (such as CCXML or SCXML) script execution to an MRFC. An AS supporting delegation of XML script execution shall use RFC 6230 together with appropriate packages.
The packages, or extensions to existing packages using RFC 6230 framework are not specified in this release.
The AS may support the media server resource consumer interface as defined by RFC 6917. If supported the AS can support either the in-line mode or the query mode or both.
Up

10.2.2  Tones and announcements

10.2.2.1  General

An AS may support control of the MRFC for tones and announcements. An AS supporting control of the MRFC for tones and announcements shall support one or more of the following methods:
  • RFC 4240 announcement service;
  • RFC 5552; or
  • RFC 6230 and RFC 6231.
  • 10.2.2.2  Basic network media services with SIPWord‑p. 490
    The AS may support control of the MRFC for basic announcements by the use of RFC 4240 and the announcement service described in RFC 4240 subclause 3.
    The media control commands are carried between the AS and the MRFC either directly over the Mr' interface or via the S-CSCF over the ISC and Mr interfaces.
    The AS shall provide remote prompts to the MRFC using the AS-MRFC Cr interface.
    Up

    10.2.2.3  SIP interface to VoiceXML media services

    The AS may support control of the MRFC for voice dialogs by the use of RFC 5552.
    The media control commands are carried between the AS and the MRFC either directly over the Mr' interface or via the S-CSCF over the ISC and Mr interfaces.
    The AS shall provide remote prompts and scripts to the MRFC using the AS-MRFC Cr interface.
    Data shall be returned to the AS from the MRFC by either use of the AS-MRFC Cr interface (subclause 4.1 of RFC 5552), via the ISC interface (subclause 4.2 of RFC 5552) or via the Mr' interface.
    Up

    10.2.2.4  Media control channel framework and packages

    The AS may support control of the MRFC for interactive voice response by the use of RFC 6231 and RFC 6230.
    The AS shall provide remote prompts, media control commands and scripts to the MRFC using the AS-MRFC Cr interface.
    The AS shall implement the control client role as described in RFC 6230.

    10.2.3  Ad-hoc conferences

    10.2.3.1  General

    An AS may support control of the MRFC for ad-hoc conferencing. An AS supporting control of the MRFC for ad-hoc conferencing shall support one or more of the following methods:
  • RFC 4240 conference service; or
  • RFC 6230 and RFC 6505.
  • 10.2.3.2  Basic network media services with SIP

    The AS may support control of the MRFC for basic conferencing by the use of RFC 4240 and the conference service described in RFC 4240 subclause 5.
    The media control commands are carried between the AS and the MRFC either directly over the Mr' interface or via the S-CSCF over the ISC and Mr interfaces.

    10.2.3.3  Media control channel framework and packages

    The AS may support control of the MRFC for conference mixing by the use of RFC 6505 and RFC 6230.
    An AS may support control of the MRFC for floor controlled conferences (as specified in TS 24.147), via the use of RFC 6230 together with appropriate packages. The packages, or extensions to existing packages using RFC 6230 framework are not specified in this release.
    An AS may support control of the MRFC for session-mode messaging conferences (as specified in TS 24.247), via the use of RFC 6230 together with appropriate packages. The packages, or extensions to existing packages using RFC 6230 framework are not specified in this release.
    The AS shall provide media control commands to the MRFC using the AS-MRFC Cr interface.
    The AS shall implement the control client role as described in RFC 6230.
    Up

    10.2.4  TranscodingWord‑p. 491

    10.2.4.1  General

    An AS may support control of the MRFC for transcoding. An AS supporting control of the MRFC for transcoding shall support one or more of the following methods:
  • RFC 4240 conference service; or
  • RFC 6230 and RFC 6505.
  • 10.2.4.2  Basic network media services with SIP

    The AS may support control of the MRFC for transcoding by the use of RFC 4240 and the conference service described in RFC 4240 subclause 5.
    The media control commands are carried between the AS and the MRFC either directly over the Mr' interface or via the S-CSCF over the ISC and Mr interfaces.

    10.2.4.3  Media control channel framework and packages

    The AS may support control of the MRFC for transcoding by the use of RFC 6505 and RFC 6230.
    The AS shall provide media control commands to the MRFC using the AS-MRFC Cr interface.
    The AS shall implement the control client role as described in RFC 6230.

    10.3  Procedures at the MRFC

    10.3.1  General

    An MRFC required to generate charging information and authorize requests from an AS for specific media operations and media usage shall support RFC 6230 together with appropriate packages.
    An MRFC may support delegated XML (such as CCXML or SCXML) script execution from an AS. An MRFC supporting delegation of XML script execution shall use RFC 6230 together with appropriate packages.
    The packages, or extensions to existing packages using RFC 6230 framework above are not specified in this release.
    The MRFC may support the media server resource publish interface as defined by RFC 6917.
    Up

    10.3.2  Tones and announcements

    10.3.2.1  General

    An MRFC may support control of tones and announcements. An MRFC supporting control of tones and announcements shall support one or more of the following methods:
  • RFC 4240 announcement service;
  • RFC 5552; or
  • RFC 6230 and RFC 6231.
  • 10.3.2.2  Basic network media services with SIPWord‑p. 492
    The MRFC may support control of basic announcements by the use of RFC 4240 and the announcement service described in RFC 4240 subclause 3.
    The media control commands are received from the AS either directly over the Mr' interface or via the S-CSCF over the ISC and Mr interfaces.
    The MRFC shall fetch remote prompts from the AS using the AS-MRFC Cr interface.
    The MRFC acts as the media server described in RFC 4240.
    Up

    10.3.2.3  SIP interface to VoiceXML media services

    The MRFC may support control of voice dialogs by the use of RFC 5552.
    The media control commands are received from the AS either directly over the Mr' interface or via the S-CSCF over the ISC and Mr interfaces.
    The MRFC shall fetch via the AS-MRFC Cr interface the remote prompts and scripts from the address included in the "voicexml" URI parameter, if received, in the Request-URI of the SIP INVITE request.
    Data shall be returned to the AS from the MRFC by either use of the AS-MRFC Cr interface (subclause 4.1 of RFC 5552), via the ISC interface (subclause 4.2 of RFC 5552) or via the Mr' interface.
    The MRFC acts as the VoiceXML media server described in RFC 5552.
    Up

    10.3.2.4  Media control channel framework and packages

    The MRFC may support control of interactive voice response by the use of RFC 6231 and RFC 6230.
    The MRFC shall fetch remote prompts and scripts from the MRFC using the AS-MRFC Cr interface. The MRFC shall send media control command responses and notifications to the AS using the AS-MRFC Cr interface.
    The MRFC shall implement the control server role as described in RFC 6230.
    Up

    10.3.3  Ad-hoc conferences

    10.3.3.1  General

    An MRFC may support control of ad-hoc conferencing. An MRFC supporting control of ad-hoc conferencing shall support one or more of the following methods:
  • RFC 4240 conference service; or
  • RFC 6230 and RFC 6505.
  • 10.3.3.2  Basic network media services with SIP

    The MRFC may support control of basic conferencing by the use of RFC 4240 and the conference service described in RFC 4240 subclause 5.
    The media control commands are received from the AS either directly over the Mr' interface or via the S-CSCF over the ISC and Mr interfaces.
    The MRFC acts as the media server described in RFC 4240.
    Up

    10.3.3.3  Media control channel framework and packages

    The MRFC may support control of conference mixing by the use of RFC 6505 and RFC 6230.
    An MRFC may support control of floor controlled conferences (as specified in TS 24.147), via the use of RFC 6230 together with appropriate packages. The packages, or extensions to existing packages using RFC 6230 framework are not specified in this release. In addition, the MRFC may support the procedures for a multi-stream multiparty multimedia conference using simulcast defined in TS 26.114 Annex S.
    An MRFC may support control of session-mode messaging conferences (as specified in TS 24.247), via the use of RFC 6230 together with appropriate packages. The packages, or extensions to existing packages using RFC 6230 framework are not specified in this release.
    The MRFC shall send media control command responses and notifications to the AS using the AS-MRFC Cr interface.
    The MRFC shall implement the control server role as described in RFC 6230.
    Up

    10.3.4  TranscodingWord‑p. 493

    10.3.4.1  General

    An MRFC may support control of transcoding. An MRFC supporting control of transcoding shall support one or more of the following methods:
  • RFC 4240 conference service;
  • RFC 6230 and RFC 6505; or
  • RFC 4117. This is detailed in subclause 5.7.5.6.
  • Up

    10.3.4.2  Basic network media services with SIP

    The MRFC may support control of transcoding by the use of RFC 4240 and the conference service described in RFC 4240 subclause 5.
    The media control commands are received from the AS either directly over the Mr' interface or via the S-CSCF over the ISC and Mr interfaces.
    The MRFC acts as the media server described in RFC 4240.
    Up

    10.3.4.3  Media control channel framework and packages

    The MRFC may support control of transcoding by the use of RFC 6505 and RFC 6230.
    The MRFC shall send media control command responses and notifications to the AS using the AS-MRFC Cr interface.
    The MRFC shall implement the control server role as described in RFC 6230.

    10.4  Procedures at the MRB |R11|

    The MRB shall support:
    1. the in-line unaware MRB interface.
    as defined in RFC 5917.
    The MRB may support:
    1. the media server resource publish interface; and
    2. the media server resource consumer interface;
    as defined in RFC 6917.

    Up   Top   ToC