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…

 

6.6  Procedures at the ASWord‑p. 382

6.6.1  General |R12|

Since an AS may provide a wide range of different services, procedures for the SDP usage for an AS acting as originating UA, terminating UA or third-party call control role are dependent on the service provided to the UA and on the capabilities on the remote UA. There is no special requirements regarding the usage of the SDP, except the requirements for the SDP capabilities described in the following paragraphs and clause A.3:
  1. Providing that an INVITE request generated by an AS contains an SDP message body, the AS has the capability of reflecting the originating AS's capabilities, desired QoS and precondition requirements for the session in the SDP message body.
  2. When the AS sends a 183 (Session Progress) response with an SDP message body including one or more "m=" media types, it has the capability of requesting confirmation for the result of the resource reservation at the originating endpoint.
When an AS acts as a B2BUA, and it controls media resources using an MRF, it may support OMR. When the AS supports OMR, and it controls media resources using an MRF, it shall also perform the procedures described in TS 29.079.
Up

6.6.2  Transcoding |R12|

The AS shall send an SDP offer to the MRFC with the codecs supported by the caller and the codecs to be offered towards the callee, and the IP address and port information received from caller, in seperate media lines. When receiving an SDP answer from the MRFC, the AS shall forward the received selected codecs and IP address and port information in the callee's media line(s) as an SDP offer towards the callee.
When the callee provides an SDP answer with selected codecs and IP address and port information, the AS shall forward this information within a new SDP offer to the MRFC. When receiving the corresponding SDP answer from the MRFC, the AS shall forward the address and port information within the caller's media line(s) as an SDP answer towards the caller.
The codecs offered for transcoding are subject to network policy which shall be according to clause T.2.
Up

6.6.3  AS procedures to support WebRTC media optimization procedure |R13|

When an AS acts as a B2BUA, and it controls media resources using an MRF, it may support switching to transparent media for WebRTC when those media have been negotiated, as specified in annex U.2.4 of TS 23.228. An AS that supports switching to transparent media for WebRTC shall apply the procedures in the present subclause.
If the AS receives an SDP offer that contains any "tra-contact" SDP attribute, and the AS decides to include an MRF in the media path, the AS shall:
  1. include the address information as received from the MRF in that contact line and also encapsulate the address information into each received "tra-contact" attribute, replacing previous information; and
  2. transparently pass all received "tra-m-line", "tra-att", "tra-SCTP-association", "tra-media-line-number" and "tra-bw" SDP attributes.
If an AS receives an SDP answer and the SDP answer includes "tra-m-line" media level SDP attributes, the AS shall:
  1. configure the MRF to transparently pass the media described in the received "tra-m-line", "tra-att", "tra-SCTP-association", and "tra-bw" SDP attributes; and
  2. transparently pass all received "tra-m-line", "tra-att", "tra-SCTP-association" and "tra-bw" SDP attributes.
Up

6.7  Procedures at the IMS-ALG functionality |R6|Word‑p. 383

6.7.1  IMS-ALG in IBCF |R9|

6.7.1.1  General |R10|

When the IBCF acts as an IMS-ALG, it makes procedures as for an originating UA and terminating UA. The IMS-ALG acts as a B2BUA. The general treatment of the SDP information between originating UA and terminating UA is described in TS 29.162. For the use of the IMS-ALG for specific capabilities, additional procedures are defined in subsequent subclauses.
Subject to local policy, the IBCF shall prohibit the negotiation of ECN during SDP offer/answer exchanges associated with multimedia priority service by removing any ECN attribute "a=ecn-capable-rtp" from the SDP offer and shall not invoke ECN for SIP transactions associated with multimedia priority service.
Up

6.7.1.2  IMS-ALG in IBCF for support of ICE |R10|

