Re: [Ekiga-devel-list] 3.2.5 release
- From: yannick <sevmek free fr>
- Cc: Ekiga development mailing list <ekiga-devel-list gnome org>
- Subject: Re: [Ekiga-devel-list] 3.2.5 release
- Date: Fri, 10 Jul 2009 12:40:50 +0200
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 ;)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]