SDP Examples

This section includes quite a few examples of SDP offers and SDP answers. They were derived by first defining the scenarios that are the most likely ones and then deriving the SDP offers and answers. The scenarios were defined based on the following parameters:

• The media that will be used in the session. It is possible to choose one or several of the following media types: narrowband speech, wideband speech, video and text.

• What codecs can be used for each respective media.

• Whether the session will be between two clients or between one client and one media gateway.

5.8.7.1 Narrowband Voice Sessions over HSPA

In the example in Table 5.25, a terminal camping on HSPA is initiating a speech session. The terminal supports only narrowband speech with the AMR codec. Since the terminal is required to support all codec modes and both the bandwidth-efficient and octet-aligned payload formats, it chooses to create the SDP offer shown in Table 5.25.

In this case, the client knows that the access type is HSPA, so it chooses to set ptime to 20. Since the client has enough memory to handle receiving up to 12 speech frames per packet, it chooses to set maxptime to 240.

It is important that the 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 terminal were to define mode set to any value, then the answerer only has the option either to accept the payload type or to reject it. If the answerer is a media gateway that is interfacing for example GSM-AMR and if mode set is defined, then the media gateway might not be capable to use the defined mode

Table 5.24: All allowed state transitions in the speech adaptation mechanism.

State transition

Conditions and actions

S1^S2a

S2a^S2b

S2b^S2a

S2a^S3

S3^S2a

S3^S1

S2b^S4

S4^S2

S4^S1

S1^S4

Condition: PLR greater than or equal to 5% or packet loss burst detected Action: The codec rate is reduced, for example from AMR 12.2 to AMR 5.9 by using CMR. The state will then be S2a

Condition: PLR greater than or equal to 5%

Action: This state transition occurs if the PLR is still high despite the reduction of codec rate. The packet rate is reduced with SHIM_REQ_AGG

Condition: PLR less than 1%

Action: This state transition involves an increase of the packet rate. Further, the packet rate is restored to the same value as in S1 using SHIM_REQ_AGG. If the state transition S2b^S2a^S2b occurs, the state will be locked to S2b for some time. This time period should randomized to avoid oscillating behavior Condition: PLR less than 1%

Action: Redundancy is turned on (100%) with SHIM_REQ_RED. Further, the packet rate is restored to the same value as in S1 using SHIM_REQ_AGG

Condition: PLR greater than or equal to 2% or packet loss burst detected Action: Same actions as in transition from S1^S2a. If the transition S2a^S3^S2a^S3^S2a happens, state S3 is disabled for some time. This time period should be randomized to avoid oscillating behavior Condition: PLR less than 2% and no packet loss burst detected Action: Redundancy is turned off by using SHIM_REQ_RED. The codec rate is increased with CMR

Condition: PLR greater than or equal to 2%

Action: Redundancy is turned on (100%) by means of shim request SHIM_REQ_RED. Further, the packet rate is restored to the same value as in SI using SHIM_REQ_AGG

Condition: PLR greater than or equal to 10%. This is indicative that the total bit rate is too high

Action: Redundancy is turned off by using SHIM_REQ_RED. State S4 is disabled for some time. This time period should be randomized to avoid oscillating behavior

Condition: PLR less than 2%

Action: Redundancy is turned off with SHIM_REQ_RED. The codec rate is increased with CMR

Condition: PLR greater than or equal to 5% or packet loss burst detected AND the previous transition was S4^S1, otherwise the transition S1^S2a will occur

Action: Redundancy is turned on (100%) with SHIM_REQ_RED. The codec rate is reduced, for example from AMR 12.2 to AMR 5.9, with CMR

Amr Octet Aligned

SHIM_REQ_AGG SHIM_REQ_RED

Figure 5.23: Extension of the RTP header to enable adaptation request signaling. The F bit indicates if another shim follows the current. The bits 1 to 3 gives a shim ID giving meaning to the last four bits.

SHIM_REQ_AGG SHIM_REQ_RED

Figure 5.23: Extension of the RTP header to enable adaptation request signaling. The F bit indicates if another shim follows the current. The bits 1 to 3 gives a shim ID giving meaning to the last four bits.

