A.1 SDP offers for speech sessions initiated by MTSI client in terminal
26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS
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 [7] 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
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
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.
Table A.1.1: SDP example
|
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) [69] 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 [28]. 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
A.1.1.2.1 One-phase approach
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.
Table A.1.2: SDP example: one-phase approach
|
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 Tables A.3.1, A.3.1a, A.3.2, A.3.3 and A.3.4.
A.1.1.2.2 Two-phase approach
Tables A.1.3 and A.1.4 show the same configurations as in table A.1.2 but when the SDP has been divided into 2 phases.
Table A.1.3: SDP example: 1st phase SDP offer
|
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 |
Table A.1.4: SDP example: 2nd phase SDP offer
|
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
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.
Table A.1.5: SDP example
|
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
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.
Table A.1.6: SDP example
|
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.