> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:asterisk-dev- > [EMAIL PROTECTED] 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 _______________________________________________ --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
