cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3417
Views
15
Helpful
4
Comments

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:

 

  • Transport Independent Application Specific (TIAS) in bps: Bandwidth does NOT include the lower layers (e.g. RTP bandwidth only)
  • Application Specific (AS) in kbps: Bandwidth includes the lower layers (e.g. TCP/UDP and IP)
  • Conference Total (CT):  Max Bandwidth that a Conference Session will use

 

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:

 

  • When generating an Early Offer or Re-Invite, CUCM uses the session modifier(s) type based on the configuration of the SIP Profile > SDP Session-Level Modifier for Early Invite and Re-invites (TIAS, AS, both)
  • When generating an Answer, CUCM uses the same session modifier(s) type received in the initial offer
  • When generating an Answer, Early Offer or Re-invite, CUCM uses the same bandwidth value for all session modifiers types

 

CUCM will use the following rules to select the video bandwidth to be used during the call and communicated to endpoints in bandwidth modifiers:

 

  • When CUCM receives an Offer or Answer from an endpoint, it checks whether there is a session level bandwidth modifier in the SDP:
    • If there is a session level bandwidth modifier, CUCM retrieves the bandwidth value from the modifier. If there is more than one modifier type, it retrieves the modifier in the following order of preference: Transport Independent Application Specific (TIAS), Application Specific (AS), Conference Total (CT).
    • If there is no session level bandwidth modifier, CUCM retrieves the bandwidth value from the sum of the media level bandwidth modifiers (e.g audio + video + bfcp video + fecc video).
  • The allocated bandwidth is the maximum of what the two endpoints support. If the maximum bandwidth is higher than Region Bandwidth, CUCM will replace the advertised value to the endpoints with the value in the region and the allocated bandwidth will be the region bandwidth. If the maximum advertised bandwidth is lower than region bandwidth, CUCM will use the maximum advertised bandwidth.
  • The selected bandwidth (whether region based or endpoint based) will be evaluated against E-LCAC. If the bandwidth (audio + video) is available, it will be deducted from the location and the call will proceed.  Else, the call will be dropped, retried as audio or AAR depending on the configuration

 

In CME, bandwidth modifier can be changed using the command 'voice-class sip bandwidth video tias-modifier bandwidth value [ negotiate end-to-end]'

Comments
Xiaopeng Yin
Level 1
Level 1

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 

Xiaopeng Yin
Level 1
Level 1

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.

Getting Started

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: