Session Description Protocol (SDP) is a communication protocol used for describing multimedia sessions between two or more endpoints. SDP provides a standardized way of describing the parameters of a multimedia session, including IPs, ports, codecs and the bandwidth requirements for each media stream. In this blog post, we’ll discuss the SDP bandwidth attributes and how they are used to specify the bandwidth requirements for media streams.
SDP Bandwidth Attributes
The SDP includes an optional bandwidth attribute with the following syntax:
b=<modifier>:<bandwidth-value>
SDP defines three bandwidth attributes that can be used to specify the bandwidth requirements for a media stream. These attributes are:
“b=AS”
The “b=AS” attribute for Application Specific (AS) which may be used to specify the total bandwidth for a single media stream from one site (source) in kilobits per second (kbps). This attribute indicates the maximum amount of bandwidth that the endpoint is willing to allocate for the stream. For example, if the “b=AS” attribute is set to 256 kbps, the endpoint will allocate at least 256 kbps for the stream.
“b=RS”
The “b=RS” attribute indicates the RTCP bandwidth allocated to active data senders. For example, if the “b=RS” attribute is set to 800 bps, the endpoint will reserve at least 800 bps for the RTCP stream to ensure a certain level of QoS, which is used for reporting and monitoring purposes in a multimedia session.
“b=RR”
The “b=RR” attribute or Receiver Report (RR) indicates the RTCP bandwidth allocated to other participants in the RTP session (i.e.receivers). For example, if the “b=RR” attribute is set to 2000 bps, the endpoint will allocate up to 2000 bps for the RTCP stream for receivers.
RS and RR attributes are used to ensure that RTCP traffic does not consume more bandwidth than necessary.
For example:
|
|
In this example, “b=AS:80” would indicate a maximum bitrate of 80 kbps for the media stream. The “b=RS:1000” attribute is specified at the media level for an audio stream. It indicates that the application expects to receive no more than an average of 1000 bytes per second of RTCP traffic for the duration of the session. “b=RR:2400” would indicate that the endpoint is willing to receive a maximum of 2400 bytes per second for the RTCP traffic.
Using SDP Bandwidth Attributes
SDP bandwidth attributes are typically used in session negotiation between two endpoints to specify the bandwidth requirements for media streams. For example, when two endpoints negotiate a session for a video conference, they can use SDP bandwidth attributes to negotiate the bandwidth requirements for the video stream.
The endpoint that initiates the session typically includes SDP bandwidth attributes in the session description to specify its bandwidth requirements for the media streams. The other endpoint can then use these attributes to determine whether it can meet the bandwidth requirements and negotiate the session accordingly. In IMS networks, as QoS is important, usually mobile handsets or UEs put the “b” params in the SIP messages like INVIITE, 183, and 200 whhich includes SDP.
If the “b=RS:” field or “b=RR:” field or both these fields are not included in a received SDP (offer or answer), then the UE must use the recommended default value for the missing field(s) as defined in RFC 3556[1].
But if the UE receives an SDP offer that contains “b=RS” attribute set to zero, then the UE must set the “b=RS” attribute to zero in an SDP answer to that SDP offer. If the UE receives an SDP offer that contains “b=RR” attribute set to zero, then the UE must set the “b=RR” attribute to zero in an SDP answer to that SDP offer. If the UE receives an SDP offer that contains both “b=RR” and “b=RS” attributes set to zero, then the UE must not send RTCP packets and must consider RTCP to be disabled for the session.
It is important to know that we need this bandwidth info for Dedicated Bearer setup that I will cover in another post soon.
SDP Bandwidth Attributes and RTPEngine
If you are using the RTPEngine as RTP proxy server, I should tell you that it doesn’t care about “b=” atributes and you have to add or remove them manually. You should know that if you transcode, for example, from AMR to PCMU, and do not handle the bandwidth parameters manually, as RTPEngine does not handle “b=” in SDP answers, the receiver receives these parameters, and if applied, voice quality would suffer.
For example, UE sends SDP “b=AS:50” and with AMR codec, but the receiver supports only PCMU, so RTPEngine does transcoding for us, then receiver gets PCMU codec with “b=AS:50”, and if it applies the bandwidth, it assigns 50 Kbps to PCMU stream that is not enough!
Conclusion
SDP bandwidth attributes provide a standardized way of specifying the bandwidth requirements for multimedia sessions. These attributes can be used to ensure a certain level of QoS for media streams and to negotiate sessions between two endpoints. By understanding how SDP bandwidth attributes work, you can ensure that your multimedia sessions meet your bandwidth requirements and provide a high level of quality of service.
Usefule Links:
[1] RFC 4556 - https://datatracker.ietf.org/doc/html/rfc3556
[2] GSMA IR92 - https://www.gsma.com/newsroom/resources/ir-92-ims-profile-for-voice-and-sms-17-0/