In this section:
The SBC Core relays all video codecs by default using static or dynamic payloads.
The SBC supports the following codecs for H.323-H.323 video peering scenarios (i.e. H.323-H.323 calls with an audio and video stream).
When using H.263/H.264, the endpoint must support RTCP to ensure quality video.
The SBC supports determining a session bandwidth value when a video is present in a call and use the same session bandwidth value to allocate for the entire call. Since, a call is a multiplex of streams, the same bandwidth number is used to allocate the video stream. This is based on the assumption that at any point of time during a call, all the session bandwidth can also be used by the video. But, this happens if all the other streams are stopped or currently not in use. If there is a video in the call, the SBC switches between the new session based allocation and the original stream based methods.
The SBC includes the following advantages with using the session-based allocation method:
The bandwidth signaling in SDP can be done at the session level, the media level or both. The majority of the endpoint implementation uses the session level signaling. When the bandwidth is signaled at the session level, the usage of the bandwidth across the stream varies in a call.
For example: If a call with audio exists, video and slides in it with the following conditions:
If | Then |
---|---|
the slide stream is not in use. | the video stream consumes more bandwidth. |
the slide stream is in use. | the main video stream gets reduced by the amount of bandwidth used by the slide stream. |
the slide stream is paused and audio is in mute. | the main video stream could use all of the available session bandwidth. |
Considering the scenarios described above, the bandwidth allocation is performed for the entire session and not on individual streams.
For information on SIP-SIP Video treatment, refer to Video Support.