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

[John Martin]

Matt,
  Thanks for responding so quickly, see comments below:

John Martin

>>   I know that many of you consider video to be of limited interest at
>> the moment but we make a business out of it J 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.
>
>Agreed.  We are doing quite a bit of work with Video in the European
market.
>> 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.
>
>I'm more attacking it from the other side.  Our servers have 50Mbps and
some
>of our clients have similar.  They don't want to save bandwidth, they
want
>great quality video.  Asterisk supporting other resolutions would go a
long
>way towards that.
>
>> 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.
>
>Such as?  Surely this is something that needs to be submitted as a bug
with
>the endpoint manufacturer.
>

There are a number of far-eastern video phones that do this sort of
thing.
If you send them 4CIF at 30fps then the get a bit upset. The
manufacturers
say - well the capability exchange is in there for a reason. They will
fix
the problem but over a period of many months.

>> 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.
>
>Obviously :)
>
>> 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).
>
>It does support video.  We have video calls between users, video IVR,
and
>realtime selection of videos to watch (no, not pr0n - although...).
>

I guess I was being a bit harsh - we also have Interactive Video
Response
and clips working but it gets a bit problematic with Asterisk and low
bandwidth callers - and don't get me started on rate control for 
pre-recorded video clips :-) We've done a number of H.320 and H.323
IVideoR systems in the past and they can get very complicated as I'm
sure
you're aware.

>> 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)
>
>Giz a patch then bazza!
>

I'll work on that over then next day or so.

>> 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
>
>Yes.
>
>> 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.
>
>Agreed, but we can restrict customer codecs.
>

I'm guessing that you mean restricting the bandwidth in the endpoint...
That's fine when you have a few but some of our customers have 10s of
thousands of 
endpoints.

>> 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
>
>Why not
>allow=h263p
>allow=h263
>resolution=4CIF2
>resolution=CIF
>minvideobandwidth=1440
>maxvideobandwidth=3840
>
>or something, just to keep close to the pre-existing stuff.
>

Yeh - I've been trying to think of a way of doing this in a similar
manner but 
each h26x codec can have very different capabilities. It's much harder
to do
H.264 than H.261 and so you'll might only support CIF at an MPI of 3 for
H.264
and yet do H.261 CIF at MPI of 1. We could use the mechanism you propose
above
and then make the settings apply to all codecs below. I think you'd then
have
to support it with something like allow and disallow instead of
resolution or
else your going to get in a mess with only being able to turn on
capabilities as
you go through the conf file.

minvideobandwidth=1440
maxvideobandwidth=3840
disallow=4CIF
disallow=16CIF
allow=CIF
allow=QCIF
allow=h263p
allow=4CIF2
allow=h263
allow=4CIF2
resolution=CIF
allow=h261

And then what happens with H.264 and you want to specify a custom
portrait
format like the Motorola Ojo does? You'd need syntax like:

allow=288x352  ???
framerate=120  ???

>> 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.
>
>Yeah, the tipic patches will probably be in IAXclient soon which enable
video
>conferencing in the Open Source library.
>

How do I find out more about this? I've been reading the posts,
bugs.digium and
everything else I can think of for the last 9 months and haven't spotted
this.

>-- 
>Cheers,
>
>Matt Riddell