Re: [Ekiga-devel-list] 3.2.5 release

[yannick <sevmek free fr>]

Damien Sandras a écrit :
> Le vendredi 10 juillet 2009 à 11:17 +0200, yannick a écrit :
>> Damien Sandras a écrit :
>>> Le vendredi 10 juillet 2009 à 10:49 +0200, yannick a écrit :
>>>>>>> That's what I thought. By default, only a few codecs are enabled.
>>>>>> The bug is strange, since 
>>>>>> https://launchpadlibrarian.net/24407094/ekiga_3.2.0-0ubuntu1.diff.gz 
>>>>>> does not show any change related to enabled codecs in ekiga...
>>>>>>
>>>>> I guess people enable everything.
>>>> I have done some limited search on the MTU topic and it seems the MTU
>>>> can vary along the patch. Beside large bandwidth can greatly benefit for
>>>> a larger MTU than 1500 and some people are pushing to have larger MTU in
>>>> this case. (I have a report with this case at hand here:
>>>> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/380091 )I do not
>>>> know how the choice if 1500 is made inside OPAL; if it is hardcoded it
>>>> is probably a source of frame dropping in some case (and it happen
>>>> probably in silence). Around 1400 seems more safe but it seems to not
>>>> cover all cases.
>>>>
>>>> AFAIK a proper fix for this situation is to use a discovery mechanism
>>>> for the MTU: fortunately this exist in RFC:
>>>> http://tools.ietf.org/html/rfc4821
>>> OPAL does not touch the MTU.
>>>
>>> The MTU setting on a machine is an OS thing, not a user program thing.
>> (ARGH I only answered to Damien, reposting to the list, sorry Damien for
>> the noise...)
>>
>> It does not matter, even if your host has a 1500 MTU, the next hop in
>> the path can have a 1400 MTU (I agree this should be a rare case), thus
>> if you only take your host in account you'll be screwed.
> 
> Anyway, the only clean solution is to use TCP.

By default? If we use UDP by default, then we need either the MTU
discover mechanism in the RFC, either to use a safer MTU value (1400
seems a reasonable choice), because AFAIK UDP has no mechanism for
fragmented packet and frames will be dropped silently if we are in the
bad range (close to 1500). Or maybe use the fact frame are dropped to
switch to TCP? Is there a way to know if frames has been dropped?