6.7.1.2.1  General
This subclause describes procedures of an IBCF to support ICE as defined in RFC 5245.
If no TrGW is inserted, an IBCF may transparently pass ICE related SDP attibutes to support ICE. The remaining procedures in this subclause are only applicable if the IBCF is inserting a TrGW on the media plane.
When the IBCF with attached TrGW receives SDP candidate information from the SDP offerer the IBCF shall not forward the candidate information towards the SDP answerer. When the IBCF receives SDP candidate information from the SDP answerer the IBCF shall not forward the candidate information towards the SDP offerer. The remaining procedures in this subclause are optional.
The IBCF with attached TrGW performs separate ICE procedures towards the SDP offerer and the SDP answerer. The usage of ICE is negotiated separately with the SDP offerer and SDP answerer, and ICE may be applied independently at either side. Furthermore, the IBCF may be configured to apply ICE procedures only towards one network side, e.g. towards the IM CN subsystem it belongs to.
Since the IBCF is not located behind a NAT, it does not request the TrGW to generate keep-alive messages even when acting as a full ICE entity. The IBCF only requests the TrGW to terminate and generate STUN messages used for the candidate selection procedures.
Since the IBCF is not located behind a NAT the IBCF shall only include host candidates in SDP offers and answers generated by the IBCF.
Up
6.7.1.2.2  IBCF full ICE procedures for UDP based streams
6.7.1.2.2.1  General
This subclause describes the IBCF full ICE procedures for UDP based streams.
6.7.1.2.2.2  IBCF receiving SDP offerWord‑p. 384
When the IBCF receives an SDP offer including ICE candidate information, the IBCF shall send the candidate information for each UDP based stream received in the SDP offer towards the TrGW. The IBCF will request the TrGW to reserve media- and STUN resources towards the SDP offerer, based on the candidate information, in order to allow the TrGW to perform the necessary connectivity checks per the ICE procedures.
If the SDP offerer is acting as an ICE controller entity the IBCF shall act as an ICE controlled entity in the direction towards the SDP offerer. If the SDP offerer is acting as an ICE controlled entity the IBCF shall act as an ICE controller entity in the direction towards the SDP offerer.
Up
6.7.1.2.2.3  IBCF sending SDP offer
Prior to sending an SDP offer, the IBCF may choose to apply related ICE procedues, e.g. if it expects to interact with terminals applying procedures as described in subclause K.5.2, and if both the IBCF and TrGW also support ICE procedures. To invoke these ICE procedures, the IBCF will request the TrGW to reserve media- and STUN resources towards the SDP answerer for each UDP based media stream and include a host candidate attribute for each UDP based stream in the SDP offer, providing the reserved address and port at the TrGW as destination.
The IBCF shall always act as an ICE controller entity towards the SDP answerer.
Up
6.7.1.2.2.4  IBCF receiving SDP answer
When the IBCF receives an SDP answer including ICE candidate information, the IBCF will send the candidate information for each UDP based stream received in the SDP answer towards the TrGW.
The IBCF will request the TrGW to perform ICE candidate selection procedures towards the SDP answerer. The IBCF will request the TrGW to inform the IBCF, for each UDP stream, which candidate pair has been selected towards the SDP answerer, once the candidate selection procedure towards the SDP answerer has finished.
If the TrGW indicates to the IBCF that, for at least one UDP stream, the selected candidate pair does not match the c- and m- line address information for the associated UDP stream, exchanged between the IBCF and the SDP answerer, and the IBCF acts an ICE controller entity towards the SDP answerer, the IBCF shall send a new offer towards the SDP answerer in order to allign the c- and m- lines address information with the chosen candidate pair for the associated UDP stream.
Up
6.7.1.2.2.5  IBCF sending SDP answer
When the IBCF generates an SDP answer for an offer that included ICE candidate information, the IBCF will request the TrGW to reserve media- and STUN resources towards the SDP offerer for each UDP based media stream and include an SDP host candidate attribute for each UDP based stream in the SDP answer, providing the reserved address and port at the TrGW as destination.
The IBCF shall in the generated SDP answer include host candidate information which matches the c- and m line information for the associated UDP stream in the SDP answer.
The IBCF will request the TrGW to perform ICE candidate selection procedures towards the SDP offerer. The IBCF will request the TrGW to inform the IBCF, for each UDP stream, which candidate pair has been selected towards the SDP offerer, once the candidate selection procedure towards the SDP answerer has finished.
If the TrGW indicates to the IBCF that the selected candidate pair towards the SDP offerer does not match the c- and m- line address information for the associated UDP stream, exchanged between the IBCF and the SDP offerer, and the IBCF acts an ICE controller entity towards the SDP offerer, the IBCF shall send an offer towards the SDP offerer (which will now act as an SDP answerer) in order to allign the c- and m- line address information with the chosen candidate pair for the associated UDP stream.
Up
6.7.1.2.3  IBCF ICE lite procedures for UDP based streams
When the IBCF is using ICE lite procedures for UDP based streams, the IBCF procedures are identical as described in subclause 6.7.1.2.2, with the following exceptions:
  • The IBCF always acts as an ICE controlled entity towards the SDP offerer and towards the SDP answerer, and;
  • The IBCF requests the TrGW to perform ICE lite candidate selection procedures, as defined in ICE
6.7.1.2.4  ICE procedures for TCP based streamsWord‑p. 385
6.7.1.2.4.1  General
The IBCF shall terminate ICE procedures for TCP based streams. Instead the IBCF will use the mechanism defined in RFC 4145 for establishing TCP based streams, as defined in RFC 6544.
An entity that supports ICE continues the ICE procedures for UDP based streams, even if no candidates are provided for TCP based streams.
Up
6.7.1.2.4.2  IBCF receiving SDP offer
When the IBCF receives an SDP offer, the IBCF shall ignore the candidate attributes for TCP based streams. The IBCF shall not send the candidate information for TCP based streams towards the TrGW.
6.7.1.2.4.3  IBCF sending SDP offer
When the IBCF generates an SDP offer the IBCF shall include an "actpass" setup attribute, as defined in RFC 4145, for each TCP based stream, which will cause the SDP answerer to initiate the TCP connections towards the TrGW. The IBCF shall not include any candidate attributes for TCP based streams in the SDP offer.
6.7.1.2.4.4  IBCF receiving SDP answer
Since the IBCF does not include candidates in the SDP offer towards the SDP answerer, there are no ICE specific procedures when the IBCF receives an SDP answer.
6.7.1.2.4.5  IBCF sending SDP answer
When the IBCF generates an SDP answer the IBCF shall include a "passive" setup attribute, as defined in RFC 4145, for each TCP based stream, which will cause the SDP offerer to initiate the TCP connections towards the TrGW. The IBCF shall not include any candidate attributes for TCP based streams in the SDP answer.

6.7.1.3  IMS-ALG in IBCF for transcoding |R12|

Before forwarding the SDP offer to the answerer, the IBCF may add to the selected media one or more codecs to the codec list contained in the SDP offer. The codecs added to the SDP offer are based on local policy and shall be in accordance with the requirements of clause T.2.
Upon receipt of an SDP answer, the IBCF shall inspect the list of the returned codecs and proceed as follows:
  • if the list contains at least one of the codecs belonging to the original SDP offer, the IBCF shall not invoke the transcoding function; and
  • if the list contains none of the codecs belonging to the original SDP offer, the IBCF shall select one of the returned codecs introduced in the answer and invoke the transcoding function. In order to perform the transcoding the IBCF shall select one of the codecs originally offered and set to a non-zero port value the related media stream in the answer sent to the offerer.
The IBCF shall remove from the SDP the codecs added to the original SDP offer before forwarding the SDP answer to the offerer.
Up

6.7.1.4  IMS-ALG in IBCF for NA(P)T and NA(P)T-PT controlled by the IBCF |R12|Word‑p. 386
6.7.1.4.1  General
This subclause describes the IBCF procedures for supporting the scenario where IP address and/or port conversions occur at the TrGW level in the media path between the UE and the backbone. Two types of address conversions are covered:
  • IP version interworking (NA(P)T-PT); and
  • IP address/port translation (NA(P)T).
When the IBCF performs procedures for IBCF controlled NA(P)T and NA(P)T-PT, the IBCF shall modify the IP address(es) and port numbers (in case of NA(P)T) in SDP offers and answers, based on the IP address(es) and port number(s) received from the TrGW, as described in subclause 6.7.2.1.
For terminating sessions the IBCF may towards a UE performing the functions of an external attached network indicate in the SDP offer alternate IP address versions (IPv4 and IPv6) by inserting two "altc" attributes as defined in RFC 6947. The order of setting the two IP addresses in the two "altc" SDP attributes shall be based on local policy. The insertion of the "altc" attributes is independent of their presence in the received SDP offer.
If the IBCF sends an initial INVITE request that includes only an IPv6 address in the SDP offer, and receives a 488 (Not Acceptable Here) response with 301 Warning header field indicating "incompatible network address format", the IBCF shall send an ACK as per standard SIP procedures. Subsequently, based on operator policy, the IBCF may, by performing the IP version interworking, acquire an IPv4 address or use an existing IPv4 address, and send a new initial INVITE request to the same destination containing only the IPv4 address in the SDP offer.
Up

6.7.1.5  IMS-ALG procedure in IBCF to support WebRTC media optimization procedure |R13|

The IMS-ALG in the IBCF may support switching to transparent media for WebRTC when those media have been negotiated, as specified in annex U.2.4 of TS 23.228. An IMS-ALG that supports switching to transparent media for WebRTC shall apply the procedures in the present subclause.
If the IMS-ALG receives an SDP offer that contains any "tra-contact" SDP attribute, and the IMS-ALG decides to include a TrGw in the media path, the IMS-ALG shall:
  1. include the address information as received from the TrGW in that contact line and also encapsulate the address information into each received "tra-contact" attribute, replacing previous information; and
  2. transparently pass all received "tra-m-line", "tra-att", "tra-SCTP-association", "tra-media-line-number" and "tra-bw" SDP attributes.
If an IMS-ALG receives an SDP answer and the SDP answer includes "tra-m-line" media level SDP attributes, the IMS-ALG shall:
  1. configure the TrGW to transparently pass the media described in the received "tra-m-line", "tra-att", "tra-SCTP-association", and "tra-bw" SDP attributes; and
  2. transparently pass all received "tra-m-line", "tra-att", "tra-SCTP-association" and "tra-bw" SDP attributes.
Up

6.7.2  IMS-ALG in P-CSCF |R9|Word‑p. 387

6.7.2.1  General |R10|

This subclause specifies the general procedures for the support of SDP in IMS-ALG within the P-CSCF. For the use of the IMS-ALG for specific capabilities, additional procedures are defined in subsequent subclauses.
When the IMS-ALG receives an SDP offer, it shall create a new SDP offer, based the contents of the received SDP offer, modified according to procedures and policies associated with specific capabilities that the IMS-ALG is used for, according to capabilities supported by the IMS-AGW, and to provide the IP address and port information received by the IMS-AGW.
When the IMS-ALG receives an SDP answer, it shall create a new SDP answer, to respond to the originally received SDP offer, modified according to the same procedures and policies that were used to modify the SDP offer.
The P-CSCF may receive multiple provisional responses with an SDP answer due to forking of a request before the first final answer is received. For each SDP answer received in such subsequent provisional responses, the P-CSCF shall apply the procedure in this subclause.
After the session is established, it is possible for both ends of the session to change the media connection data for the session. When the P-CSCF receives a SDP offer/answer where port number(s) or IP address(es) is/are included, there are three different possibilities:
  • IP address(es) or/and port number(s) have been added;
  • IP address(es) and port number(s) have been reassigned to the end points; or
  • no change has been made to the IP address(es) and port number(s).
