## 5.16 Optional support of SDP and Annex C information elements

29.3343GPPIMS Application Level Gateway (IMS-ALG) - IMS Access Gateway (IMS-AGW)Iq InterfaceRelease 17Stage 3TS

Specifies what SDP attributes and Annex C information elements may be supported.

Table 5.16.1: Optional Annex C and SDP information elements

 Information Element Annex C Support SDP Support a-line "SDP_A " 1) Application "RTCP transport address control": a) Default mode "without RTP/RTCP transport multiplexing": The attribute "a=rtcp" line may either contain (a=rtcp: ) or (a=rtcp:
) when the "a=" line is used for RTCP transport port and optionally network address transmission (see IETF RFC 3605 [21]). . The MGC shall supply the "a=rtcp" line in the RD when non-default RTCP network address or transport port values are used by the peer media entity. "RTCP transport address control" should be supported by MG (NOTE 2). b) Optional extension mode "with RTP/RTCP transport multiplexing": The attribute "a=rtcp-mux" (see IETF RFC 5761 [59]) is used for indicating RTP/RTCP transport multiplexing. Tables 4/1 to 4/5 in ITU-T Recommendation H.248.57 [5] define the appropriate RTCP port allocation rules. 2) Media related parameters in general: The "a=" line provides the complementary information for the "m=" line with regards to a specified media type/format (e.g. an optional SDP „a=ptime" line for a particular media format). For a dynamic RTP payload type, for each media information on the codec type shall be provided in a separate SDP "a=rtpmap"line and possibly additional SDP "a=fmtp"-line(s). 3) Application " Media interworking (transcoding)": See "a=" line specification in (2). Media interworking is limited to audio transcoding only (NOTE 1). 4) IMS media plane security related parameters: 4.1) SRTP-specific security parameters: The attribute "a=crypto" (see IETF RFC 4568 [29]) shall be provided for an m-line in the local and remote descriptor of an access network termination if the IMS-ALG wants that the corresponding media is encrypted, decrypted and/or integrity protected by the IMS-AGW (IMS end-to-access-edge media plane security). For each m-line, only a single "a=crypto" attribute shall be provisioned (i.e. only information related to a single crypto suite is provisioned to the IMS-AGW). The "a=crypto" attribute may contain several master keys. An IMS-AGW supporting end-to-access-edge media plane security shall support parameters within the "a=crypto" attribute in accordance with the profile in Annex of 3GPP TS 33.328 [34]. 4.2) (D)TLS-specific security parameters: The attribute(s) "a=fingerprint" (see IETF RFC 8122 [55]) shall be provided in accordance with ITU-T Recommendation H.248.90 [48] for an "m="-line in the local and remote descriptor of an access network termination if the IMS-ALG wants that the corresponding media is encrypted, decrypted and/or integrity protected by the IMS-AGW (IMS end-to-access-edge media plane security). 5) Coordination of Video Orientation The attribute "a=extmap" (see IETF RFC 5285 [41]) may be provided for an m-line in the local and remote descriptor if the IMS-AGW supports the extended RTP header with Coordination of Video Orientation information, see also 3GPP TS 26.114 [26]. 6) Generic Image Attribute The attribute "a=imageattr" (see IETF RFC 6236 [42]) may be provided for an m-line in the local and remote descriptor if the IMS-AGW supports the generic image attributes, see also 3GPP TS 26.114 [26]. The local descriptor indicates the image sizes which the IMS-AGW supports in the receiving direction for the selected payload type and corresponds to the "recv" keyword (see IETF RFC 6236 [42]) in the "a=imageattr" that the IMS-ALG will send within the SDP body on the Mw/Mx interface. The remote descriptor indicates the image sizes which the IMS-AGW supports in the sending direction for the selected payload type and corresponds to the "send" keyword (see IETF RFC 6236 [42]) in the "a=imageattr" that the IMS-ALG will send within the SDP body on the Mw/Mx interface. 7) ICE support The attributes "a=candidate", "a=ice-pwd", and "a=ice-ufrag" (see IETF RFC 5245 [44]) may be provided for an SDP m-line in the local and remote descriptor if the IMS-AGW supports ICE, see also 3GPP TS 24.229 [45]. In the local descriptor, the IMS-ALG shall provide "a=ice-pwd", and "a=ice-ufrag" with wildcard sign "$" to request the allocation of a password and user name fragment, and the "a=candidate" of type "host" with the transport, port and priority parameters with wildcard sign "$" to request the allocation of a host candidate. The IMS-AGW shall then reply with completed "a=ice-pwd", and "a=ice-ufrag" and "a=candidate" attributes in the local descriptor, and shall include "a=ice-lite" if it only supports ICE lite. In the remote descriptor, the IMS-ALG may provide the "a=candidate", "a=ice-pwd", and "a=ice-ufrag". 8) state-agnostic and state-aware TCP handling: The attribute "a=setup" (see IETF RFC 4145 [20]) shall be provided for TCP-based media, in accordance with ITU-T Recommendation H.248.84 [46], when triggering an end-to-end TCP simultaneous open (leading to a TCP merge mode in the IMS-AGW) or other TCP modes of operation. 9) Application-aware interworking for MSRP traffic: The attribute "a=path" (see IETF RFC 4975 [11]) shall be provided, when enabling a bearer level application gateway (B-ALG) function for MSRP traffic, according to ITU-T Recommendation H.248.78 [56]. 10) Handling of RTCP APP messages when transcoding between EVS and non EVS codecs: The attribute "a=3gpp_mtsi_app_adapt" (see 3GPP TS 26.114 [26]) containing the allowed RTCP APP message types shall be provided when the IMS-AGW is allowed to send RTCP APP messages. 11) Pre-defined Video Region-of-Interest (ROI): The attribute "a=rtcp-fb" with the "Predefined ROI" type expressed by the parameter "3gpp-roi-predefined" may be provided for an m-line in the local and remote descriptor if the IMS-AGW supports the Predefined ROI mode, see also 3GPP TS 26.114 [26]. In addition, the attribute "a=extmap" (see IETF RFC 5285 [41]) may be provided for an m-line in the local and remote descriptor if the IMS-AGW supports the extended RTP header for carriage of pre-defined video Region of Interest (ROI) information in the sent video, see also 3GPP TS 26.114 [26]. 12) Arbitrary Video Region of Interest (ROI): The attribute a=rtcp-fb" with the "Arbitrary ROI" type expressed by the parameter "3gpp-roi-arbitrary" may be provided for an m-line in the local and remote descriptor if the IMS-AGW supports the Arbitrary ROI mode, see also 3GPP TS 26.114 [26]. In addition, the attribute "a=extmap" (see IETF RFC 5285 [41]) may be provided for an m-line in the local and remote descriptor if the IMS-AGW supports the extended RTP header for carriage of arbitrary video Region of Interest (ROI) information in the sent video, see also 3GPP TS 26.114 [26]. . 13) WebRTC data channel:The attributes "a=sctp-port" and "a=max-message-size" shall be provided in the remote descriptor (see IETF RFC 8841 [68]). In the local descriptor, the IMS-ALG shall provide "a=sctp-port" with omission sign "-" to indicate that the IMS-ALG shall use the same port as for UDP, and "a=max-message-size" with wildcard sign "\$". The IMS-AGW shall then reply with completed "a=sctp-port" and "a=max-message-size" attributes in the local descriptor, The attribute "a=dcmap" shall be provided in the local and remote descriptor, with the parameter "subprotocol" either set to "-" (Application-agnostic data channel configuration) or with real value (Application-aware data channel configuration). 14) Application aware interworking of traffic within a WebRTC data channel:The attribute "a=dcsa" may be provided in the local descriptor and/or remote descriptor (see IETF RFC 8864 [69], NOTE 3). T.140 (see ITU‑T Recommendation T.140 [75]) is used for Global Text Telephony (GTT). Application aware interworking between the transport according to IETF RFC 8865 [77] within WebRTC data channels and the transport according to IETF RFC 4103 [76] in the IMS core network should be applied for T.140 according to ITU-T Recommendation H.248.94 [67] Appendix 2. For application aware T.140 interworking, the "a= rtpmap" attribute shall be provided with "t140" payload type for the termination towards the IMS core network and "t140" value of the "subprotocol" parameter of the SDP "a=dcmap" attribute shall be provided for the termination towards the served WIC. 15) SDP Capability Negotiation:The attributes of "a=acap", "a=tcap", "a=pcfg" and "a=acfg" (see IETF RFC 5939 [72]) may be provided in the local descriptor and/or remote descriptor. 16) Rate adaptation for media endpoints: If the IMS-AGW performs media transcoding and if the rate adaptation for media endpoints using the enhanced bandwidth negotiation is supported by the IMS-AGW, attribute(s) "a=bw-info" with direction "send" or "sendrecv" may be provided for an m-line and the selected IP payload type and applicable IP version in the remote descriptor. The following bandwidth properties, as defined in 3GPP TS 26.114 [26], clause 19, may be included in "a=bw-info" line: , , , and . 17) "RTP-level pause and resume" signalling: The "rtcp-fb" SDP attribute with the "ccm" feedback parameter and the "pause" ccm parameter as defined in IETF RFC 7728 [79] may be provided for an m-line in the local and remote descriptor to indicate that the IMS-AGW shall forward RTCP feedback "CCM PAUSE-RESUME" messages transparently. 18) "RTCP Codec Control Commands and Indications" signalling: The "rtcp-fb" SDP attribute with the "ccm" feedback parameter and the "fir" and/or "tmmbr" ccm parameters as defined in IETF RFC 5104 [78] may be provided for an m-line in the local and remote descriptor to indicate that the IMS-AGW shall be prepared to receive and is allowed to send, respectively, the RTCP CCM feedback messages FIR, and/or TMMBR and TMMBN. 19) DBI signalling: The "rtcp-fb" SDP attribute with the "3gpp-delay-budget" feedback parameter (as defined in 3GPP TS 26.114 [26] clause 6.2.8) may be provided for an m-line in the local and remote descriptor to indicate that the IMS-AGW shall forward RTCP feedback "DBI" messages (as defined in 3GPP TS 26.114 [26] clause 7.3.8) transparently. NOTE 1: Media Interworking is optional. NOTE 2: Table 1 in ITU-T Recommendation H.248.57 [5] provides the correspondent RTCP port allocation rules. NOTE 3: See IETF RFC 8873 [70] for WebRTC data application ‘MSRP’.

Editor’s Note: The support for video transcoding is required for vSRVCC but should be changed from Rel-11, separate CRs would be required for this change.