Re: [Ekiga-devel-list] 3.2.5 release

[Damien Sandras <dsandras seconix com>]

Le vendredi 10 juillet 2009 à 11:30 +0200, yannick a écrit :
> 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?

No because it is UDP => no feedback.
And the value indicating when to switch from udp to tcp is in the SIP
RFC. I think guessing the MTU is overly complex.

On the mid term, ekiga should fully switch to TCP, but I need to review
both teh RFC and the opal code to check routing is done correctly in
that case.
-- 
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras ekiga net