Up

6.7.2.2  IMS-ALG in P-CSCF for media plane security |R10|

When the P-CSCF acts as an IMS-ALG, it acts as a B2BUA and modifies the SDP as described as described in TS 23.334.
If the P-CSCF indicated support for end-to-access-edge media security using SDES during registration:
  1. upon receiving an SDP offer from the served UE containing an end-to-access-edge protected RTP based media, i.e. a RTP media stream:
    • transported using the SRTP transport protocol as defined in RFC 3711;
    • with an SDP crypto attribute as defined in RFC 4568; and
    • with the SDP "a=3ge2ae:requested" attribute;
    the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 as far as SDP and SRTP is concerned, and shall:
    • if the SDP offer contains a Transport Protocol Capability SDP attribute (see RFC 5939) offering:
      1. "RTP/SAVPF" transport, e.g. "a=tcap:x RTP/SAVPF", replace this transport with "RTP/AVPF" within that attribute; and
      2. "RTP/SAVP" transport, e.g. "a=tcap:x RTP/SAVP", replace this transport with "RTP/AVP" within that attribute; and
    • strip the SDP "a=3ge2ae:requested" attribute and the SDP crypto attribute from the end-to-access-edge protected RTP based media of the received SDP offer; and
  2. upon sending an SDP answer to the SDP offer from the served UE, for each end-to-access-edge protected RTP based media of the SDP offer from the served UE which is accepted in the SDP answer, the P-CSCF will act as defined in TS 23.334 as far as SDP and SRTP is concerned and shall:
    • indicate the SRTP transport protocol according to RFC 3711 and the profile defined in TS 33.328; and
    • include a SDP crypto attribute according to RFC 4568 and the profile defined in TS 33.328.
If the served UE indicated support for end-to-access-edge media security using SDES, during registration, and the P-CSCF indicated support for end-to-access-edge 2ae-media security using SDES during registration:
  1. upon receiving an SDP offer from remote user with an RTP based media, for each end-to-access-edge protected RTP based media, i.e. a RTP based media except those for which the result of the SDP offer / answer exchange results in the application of an end-to-end media security mechanism, the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 as far as SDP and RTP is concerned, and shall:
    • remove any SDP crypto attribute and any "a=acap:x crypto" SDP attribute (see RFC 5939);
    • if the SDP offer contains any potential configuration(s) using "RTP/SAVPF" transport or "RTP/SAVP" transport, as offered in corresponding Transport Protocol Capability SDP attribute(s) (see RFC 5939), (e.g. "a=tcap:x RTP/AVPF a=pcfg:y t=x"), remove those potential configuration(s);
    • if the SDP offer contains a Transport Protocol Capability SDP attribute (see RFC 5939) offering:
      1. "RTP/AVPF" transport (e.g. "a=tcap:x RTP/AVPF"), replace this transport with "RTP/SAVPF" within that attribute; and
      2. "RTP/AVP" transport (e.g. "a=tcap:x RTP/AVP"), replace this transport with "RTP/SAVP" within that attribute;
    • if the SDP offer contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);
    • offer SRTP transport protocol according to RFC 3711 and the profile defined in TS 33.328;
    • include a SDP crypto attribute according to RFC 4568 and the profile defined in TS 33.328; and
    • include a SDP "a=3ge2ae:applied" attribute; and
  2. upon receiving an SDP answer to the SDP offer from remote user, for each accepted end-to-access-edge protected RTP based media, the P-CSCF will act as defined in TS 23.334 as far as SDP and RTP is concerned, and shall remove the SDP crypto attribute.
    If the P-CSCF indicated support for the end-to-access-edge media security for MSRP using TLS and certificate fingerprints during registration:
  3. upon receiving an SDP offer from the served UE containing an end-to-access-edge protected MSRP based media, i.e. an MSRP based media:
    • transported using the MSRP over TLS transport protocol as defined in RFC 4975 and RFC 6714;
    • with the SDP fingerprint attribute as defined in RFC 8122; and
    • with the SDP "a=3ge2ae:requested" attribute;
    the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 as far as SDP and MSRP is concerned, and shall strip the SDP "a=3ge2ae:requested" attribute and the SDP fingerprint attribute from the end-to-access-edge protected MSRP based media of the received SDP offer; and
  4. upon sending an SDP answer to the SDP offer from the served UE, for each end-to-access-edge protected MSRP based media of the SDP offer from the served UE which is accepted in the SDP answer, the P-CSCF will act as defined in TS 23.334 as far as SDP and MSRP is concerned and shall:
    • indicate the MSRP over TLS transport protocol according to RFC 4975, RFC 6714 and the profile defined in TS 33.328; and
    • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328.
