Content for TS 26.114 Word version: 18.8.0
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 Examples of SDP offers and answers
A.1 SDP offers for speech sessions initiated by MTSI client in terminal
A.1.1 HSPA or unknown access technology
A.1.1.1 Only AMR-NB supported by MTSI client in terminal
A.1.1.2 AMR and AMR-WB are supported by MTSI client in terminal
A.1.1.2.1 One-phase approach
A.1.1.2.2 Two-phase approach
A.1.2 EGPRS
A.1.3 Generic Access
A.2 SDP offers for speech sessions initiated by media gateway
A.2.1 General
A.2.2 MGW between GERAN UE and MTSI
A.2.3 MGW between legacy UTRAN UE and MTSI
A.2.4 MGW between CS UE and MTSI
A.2.5 MGW between GERAN UE and MTSI when wideband speech is supported
...
...
A Examples of SDP offers and answers p. 234
A.1 SDP offers for speech sessions initiated by MTSI client in terminal p. 234
This Annex includes several SDP examples for session setup for speech. SDP examples for sessions with speech and DTMF are shown in Annex G. These SDP offer and answer examples are designed to highlight the respective area that is being described and should therefore not be considered as complete SDP offers and answers. See TS 24.229 for a complete description of the SDPs. Therefore mandated session parameters such as b=AS should be assumed as present in the media and session level, even if they are not included in the SDP examples.
Some of the SDP examples contain a=fmtp lines that are too long to meet the column width constraints of this document and are therefore folded into several lines using the backslash ("\") character. In a real SDP, long lines would appear as one single line and not as such folded lines.
Some of the examples included in this Annex outline configurations that have been optimized for HSPA. These configurations are equally applicable to E-UTRAN and NR access since the packetization recommendations for HSPA and E-UTRAN and NR in clauses 7.4.2 and 7.5.2.1 for MTSI clients and clause 12.3.2 for MTSI media gateways are identical.
A.1.1 HSPA or unknown access technology p. 234
When the access technology is unknown to the MTSI client in terminal, the client uses the encapsulation parameters of default operation as defined in clause 7.5.2.1.2. The SDP examples below apply to HSPA as well as the default operation since the encapsulation parameters are the same.
A.1.1.1 Only AMR-NB supported by MTSI client in terminal p. 234
In this example one RTP Payload Type (97) is defined for the bandwidth-efficient payload format and another RTP payload type (98) for the octet-aligned payload format. In this case, the MTSI client in terminal supports mode changes at any time, mode changes to any mode and mode change restrictions.
| 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:
The UDP port number (49152) and the payload type numbers (97 and 98) are examples and the offerer is free to select other numbers within the restrictions of the UDP and RTP specifications. It is recommended to use the dynamic port numbers in the 49152 to 65535 range. RTP should use even numbers for RTP media and the next higher odd number for RTCP. It is however allowed to use any number within the registered port range 1,024 to 49,151. The receiver must be capable of using any combination of even and odd numbers for RTP and RTCP.
The SDP Capabilities Negotiation framework (SDPCapNeg) (RFC 5939) is used to negotiate what RTP profile to use. The offer includes RTP/AVP in the conventional SDP part by including it in the media (m=) line, while RTP/AVPF is given as a transport capability using the SDPCapNeg framework "a=tcap:1 RTP/AVPF". A potential configuration gives RTP/AVPF as an alternative "a=pcfg:1 t=1". Given by the rules in SDPCapNeg, the RTP/AVPF profile has higher preference than RTP/AVP.
It is important that the MTSI client in terminal does not define any mode-set because then the answerer is free to respond with any mode-set that it can support. If the MTSI client in terminal would define mode-set to any value, then the answer only has the option to either accept it or reject it. The latter case might require several ping-pong between the MTSI clients before they can reach an agreement on what mode set to use in the session. This would increase the setup time significantly. This is also one important reason for why the MTSI clients in terminals must support the complete codec mode set of the AMR and AMR-WB codecs, because then a media gateway interfacing GERAN or UTRAN can immediately define the mode-set that it supports on the GERAN or UTRAN circuit switched access.
Since the MTSI client in terminal is required to support mode changes at any frame border and also to any mode in the received media stream, it does not set the mode-change-period and mode-change-neighbor parameters.
The mode-change-capability and max-red parameter are new in the updated AMR payload format (RFC 4867). With mode-change-capability=2, the MTSI client in terminal shows that it does support aligning mode changes every other frame and the answerer then knows that requesting mode-change-period=2 in the SDP answer will work properly. The max-red parameter indicates the maximum interval between a non-redundant frame and a redundant frame. Note that the maxptime and max-red parameters do not need to be synchronized.
The payload type for the bandwidth-efficient payload format (97) is listed before the payload type for the octet-aligned payload format (98) because it is the preferred one.
With the combination of ptime:20 and maxptime:240, the MTSI client in terminal shows that it desires to receive one speech frame per packet but can handle up to 12 speech frames per packet. However, no more than 4 original speech frames can be encapsulated in one packet.
A suitable SDP answer from another MTSI client in terminal is shown in Table A.3.0.
A.1.1.2 AMR and AMR-WB are supported by MTSI client in terminal p. 235
A.1.1.2.1 One-phase approach p. 235
The size of the SDP may become quite big, depending on how many configurations the MTSI client in terminal supports for different media. Therefore, the session setup may be divided into phases where the most desirable configurations are offered in the first phase. If the first phase fails, then the remaining configurations can be offered in a second phase.
In Table A.1.2 an example is shown where a one-phase approach is used and where the SDP includes both AMR and AMR-WB and both the bandwidth-efficient and octet-aligned payload formats.
| 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:
It is easy to imagine that the SDP offer can become quite large if the client supports many different configurations for one or several media. A solution to this problem is shown in clause A.1.1.2.2.
A few possible SDP answers are outlined in Table A.3.1, Table A.3.1a, Table A.3.2, Table A.3.3 and Table A.3.4.
A.1.1.2.2 Two-phase approach p. 236
Table A.1.3 and Table A.1.4 show the same configurations as in Table A.1.2 but when the SDP has been divided into 2 phases.
| SDP offer |
|---|
m=audio 49152 RTP/AVP 97 98 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/8000/1 a=fmtp:98 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 |
| SDP offer |
|---|
m=audio 49152 RTP/AVPF 97 98 a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220; octet-align=1 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:
Many types of media and maybe even many different configurations for some or all media types, may give quite large SIP messages. When constructing the offer, the access type and the radio bearer(s) for the answerer are not yet known. To maintain a reasonable setup time, a 2-phase approach may be useful where the most desirable configurations are included in the 1st phase and the 2nd phase is entered only if all payload types for one media type are rejected.
There is however a drawback with the two-phase approach. If the 2nd phase is not entered, then a cell change that would require configurations from the 2nd phase SDP is likely to give long interruption times, several seconds, while the session parameters are re-negotiated.
The SDPCapNeg framework is only used in the 1st SDP offer because when generating the 2nd SDP offer the profile is already agreed. In this example, it is assumed that AVPF was accepted in the first round.
If the 1st SDP offer, shown in Table A.1.3, is accepted by the answerer then a few possible example SDP answers are shown in: Table A.3.1 if the answerer is an MTSI client in terminal and supports AMR-WB; Table A.3.2 if the answerer is an MTSI client in terminal but does not support AMR-WB; Table A.3.3 if the answerer is an MTSI client in terminal, supports AMR-WB and is using EGPRS access; Table A.3.4 if the answerer is a CS terminal, supports AMR-WB and an MTSI MGW is therefore needed.
A.1.2 EGPRS p. 237
In this example one RTP Payload Type (97) is defined for the bandwidth-efficient payload format and another RTP Payload Type (98) is defined for the octet-aligned payload format.
| 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=200 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-change-capability=2; max-red=200; octet-align=1 a=ptime:40 a=maxptime:240 |
Comments:
The only difference compared with the SDP offer for HSPA is ptime: 40. This definition is used to optimize capacity by reducing the amount of overhead that lower layers introduce. Defining ptime:20 will also work, but will be less optimal. Thus, when performing a cell change from HSPA to EGPRS, it is not an absolute necessity to update the session parameters immediately. It can be done after a while, which would also reduce the amount of SIP signalling if a MTSI client in terminal is switching frequently between HSPA and EGPRS or some other access type.
It is recommended to set the max-red parameter to an integer multiple of the ptime.
An example of a suitable SDP answer to this SDP offer is shown in Table A.3.3a.
A.1.3 Generic Access p. 238
In this example one RTP Payload Type (97) is defined for the bandwidth-efficient payload format and another RTP Payload Type (98) is defined for the octet-aligned payload format.
| 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=160 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-change-capability=2; max-red=160; octet-align=1 a=ptime:80 a=maxptime:240 |
Comments:
In this case the MTSI client in terminal has detected that the load on the WLAN network is quite high and therefore ptime is set to 80. For other operating conditions, it could set ptime to 20, 40 or 60. This parameter may be updated during the session if the load of the WLAN network changes.
An example of a suitable SDP answer to this SDP offer is shown in Table A.3.3b.
A.2 SDP offers for speech sessions initiated by media gateway p. 238
A.2.1 General p. 238
These examples show only SDP offers when the MTSI media gateway does not support the same configurations as for the MTSI terminal in clause A.1. A media gateway supporting the same configurations as for the examples in clause A.1 should create the same SDP offers.
A.2.2 MGW between GERAN UE and MTSI p. 238
This example shows the SDP offer when the call is initiated from GSM CS using the AMR with the {12.2, 7.4, 5.9 and 4.75} codec mode set. In this example, it is also assumed that only the bandwidth-efficient payload format is supported and that it will not send any redundant speech frames.
| SDP offer |
|---|
m=audio 49152 RTP/AVP 97 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2, \ mode-change-neighbor=1; mode-change-capability=2; max-red=0 a=ptime:20 a=maxptime:80 |
Comments:
Since the MGW only supports a subset of the AMR codec modes, it needs to indicate this in the SDP. The same applies for the mode change restrictions.
An example of a suitable SDP answer to this SDP offer is shown in Table A.3.5.
A.2.3 MGW between legacy UTRAN UE and MTSI p. 239
This example shows the SDP offer when the call is initiated from legacy UTRAN CS mobile that only the AMR 12.2 mode. In this example, it is also assumed that only the bandwidth-efficient payload format is supported.
| SDP offer |
|---|
m=audio 49152 RTP/AVP 97 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=7; max-red=0 a=ptime:20 a=maxptime:20 |
Comments:
Since only one mode is supported, the mode-change-period, mode-change-neighbor and mode-change-capability parameters do not apply.
In this case it is advisable to not allow redundancy since the legacy UTRAN CS mobile does not support any lower rate codec modes and then redundancy would almost double the bitrate on the PS access side. Therefore, maxptime is set to 20 and max-red is set to 0.
If a mode-set with several codec modes was defined and if max-red and maxptime are set to larger values than what Table A.1.8 shows, then redundancy is possible on the PS access side but not together with TFO.
An example of a suitable SDP answer to this SDP offer is shown in Table A.3.6.
A.2.4 MGW between CS UE and MTSI p. 239
This example shows the SDP offer when two mode sets are supported by the MGW.
| 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-set=0,2,4,7; mode-change-period=2, \ mode-change-neighbor=1; mode-change-capability=2; max-red=20 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-set=0,3,5,6; mode-change-period=2, \ mode-change-neighbor=1; mode-change-capability=2; max-red=20 a=ptime:20 a=maxptime:80 |
Comments:
Redundancy up to 100% is supported in this case since max-red is set to 20.
An example of a suitable SDP answer to this SDP offer is shown in Table A.3.6.
A.2.5 MGW between GERAN UE and MTSI when wideband speech is supported p. 240
This example shows the SDP offer when the call is initiated from GSM CS when AMR is supported with the {12.2, 7.4, 5.9 and 4.75} codec mode set and when AMR-WB is supported with the {12.65, 8.85 and 6.60} mode set. In this example, it is also assumed that only the bandwidth-efficient payload format is supported and that the MTSI MGW will not send any redundant speech frames.
| SDP offer |
|---|
m=audio 49152 RTP/AVP 98 97 a=tcap:1 RTP/AVPF a=pcfg:1 t=1 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2, \ mode-change-neighbor=1; mode-change-capability=2; max-red=0 a=rtpmap:98 AMR-WB/16000/1 a=fmtp:98 mode-set=0,1,2; mode-change-period=2, \ mode-change-neighbor=1; mode-change-capability=2; max-red=0 a=ptime:20 a=maxptime:80 |
Comments:
Since the MGW only supports a subset of the AMR codec modes and of the AMR-WB codec modes, it needs to indicate this in the SDP. The same applies for the mode change restrictions.
