10.2.5 Media Control

29.1623GPPInterworking between the IM CN subsystem and IP networksRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

10.2.5.1 General

The transcoding functionality, where the TrGW processes and possibly converts application / media data (like e.g. RTP payload) is optional for the TrGW and IBCF to support.

The IBCF shall determine the TrGW transcoding capability through provisioning and MGW selection, outside the scope of this specification.

IBCF procedures to offer transcoding in SIP/SDP signalling are described in 3GPP TS 23.228 [8] and in 3GPP TS 24.229 [1]. The IBCF shall only apply those transcoding procedures if an attached TrGW supports transcoding. For media with "RTP/SAVP" (see IETF RFC 3711 [34]) or "RTP/SAVPF" (see IETF RFC 5124 [35]) as transport protocol, the IBCF shall not offer or apply transcoding.

If the IBCF and available TrGW support transcoding, the IBCF may add codecs to a SDP offer within a SIP request.

If the IBCF and available TrGW do not support transcoding, or if the IBCF chooses not to offer transcoding, the IBCF shall pass SDP offers without adding codecs to the SDP offer and the IBCF shall pass SDP answers without modification to the contained codecs.

If the IBCF does not offer or apply transcoding procedures (as described above) but inserts the TrGW for any other reason, the IBCF shall either not signal media related information to the TrGW, or it shall signal the same media related information for all interconnected terminations (i.e. identical media configurations for the two connected H.248 stream endpoints).

If the IBCF does not offer or apply transcoding but signals media attributes to a TrGW that does not support transcoding without having seized the peer termination (see figure 10.2.5.3, Step 3) the TrGW’ shall accept this request even though it cannot reserve any transcoding resources related to this media. When the peer termination is seized and configured it shall be configured with the same media related sub-fields in the media descriptor as for the first termination. If the selected codec is not the same as the codec configured at the first termination then this termination shall be modified before the peer termination is seized.

NOTE 1: The signalling of such codec related information by an IBCF to a TrGW not supporting transcoding is an implementation decision.

NOTE 2: A TrGW not supporting transcoding can use such codec related information to learn that RTCP ports need to be reserved, and to derive information about packet size and frequency useful for internal resource reservation.

If the IBCF and available TrGW support transcoding and the IBCF includes in a SDP offer additional codecs, the following procedures apply:

– The IBCF may seize a termination towards the terminating user, using the "Reserve TrGW Connection Point" procedure before sending an SDP offer with added codecs to the terminating user. The IBCF may signal media related information to the TrGW or omit media when adding the IP termination at this stage.

NOTE 3: The signalling of media related information to a MGW requires that it reserve the indicated resources before returning a positive response to the H.248 command, by omitting media related information the TrGW does not need to reserve any associated resources at this stage.

– When the IBCF receives the SDP answer from the terminating user, the IBCF shall check if any of the codecs offered by the originating side are contained in the answer.

– If only the codecs inserted by the IBCF are contained in the answer, the IBCF shall configure the TrGW to transcode. If it previously performed a "Reserve TrGW Connection Point" procedure it shall configure the TrGW using the "Configure TrGW Connection Point" procedure towards the termination on the terminating user side by supplying the media returned in the answer from the terminating user, otherwise it shall perform a "Reserve and Configure TrGW Connection Point" procedure. Within those procedures, the IBCF shall supply the media returned in the answer from the terminating user. If the IBCF seized the termination only at this point in time, it shall send the IP address and port information received from the TrGW in the acknowledment to the "Reserve and Configure TrGW Connection Point" procedure towards the terminating user in a new SDP offer. The IBCF shall perform the "Reserve and Configure TrGW Connection Point" procedure towards the termination on the originating user side, supplying the preferred media offered by the originating side.

– If the returned SDP contains media offered by the originating user no transcoding at the TrGW is required. If the IBCF previously performed the "Reserve TrGW Connection Point" procedure the IBCF shall configure the TrGW accordingly by either either supplying the same media related information for all interconnected terminations or by omitting the media related information.