If the served UE indicated support for the end-to-access-edge media security for MSRP using TLS and certificate fingerprints during registration, and the P-CSCF indicated support for the end-to-access-edge media security for MSRP using TLS and certificate fingerprints during registration:
  1. upon receiving an SDP offer from remote user with an MSRP based media, for each end-to-access-edge protected MSRP based media, i.e. an MSRP based media except those for which the result of the SDP offer / answer exchange results in the application of an end-to-end security mechanism, the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 as far as SDP and MSRP is concerned, and shall:
    • remove any SDP fingerprint attribute;
    • offer MSRP over TLS transport protocol according to RFC 4975, RFC 6714 and the profile defined in TS 33.328;
    • if the SDP offer contains contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);
    • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328; and
    • include the SDP "a=3ge2ae:applied" attribute; and
  2. upon receiving an SDP answer to the SDP offer from remote user, for each accepted end-to-access-edge protected MSRP based media, the P-CSCF will act as defined in TS 23.334 as far as SDP and MSRP is concerned, and shall remove the SDP fingerprint attribute.
    If the P-CSCF indicated support for the end-to-access-edge media security for BFCP using TLS and certificate fingerprints during registration:
  3. upon receiving an SDP offer from the served UE containing an end-to-access-edge protected BFCP based media, i.e. a BFCP based media:
    • transported using the BFCP over TLS transport protocol as defined in RFC 4583;
    • with the SDP fingerprint attribute as defined in RFC 8122; and
    • with the SDP "a=3ge2ae:requested" attribute;
    the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 as far as SDP and BFCP is concerned, and shall strip the SDP "a=3ge2ae:requested" attribute and the SDP fingerprint attribute from the BFCP based media of the received SDP offer; and
  4. upon sending an SDP answer to the SDP offer from the served UE, for each end-to-access-edge protected BFCP based media of the SDP offer from the served UE which is accepted in the SDP answer, the P-CSCF will act as defined in TS 23.334 as far as SDP and BFCP is concerned and shall:
    • transported using the BFCP over TLS transport protocol as defined in RFC 4583;
    • indicate the BFCP over TLS transport protocol according to RFC 4583 and the profile defined in TS 33.328; and
    • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328.
If the served UE indicated support for the end-to-access-edge media security for BFCP using TLS and certificate fingerprints during registration, and the P-CSCF indicated support for the end-to-access-edge media security for BFCP using TLS and certificate fingerprints during registration:
  1. upon receiving an SDP offer from remote UE with an BFCP based media, for each end-to-access-edge protected BFCP based media, i.e. a BFCP based media except those for which the result of the SDP offer / answer exchange results in the application of an end-to-end security mechanism, the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 as far as SDP and BFCP is concerned, and shall:
    • remove any SDP fingerprint attribute;
    • offer BFCP over TLS transport protocol according to RFC 4583 and the profile defined in TS 33.328;
    • if the SDP offer contains contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);
    • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328; and
    • include the SDP "a=3ge2ae:applied" attribute; and
  2. upon receiving an SDP answer to the SDP offer from remote user, for each accepted end-to-access-edge protected BFCP based media, the P-CSCF will act as defined in TS 23.334 as far as SDP and BFCP is concerned, and shall remove the SDP fingerprint attribute.
If the P-CSCF indicated support for the end-to-access-edge media security for UDPTL over DTLS and certificate fingerprints during registration:
  1. upon receiving an SDP offer from the served UE containing an end-to-access-edge protected UDPTL based media, i.e. a UDPTL based media:
    the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 as far as SDP and UDPTL is concerned, and shall strip the SDP "a=3ge2ae:requested" attribute and the SDP fingerprint attribute and the SDP tls-id attribute from the UDPTL based media of the received SDP offer; and
  2. upon sending an SDP answer to the SDP offer from the served UE, for each end-to-access-edge protected UDPTL based media of the SDP offer from the served UE which is accepted in the SDP answer, the P-CSCF will act as defined in TS 23.334 as far as SDP and UDPTL is concerned and shall:
If the served UE indicated support for the end-to-access-edge media security for UDPTL using DTLS and certificate fingerprints during registration, and the P-CSCF indicated support for the end-to-access-edge media security for UDPTL using DTLS and certificate fingerprints during registration:
  1. upon receiving an SDP offer from remote UE with an UDPTL based media, for each end-to-access-edge protected UDPTL based media, i.e. a UDPTL based media except those for which the result of the SDP offer / answer exchange results in the application of an end-to-end security mechanism, the P-CSCF shall invoke IMS-ALG procedures, will act as defined in TS 23.334 as far as SDP and UDPTL is concerned, and shall:
    • remove any SDP fingerprint attribute;
    • remove any SDP tls-id attribute;
    • offer UDPTL over DTLS transport protocol according to RFC 7345, draft-ietf-mmusic-dtls-sdp [240] and the profile defined in TS 33.328;
    • if the SDP offer contains contains any potential configuration(s) with delete-attribute parameter(s) (see RFC 5939), (e.g. "a=pcfg:1 a=-sm:1"), remove those potential configuration(s);
    • include the SDP fingerprint attribute according to RFC 8122 and the profile defined in TS 33.328;
    • include the SDP "a=3ge2ae:applied" attribute; and
    • include the SDP tls-id attribute as defined in draft-ietf-mmusic-dtls-sdp [240]; and
  2. upon receiving an SDP answer to the SDP offer from remote user, for each accepted end-to-access-edge protected UDPTL based media, the P-CSCF will act as defined in TS 23.334 as far as SDP and UDPTL is concerned, and shall remove the SDP fingerprint attribute and SDP tls-id attribute.
