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

[Matt Riddell]

John Martin wrote:
>   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.

> 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...).

> 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!

> 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.

> 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.

> 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.

-- 
Cheers,

Matt Riddell
_______________________________________________

http://www.sineapps.com/news.php (Daily Asterisk News - html)
http://freevoip.gedameurope.com (Free Asterisk Voip Community)
http://www.sineapps.com/rssfeed.php (Daily Asterisk News - rss)