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:dsand...@ekiga.net _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list