Some basic use cases are depicted in figures 10.2.5.1, 10.2.5.2, and 10.2.5.3.

1. The IBCF receives an SDP offer in SIP signalling.

2. The IBCF adds additional codecs to the subsequent SDP offer, giving priority to those offered by the preceding node/network.

3. In this example the IBCF seizes a TrGW prior to sending the new SDP offer; as this scenario is preparing for a possible transcoding in the TrGW then a TrGW supporting media shall be seized. The IBCF sends a H.248 ADD request command to create the outgoing termination and to request IP resources to execute TrGW function. As no media transcoding is yet known to be needed this may be indicated by omitting media related sub-fields in the media descriptor (i.e.signalling "-"). Alternatively the preferred codec (e.g. codec 1) may be signalled in order to reserve this resource in the event that transcoding was required.

4. The TrGW creates the outgoing termination.

5. The TrGW replies to IBCF with a H.248 ADD reply command and provides the local address and port of the outgoing termination.

6. The IBCF replaces the IP address inside the SDP offer using the information coming from TrGW

7. The IBCF forwards the new SDP offer to the succeeding node.

8. The SDP answer is received by IBCF. In this example the codec1 received in the original SDP offer in step1 has been selected by the succeeding network/terminating UE and the IBCF determines that transcoding is not required.

9. The IBCF sends a H.248 MOD request command to configure the outgoing termination with address and port information received in the SDP answer. As no media transcoding is needed this may be indicated by omitting media related sub-fields in the media descriptor (i.e. signalling "-"). Alternatively the selected codec (codec 1) may be signalled.

10. The TrGW configures the outgoing termination.

11. The TrGW replies to IBCF with a H.248 MOD reply command.

12. The IBCF sends a H.248 ADD request command to create the incoming termination to configure this termination with remote address and port information and to request resources to execute TrGW function. As no media transcoding is needed this may be indicated by omitting media related sub-fields in the media descriptor (i.e. signalling "-"). Alternatively the selected codec received in step 8 (Codec 1) may be signalled.

13. The TrGW creates the incoming termination.

14. The TrGW replies to the IBCF with a H.248 ADD reply command and provides the local address and port of the incoming termination.

15. The IBCF replaces the IP address inside the SDP using the information coming from TrGW.

16. The SDP answer is sent to the network at the incoming side.

Figure 10.2.5.1: IBCF and TrGW interaction when the IBCF offers additional codecs but no transcoding is required, and the TrGW is seized in advance.

1. The IBCF receives an SDP offer in SIP signalling.

2. The IBCF adds additional codecs to the subsequent SDP offer, giving priority to those offered by the preceding node/network.

3. In this example the IBCF seizes a TrGW prior to sending the new SDP offer; as this scenario is preparing for a possible transcoding in the TrGW then a TrGW supporting media shall be seized. The IBCF sends a H.248 ADD request command to create the outgoing termination and to request IP resources to execute TrGW function. As no media transcoding is yet known to be needed this may be indicated by omitting media related sub-fields in the media descriptor (i.e.signalling "-"). Alternatively the preferred codec (e.g. Codec 1) may be signalled in order to reserve this resource in the event that transcoding was required.

4. The TrGW creates the outgoing termination.

5. The TrGW replies to IBCF with a H.248 ADD reply command and provides the local address and port of the outgoing termination.

6. The IBCF replaces the IP address inside the SDP offer using the information coming from TrGW.

7. The IBCF forwards the new SDP offer to the succeeding node.

8. The SDP answer is received by IBCF. In this example the codec 3 added by the IBCF to the SDP offer has been selected. Transcoding is therefore required.

9. The IBCF sends a H.248 MOD request command to configure the outgoing termination with address and port information received in the SDP answer and the selected media attibutes (codec 3).

10. The TrGW configures the outgoing termination.

11. The TrGW replies to IBCF with a H.248 MOD reply command.

12. The IBCF sends a H.248 ADD request command to create the incoming termination to configure this termination with remote address and port information and to request resources to execute TrGW function. As media transcoding is required it indicates this explicitly with a codec selected by the IBCF for the incoming termination from the offered codec(s) received in step1.

13. The TrGW creates the incoming termination.

14. The TrGW replies to the IBCF with a H.248 ADD reply command and provides the local address and port of the incoming termination.

15. The IBCF replaces the IP address inside the SDP using the information coming from TrGW and replaces the codec with the codec it selected for the incoming termination.

16. The SDP answer is sent to the network at the incoming side.

Figure 10.2.5.2: IBCF and TrGW interaction when IBCF offers additional codecs and transcoding is required, and the TrGW is seized in advance.

1. The IBCF receives an SDP offer in SIP signalling.

2. The IBCF requires a TrGW for another use case but does not offer transcoding.

3. The IBCF sends a H.248 ADD request command to create the outgoing termination and to request IP resources to execute TrGW function. As no media transcoding is required this may be indicated by signalling "-". Alternatively any codec (e.g. codec 1) can be signalled. If the IBCF selects a TrGW that does not support transcoding, the IBCF may signal media related sub-fields in the media descriptor to the TrGW if the TrGW supports media encoding. The TrGW shall accept the ADD request even though it cannot reserve any transcoding resources for the indicated media.

4. The TrGW creates the outgoing termination.

5. The TrGW replies to IBCF with a H.248 ADD reply command and provides the local address and port of the outgoing termination.

6. The IBCF replaces the IP address inside the SDP using the information coming from TrGW.

7. The IBCF forwards the new offer to the succeeding node.

8. The SDP answer is received by IBCF. In this example the codec 1 received in the original SDP offer in step 1 has been selected.

9. The IBCF sends a H.248 MOD request command to configure the outgoing termination with address and port information. As no media transcoding is needed this may be indicated by signalling "-" .Alternatively the selected codec (codec 1) can be signalled.

10. The TrGW configures the outgoing termination.

11. The TrGW replies to IBCF with a H.248 MOD reply command.

12. The IBCF sends a H.248 ADD command to create the incoming termination to configure this termination with remote address and port information and to request resources to execute TrGW function. As no media transcoding is needed this may be indicated by signalling "-" .Alternatively media related sub-fields in the media descriptor for the codec indicated to the incoming termination may be signalled (e.g. the selected codec received in step 8 (codec 1).

13. The TrGW creates the incoming termination.

14. The TrGW replies to the IBCF with a H.248 ADD reply command and provides the local address and port of the incoming termination.

15. The IBCF replaces the IP address inside the SDP answer using the information coming from TrGW.

16. The SDP answer is sent to the network at the incoming side.

Figure 10.2.5.3: IBCF and TrGW interaction when IBCF does not offer transcoding

10.2.5.2 Handling of common codec parameters

The requirements as described in subclause 5.13.2 of 3GPP TS 23.334 [43] for the IMS-ALG and the IMS-AGW, apply to the IBCF and the TrGW.

10.2.5.3 EVS speech codec parameters handling

The Enhanced Voice Services (EVS) speech codec is defined in 3GPP TS 26.441 [52]. Its RTP payload type is defined in 3GPP TS 26.445 [53], and procedures for its usage as IMS Multimedia Telephony speech codec are defined in 3GPP TS 26.114 [36].

The IBCF and the TrGW may support transcoding to and from the EVS speech codec. If they do so, the requirements as described in subclause 5.13.3 of 3GPP TS 23.334 [43] for the IMS-ALG and the IMS-AGW, apply to the IBCF and the TrGW.

10.2.5.4 Rate adaptation for media endpoints

If the IBCF and the TrGW support rate adaptation for media endpoints using the enhanced bandwidth negotiation mechanism defined in 3GPP TS 26.114 [36] the requirements and procedures in the present subclause apply.

If the IBCF receives an SDP offer and if the IBCF and the TrGW apply the transcoding procedure, defined in subclause 10.2.5.1, then the following additional actions may be performed:

– if the received SDP offer (figure 10.2.5.2, step 1) contained the SDP "a=bw-info" attribute(s), defined in clause 19 of 3GPP TS 26.114 [36] for payload type(s) that the IBCF retains in the forwarded SDP offer, the IBCF:

a) if the IP version interworking is required and the received "a=bw-info" SDP attribute lines do not contain bandwidth properties for both IPv4 and IPv6, should adjust the bandwidth properties in accordance with subclause 9.1.5; or

