Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 26.114  Word version:  18.5.0

Top   Top   Up   Prev   Next
0…   3…   4…   5…   6…   6.2.3…   6.2.5…   6.2.7…   6.2.10…   7…   7.5…   8…   9…   10…   10.2.1.6…   10.2.2…   10.3…   10.4…   11…   12…   12.3…   12.7…   13a…   16…   16.5…   17…   18…   19…   A…   A.3…   A.4…   A.5…   A.10…   A.14…   A.15…   B…   C…   C.1.3…   C.1.3.5   C.2…   D   E…   E.18…   E.31…   G…   K…   L…   M…   N…   O…   P…   P.3   Q…   R…   S…   T…   U…   V…   W…   X…   Y…   Y.6…   Y.6.4…   Y.6.5…   Y.7… 
A.10 Examples of SDP offers and answers for inter-working with other IMS or non-IMS IP networks  A.10.1 General  A.10.2 Session initiated by MTSI client in terminal  A.10.2.1 SDP offers from an MTSI client in terminal  A.10.2.2 SDP offers modified by MTSI MGW when pre-emptively adding inter-working formats  A.10.2.3 SDP modified by MGW when adding inter-working formats only when the original SDP offer was rejected  A.11 Adding or removing a video component to/from an on-going video call session  A.12 SDP examples when using ECN  A.12.1 SDP examples when using ECN for speech  A.12.1.1 With RTP/AVP and zero RTCP bandwidth  A.12.1.2 With RTP/AVPF and non-zero RTCP bandwidth  A.12.1.3 With RTCP ECN feedback messages and RTCP XR ECN summary reports for inter-working with non-MTSI clients  A.12.2 SDP examples when using ECN for video in RTP  A.12.2.1 Without RTCP AVPF ECN feedback messages and RTCP XR ECN summary reports  A.12.2.2 With RTCP AVPF ECN feedback messages and RTCP XR ECN summary reports for inter-working with non-MTSI clients  A.13 SDP examples for MTSI client in terminal using fixed access  A.13.1 General  A.13.2 SDP examples for PCM  A.13.3 SDP example for G.722  A.13.4 SDP example for EVS, AMR-WB, G.722, AMR, PCM and DTMF 
...

 

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

A.10.1  General  p. 278

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.
Up

A.10.2  Session initiated by MTSI client in terminal  p. 278

A.10.2.1  SDP offers from an MTSI client in terminal  p. 278

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).
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.
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.
Up

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

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).
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.
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).
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.
Up

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

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.
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.
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).
In this case, the maxptime is set to 80, if the MTSI MGW does not support redundancy.
Up

A.11  Adding or removing a video component to/from an on-going video call session |R8|  p. 282

