A.10 Examples of SDP offers and answers for inter-working with other IMS or non-IMS IP networks

26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS

A.10.1 General

The session between an MTSI client in a terminal and a client in a remote (IMS or non-IMS) network can be established in many ways, especially when the session is initiated by the remote network and when the remote network does not use the MTSI service.

The SDP will also depend on how and when the MTSI MGW chooses to add information about what formats (other than AMR and AMR-WB) that can be used for inter-working. There are, in general, two methods for MTSI MGWs to add information about the alternative formats. The first method is to add the alternative formats to the original SDP offer from the initiating client as a pre-emptive action. The second method is to leave the original SDP offer unchanged, forward it to the remote network and wait for the answerer to respond and only add the alternative formats if/when the SDP offer was rejected. A further complication is that there might be multiple MGWs in the path for this kind of inter-working and different MGWs might work differently.

The SDP examples included below should therefore be regarded as a few samples of possible SDPs and should not be regarded as a complete description of what might occur in a real implementation.

A.10.2 Session initiated by MTSI client in terminal

A.10.2.1 SDP offers from an MTSI client in terminal

The MTSI client in terminal could send an SDP offer as shown in Table A.10.1 (narrow-band speech only) or Table A.10.2 (wide-band and narrow-band speech).

Table A.10.1: Original SDP offer from an MTSI client in terminal for narrow-band speech

SDP offer

m=audio 49152 RTP/AVP 97 98 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 a=ptime:20 a=maxptime:240

Comments:

This SDP offer is identical to the SDP offer in Table A.1.1.

Table A.10.2: Original SDP offer from an MTSI client in terminal for narrow-band and wide-band speech

SDP offer

m=audio 49152 RTP/AVP 97 98 99 100 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=rtpmap:98 AMR-WB/16000/1 a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-change-capability=2; max-red=220 a=rtpmap:100 AMR/8000/1 a=fmtp:100 mode-change-capability=2; max-red=220; octet-align=1 a=ptime:20 a=maxptime:240

Comments:

This SDP offer is identical to the SDP offer in Table A.1.2.

A.10.2.2 SDP offers modified by MTSI MGW when pre-emptively adding inter-working formats

In this example, the MTSI MGW intercepts the SIP INVITE with the original SDP offer from the MTSI client in terminal and adds the codecs and formats that are supported for inter-working before forwarding the SDP offer to the remote network.

When an MTSI MGW pre-emptively adds codecs and formats for inter-working it will also remove lines that it does not support. These examples show an MTSI MGW that does not support AVPF nor SDPCapNeg and it will therefore remove the corresponding lines. The SDP offers could look like the examples included in Table A.10.3 (narrow-band speech only) and Table A.10.4 (wide-band and narrow-band speech).

Table A.10.3: SDP offer for narrow-band speech which has been modified by the MTSI MGW before it is sent to the remote network

Modified SDP offer

m=audio 49152 RTP/AVP 97 98 99 100 101 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 a=rtpmap:99 PCMA/8000/1 a=rtpmap:100 PCMU/8000/1 a=rtpmap:101 L16/8000/1 a=ptime:20 a=maxptime:240

Comments:

The SDP offer from Table A.10.1 has been modified by adding RTP Payload Types 99 (A-law PCM), 100 (-law PCM) and 101 (linear 16 bit PCM with 8 kHz sampling frequency).

The lines "a=tcap:1 RTP/AVPF" and "a=pcfg:1 t=1" are removed because the MTSI MGW does not support AVPF nor SDPCapNeg in this example.

To allow for end-to-end adaptation for AMR and AMR-WB, the MTSI MGW keeps a=maxptime:240.

If the remote network supports AMR, then the received SDP answer should contain at least one RTP Payload Type for AMR but there may also be one or more RTP Payload types for non-AMR codecs. In this case, the MTSI MGW does not need to perform transcoding and may forward the SDP offer to the MTSI client in terminal unchanged.

If the SDP answer contains no AMR RTP Payload Type then the MTSI MGW needs to perform transcoding to and from the format indicated by the remote network. In this case, the MTSI MGW needs to add AMR to the SDP answer that is sent back to the MTSI client in terminal.

Table A.10.4: SDP offer for wide-band and narrow-band speech which has been modified by the MTSI MGW before it is sent to the remote network

Modified SDP offer

m=audio 49152 RTP/AVP 97 98 101 102 99 100 103 104 105 a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=rtpmap:98 AMR-WB/16000/1 a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 a=rtpmap:101 G722/8000/1 a=rtpmap:102 L16/16000/1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-change-capability=2; max-red=220 a=rtpmap:100 AMR/8000/1 a=fmtp:100 mode-change-capability=2; max-red=220; octet-align=1 a=rtpmap:103 PCMA/8000/1 a=rtpmap:104 PCMU/8000/1 a=rtpmap:105 L16/8000/1 a=ptime:20 a=maxptime:240

Comments:

The SDP offer from Table A.10.2 has been modified by adding RTP Payload Types 101 (G.722), 102 (linear 16 bit PCM with 16 kHz sampling frequency), 103 (A-law PCM), 104 (-law PCM) and 105 (linear 16 bit PCM with 8 kHz sampling frequency).

NOTE: The sampling frequency for G.722 is 16 kHz but has been set to 8 kHz in the SDP because G.722 was (erroneously) assigned this value in the original version of the RTP A/V profile. Hence, one need to use "8000" for backwards compatibility reasons, see also [10].

The lines "a=tcap:1 RTP/AVPF" and "a=pcfg:1 t=1" are removed because the MTSI MGW does not support SDPCapNeg (in this example).

To allow for end-to-end adaptation for AMR and AMR-WB, the MTSI MGW keeps a=maxptime:240.

If the remote network supports AMR-WB or AMR, then the received SDP answer should contain at least one RTP Payload Type for AMR-WB or AMR but there may also be one or more RTP Payload Types for non-AMR codecs. In this case, the MTSI MGW does not need to perform transcoding and can remove the non-AMR RTP Payload Types before forwarding the SDP answer to the MTSI client in terminal.

If the SDP answer contains no AMR-WB or AMR RTP Payload Type then the MTSI MGW needs to perform transcoding to and from the format indicated by the remote network.

A.10.2.3 SDP modified by MGW when adding inter-working formats only when the original SDP offer was rejected

In this example, the MTSI MGW either forwards the original SDP offer that was received from the MTSI client in terminal to the remote network or it is not involved in the session setup at all until it is concluded that the same codecs are not supported in the different networks. In this latter case, the MTSI MGW is invoked only if the remote network rejects the SDP offer.

In this case, when the MTSI MGW sends the (new) SDP offer to the remote network it knows that the AMR (and AMR-WB) codecs are not supported by the remote network because the original SDP offer was rejected. It is therefore unnecessary to include these codecs in the (new) SDP offer. The SDP offers could look like the examples included in Table A.10.5 (narrow-band speech only) and Table A.10.6 (wide-band and narrow-band speech).

The remote client may also suggest codecs and configurations when it rejects the SDP offer. Existence of such information can, of course, be used to increase the likelihood that the session setup will be successful. These SDP examples are however designed for the case when no such information is available from the remote network.

Table A.10.5: New SDP offer for narrow-band speech sent by the MTSI MGW to the remote network

New SDP offer

m=audio 49152 RTP/AVP 99 100 101 a=rtpmap:99 PCMA/8000/1 a=rtpmap:100 PCMU/8000/1 a=rtpmap:101 L16/8000/1 a=ptime:20 a=maxptime:80

Comments:

The new SDP offer includes RTP Payload Types 99 (A-law PCM), 100 (-law PCM) and 101 (linear 16 bit PCM with 8 kHz sampling frequency).

In this case, the maxptime is set to 80, if the MTSI MGW does not support redundancy.

Table A.10.6: New SDP offer for narrow-band and wide-band speech sent by the MTSI MGW to the remote network

New SDP offer

m=audio 49152 RTP/AVP 101 102 103 104 105 a=rtpmap:101 G722/8000/1 a=rtpmap:102 L16/16000/1 a=rtpmap:103 PCMA/8000/1 a=rtpmap:104 PCMU/8000/1 a=rtpmap:105 L16/8000/1 a=ptime:20 a=maxptime:80

Comments:

The new SDP offer includes RTP Payload Types 101 (G.722), 102 (linear 16 bit PCM with 16 kHz sampling frequency), 103 (A-law PCM), 104 (-law PCM) and 105 (linear 16 bit PCM with 8 kHz sampling frequency).

NOTE: The sampling frequency for G.722 is 16 kHz but has been set to 8 kHz in the SDP because G.722 was (erroneously) assigned this value in the original version of the RTP A/V profile. Hence, one need to use "8000" for backwards compatibility reasons, see also [10].

In this case, the maxptime is set to 80, if the MTSI MGW does not support redundancy.