[asterisk-dev] H.263 Buffer size

[John Martin]

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-
> bounces at lists.digium.com] On Behalf Of John Lange
> Sent: 18 July 2006 16:57
> To: Asterisk Developers Mailing List
> Subject: RE: [asterisk-dev] H.263 Buffer size
> 
> On Tue, 2006-07-18 at 08:29 +0200, Sergio García Murillo wrote:
> > John Martin wrote:
> > > Hi Devs,
> > >   I was just watching the SVN commits going by and I was wondering
> > > why the H.263 buffer size in format_h263.c had to be increased to
> > > 32kB?
> >
> > I really don't see the point if it either (perhaps someone can enlighten
> us).
> > I don't know if there is any special case in which it's needed, but if
> you
> > work with rtp you shouldn't exceed the MTU to avoid problems.
> 
> Since MTU is a network layer 2 feature, and since you may traverse any
> number of different networks on your way from point A to point B, I
> don't see how anything at the application layer could possibly know what
> the MTU is.
> 
> When developing at the application layer you are supposed to be able to
> safely ignore the layer 2 stuff and let the network(s) do its job. If
> that involves fragmenting and reassembling packets then so be it; it
> should be 100% transparent to the application layer.
> 
> Now I suppose your point is that in the real world you do have to pay
> attention to MTU when coding RTP because it impacts performance. I will
> grant you that. Its a shame to have to "corrupt" an application with
> issues it shouldn't be concerned with. For one thing if you subsequently
> put it on a properly optimized network (larger MTU) it will not perform
> optimally.
> 

Brief response as I leave the office... (I said I wouldn't do that the other day :-) )
It often does worse than impact performance, many paths through the Internet (at least that I've come across in the last 5 years) don't let fragmented packets through at all, there always seems to be a device somewhere that'll block fragmented UDP packets - 100% packet loss is a bit of a problem :-) Local networks are a different matter, and so perhaps the RTP packet sizes should be configurable. This is all a fairly moot point because every endpoint I've tested with uses a max packet size of around 1500 bytes and will do so until everywhere on the internet can do more or there's a reliable way of deciding on an MTU before a call starts. I'm not sure what all the fuss is about, people seem quite happy to send G.729 20ms audio packets around with huge overhead, adding a few percent to a video stream to make it work doesn't seem to much of a problem :-)

So you have to take account of RTP packet size, even though it might break some application layer models. :-(

> By the way, which phones are you guys using to test video?
> 

We use a combination of SIP and H.323 with Huawei, Grandstream, Polycom, Tandberg, Xten, D-Link, TelePhoSee and of course our own :-) For infrastructure we mainly use RadVision and Cisco.

> John
> 
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev