7 User plane Interconnection

29.1653GPPInter-IMS Network to Network Interface (NNI)Release 18TS

7.1 Media and Codec

For "end-to-end" media session involving the II-NNI, the SIP/SDP codec negotiation procedure can be applied between IM CN subsystems using different media codecs. It is possible that the end-to-end codec negotiation could fail because no common codec could be supported by the UEs, in particular for voice services.

To enhance interoperability, the IBCF, the MRFC, or other IMS network entities can interfere with the end-to-end codec negotiation to offer additional codec(s) available via transcoding, or to remove codecs. The IBCF can configure an attached TrGW to transcode, and the MRFC can configure an attached MRFP to transcode.

Codecs applicable at the II-NNI may be a subject of interworking agreements.

NOTE 1: Possible codecs which could be used at the II-NNI are described in 3GPP TS 26.114 [11] and ETSI TS 181 005 [12].

NOTE 2: As described in 3GPP TS 24.229 [5], the IETF RFC 4733 [157] is used to encode DTMF events and a payload type number associated with the MIME subtype "telephone-event" is included in a SDP message.

However, to avoid that transcoding is performed several times, applicable codecs at the II-NNI should be restricted as little as possible in the inter-operator agreements. It is not recommended to set only codecs which are not agreed to use by the inter-operator agreement into the SDP of the SIP message at the II-NNI. Whether it is allowed to offer codecs which are not included in the applicable codec list made by inter-operator agreements over the II-NNI is also determined by the inter-operator agreement if necessary.

NOTE 3: Transcoding can be performed in an IMS network serving an SDP offerer or in an IMS network serving an SDP answerer. To avoid that transcoding is performed multiple times, inter-operator agreements can clarify if it is preferred that IMS network serving an SDP offerer (with respect to the initial offer-answer exchange) or IMS network serving an SDP answerer (with respect to the initial offer-answer exchange) modify an SDP offer to offer transcoding. Furthermore, if transcoding is ongoing then subsequent SDP negotiation should avoid adding transcoding steps as specified in 3GPP TS 24.229 [5] Annex T.2 steps G), H), and I).

If the IBCF performs media transcoding control, the IBCF shall apply the related procedures in 3GPP TS 24.229 [5].

7.2 User Plane Transport

The user plane transport of the II-NNI may use the protocols listed in table 7.2.1. Protocols that use UDP, RTP, SCTP or TCP as the underlying transport protocol may be used based on agreements between operators. The used protocols to transport media are negotiated by means of the SDP offer/answer procedure specified in IETF RFC 3264 [146].

Table 7.2.1: Supported transport-level RFCs to be described in SIP/SDP messages

Item	RFC	Title	Support
1	IETF RFC 3550 [151]	RTP: A Transport Protocol for Real-Time Applications	Mandatory
2	IETF RFC 768 [152]	User Datagram Protocol	Mandatory
3	IETF RFC 3551 [153]	RTP Profile for Audio and Video Conferences with Minimal Control	Mandatory
4	IETF RFC 3556 [154]	Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth	Mandatory
5	IETF RFC 4585 [155]	Extended RTP Profile for Real-time Transport Control Protocol (RTCP) – Based Feedback (RTP/AVPF)	Optional (NOTE 1)
6	IETF RFC 793 [156]	Transmission Control Protocol	Optional (NOTE 2)
7	IETF RFC 8841 [190]	Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport	Optional (NOTE 3)
NOTE 1: Used by MTSI, as indicated in 3GPP TS 26.114 [11]. NOTE 2: Used for MSRP service. NOTE 3: Used for data channel in telepresence using IMS, as indicated in 3GPP TS 24.103 [189].