The MTSI client in a terminal can add, remove and modify the media components during an ongoing MTSI session. This clause describes the SDP offer in the initial SIP INVITE message, see Table A.11.1, and the SDP in the subsequent re-INVITE or UPDATE message for adding and removing a video stream to/from the ongoing MTSI video call session, see Table A.11.2 and Table A.11.3, respectively. Corresponding SDP answers in the SIP 200/OK responses are also described.
The initial video call session contains one video component and one speech component. During the session, the MTSI client in terminal A adds a uni-directional video component (such as one video clip) to the ongoing video call session. The SDP content attribute "a=content:main" and "a=content:alt" are used to label the main and alternative video components respectively (RFC 4796).
This example does not show how to use the content attribute in combination with the grouping attribute, nor does it show how to use the content attribute in combination with the synchronization attribute defined in clause 6.2.6.
SDP offer from MTSI client in terminal A to B in SIP INVITE message 
a=tcap:1 RTP/AVPF
m=audio 49150 RTP/AVP 96
a=pcfg:1 t=1
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:96 AMR/8000/1
a=fmtp:96 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
m=video 54320 RTP/AVP 99
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
SDP answer from MTSI client in terminal B to A in 200/OK RESPONSE message 
m=audio 49152 RTP/AVPF 96
a=acfg:1 t=1
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:96 AMR/8000/1
a=fmtp:96 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
m=video 54320 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=extmap:4 urn:3gpp:video-orientation
SDP offer from MTSI client in terminal A to B in SIP UPDATE/Re-INVITE message 
a=tcap:1 RTP/AVPF
m=audio 49150 RTP/AVP 96
a=pcfg:1 t=1
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:96 AMR/8000/1
a=fmtp:96 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
m=video 54320 RTP/AVP 99
i=Main video
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=content:main
a=extmap:4 urn:3gpp:video-orientation
m=video 43200 RTP/AVP 100
i=Alternative video
a=pcfg:1 t=1
b=AS:128
b=RS:0
b=RR:2500
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=content:alt
a=sendonly
a=extmap:4 urn:3gpp:video-orientation
SDP answer from MTSI client in terminal B to A in 200/OK RESPONSE to UPDATE/Re-INVITE message 
m=audio 49152 RTP/AVPF 96
a=acfg:1 t=1
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:96 AMR/8000/1
a=fmtp:96 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
m=video 54320 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=content:main
a=extmap:4 urn:3gpp:video-orientation
m=video 43200 RTP/AVPF 100
a=acfg:1 t=1
b=AS:128
b=RS:0
b=RR:2500
a=rtpmap:100 H264/90000
a=fmtp:100 packetization-mode=0; profile-level-id=42e00c; \
     sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==
a=content:alt
a=recvonly
a=extmap:4 urn:3gpp:video-orientation
SDP offer from MTSI client in terminal A to B in SIP INVITE message 
m=audio 49150 RTP/AVPF 96
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:96 AMR/8000/1
a=fmtp:96 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
m=video 0 RTP/AVP 99
SDP answer from MTSI client in terminal B to A in 200/OK RESPONSE message 
m=audio 49152 RTP/AVPF 96
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:96 AMR/8000/1
a=fmtp:96 mode-change-capability=2; max-red=220
a=ptime:20
a=maxptime:240
m=video 0 RTP/AVP 99
Up

A.12  SDP examples when using ECN |R9|  p. 286

A.12.1  SDP examples when using ECN for speech  p. 286

A.12.1.1  With RTP/AVP and zero RTCP bandwidth  p. 286

The following SDP offer and SDP answer are likely when both MTSI clients in terminals use ECN for speech.
This SDP example is based on the SDP example found in Table A.3.0 except that bandwidth information for the media has been added, zero RTCP bandwidth has been negotiated, and AVPF is not offered.
SDP offer 
m=audio 49152 RTP/AVP 97 98
b=AS:30
b=RS:0
b=RR:0
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=ecn-capable-rtp: leap ect=0
a=ptime:20
a=maxptime:240
SDP answer 
m=audio 49152 RTP/AVP 99
b=AS:29
b=RS:0
b=RR:0
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-change-capability=2; max-red=220
a=ecn-capable-rtp: leap ect=0
a=ptime:20
a=maxptime:240
Comments:
The SDP offer includes the SDP attribute 'ecn-capable-rtp' to indicate that ECN is supported. The SDP offer further includes the parameters: 'leap' to indicate that the leap-of-faith initiation method is to be used; and 'ect=0' to request that the other endpoint sets the ECN bits to ECT(0). The SDP offer does not include the "rtcp-fb" attribute for negotiating use of the RTCP AVPF ECN feedback messages (RFC 6679). This results in RTP CMR (RFC 4867) being used as the application specific feedback for ECN-triggered adaptation. The SDP offer also proposes to not use RTCP for the session.
The SDP answer is configured in the same way as in the offer to indicate that the ECN usage and its configuration is agreeable to be used in the session.
Up

A.12.1.2  With RTP/AVPF and non-zero RTCP bandwidth  p. 287

