Content for  TS 23.334  Word version:  17.2.0

The SDP Capability Negotiation (SDPCapNeg) as specified in RFC 5939 is adopted as an optional functionality to negotiate capabilities and their associated configurations according to TS 24.229. If the ICS service is supported then the IMS-ALG and the IMS-AGW may further optionally support SDP Media Capability Negotiation as specified in RFC 6871 for alternative CS configuration. Upon receipt of an incoming SDP offer containing the attributes of SDP capability negotiation, e.g. offer AVPF and AVP together for the RTP profile negotiation using "a=tcap", "a=pcfg" and "a=acfg" attributes, the IMS-ALG shall:

• request the IMS-AGW to reserve resources only for the default configuration without SDPCapNeg, and make the decision on support of the alternative configurations based on the IMS-ALG/IMS-AGW capability as provisioned before forwarding the SDP offer, i.e. handling SDPCapNeg at the controller level; or
• request the IMS-AGW to reserve resources for all of these configurations by signalling SDPCapNeg to the IMS-AGW, and update the SDP offer based on the response from the IMS-AGW before forwarding.

In case the IMS-ALG decides to request the IMS-AGW to reserve resources for all of those configurations, the IMS-ALG shall:

• use legacy SDP attributes as specified in RFC 4566 to do the mapping of actual and potential configurations with the H.248 ReserveGroup concept; or
• use SDP extensions for SDP capability negotiation as specified in RFC 5939, if supported by the IMS-AGW.

Before using SDP extensions for SDP capability negotiation as specified in RFC 5939 towards the IMS-AGW, the IMS-ALG shall perform the necessary checks (i.e. through auditing or via prior provisioning) to ensure that the IMS-AGW supports the syntax and capabilities requested. For an auditing the procedure in clause 6.1.8.1 is used with the "SDPCapNeg Supported Capabilities" as the object. When receiving a request from the IMS-ALG with information element "SDPCapNeg configuration" indicating the potential use of multiple configurations, the IMS-AGW shall reserve resources for all of those configurations that it supports and shall send indicate the configurations for which it reserved resources in an "SDPCapNeg configuration" information element in the response. The IMS-ALG shall update the SDP offer with SDPCapNeg configurations in the response from the IMS-AGW and shall forward the SDP offer to the next hop. The IMS-ALG may also provide SDP configurations to the IMS-AGW with no dependency on the incoming SDP offer, e.g. the IMS-ALG may wildcard the supported configurations in order to construct or update an SDP offer with the addition of alternative configurations via SDPCapNeg attributes. On receipt of an SDP answer with SDPCapNeg, the IMS-ALG shall request the IMS-AGW to configure the resources for the selected configuration. If the IMS-AGW previously reserved any temporary resources for configurations that were not selected, the IMS-ALG shall also request the IMS-AGW to release those resources.

The IMS-ALG and the IMS-AGW may support the "RTP-level pause and resume" signalling as defined in TS 26.114 and RFC 7728. RTCP feedback messages to request for pause and resume of media streams can be used by conference participants supporting Multi-stream Multiparty Conferencing Media Handling feature, as specified in TS 26.114 Annex S. Usage of the RTCP feedback "pause and resume" messages is negotiated via SDP offer/answer exchange through an extension of RTCP feedback capability attribute "a=rtcp-fb" (defined in RFC 4585). If the IMS-ALG and IMS-AGW support the "RTP-level pause and resume" signalling, the IMS-ALG and IMS-AGW shall apply the procedures in the present clause. If the IMS-ALG receives an SDP offer containing "a=rtcp-fb" line(s) with a "CCM" parameter (as defined in RFC 5104) and a "pause" CCM parameter (as defined in RFC 7728), and if the IMS-ALG does not support or does not apply the transcoding procedure defined in clause 5.13, the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node with unmodified "a=rtcp-fb" line(s) with a "pause" CCM parameter. Otherwise, if the IMS-ALG does insert any transcoding or if the IMS-AGW does not support the "RTP-level pause and resume" signalling, the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node without any "a=rtcp-fb" line(s) with a "pause" CCM parameter. If the IMS-ALG forwarded the SDP offer containing the "a=rtcp-fb" line(s) with a "pause" CCM parameter and receives an SDP answer also containing the "a=rtcp-fb" line(s) with a "pause" CCM parameter (the reception of the attribute indicates a successful "RTP-level pause and resume" negotiation) then the IMS-ALG shall:

1. when requesting the IMS-AGW to configure resources towards the succeeding node and towards the preceding node, include the "CCM pause-resume" information element to indicate that the IMS-AGW shall forward RTCP feedback "CCM PAUSE-RESUME" messages transparently; and
2. forward the SDP answer containing the "a=rtcp-fb" line(s) with a "pause" CCM parameter to its preceding node.

The IMS-AGW shall then assign resources for the requested RTCP control flow and shall transparently forward the RTCP "CCM PAUSE" packets between incoming and outgoing networks.

The IMS-ALG and the IMS-AGW may support signalling of "RTCP Codec Control Commands and Indications", as defined in TS 26.114 and RFC 5104. The RTCP feedback FIR message can be used both by point-to-point video calls, and by conference participants supporting Multi-stream Multiparty Conferencing Media Handling feature, as specified in TS 26.114 Annex S, to request the media sender to send a decoder refresh point. The RTCP TMMBR and TMMBN feedback messages can also be used in reaction to the Explicit Congestion Notification, as specified in clause 5.12. Usage of the RTCP feedback "CCM" messages is negotiated via SDP offer/answer exchange through an extension (defined in RFC 5104) of the RTCP feedback capability attribute "a=rtcp-fb" (defined in RFC 4585). If the IMS-ALG and IMS-AGW support the "RTCP Codec Control Commands and Indications" signalling, the IMS-ALG and IMS-AGW shall apply the procedures in the present clause. If the IMS-ALG receives an SDP offer containing "a=rtcp-fb" line(s) with a "CCM" parameter and with a "fir" and/or "tmmbr" CCM parameters (defined in RFC 5104) under video "m=" line(s), and if the IMS-ALG does not configure the IMS-AGW to transcode the corresponding video media stream and/or to act as ECN endpoint for the corresponding video media stream, the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node with unmodified "a=rtcp-fb" line(s) with the "CCM" parameter and with "fir" and/or "tmmbr" CCM parameters. If the IMS-ALG does not configure the IMS-AGW to transcode the corresponding video media stream and/or to act as ECN endpoint, and if the IMS-ALG received an SDP answer also containing the "a=rtcp-fb" line(s) with the "CCM" parameter and with the same "fir" and/or "tmmbr" CCM parameters (the presence of the same "a=rtcp-fb ccm" line(s) in the SDP answer indicates a successful negotiation of the particular CCM message), then the IMS-ALG shall:

• when requesting the IMS-AGW to configure resources towards the succeeding node and towards the preceding node, include the "CCM BASE" information element with the "fir" and/or "tmmbr" CCM parameters to indicate that the IMS-AGW shall be prepared to receive and is allowed to send the RTCP CCM "FIR" and/or "TMMBR/TMMBN" feedback messages; and
• forward the SDP answer containing the "a=rtcp-fb" line(s) with the "fir" and/or "tmmbr" CCM parameters (from the received SDP answer) to its preceding node.

If the IMS-ALG configures the IMS-AGW to transcode the corresponding video media stream and/or to act as ECN endpoint:

• if the IMS-ALG did not send towards the succeeding node the SDP offer containing the "a=rtcp-fb" line(s) with the "CCM" parameter and the with "fir" and/or "tmmbr" CCM parameters, then the IMS-ALG may:
  1. when requesting the IMS-AGW to configure resources towards the preceding node, include the "CCM BASE" information element with the "fir" and/or "tmmbr" CCM parameters to indicate that the IMS-AGW shall be prepared to receive and is allowed to send the RTCP CCM "FIR" and/or "TMMBR/TMMBN" feedback messages; and
  2. include in the SDP answer it sends to the preceding node the "a=rtcp-fb" line(s) with the "fir" and/or "tmmbr" CCM parameters (as received SDP offer); and
• if the IMS-ALG sent towards the succeeding node the SDP offer containing the "a=rtcp-fb" line(s) with the "CCM" parameter and the with "fir" and/or "tmmbr" CCM parameters, and received an SDP answer also containing the "a=rtcp-fb" line(s) with the "CCM" parameter and with the same "fir" and/or "tmmbr" CCM parameters, then the IMS-ALG shall:
  1. when requesting the IMS-AGW to configure resources towards the succeeding node, include the "CCM BASE" information element with the "fir" and/or "tmmbr" CCM parameters to indicate that the IMS-AGW shall be prepared to receive and is allowed to send the RTCP CCM "FIR" and/or "TMMBR/TMMBN" feedback messages; and
  2. if the the IMS-ALG received from the preceding node the SDP offer containing the "a=rtcp-fb" line(s) with the "CCM" parameter and the with "fir" and/or "tmmbr" CCM parameters, include in the SDP answer it sends to the preceding node the "a=rtcp-fb" line(s) with the "fir" and/or "tmmbr" CCM parameters (as received SDP offer).

The IMS-AGW shall then assign resources for the requested RTCP control flow:

• if the IMS-AGW acts as an ECN endpoint (as described in clause 5.12) or applies the video transcoding procedure, the IMS-AGW:
  1. may send the RTCP TMMBR feedback message with an "IMS-AGW-generated" value in an "SSRC of media sender" field that is kept constant for the duration of the session, different from any SSRC value in the active RTP streams for the session, to request the media sender to limit the maximum bit rate for a media stream to, or below, the provided value;
  2. upon reception of the RTCP TMMBR feedback message and if performing transcoding, shall adjust the sent media rate to the requested rate or lower and shall respond by sending the RTCP TMMBN feedback message; and
  3. may send the RTCP FIR feedback message to request the media sender to send a decoder refresh point; or
• if the IMS-AGW does not act as an ECN endpoint and does not apply the video transcoding procedure, the IMS-AGW shall transparently forward received RTCP FIR feedback message, and received RTCP TMMBR and TMMBN feedback messages between the incoming and outgoing networks.

The IMS-ALG and the IMS-AGW may support the "DBI" signalling as defined in TS 26.114. RTCP feedback messages to report or request additional delay budget for voice and video media streams (as defined in clause 7.3.8 of TS 26.114) can be used by participants in a point-to-point MTSI session, and by conference participants, as specified in TS 26.114. If the IMS-ALG and IMS-AGW support the "DBI" signalling, the IMS-ALG and IMS-AGW shall apply the procedures in the present clause. If the IMS-ALG receives an SDP offer containing an "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter as defined in TS 26.114, the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node with the unmodified "a=rtcp-fb" line(s) with "3GPP-delay-budget" parameter. Otherwise, if the IMS-AGW does not support the "DBI" signalling, the IMS-ALG shall forward within SIP signalling, the SDP offer received from the preceding node without any "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter. If the IMS-ALG forwarded the SDP offer containing the "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter and receives an SDP answer also containing the "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter (the reception of the attribute indicates a successful "3GPP-delay-budget" negotiation) then the IMS-ALG shall:

1. when requesting the IMS-AGW to configure resources towards the succeeding node and towards the preceding node, include the "DBI" information element to indicate that the IMS-AGW shall forward RTCP DBI feedback messages transparently; and
2. forward the SDP answer containing the "a=rtcp-fb" line(s) with a "3GPP-delay-budget" parameter to its preceding node.

The IMS-AGW shall then assign resources for the requested RTCP control flow and shall transparently forward the RTCP DBI feedback messages between incoming and outgoing networks.