Re: [Ekiga-devel-list] 3.2.5 release

[yannick <sevmek free fr>]

Eugen Dedu a écrit :
> yannick wrote:
>> Eugen Dedu a écrit :
>>> yannick wrote:
>>>> 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?
>>> As I wrote on TCP bug, IPv4 does fragmentation (IPv6 does not).  No need
>>> to worry about MTU other than the local one.  I can send my courses if
>>> you wish :o)
>>>
>>
>> Good to know. Thank you. Well, for my education if you could send me
>> your courses in private i'll be happy ;)
> 
> In French, "Technologie IP", http://eugen.dedu.free.fr/index.html#teaching
> 

I digged this up further. To really be sure Ekiga handle all that
properly, I've 2 questions:

* there is flag to allow, or not, fragmentation. Does Ekiga use this flag?
* in some cases, an ICMP packet can be send back if the datagram turn to
be too big for some operations. How ekiga deals with this?