This SDP example is based on the SDP example found in Table A.3.0 except that bandwidth information for the media has been added. The negotiation of Reduced-Size RTCP is added together with the ECN negotiation. Non-zero RTCP bandwidth and AVPF have also been negotiated.
SDP offer 
m=audio 49152 RTP/AVP 97 98
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:30
b=RS:0
b=RR:2000
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=ecn-capable-rtp: leap ect=0
a=rtcp-rsize
a=ptime:20
a=maxptime:240
SDP answer 
m=audio 49152 RTP/AVPF 99
a=acfg:1 t=1
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-change-capability=2; max-red=220
a=ecn-capable-rtp: leap ect=0
a=rtcp-rsize
a=ptime:20
a=maxptime:240
Comments:
The SDP offer includes the SDP attribute 'ecn-capable-rtp' to indicate that ECN is supported. The SDP offer further includes the parameters: 'leap' to indicate that the leap-of-faith initiation method is to be used; and 'ect=0' to request that the other endpoint sets the ECN bits to ECT(0). The SDP offer does not include the "rtcp-fb" attribute for negotiating use of the RTCP AVPF ECN feedback messages (RFC 6679). This results in RTCP-APP CMR and reduced-size RTCP being used as the application specific feedback for ECN-related adaptation.
The SDP answer is configured in the same way as in the offer to indicate that the ECN usage and its configuration is agreeable to be used in the session.
Up

A.12.1.3  With RTCP ECN feedback messages and RTCP XR ECN summary reports for inter-working with non-MTSI clients  p. 288

The following SDP offer and SDP answer are possible when an MTSI client is inter-working with non-MTSI clients and when the MTSI client supports RTCP AVPF ECN feedback messages and RTCP XR ECN summary reports.
SDP offer 
m=audio 49152 RTP/AVP 97 98
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:30
b=RS:0
b=RR:2000
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=ecn-capable-rtp: leap ect=0
a=rtcp-fb:* nack ecn
a=rtcp-xr:ecn-sum
a=rtcp-rsize
a=ptime:20
a=maxptime:240
SDP answer 
m=audio 49152 RTP/AVPF 99
a=acfg:1 t=1
b=AS:29
b=RS:0
b=RR:2000
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-change-capability=2; max-red=220
a=ecn-capable-rtp: leap ect=0
a=rtcp-fb:* nack ecn
a=rtcp-xr:ecn-sum 
a=rtcp-rsize
a=ptime:20
a=maxptime:240
Comments:
The SDP offer is similar to the offer in Table A.12.2. The line "a=rtcp-fb:* nack ecn" is included to indicate that the RTCP AVPF ECN feedback messages can be used by all payload types for speech. The line "a=rtcp-xr:ecn-sum" is included to indicate that the RTCP XR ECN summary reports can also be used.
Since the offering MTSI client supports the RTCP AVPF ECN feedback messages and RTCP XR ECN summary reports there is no need to insert any media gateway in the path to solve inter-working.
Up

A.12.2  SDP examples when using ECN for video in RTP |R10|  p. 289

A.12.2.1  Without RTCP AVPF ECN feedback messages and RTCP XR ECN summary reports  p. 289

The following SDP offer and SDP answer are likely when both MTSI clients in terminals use ECN for video and TMMBR for rate adaptation.
This SDP example is the same as the SDP example found in Table A.4.4b and Table A.4.4c, except that the negotiation for ECN has been added.
SDP offer 
m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e00a; \
     sprop-parameter-sets=J0LgCpWgsToB/UA=,KM4Gag==
a=rtcp-fb:* trr-int 5000
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli 
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* ccm fir
a=ecn-capable-rtp: leap ect=0
a=extmap:4 urn:3gpp:video-orientation
SDP answer 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e00a; \
     sprop-parameter-sets=J0LgCpWgsToB/UA=,KM4Gag==
