Content for TS 26.114 Word version: 18.5.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.3 SDP answers to SDP speech session offers
A.3.1 General
A.3.1a SDP answer from an MTSI client in terminal when only narrowband speech was offered
A.3.2 SDP answer from an MTSI client in terminal
A.3.2a SDP answer from a non-MTSI UE with AVP
A.3.3 SDP answer from an MTSI client in terminal supporting only AMR
A.3.4 SDP answer from an MTSI client in terminal using EGPRS access when both AMR and AMR-WB are supported
A.3.4a SDP answer from an MTSI client in terminal using EGPRS access when only AMR is supported
A.3.4b SDP answer from an MTSI client in terminal using WLAN
A.3.5 SDP answer from MTSI MGW supporting only one codec mode set for AMR and AMR-WB each
A.3.5a SDP answer from MTSI MGW supporting only one codec mode set for AMR
A.3.6 SDP answer from MTSI client in terminal on HSPA for session initiated from MTSI MGW interfacing UE on GERAN
A.3.7 SDP answer from MTSI client in terminal on HSPA for session initiated from MTSI MGW interfacing legacy UE on UTRAN
...
...
A.3 SDP answers to SDP speech session offers p. 232
A.3.1 General p. 232
This clause gives a few examples of possible SDP answers. The likelihood that these SDP answers will be used may vary from case to case since the SDP answer depends on circumstances outside the scope of this specification for example: availability of resources, radio bearer assignment and policy control. It is impossible to cover all the possible variants and hence these examples should be regarded as just a few examples of many possible alternatives. They were however selected because they span the range of possible SDP answers quite well.
The SDP offers are included to clarify what is being answered.
A.3.1a SDP answer from an MTSI client in terminal when only narrowband speech was offered p. 233
These SDP offers and answer are likely when the offering MTSI client in terminal (or other client) only supports narrowband speech (AMR).
The SDP offer included in this example is identical to the SDP offer shown in Table A.1.1.
| 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 |
| SDP answer |
m=audio 49152 RTP/AVPF 99 a=acfg:1 t=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 |
Comments:
The SDP answer contains only one encoding format since TS 24.229 requires that the answerer shall select exactly one codec for the answer. Since both MTSI clients in terminals support the same configurations for narrowband speech, it is likely that the selected configuration included in the answer is identical to the configuration in the offer and that no mode-set is defined by the terminating client.
The conclusion from this offer-answer procedure is that the offerer can only send AMR encoded speech to the answerer using the bandwidth-efficient payload type with RTP Payload Type 99, since this was the only configuration included in the answer. The answerer sends AMR encoded speech to the offerer using the bandwidth-efficient payload format, in this case RTP Payload Type 97.
Even though both MTSI clients in terminals support all codec modes, it is desirable to mainly use the codec modes from the AMR {12.2, 7.4, 5.9 and 4.75} mode set because the set includes codec modes frequently used in GERAN and UTRAN, and enables to control quality and capacity with appropriate bit-rate granularity.
Unless transmission conditions necessitate other encapsulation types it is also desirable to encapsulate only 1 speech frame per packet, even though both MTSI clients in terminals support receiving several frames per packet.
In the above example it is assumed that AVPF will be accepted since the MTSI client is required to support this RTP profile.
A.3.2 SDP answer from an MTSI client in terminal p. 233
These SDP offers and answers are likely when both MTSI clients in terminals support AMR and AMR-WB and also both the bandwidth-efficient and the octet-aligned payload formats.
The SDP offer included in this example is identical to the SDP offer shown in Table A.1.2, with the exception that the number of channels is omitted for each of the codecs. This implies that the terminal is offering one channel for each codec.
| 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 a=fmtp:97 mode-change-capability=2; max-red=220 a=rtpmap:98 AMR-WB/16000 a=fmtp:98 mode-change-capability=2; max-red=220; octet-align=1 a=rtpmap:99 AMR/8000 a=fmtp:99 mode-change-capability=2; max-red=220 a=rtpmap:100 AMR/8000 a=fmtp:100 mode-change-capability=2; max-red=220; octet-align=1 a=ptime:20 a=maxptime:240 |
| SDP answer if AVPF is accepted |
m=audio 49152 RTP/AVPF 97 a=acfg:1 t=1 a=rtpmap:97 AMR-WB/16000 a=fmtp:97 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 |
Comments:
The SDP answer contains only one encoding format since TS 24.229 requires that the answerer shall select exactly one codec for the answer. Since both MTSI clients in terminals support the same configurations, it is likely that the selected configuration included in the answer is identical to the configuration in the offer and that no mode-set is defined by the terminating client. The conclusion from this offer-answer process is that AMR-WB will be used during the session with RTP Payload Type 97. The SDP answer does not include the number of audio channels, implying that one channel has been accepted.
Even though both MTSI clients in terminals support all codec modes, it is desirable to mainly use the codec modes from the AMR-WB {12.65, 8.85 and 6.60} mode set because the set includes codec modes frequently used in GERAN and UTRAN, and enables to control quality and capacity with appropriate bit-rate granularity.
Unless transmission conditions necessitate other encapsulation types it is also desirable to encapsulate only 1 speech frame per packet, even though both MTSI clients in terminals support receiving several frames per packet.
In the above example it is assumed that AVPF will be accepted since the MTSI client is required to support this RTP profile.
This SDP answer is also a possible answer to the SDP offer shown in Table A.1.3.
A.3.2a SDP answer from a non-MTSI UE with AVP p. 234
The MTSI client must be prepared to receive an SDP answer with AVP. This is likely to occur for legacy clients that do not support AVPF or SDPCapNeg. The example in Table A.3.1a shows a possible SDP answer with AVP to an SDP offer as shown in Table A.1.2.
| SDP answer with AVP |
|---|
m=audio 49152 RTP/AVP 97 a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 |
Comments:
A client that does not support SDPCapNeg would not understand the attributes defined by the SDPCapNeg framework and would therefore ignore the lines with 'a=tcap' and 'a=pcfg'.
A.3.3 SDP answer from an MTSI client in terminal supporting only AMR p. 235
These SDP offers and answers are likely when the answering MTSI client in terminal supports only AMR.
The SDP offer included in this example is identical to the SDP offer shown in Table A.1.2.
| 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 |
| SDP answer |
m=audio 49152 RTP/AVPF 99 a=acfg:1 t=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 |
Comments:
In the answer, RTP Payload Types 97 and 98 have been removed since AMR-WB is not supported and RTP Payload Type 100 is removed since the answerer is required to answer with only one encoding format.
Even though both MTSI clients in terminals support all codec modes, it is desirable to mainly use the codec modes from the AMR [12.2, 7.4 5.9 and 4.75] mode set because the set includes codec modes frequently used in GERAN and UTRAN, and enables to control quality and capacity with appropriate bit-rate granularity.
This SDP answer is also a possible answer to the SDP offer shown in Table A.1.3.
A.3.4 SDP answer from an MTSI client in terminal using EGPRS access when both AMR and AMR-WB are supported p. 236
In this case the answering MTSI client in terminal is using EGPRS access and supports both narrowband and wideband speech, i.e. both AMR and AMR-WB.
The SDP offer is identical to the SDP offer shown in Table A.1.2.
| 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 |
| SDP answer |
m=audio 49152 RTP/AVPF 97 a=acfg:1 t=1 a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 mode-change-capability=2; max-red=200 a=ptime:40 a=maxptime:240 |
Comments:
The answering MTSI client in terminal responds that it desires to receive 2 frames encapsulated in each packet. It will however send with 1 frame per packet since the offering MTSI client in terminal desires to receive this format. A future SIP UPDATE may change this so that 2 frames per packet are used in both directions.
The answering MTSI client in terminal also responds with max-red defined to 200 ms since this is the closes multiple of the desired frame aggregation. It should however be noted that it is not a requirement to define max-red to be a multiple of ptime, but it is recommended to do so.
This SDP answer is also a possible answer to the SDP offer shown in Table A.1.3.
A.3.4a SDP answer from an MTSI client in terminal using EGPRS access when only AMR is supported p. 237
In this case the answering MTSI client in terminal is using EGPRS access but supports only narroband speech, i.e. only AMR.
The SDP offer is identical to the SDP offer shown in Table A.1.2 although the SDP answer here would also work nicely as a response to the SDP offer shown in Table A.1.5.
| 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 |
| SDP answer |
m=audio 49152 RTP/AVPF 97 a=acfg:1 t=1 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2; max-red=200 a=ptime:40 a=maxptime:240 |
Comments:
The answering MTSI client in terminal responds that it desires to receive 2 frames encapsulated in each packet. It will however send with 1 frame per packet since the offering MTSI client in terminal desires to receive this format. A future SIP UPDATE may change this so that 2 frames per packet are used in both directions.
The answering MTSI client in terminal also responds with max-red defined to 200 ms since this is the closes multiple of the desired frame aggregation. It should however be noted that it is not a requirement to define max-red to be a multiple of ptime, but it is recommended to do so.
This SDP answer is also a suitable response to an SDP offer as shown in Table A.1.5, even if the answering MTSI client in a terminal is using HSPA access. This is because it is wise to harmonize the packetization, and the ptime in the SDP answer, with the ptime in the SDP offer so that 2 frames per packet will be used in both directions when one of the end-points is using EGPRS access.
A.3.4b SDP answer from an MTSI client in terminal using WLAN p. 237
In this example, the MTSI client in terminal is using a WLAN network.
The SDP offer shown here is identical to the SDP offer shown in Table A.1.1.
| 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 |
| SDP answer |
m=audio 49152 RTP/AVPF 97 a=acfg:1 t=1 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2; max-red=160 a=ptime:80 a=maxptime:240 |
Comments:
This SDP answer, with ptime=80, is suitable if the MTSI client in terminal can measure the load in the WLAN network and has detected that the load is high. If, on the other hand, the load is low then the MTSI client in terminal may very well choose to use a lower value for the ptime attribute, for example 20 or 40.
This SDP answer is also suitable when the answering MTSI client in terminal is using HSPA access but when the offerer is using WLAN and indicates ptime=80, e.g. as shown in the SDP offer in Table A.1.6. In such a case, it is wise to harmonize the ptime values in both directions to increase the likelihood that several frames will be encapsulated in the RTP packets.
This SDP answer is also a possible answer to the SDP offer shown in Table A.1.3.
A.3.5 SDP answer from MTSI MGW supporting only one codec mode set for AMR and AMR-WB each p. 238
In this case the MTSI MGW supports only one codec mode set for AMR, {12.2, 7.4, 5.9 and 4.75}, and one codec mode set for AMR-WB, {12.65, 8.85 and 6.60}, since the CS terminal only supports these mode sets. The MTSI MGW also only supports the bandwidth-efficient payload format.
The SDP offer included in this example is identical to the SDP offer shown in Table A.1.2.
| SDP offer (from MTSI client in terminal on HSPA) |
|---|
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 |
| SDP answer (from MTSI MGW) |
m=audio 49152 RTP/AVPF 97 a=acfg:1 t=1 a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 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:
The MTSI MGW is allowed to define the mode-set parameter since the MTSI client in terminal did not define it. Thereby, it is possible to avoid several SDP offers and answers.
The SDP answer contains only one encoding format since TS 24.229 requires that the answerer shall select exactly one codec for the answer. In this case, the CS terminal supports wideband speech and the MTSI MGW therefore chooses to establish a wideband speech session.
Since the MTSI client in terminal has defined that it does support restrictions in mode changes, the MTSI MGW can safely set the mode-change-period and mode-change-neighbor parameters.
In this example, the MTSI MGW also does not support redundancy so it sets max-red to zero.
This SDP answer is also a possible answer to the SDP offer shown in Table A.1.3.
A.3.5a SDP answer from MTSI MGW supporting only one codec mode set for AMR p. 240
In this case the MTSI MGW supports only one codec mode set for AMR, {12.2, 7.4, 5.9 and 4.75}, since the CS terminal supports only this mode set. The MTSI MGW also only supports the bandwidth-efficient payload format.
| SDP offer (from MTSI client in terminal on HSPA) |
|---|
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 |
| SDP answer (from MTSI MGW) |
m=audio 49152 RTP/AVPF 97 a=acfg: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:
The MTSI MGW is allowed to define the mode-set parameter since the MTSI client in terminal did not define it. Thereby, it is possible to avoid several SDP offers and answers.
The SDP answer contains only one encoding format since TS 24.229 requires that the answerer shall select exactly one codec for the answer. In this case, the CS terminal does not supports wideband speech and the MTSI MGW therefore selects to establish a narrowband speech session.
Since the MTSI client in terminal has defined that it does support restrictions in mode changes, the MTSI MGW can safely set the mode-change-period and mode-change-neighbor parameters.
In this example, the MTSI MGW also does not support redundancy so it sets max-red to zero.
A.3.6 SDP answer from MTSI client in terminal on HSPA for session initiated from MTSI MGW interfacing UE on GERAN p. 240
This example shows the offers and answers for a session between a GERAN CS UE, through a MTSI media gateway, and a MTSI client in terminal.
The SDP offer shown here is very similar to the SDP offer shown in Table A.2.1. The only difference is that maxptime is set to 20.
| SDP offer (from MTSI MGW) |
|---|
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:20 |
| SDP answer (from MTSI client in terminal) |
m=audio 49152 RTP/AVPF 97 a=acfg: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:240 |
Comments:
The MTSI media gateway offers only a restricted mode set sincethe CS terminal does not support anything else. The MTSI client in terminal has to accept this, if it wants to continue with the session setup.
This example also shows that the MTSI media gateway wants to receive only 1 frame per packet. The maxptime parameter is therefore set to 20. With max-red set to 0 the MTSI media gateway also shows that it will not send redundancy. The MTSI terminal can support receiving up to 12 frames per packet. It therefore set the maxptime parameter to 240.
The MTSI client in terminal detects that the MTSI media gateway does not want to receive redundancy and therefore sets max-red to 0.
The SDP answer shown in this example is also a suitable answer to the SDP offer shown in Table A.2.1. This SDP answer is also suitable for the SDP offer shown Table A.2.3.
A.3.7 SDP answer from MTSI client in terminal on HSPA for session initiated from MTSI MGW interfacing legacy UE on UTRAN p. 241
This example shows the offers and answers for a session between a legacy UTRAN CS UE that only supports AMR 12.2, through a MTSI media gateway, and a MTSI client in terminal.
The SDP offer shown here is identical to the SDP offer shown in Table A.2.2.
| SDP offer (from MTSI MGW) |
|---|
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 |
| SDP answer (from MTSI client in terminal) |
m=audio 49152 RTP/AVPF 97 a=acfg:1 t=1 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=7; max-red=0 a=ptime:20 a=maxptime:240 |
Comments:
The MTSI media gateway offers only one codec mode set since the CS terminal does not support anything else. The MTSI client in terminal has to accept this, if it wants to continue with the session setup.
This example also shows that the MTSI media gateway want to receive only 1 frame per packet. The maxptime parameter is therefore set to 20. With max-red set to 0 the MTSI media gateway also shows that it will not send redundancy. The MTSI terminal can support receiving up to 12 frames per packet. It therefore set the maxptime parameter to 240.
The MTSI client in terminal detects that the MTSI media gateway does not want to receive redundancy and therefore sets max-red to 0.