Up

6.7.2.3  IMS-ALG in P-CSCF for explicit congestion control support |R10|Word‑p. 391
6.7.2.3.1  General
An IMS-ALG may support ECN according to RFC 6679.
Subject to local policy, an IMS-ALG shall prohibit the negotiation of ECN during SDP offer/answer exchanges associated with multimedia priority service by removing any ECN attribute "a=ecn-capable-rtp" from the SDP offer and shall not invoke ECN for SIP transactions associated with multimedia priority service.
6.7.2.3.2  Incoming SDP offer with ECN
If the IMS-ALG receives an SDP offer containing the "a=ecn-capable-rtp" attribute as specified in RFC 6679 and:
  • the IMS-ALG knows via configuration that the IMS-AGW supports transparently forwarding of ECN bits according to RFC 3168;
  • the IMS-ALG knows via configuration that the (IMS) network handles ECN-marked packets properly; and
  • the IMS-ALG does not configure the IMS-AGW to transcode,
then the IMS-ALG shall:
  • if the "ecn-capable-rtp" attribute includes both the "ice" initialisation method and other initialisation methods, remove the "ice" initialisation method from the "ecn-capable-rtp" attribute and add the attribute with this modification in the outgoing the SDP offer;
  • if the "ecn-capable-rtp" attribute only includes the "ice" initialisation method, do not include the "ecn-capable-rtp" attribute it outgoing SDP offer; and
  • if the "ecn-capable-rtp" attribute did not includes the "ice" initialisation method include the unmodified "ecn-capable-rtp" attribute within the outgoing SDP offer.
If the IMS-ALG receives an SDP offer containing the ECN attribute "a=ecn-capable-rtp" as specified in RFC 6679 and any of the following conditions apply:
  • the IMS-ALG knows by configuration that the IMS-AGW does not support transparent transport of ECN-marked packets;
  • the IMS-ALG knows by configuration that the (IMS) network does not properly handle ECN-marked packets; or
  • the IMS-ALG does not configure the IMS-AGW to transcode,
then the IMS-ALG shall not include ECN attributes in the outgoing SDP offer, and, if the IMS-ALG knows in addition via configuration that the IMS-AGW supports acting as an ECN endpoint and that the IMS-ALG supports at least some of the initialisation methods offered within the "a=ecn-capable-rtp" attribute, the IMS-ALG shall:
  • select an initialisation method supported by the IMS-AGW; and
  • return a SDP answer according to the capabilities of the IMS-AGW, containing the "a=ecn-capable-rtp" attribute,
and the IMS-ALG will configure the IMS-AGW to act as an end point for ECN.
If the IMS-ALG receives an SDP answer containing the "a=ecn-capable-rtp" attribute it will instruct the IMS-AGW to transparently forward the ECN bits described in RFC 3168.
Up
6.7.2.3.3  Incoming SDP offer without ECNWord‑p. 392
If the IMS-ALG receives a SDP offer without the "a=ecn-capable-rtp" attribute and all of the following conditions apply:
  • the IMS-ALG knows via configuration that the IMS-AGW supports acting as ECN endpoint; and
  • the IMS-ALG knows via configuration that the succeeding network supports ECN,
then the IMS-ALG may include the "a=ecn-capable-rtp" attribute in the offer it forwards towards the succeeding node, indicating the related capabilities of the IMS-AGW.
If the IMS-ALG inserted ECN attributes in the SDP offer and receives an SDP answer containing the "a=ecn-capable-rtp" attribute, the IMS-ALG shall return the SDP answer to the preceding node removing the "a=ecn-capable-rtp" attribute, and will configure the IMS-AGW to act as an ECN endpoint.
Up

6.7.2.4  IMS-ALG in P-CSCF for Optimal Media Routeing (OMR) |R10|

Based on operator policy, the P-CSCF shall remove OMR related SDP attributes before it sends an SDP offer or answer towards an UE, as specified in subclause 2.1.9 of TS 29.079.

6.7.2.5  IMS-ALG in P-CSCF for NA(P)T and NA(P)T-PT controlled by the P-CSCF |R10|

6.7.2.5.1  General
This subclause describes the P-CSCF procedures for supporting the scenario where IP address and/or port conversions occur at the IMS-AGW level in the media path between the UE and the backbone. Two types of address conversions are covered:
  • IP version interworking (NA(P)T-PT); and
  • IP address/port translation (NA(P)T).
When the P-CSCF performs procedures for P-CSCF controlled NA(P)T and NA(P)T-PT, it shall modify the IP address(es) and port numbers (in case of NA(P)T) in SDP offers and answers, based on the IP address(es) and port number(s) received from the IMS-AGW, as described in subclause 6.7.2.1.
For terminating sessions the P-CSCF may towards a UE performing the functions of an external attached network indicate in the SDP offer alternate IP address versions (IPv4 and IPv6) by inserting two "altc" attributes as defined in RFC 6947. The order of setting the two IP addresses in the two "altc" SDP attributes shall be based on local policy. The insertion of the "altc" attributes is independent of their presence in the received SDP offer.
Up