a=rtcp-fb:* trr-int 5000 
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* ccm fir
a=ecn-capable-rtp: leap ect=0
a=extmap:4 urn:3gpp:video-orientation
Comments:
The SDP offer includes the SDP attribute 'ecn-capable-rtp' to indicate that ECN is supported. The SDP offer further includes the parameters: 'leap' to indicate that the leap-of-faith initiation method is to be used; and 'ect=0' to request that the other endpoint sets the ECN bits to ECT(0).
The SDP offer also includes an offer for AVPF to enable sending adaptation requests without following the normal rules for RTCP transmission intervals. TMMBR is also offered to indicate that this can be used for rate adaptation.
The SDP answer is configured in the same way as in the offer to indicate that the ECN usage and its configuration is agreeable to be used in the session.
Up

A.12.2.2  With RTCP AVPF ECN feedback messages and RTCP XR ECN summary reports for inter-working with non-MTSI clients  p. 290

The following SDP offer and SDP answer are possible when an MTSI client is inter-working with non-MTSI clients not supporting TMMBR and when the MTSI client supports RTCP AVPF ECN feedback messages and RTCP XR ECN summary reports.
This SDP example is the same as the SDP example found in Table A.4.4b and Table A.4.4c, except that the negotiation for ECN has been added.
SDP offer 
m=video 49154 RTP/AVP 99
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e00a; \
     sprop-parameter-sets=J0LgCpWgsToB/UA=,KM4Gag==
a=ecn-capable-rtp: leap ect=0
a=rtcp-fb:* trr-int 5000 
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm tmmbr
a=rtcp-fb:* ccm fir
a=rtcp-fb:* nack ecn
a=rtcp-xr:ecn-sum
a=extmap:4 urn:3gpp:video-orientation
SDP answer (non-MTSI client) 
m=video 49154 RTP/AVPF 99
a=acfg:1 t=1
b=AS:315
b=RS:0
b=RR:2500
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=0;profile-level-id=42e00a; \
     sprop-parameter-sets=J0LgCpWgsToB/UA=,KM4Gag== 
a=ecn-capable-rtp: leap ect=0
a=rtcp-fb:* trr-int 5000 
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* nack ecn
a=rtcp-xr:ecn-sum
a=extmap:4 urn:3gpp:video-orientation
Comments:
The SDP offer is similar to the offer in Table A.12.2.1. The line "a=rtcp-fb:* nack ecn" is included to indicate that the RTCP AVPF ECN feedback messages can be used all payload types for video. The line "a=rtcp-xr:ecn-sum" is included to indicate that the RTCP XR ECN summary reports can also be used.
The answering client does not support TMMBR and full intra requests and therefore removes these attribute lines when creating the SDP answer.
Since the offering MTSI client supports the RTCP AVPF ECN feedback messages and RTCP XR ECN summary reports there is no need to insert any media gateway in the path to provide inter-working.
Up

A.13  SDP examples for MTSI client in terminal using fixed access |R12|  p. 291

A.13.1  General  p. 291

This clause includes SDP examples that may be applicable to an MTSI client in terminal using fixed access. The SDP examples in Annex A.13.2 to A.13.6 show SDPs including PCM, G.729, G.722 and G.729.1. Examples of SDP offers for the AMR and AMR-WB codecs are described in Annex A.1 and the corresponding examples of SDP answers are found in Annex A.3. SDP examples for EVRC, EVRC-B and EVRC-WB are found in [97].
Examples of SDP offer and answer for video are described in Annex A.4.
An example for an SDP offer for real-time text is described in Annex A.5.
These examples also include bandwidth information which is calculated assuming IPv6 and 20 ms packetization.
Up

A.13.2  SDP examples for PCM  p. 291