b) otherwise (if the IP version interworking is not required or the received "a=bw-info" SDP attribute lines contain bandwidth properties for both IPv4 and IPv6), should forward the SDP offer with unmodified related SDP "a=bw-info" attribute(s); and

NOTE 1: The IBCF can modify the related SDP "a=bw-info" attribute(s) according to operator policies as specified in 3GPP TS 26.114 [36].

– for the each added codec in the SDP offer (figure 10.2.5.2, step 6) the IBCF shall include appropriate bandwidth information in new or existing "a=bw-info" attribute lines(s).

If the IBCF then receives an SDP answer (figure 10.2.5.2, step 8) and if only the codecs inserted by the IBCF with the corresponding SDP "a=bw-info" attribute(s) are contained in the SDP answer the IBCF:

– when requesting the TrGW to configure resources towards the succeeding node (figure 10.2.5.2, step 9), shall include for the selected codec the "Additional Bandwidth Properties" information element containing "a=bw-info" SDP attribute(s) providing information for the selected codec in the remote descriptor about bandwidths that will be used for the selected codec in the sending direction towards the succeeding node;

NOTE 2: The included information corresponds to "a=bw-info" SDP attribute(s) from the received SDP answer for the "recv" or "sendrecv" direction.

– shall select a codec from the ones in the previously received SDP offer from the preceding node;

– if the received SDP offer contained the SDP "a=bw-info" attribute(s) for the selected codec:

a) shall construct appropriate SDP "a=bw-info" attribute(s) for the selected codec according to the rules in 3GPP TS 26.114 [36]; and

NOTE 3: The offer/answer negotiation is performed for each "a=bw-info" SDP attribute line, payload type, direction and bandwidth property individually.

b) shall include the "Additional Bandwidth Properties" information element containing "a=bw-info" SDP attribute(s) in the remote descriptor describing bandwidths that will be used for the selected codec in the sending direction towards the preceding node when requesting the TrGW to reserve resources towards the preceding node (figure 10.2.5.2, step 12); and

NOTE 4: The included information corresponds to "a=bw-info" SDP attribute(s) in the sent SDP answer for the "send" or "sendrecv" direction.

– include the selected codec with the corresponding SDP "a=bw-info" attribute(s) in the modified SDP answer (figure 10.2.5.2, step 15) that will be sent towards the preceding node.

If the received SDP answer contains codecs received in the SDP offer no transcoding at the TrGW is required and the IBCF shall:

– not include the "Additional Bandwidth Properties" information element containing the "a=bw-info" SDP attribute(s) when requesting the TrGW to configure resources towards the succeeding node (figure 10.2.5.2, step 9);

– if the received SDP answer (figure 10.2.5.2, step 8) contained the SDP "a=bw-info" attribute(s), the IBCF shall check:

a) if the IP version interworking is required and the received "a=bw-info" SDP attribute lines do not contain bandwidth properties for both IPv4 and IPv6, the IBCF may adjust the bandwidth properties in accordance with subclause 9.1.5;

b) otherwise (if the IP version interworking is not required or the received "a=bw-info" SDP attribute lines contain bandwidth properties for both IPv4 and IPv6), the IBCF shall forward the SDP answer with unmodified SDP "a=bw-info" attribute(s).

The TrGW may use the "Additional Bandwidth Properties" information element indicating media bandwidth range for rate adaption (i.e. to select an appropriate encoding and redundancy) when transcoding media streams.