6.7.2.6  IMS-ALG in P-CSCF for support of hosted NAT |R10|Word‑p. 393
6.7.2.6.1  General
When the P-CSCF performs procedures for hosted NAT, it shall modify the IP address(es) and port numbers, based on the IP address(es) and number(s) received from the IMS-AGW, as described in subclause 6.7.2.1.
6.7.2.6.2  Hosted NAT traversal for TCP based streams |R13|
When the P-CSCF acts as an IMS-ALG, it acts as a B2BUA and modifies the SDP as described as described in TS 23.334.

6.7.2.7  IMS-ALG in P-CSCF for support of ICE |R10|

6.7.2.7.1  General
This subclause describes procedures of a P-CSCF to support ICE, as defined in RFC 5245.
When the P-CSCF with attached IMS-AGW receives SDP candidate information from the offerer, it shall not forward the candidate information towards the answerer. When the P-CSCF receives SDP candidate information from the answerer, it shall not forward the candidate information towards the offerer. The remaining procedures in subclause 6.7.2.7.1 are optional.
The P-CSCF with attached IMS-ALG performs separate ICE procedures towards the offerer and the answerer. The usage of ICE is negotiated separately with the offerer and answerer, and ICE may be applied independently at either side. Furthermore, the P-CSCF may be configured to apply ICE procedures only towards one network side, e.g. towards the IM CN subsystem it belongs to.
Since the P-CSCF is not located behind a NAT, it does not request the IMS-ALG to generate keep-alive messages even when acting as a full ICE entity. The P-CSCF only requests the IMS-ALG to terminate and generate STUN messages used for the candidate selection procedures.
Since the P-CSCF is not located behind a NAT the P-CSCF shall only include host candidates in SDP offers and answers generated by the P-CSCF.
Up
6.7.2.7.2  P-CSCF full ICE procedures for UDP based streamsWord‑p. 394
6.7.2.7.2.1  General
This subclause describes the P-CSCF full ICE procedures for UDP based streams.
6.7.2.7.2.2  P-CSCF receiving SDP offer
When the P-CSCF receives an SDP offer including ICE candidate information, the P-CSCF shall send the candidate information for each UDP based stream received in the SDP offer towards the IMS-ALG. If the SDP offer includes TCP candidate information for a UDP based stream, the P-CSCF may send such candidate information to the IMS-AGW, in addition to the UDP candidate information as defined in RFC 6544. The P-CSCF shall request the IMS-ALG to reserve media- and STUN resources towards the offerer, based on the candidate information, in order to allow the IMS-ALG to perform the necessary connectivity checks per the ICE procedures.
If the offerer is acting as an ICE controller entity the P-CSCF shall act as an ICE controlled entity in the direction towards the offerer. If the offerer is acting as an ICE controlled entity the P-CSCF shall act as an ICE controller entity in the direction towards the offerer.
Up
6.7.2.7.2.3  P-CSCF sending SDP offer
Prior to sending an SDP offer, the P-CSCF may choose to apply related ICE procedues, e.g. if it expects to interact with terminals applying procedures as described in subclause K.5.2, and if both the P-CSCF and IMS-ALG also support ICE procedures. To invoking these ICE procedures, the P-CSCF shall request the IMS-ALG to reserve media- and STUN resources towards the answerer for each UDP based media stream and include a host candidate attribute for each UDP based stream in the SDP offer, providing the reserved address and port at the IMS-ALG as destination. The P-CSCF may also include host TCP candidate information for UDP based streams in the SDP offer as defined in RFC 6544.
The P-CSCF shall always act as an ICE controller entity towards the answerer.
Up
6.7.2.7.2.4  P-CSCF receiving SDP answer
When the P-CSCF receives an SDP answer including ICE candidate information, the P-CSCF shall send the candidate information for each UDP based stream received in the SDP answer towards the IMS-ALG.
The P-CSCF shall request the IMS-ALG to perform ICE candidate selection procedures towards the answerer. The P-CSCF shall request the IMS-ALG to inform the P-CSCF, for each UDP stream, which candidate pair has been selected towards the answerer, once the candidate selection procedure towards the answerer has finished.
If the IMS-ALG indicates to the P-CSCF that, for at least one UDP stream, the selected candidate pair does not match the c- and m- line address information for the associated UDP stream, exchanged between the P-CSCF and the answerer, and the P-CSCF acts an ICE controller entity towards the answerer, the P-CSCF shall send a new offer towards the answerer in order to allign the c- and m- lines address information with the chosen candidate pair for the associated UDP stream.
Up
6.7.2.7.2.5  P-CSCF sending SDP answer
When the P-CSCF generates an SDP answer for an offer that included ICE candidate information, the P-CSCF shall request the IMS-ALG to reserve media- and STUN resources towards the offerer for each UDP based media stream and include an SDP host candidate attribute for each UDP based stream in the SDP answer, providing the reserved address and port at the IMS-ALG as destination.
The P-CSCF shall in the generated SDP answer include host candidate information which matches the c- and m line information for the associated UDP stream in the SDP answer.
The P-CSCF shall request the IMS-ALG to perform ICE candidate selection procedures towards the offerer. The P-CSCF shall request the IMS-ALG to inform the P-CSCF, for each UDP stream, which candidate pair has been selected towards the offerer, once the candidate selection procedure towards the answerer has finished.
If the IMS-ALG indicates to the P-CSCF that the selected candidate pair towards the offerer does not match the c- and m- line address information for the associated UDP stream, exchanged between the P-CSCF and the offerer, and the P-CSCF acts an ICE controller entity towards the offerer, the P-CSCF shall send an offer towards the offerer (which will now act as an answerer) in order to allign the c- and m- line address information with the chosen candidate pair for the associated UDP stream.
Up
6.7.2.7.3  P-CSCF ICE lite procedures for UDP based streamsWord‑p. 395
When the P-CSCF is using ICE lite procedures for UDP based streams, the P-CSCF procedures are identical as described in subclause 6.7.2.7.2, with the following exceptions:
  • The P-CSCF always acts as an ICE controlled entity towards the offerer and towards the answerer; and
  • The P-CSCF requests the IMS-ALG to perform ICE lite candidate selection procedures, as defined in RFC 5245.