Table A.13.1 shows an example for the SDP offer and answer negotiation for PCM. The SDP offer uses the static payload type numbers that are defined in RFC 3551 for PCM, i.e. payload type number 0 for μ-law PCM and payload type number 8 for A-law PCM, see also clause 18.4.3. Since static payload type numbers are used, as shown on the m= line, then there is no need for adding any a=rtpmap attribute lines. The answerer chooses to accept A-law PCM and therefore sends an SDP answer with RTP payload type number 8 on the m= line.
SDP offer 
m=audio 49152 RTP/AVP 0 8
b=AS:88
a=ptime:20
a=maxptime:240
SDP answer 
m=audio 49152 RTP/AVP 8
b=AS:88
a=ptime:20
a=maxptime:240
Comments:
The SDPs further describe that the clients prefer to receive speech with 20 ms packetization (ptime is set to 20) but up to 240 ms packetization is allowed.
Table A.13.2 shows an example for how the PCM codec can be negotiated using dynamic payload type numbers. In this case, payload type number 96 is used for μ-law PCM and payload type number 97 is used for A-law PCM. The answerer chooses to accept μ-law PCM.
SDP offer 
m=audio 49152 RTP/AVP 96 97
b=AS:88
a=rtpmap:96 PCMU/8000/1
a=rtpmap:97 PCMA/8000/1
a=ptime:20
a=maxptime:240
SDP answer 
m=audio 49152 RTP/AVP 96
b=AS:88
a=rtpmap:96 PCMU/8000/1
a=ptime:20
a=maxptime:240
Comments:
This example is included here to show that it is possible to use dynamic payload type numbers also for codecs for which static payload type numbers have been defined. It is however preferable to use static payload type numbers, see clause 18.4.3.
Up

A.13.3  SDP example for G.722  p. 292

Table A.13.3 shows an example for how G.722 can be negotiated using the static payload type number (9) defined in RFC 3551, see also clause 18.4.3.
SDP offer 
m=audio 49152 RTP/AVP 9
b=AS:88
a=rtpmap:9 G722/8000/1
a=ptime:20
a=maxptime:240
SDP answer 
m=audio 49152 RTP/AVP 9
b=AS:88
a=rtpmap:9 G722/8000/1
a=ptime:20
a=maxptime:240
Comments:
The G.722 codec uses an RTP clock rate of 8 kHz even though G.722 is a wideband speech codec that uses a sampling frequency of 16 kHz. This means that the RTP Time Stamp is sampled with 8 kHz.
The SDPs further describe that the clients prefer to receive speech with 20 ms packetization (ptime is set to 20) but up to 240 ms packetization is allowed.
Up

A.13.4  SDP example for EVS, AMR-WB, G.722, AMR, PCM and DTMF  p. 292

Table A.13.4 shows an example where an MTSI client in terminal using fixed access has been developed to support fixed-mobile interworking without the need for transcoding in a media gateway. It therefore supports the G.722 and PCM codecs that are normally used in fixed networks. In addition, it also supports the AMR-WB and AMR codecs in the same way as an MTSI client in terminal using mobile access would do. The SDP offer includes all these codecs as well as DTMF.
SDP offer 
m=audio 49152 RTP/AVP 96 97 98 9 99 100 8 0 105 106
b=AS:89
b=RS:0
b=RR:4000
a=rtpmap:96 EVS/16000/1
a=fmtp:96 br=64; bw=swb; max-red=220
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=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:105 telephone-event/16000
a=fmtp:105 0-15
a=rtpmap:106 telephone-event/8000
a=fmtp:106 0-15
a=ptime:20
a=maxptime:240
Comments:
The wideband codecs (AMR-WB and G.722) are listed as preferred over the narrowband codecs (AMR and PCM). This ensures that a wideband service will be set up whenever possible.
The AMR and AMR-WB codecs are listed here as preferred over the PCM and G.722 codecs, respectively, because of their lower bitrate and also because of their bitrate adaptation capabilities.
The SDP offer includes DTMF with both 8 kHz and 16 kHz RTP clock rate since there are codecs with both clock rates in the offer. An answerer is expected to accept the DTMF variant that has the same clock rate as for the accepted codec. This means that when G.722 is accepted then DTMF with 8 kHz clock rate should also be accepted, even though G.722 is a wideband speech codec. This is because G.722 uses 8 kHz clock rate, see RFC 3551.
Since the clock rate of EVS is set to 16 kHz, regardless of the bandwidth in the session, DTMF with 16 kHz RTP clock rate should be accepted when EVS is accepted.
Up

Up   Top   ToC