Table 5.25: Example SDP offer for voice created by a terminal camping on HSPA.

m=audio 49152 RTP/AVP 97 98 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:20

a=maxptime:240

set and would then be forced to reject the whole session. If so, then it might require several initiating trials to agree on a common mode set to use. This would increase the setup time significantly. In the worst case, the session initiator might not try enough mode set variants and the session initiation may fail. This is also one important reason why the terminals must support the complete codec mode sets of the AMR and AMR-WB codecs.

With mode-change-capability=2, the 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 an original frame and a redundant frame.

The SDP answer from another terminal camping on HSPA would probably respond with an identical SDP message showing that it can support all the configurations that the offerer chooses to use.

An SDP answer from a media gateway is much more interesting. The media gateway most probably needs to restrict the codec modes to the codecs that the circuit switched terminal can handle. In the case that the media gateway is interfacing GSM-AMR it must restrict the codec modes to at most four. In this case, it also needs to restrict codec mode changes to be aligned to every other frame border. To improve the likelihood that the codec mode indication is transmitted over GERAN, the media gateway will also set mode-change-neighbor=1.

Furthermore, it is likely that the media gateway only supports the bandwidth-efficient payload format. This would give an SDP answer like the one shown in Table 5.26.

Table 5.26: Example SDP answer from a media gateway. m=audio 49152 RTP/AVP 97 a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2, mode-change-neighbor=l; \

mode-change-capability=2; max-red=20; a=ptime:20 a=maxptime:40

The media gateway also set max-red to 20 to show that it might use redundancy and the redundant frame may be transmitted up to 20 ms after the original speech frame. This is helpful for the receiving client because it defines an upper limit of how long the receiving client may have to wait for redundant frames.

By setting ptime to 20 and maxptime to 40, the media gateway shows that it wants to receive one frame per packet but can also handle two frames per packet.

When a media gateway initiates the session it is likely that it will create an SDP offer that is identical to the SDP answer in Table 5.26.

Legacy circuit switched UTRAN terminals typically only support the AMR 12.2 mode. If a media gateway interfaces such a terminal, it is likely that the SDP offer is constructed as in Table 5.27.

Table 5.27: Example SDP answer from a media gateway interfacing a legacy UTRAN terminal.

m=audio 49152 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=7; max-red=0; a=ptime:20 a=maxptime:40

In this case, there is no need to define the mode-change-period and the mode-change-neighbor parameters for the receiver since there is only one codec mode allowed in the session. For similar reasons there is no need to include the mode-change-capability parameter for the transmitting direction.

The max-red parameter is also set to 0 to clarify that the media gateway will not use redundancy. It anyway sets maxptime to 40 to indicate that it can handle receiving up to two speech frames per packet.

It is possible for a media gateway to support multiple codec mode sets. If the media gateway initiates a session and supports, for example, two mode sets, the SDP offer may be constructed as shown in Table 5.28. In this case, the media gateway declares that it supports the mode sets:

The terminal receiving this SDP offer will then probably respond with an identical SDP answer since it has to support all codec modes.

5.8.7.2 Wideband Voice Sessions over HSPA

A terminal supporting both wideband and narrowband voice will probably create the SDP offer shown in Table 5.29.

Since wideband codecs give a better quality than narrowband codecs, it is important to list the payload types for AMR-WB before the payload types for AMR. If the payload types were listed with the payload types for AMR first, then the answerer would believe that the offerer prefers to use narrowband and since all terminals and media gateways are required to support this codec they would then create an SDP answer with a preference for the AMR codec and the wideband codec would probably never be used.

It is also important that a terminal offering AMR-WB also offers AMR as a back-up. Then the answerer can immediately remove the payload types for AMR-WB and a narrowband speech session will be used. If the offerer did not offer both wideband and narrowband speech, then the answerer would have to reject all payload types for speech, thereby forcing the offerer to create a second offer. This would increase the call setup time and might in the worst case even mean that a session cannot be established.

In this example, ptime and maxptime are inserted directly after the media line to show that this is also a valid structure.

There are several possible SDP answers to this SDP offer depending on what configurations the other terminal or the media gateway supports. If the responding terminal supports both AMR and AMR-WB, then the SDP answer will probably be identical to the SDP offer.

Table 5.28: Possible SDP offer from a media gateway.

m=audio 49152 RTP/AVP 97

98

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

Table 5.29: Example SDP offer from a terminal supporting both wideband and narrowband speech.

m=audio 49152 RTP/AVP 97 98 99 100

a=ptime:20

a=maxptime:240

a=rtpmap:97 AMR-WB/16000/1

a=fmtp:97 mode-change-capability=2

a=rtpmap:98 AMR-WB/16000/1

a=fmtp:98 mode-change-capability=2; octet-align=l a=rtpmap:99 AMR/8000/1

a=fmtp:99 mode-change-capability=2

a=rtpmap:100 AMR/8000/1

a=fmtp:100 mode-change-capability=2; octet-align=l

In the case that the responding terminal does not support AMR-WB, then the terminal would have to remove the payload types for AMR-WB. In the case that the answerer is a media gateway interfacing a circuit switched GERAN terminal capable of handling both wideband and narrowband speech, the media gateway needs to restrict the codec modes to a maximum of four. Since 3GPP has declared that the most important mode sets for TFO are

• 12.2, 7.4, 5.9 and 4.75 kbps for AMR, it is likely that the media gateway will answer with the SDP answer outlined in Table 5.30.

Table 5.30: Likely SDP answer from a media gateway for wideband and narrowband speech. m=audio 49152 RTP/AVP 97 99 a=rtpmap:97 AMR-WB/16000/1

a=fmtp:97 mode-set=0,1,2; mode-change-period=2, mode-change-neighbor=l; \

mode-change-capability=2; max-red=20; a=rtpmap:99 AMR/8000/1

a=fmtp:99 mode-set=0,2,4,7; mode-change-period=2, mode-change-neighbor=l; \

mode-change-capability=2 a=ptime:20 a=maxptime:80

Another quite likely SDP answer is given in Table 5.31. In this case, it is probably a UTRAN terminal on the circuit switched side and it is likely that it only supports AMR 12.2 for narrowband voice.

Table 5.31: Likely SDP answer from a media gateway for wideband and narrowband speech. m=audio 49152 RTP/AVP 97 99 a=rtpmap:97 AMR-WB/16000/1

a=fmtp:97 mode-set=0,1,2; mode-change-period=2, mode-change-neighbor=l; \

mode-change-capability=2; max-red=0; a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-set=7; max-red=0; a=ptime:20 a=maxptime:80

5.8.7.3 Narrowband Voice Sessions over EDGE

As described in Section 5.6.2, it is likely that for the EDGE access type one wants to encapsulate two speech frames in every packet. Also, redundancy might not work so nicely for EDGE. An SDP offer created based on these assumptions would probably look like in Table 5.32.

In this case, max-red=0 shows that the terminal will not send redundancy. The attribute maxptime:240 shows that the terminal can handle up to 12 speech frames per packet, which, given the requirement that no more than four original speech frames can be encapsulated in each packet, implicitly means that it can handle redundancy.

Table 5.32: Example SDP offer created by a terminal camping on EDGE.

m=audio 49152 RTP/AVP 97 98

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2;

a=rtpmap:98 AMR/8000/1

a=fmtp:98 mode-change-capability=2;

a=ptime:40

a=maxptime:240

max-red=0

max-red=160; octet-align=1

5.8.7.4 Other Narrowband Voice Sessions

For some access types it is more beneficial to reduce the packet rate than to reduce the bit rate. One example of such an access type is WLAN [81]. A suitable SDP offer for such a case is shown in Table 5.33.

Table 5.33: Example SDP offer created by a terminal using WLAN.

m=audio 49152 RTP/AVP 97 98 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

If the media is transported over access types that have no QoS mechanisms, it is beneficial if redundancy is supported to handle occasional large error rates. The SDP example in Table 5.33, in combination with the redundancy levels supported by the Multimedia Telephony specification, makes it possible to use up to 200% redundancy, even if one originally encapsulates four speech frames per packet.

It should be noted that the default packetization time, ptime, does not necessarily have to be 80 ms. It could very well vary depending on the load of the network. If the load is low, and if the terminal could detect this, then it could very well define that it wants to use 20,40 or 60 ms packetization time.

5.8.7.5 Narrowband Voice Sessions When the Access Type is Not Known

For the cases where the access type is not known and cannot be determined by implicit means, one should use the SDP offers and answers outlined for the HSPA access type. The reason behind this is that HSPA is seen as the most interesting access type for Multimedia Telephony and other access types are less likely to accommodate Multimedia Telephony with the same performance as circuit switched calls.

5.8.7.6 Video-Only Sessions

An example of a video-only session is outlined in Table 5.34. In this case, the offerer wants to communicate using the video encoded with H263 Profile 0 (Baseline) at level 45, i.e. bit rates up to 128 kbps.

Table 5.34: Example of an SDP message with only video. m=video 49154 RTP/AVP 99 a=rtpmap: 99 H263-2000/90000 a=fmtp: 99 profile=0;level=45

5.8.7.7 Text-Only Sessions

When initiating a text-only session, the Multimedia Telephony client will probably construct the SDP offer shown in Table 5.35.

Table 5.35: Example of an SDP offer for text-only sessions.

m=text 49156 RTP/AVP 100 101 a=rtpmap: 100 1140/1000 a=rtpmap:101 red/1000 a=fmtp:101 100/100/100

This example shows that RTP Payload Type 100 is to be used for sending text without redundancy while RTP Payload Type 101 is used for sending text with redundancy according to RFC 2198 [159]. It should be noted that two payload types need to be defined even if one only plans to use the payload type for redundant media. This is because, in the payload type for redundant media (101), one needs to reference a payload type which is used without redundant media, in this case payload type 100. To indicate that the sender will use 200% redundancy, the number '100' occurs three times in the slash-separated list on the a=fmtp:101 line. The meaning of this definition is that payload type 100 will be used in the primary encoding and also in the two redundant encodings.

5.8.7.8 Sessions Including Voice and Video

When multiple media types are included in a session, the SDP offer needs to include one media line, m=, for each media type. An example of this is included in Table 5.36.

Table 5.36: Example of an SDP message for voice and video.

m=audio 49152 RTP/AVP 98 97

a=rtpmap: 98 AMR-WB/16000/1

a=fmtp:98 mode-change-capability=2; max-red=160

a=rtpmap: 97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=160

a=ptime:20

a=maxptime:240

m=video 49154 RTP/AVP 99 100

a=rtpmap: 99 H264/90000

a=fmtp:99 packetization-mode=0;profile-level-id=

=42e00a;

sprop-parameter-sets=J0LgCpWgsToB/UA=

KM4Gag==

a=rtpmap: 100 H263-2000/90000

a=fmtp: 100 profile=0;level=45

In this example, both narrowband voice and wideband voice are supported for speech. For video, both H.263 and H.264 are supported.

5.8.7.9 Sessions Including Voice, Video and Text

An example of a session setup with voice, video and text is included in Table 5.37.

Table 5.37: Example of an SDP message for voice, video and text.

m=audio 49152 RTP/AVP 98 97

a=rtpmap:98 AMR-WB/16000/1

a=fmtp:98 mode-change-capability=2; max-red=160

a=rtpmap:97 AMR/8000/1

a=fmtp:97 mode-change-capability=2; max-red=160

a=ptime:20

a=maxptime:240

m=video 49154 RTP/AVP 99 100

a=rtpmap:99 H264/90000

a=fmtp:99 packetization-mode=0;profile-level-id=

=42e00a;

sprop-parameter-sets=J0LgCpWgsToB/UA=

KM4Gag==

a=rtpmap:100 H263-2000/90000

a=fmtp:100 profile=0;level=45

m=text 49156 RTP/AVP 101 102

a=rtpmap:101 tl40/1000

a=rtpmap:102 red/1000

a=fmtp:102 100/100/100

+1 -1

Responses

  • everett
    What is rtp payload type 100 rfc?
    7 years ago
  • benjamin
    What does the codec supports if it is 42e00a?
    6 years ago
  • aila
    What does the maxptime setting do?
    5 years ago

Post a comment