Up
6.7.2.7.4  ICE procedures for TCP based streams
6.7.2.7.4.1  General
The P-CSCF shall disable ICE procedures for TCP based streams, i.e. streams where TCP is indicated as transport protocol in the m-line. Instead the P-CSCF will use the mechanism defined in RFC 4145 for establishing TCP based streams, as defined in RFC 6544.
Up
6.7.2.7.4.2  P-CSCF receiving SDP offer
When the P-CSCF receives an SDP offer, the P-CSCF shall ignore the candidate attributes for TCP based streams. The P-CSCF shall not send the candidate information for TCP based streams towards the IMS-ALG.
6.7.2.7.4.3  P-CSCF sending SDP offer
When the P-CSCF generates an SDP offer the P-CSCF shall include an "actpass" setup attribute, as defined in RFC 4145, for each TCP based stream, which will cause the answerer to initiate the TCP connections towards the IMS-ALG. The P-CSCF shall not include any candidate attributes for TCP based streams in the SDP offer.
6.7.2.7.4.4  P-CSCF receiving SDP answer
Since the P-CSCF does not include candidates in the SDP offer towards the answerer, there are no ICE specific procedures when the P-CSCF receives an SDP answer.
6.7.2.7.4.5  P-CSCF sending SDP answer
When the P-CSCF generates an SDP answer the P-CSCF shall include a "passive" setup attribute, as defined in RFC 4145, for each TCP based stream, which will cause the offerer to initiate the TCP connections towards the IMS-ALG. The P-CSCF shall not include any candidate attributes for TCP based streams in the SDP answer.

6.7.2.8  IMS-ALG in P-CSCF for transcoding |R10|Word‑p. 396
An IMS-ALG may support procedures to modify SDP for transcoding purposes. The IMS-ALG shall only apply those transcoding procedures if an attached IMS-AGW supports transcoding.
Upon receipt of an SDP offer, based on local policy and SDP signalling inspection, the IMS-ALG may decide to offer transcoding.
To offer transcoding at the IMS-AGW, the IMS-ALG shall add codecs selected by local policy and supported by the IMS-AGW to the SDP offer. The local policy shall be in accordance with the requirements of clause T.2.
Upon receipt of the corresponding SDP answer, the IMS-ALG shall inspect the list of the codecs within the SDP answer and proceed as follows:
  • If the list contains at least one of the codecs that was already contained in the previously received SDP offer, no transcoding at the IMS-AGW is required and the IMS-ALG will configure the IMS-AGW accordingly. The IMS-ALG shall remove from the SDP the codecs added to the original offer before forwarding the response to the offerer.
  • If only the codecs inserted by the IMS-ALG are contained in the answer, the IMS-ALG will configure the IMS-AGW to transcode. The IMS-ALG shall replace the received codecs in the SDP anwer with the codec it configured the IMS-AGW to use towards the SDP offerer's direction.
For an IMS-ALG acting as ATCF, the following applies in addition:
  • During an originating or terminating session establishment, for media using PS transport towards the UE, the IMS-ALG (ATCF) should pass SDP offers without adding codecs to the SDP offer and pass SDP answers without modification to the contained codecs to avoid the potential need for transcoding in the IMS-AGW before the PS to CS access transfer; and
  • during the PS to CS access transfer procedure, the IMS-ALG (ATCF) shall preferentially select from the SDP offer it receives from the MSC server the codec already configured on the corresponding remote leg, if available.
Up

6.7.3  IMS-ALG in ISC gateway function |R11|

6.7.3.1  General

When the ISC gateway function acts as an IMS-ALG, it makes procedures as for an originating UA and terminating UA. The IMS-ALG acts as a B2BUA. For the use of the IMS-ALG for specific capabilities, additional procedures are defined in subsequent subclauses.

6.7.3.2  IMS-ALG in application gateway function for support of ICE

The application gateway function shall act according to the procedures defined for the IBCF in subclause 6.7.1.2.


Up   Top   ToC