[asterisk-dev] H.263 Buffer size

[Rich Adamson]

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

As a side note to the above discussion, Sonicwall firewalls have an 
issue with mtu size as well, where they silently drop any udp packets 
above approx 1492 bytes in a PPPoE environment. One can muck with the 
mtu forever (at midpoints in the net), but doesn't impact their problem. 
Although the issue has been documented several times over the last two 
years, the issue still exists in their current firmware.

FWIW, Specifying an mtu at the "endpoint" does fix the problem (which 
implies the asterisk box).