10-22-2016 10:40 PM - edited 03-12-2019 10:24 AM
The bandwidth attribute is presented in SDP body as b=<modifier>:<value>. This specifies the maximum amount of receive bandwidth supported by the endpoint.
The bandwidth attribute can be present in the session section and/or media section of the SDP body.
There are three types of Bandwidth Modifiers which can be present in the bandwidth header inside the SDP body:
Example:
o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6
s=SIP Call
b=TIAS:6000000 Transport Independent Application Specific bandwidth (RTP) in bits/sec
b=AS:6000 Application Specific bandwidth (RTP/UDP/IP) in kbps
t=0 0
m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101
b=TIAS:64000
… attributes of multiple audio codecs in the offer
…
m=video 16446 RTP/AVP 98 99
b=TIAS:6000000
For this endpoint – the maximum media stream bandwidths that can be received :
= 6 Mbps for all voice and video streams including UDP and IP headers (AS session bandwidth)
= 64kbps for voice RTP traffic – not including UDP and IP headers (TIAS audio)
= 6 Mbps for video RTP traffic – not including UDP and IP headers (TIAS video)
CUCM uses the following logic to communicate bandwidth modifiers to endpoints:
CUCM will use the following rules to select the video bandwidth to be used during the call and communicated to endpoints in bandwidth modifiers:
In CME, bandwidth modifier can be changed using the command 'voice-class sip bandwidth video tias-modifier bandwidth value [ negotiate end-to-end]'
Hi Mohammed,
Thanks for the knowledge you shared. Just want to confirm if I have understood what you said on the "This specifies the maximum amount of receive bandwidth supported by the endpoint." part.
Is that means whatever the type of sip messages(invite, 200ok or ack with the SDP) recieved by endpoint, the "b" attribute always indicate the sender's receiving bandwidth capability? And vice versa for the sending message.
Also, that means one way video may happen due to the CAC limitation for one direction?
Regards,
Terry
That is correct and its very common to have one way video
Much appreciated!
I recently came across an interesting case which was a result of CUCM not correctly representing the AS bandwidth:
for a G729 call, it will show b=AS:8 instead of b=AS:24 to account for the 16kbps of IP/UDP/RTP overhead as mentioned in your article. (your example with TIAS = AS also shows that the AS bandwidth does not take the overhead into account as it should)
As a result of this, an SBC in the path faithfully discarded 2 out of 3 packets to meet the bandwidth requirement set by the CUCM (with very bad audio as a result)! This would happen in very rare cases where the far end initiates an SDP with only AS and no TIAS. In most cases, TIAS would take precedence and not cause this problem since overhead is not included in TIAS by definition.
The fix in my case was to configure the SBC to ignore the bandwidth settings from CUCM.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: