[Asterisk-Dev] Chan_sip: video capabilities, call bandwidth and RTCP

[John Martin]

Developers, (Olle),

  

  I posted a couple of months or so ago about better video support in
chan_sip1 to which KevinF gave some good advice: go have a go.

 

  Well I've got round to having a go and wanted to get some input on
ideas and issues, sorry in advance for the length of the email. 

 

  I know that many of you consider video to be of limited interest at
the moment but we make a business out of it :-) with about 50% of our
customers wanting to use Asterisk as their preferred switch solution and
who are disappointed when they try it. So if nothing else we need to
implement some changes for us and our customers - though I'd rather have
this adopted and supported in mantis.

 

  The description below is my view on the matter - coming from a very
video centric H.32x world. Please don't take my suggestions as doctrine,
they're up for debate and for me to be educated on the wider world :-)

 

The decisions that I need to make are:

- How to support call bandwidth management.

- How to support video capabilities management.

 

The Problem:

------------------

1. Bandwidth

Sip UAs that support video have the capacity to clog up a low capacity
network such as a xDSL/cable connection. They therefore need to be set
up correctly for any particular network. This is possible at the end
point by restricting bitrates when working point-to-point but doesn't
work so well with Asterisk as it stands - Asterisk doesn't declare any
call bandwidth or video capabilities and so a UA has to guess at
Asterisk's and the remote codecs cap - and can get it very wrong.

 

Asterisk has no support for a UA to have it's video bandwidth restricted
in accordance with any centralised policy (as implemented by the
Asterisk manager), unlike audio bandwidth management which is achieved
by codec choice.

 

With no bandwidth support an unsuspecting user may be able to instigate
a high bandwidth call on a low bandwidth connection and a) experience a
poor quality call while the UA tries to ascertain the available
bandwidth and b) unwittingly swamp the connection. This is not a problem
with SoftSwitches from the big boys: Cisco, Huawei, etc and needn't
cause Asterisk users any problems either. 

 

2. Resolution

While video resolution is not going to cause problems with network
congestion it can cause incompatibilities between endpoints if not
properly configured. Most endpoints support CIF and QCIF resolutions,
but we're moving into an HD age and 4CIF, 16CIF and H.264 HD resolutions
will crash some of the UAs out there at the moment.

 

3. Framerate

A similar problem to 2 above - some endpoints can be crashed by sending
them video of a higher frame rate than they can support.

 

4. In Call Bandwidth Management

During a call on a constricted network a UA needs to co-operate with the
network so as to be sensitive to other traffic. If a home worker tries
to make a "near capacity" video call on a DSL/cable connection and they
then have other traffic come in on the network during the call (such as
an incoming email): the other traffic (usually TCP) tries to grab all
the bandwidth and will degrade the video/audio call. To reduce the
effects of this, the video channel must "throttle-back" to reduce packet
loss. The best standards based way of doing this is with RTCP - thanks
to vechers and sb for the work they've done on this. RTCP is nearly
there with Asterisk and I don't propose we need to do anything more on
this for the moment - other than perhaps to say that the RTCP RFCs
suggest that RTCP should be about 5% of traffic in order to control a
channel correctly... that means a lot more often than every 5 seconds
for a video call.

 

It needn't be this way with SIP and I propose we fix this in chan_sip1
with the hope that this can be rolled forwards into future versions.

 

The SIP Solution

------------------------

While I don't think they are ratified, most video UAs support the draft
RFCs: 

-          levin-mmusic-xml-media-control-02 - INFO fast updates and 

-          koskelainen-sdp263-02 - H263 fmtp options

 

Ideally video channel bandwidths should propagate through from one
endpoint's capability to the far end's capability - a video call should
be made at the lowest common capability.

 

Chan_sip currently (sort of) supports video and I was pleased to see the
support that is in there (chan_h323 still has some way to go but I'm
working on that too).

 

Possible Asteisk Implementation

-----------------------------------------------

So how do we add these features to chan_sip1

 

Call bandwidth:

Add   'maxcallbandwidth=x'  into [general] and [peer/user/friend]
sections of sip.conf ?

This will be translated into 'b=CT:x/r/n' in a sip header. I'd also
propose that this is only added if it's a video call.

(I have this working on a 1.2 build along with all the sip show
peer/user stuff on the cli)

 

Resolution and Frame Rate:

Support "a=fmtp:..." along the same lines as "a=rtpmap..."

For those of you that haven't looked at fmtp before a declaration looks
a bit like:

a=fmtp:34 4CIF=2 CIF=1 QCIF=1 SQCIF=1 MaxBR=3840\r\n

 

I guess there are a number of options on how this should be implemented:

1. Add sip.conf entries for each resolution, framerate, and bitrate

This doesn't allow H.263 to be different to H.261 or H.264. Which they
often are.

 

2. Add optional sip.conf entries for 'allow=h26x'

I like this solution and it could come in a number of different forms,
for example:

a) allow=h263, "4CIF=2 CIF=1 QCIF=1 SQCIF=1 MaxBR=3840\r\n"

b) allow=h263, 4cif=2, cif=1, qcif=1, sqcif=1, maxbr=3840

c) allow=h263, maxmbps=23760,maxfsmb=1584, minfsmb=48, minmbps=1440,
maxbr=3840

 

The three above are equivalent as may be recognised by those of you that
are H.264 aficionados. I'd prefer either 'b' or 'c' but I can see that
these may not be as palatable to Asterisk managers that don't know a
great deal about video - though I think that comes down to their video
UA provider giving them the right recipe.

 

In development terms it will be easier to do 'a' and more difficult to
do 'c'. 'b' is about in the middle, I think. However, 'c' is more
flexible and would be easier to support for H.264 and is less protocol
specific if we end up putting support into struct ast_channel.

 

I guess that all these settings really need to be propagated between
channels and appropriate variables should be added to the ast_channel
structure so that IAX and H323 can set video capabilities dependant on
the lowest capable UA, even across different protocols.

 

Still to be thought about

----------------------------------

- Dynamic rtp payload support for H.264 and sequence/picture parameter
definitions

- How to reflect these changes into H.323 and IAX

- Other fast update mechanisms (the H.261 RTP FU for instance)

 

Thanks in advance for your input, John



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20051123/9e76e087/attachment.htm