Depending on the packetization mode advertised by endpoints, single or multiple NALUs can be encapsulated in single RTP packet. The VCL layer creates a coded representation of the video image by partitioning the video frame into slices with each slice partitioned into Macroblocks (rectangular samples of pixels). In H264 codec, there are two layers present which and Video Coding Layer (VCL) and Network Abstraction Layer (NAL). Video codec advertised by each endpoint is considered to be the desired receive codec. Else, the call will be dropped or retried as audio depending on the configuration If the bandwidth (audio + video) is available, it will be deducted from the location and the call will proceed. The selected bandwidth (whether region based or endpoint based) will be evaluated against E-LCAC.If the maximum advertised bandwidth is lower than region bandwidth, CUCM will use the maximum advertised bandwidth. 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. The allocated bandwidth is the maximum of what the two endpoints support.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).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 a session level bandwidth modifier, CUCM retrieves the bandwidth value from the modifier.When CUCM receives an Offer or Answer from an endpoint, it checks whether there is a session level bandwidth modifier in the SDP:.When generating an Answer, Early Offer or Re-invite, CUCM uses the same bandwidth value for all session modifiers typesĬUCM will use the following rules to select the video bandwidth to be used during the call and communicated to endpoints in bandwidth modifiers:.When generating an Answer, CUCM uses the same session modifier(s) type received in the initial offer.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.= 6 Mbps for video RTP traffic – not including UDP and IP headers (TIAS video)ĬUCM uses the following logic to communicate bandwidth modifiers to endpoints: = 64kbps for voice RTP traffic – not including UDP and IP headers (TIAS audio) = 6 Mbps for all voice and video streams including UDP and IP headers (AS session bandwidth) … attributes of multiple audio codecs in the offerįor this endpoint – the maximum media stream bandwidths that can be received : O=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6ī=TIAS:6000000 Transport Independent Application Specific bandwidth (RTP) in bits/secī=AS:6000 Application Specific bandwidth (RTP/UDP/IP) in kbps Conference Total (CT): Max Bandwidth that a Conference Session will use.Application Specific (AS) in kbps: Bandwidth includes the lower layers (e.g.Transport Independent Application Specific (TIAS) in bps: Bandwidth does NOT include the lower layers (e.g.There are three types of Bandwidth Modifiers which can be present in the bandwidth header inside the SDP body: The bandwidth attribute can be present in the session section and/or media section of the SDP body. This specifies the maximum amount of receive bandwidth supported by the endpoint. The bandwidth attribute is presented in SDP body as b=. There are multiple attributes negotiated in video stream SDP This is different from audio calls where both endpoints needs to agree on common audio stream parameters (codec, dtmf, etc) Therefore, we can have asymmetric video streams. To start with important concept, in video calls each endpoint will advertise its receive capabilities for which the sending endpoint will use to encode.
0 kommentar(er)
