Re: [Ekiga-devel-list] 3.2.5 release
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. -- _ 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
Re: [Ekiga-devel-list] 3.2.5 release
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. e.g. the AOL ISP use a 1450 MTU: MTU (Maximum Transfer Unit) defines the largest data packet size you can transmit in one go across a network. Any messages larger than the MTU are divided into smaller packets before being sent. The industry standard follows the principle that in order to transmit the largest amount in one go, an MTU should be set to a high value, such as 1500. However, the AOL Broadband network runs at an MTU of 1450. Many modem routers have inbuilt auto-configurations where the hardware identifies that the AOL Broadband traffic has an MTU of 1450 and dynamically adjusts. If the modem router hardware does not have this facility, the MTU setting can manually be changed on the computer. Source: http://help.aol.co.uk/what-is-an-mtu-setting-and/article/20060802093009990042 ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 3.2.5 release
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. -- _ 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
Re: [Ekiga-devel-list] 3.2.5 release
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
Re: [Ekiga-devel-list] 3.2.5 release
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 -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 3.2.5 release
Damien Sandras wrote: Le lundi 06 juillet 2009 à 20:20 +0100, Peter Robinson a écrit : So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? The PDU1500 issue? Here is a report from a Ubnutu user (I know, I should not trust blindly a user, but i wont be able to test before tomorrow...): No I hadn't installed any non-free codecs (not knowingly anyway). I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty). Selected ekiga for installation. Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository). Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works. Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). Out-of-the-box Video codecs: h261, theora. So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500. Do we need a workaround for this before a proper fix? (TCP support) A workaround would be to switch off some codecs by default (for initial installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). What do you think? Isn't that already the case ? I need to check. The default in Fedora certainly doesn't enable them by default and we don't do anything with that sort of config so I assume its the default. 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... -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 3.2.5 release
Le mercredi 08 juillet 2009 à 09:04 +0200, Eugen Dedu a écrit : Damien Sandras wrote: Le lundi 06 juillet 2009 à 20:20 +0100, Peter Robinson a écrit : So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? The PDU1500 issue? Here is a report from a Ubnutu user (I know, I should not trust blindly a user, but i wont be able to test before tomorrow...): No I hadn't installed any non-free codecs (not knowingly anyway). I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty). Selected ekiga for installation. Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository). Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works. Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). Out-of-the-box Video codecs: h261, theora. So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500. Do we need a workaround for this before a proper fix? (TCP support) A workaround would be to switch off some codecs by default (for initial installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). What do you think? Isn't that already the case ? I need to check. The default in Fedora certainly doesn't enable them by default and we don't do anything with that sort of config so I assume its the default. 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. -- _ 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
Re: [Ekiga-devel-list] 3.2.5 release
Le lundi 06 juillet 2009 à 20:20 +0100, Peter Robinson a écrit : So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? The PDU1500 issue? Here is a report from a Ubnutu user (I know, I should not trust blindly a user, but i wont be able to test before tomorrow...): No I hadn't installed any non-free codecs (not knowingly anyway). I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty). Selected ekiga for installation. Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository). Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works. Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). Out-of-the-box Video codecs: h261, theora. So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500. Do we need a workaround for this before a proper fix? (TCP support) A workaround would be to switch off some codecs by default (for initial installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). What do you think? Isn't that already the case ? I need to check. The default in Fedora certainly doesn't enable them by default and we don't do anything with that sort of config so I assume its the default. That's what I thought. By default, only a few codecs are enabled. -- _ 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
Re: [Ekiga-devel-list] 3.2.5 release
Eugen Dedu a écrit : Hi, So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? The PDU1500 issue? Here is a report from a Ubnutu user (I know, I should not trust blindly a user, but i wont be able to test before tomorrow...): No I hadn't installed any non-free codecs (not knowingly anyway). I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty). Selected ekiga for installation. Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository). Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works. Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). Out-of-the-box Video codecs: h261, theora. So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500. Do we need a workaround for this before a proper fix? (TCP support) ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 3.2.5 release
Le lundi 06 juillet 2009 à 16:12 +0200, yannick a écrit : Eugen Dedu a écrit : Hi, So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? The PDU1500 issue? Here is a report from a Ubnutu user (I know, I should not trust blindly a user, but i wont be able to test before tomorrow...): No I hadn't installed any non-free codecs (not knowingly anyway). I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty). Selected ekiga for installation. Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository). Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works. Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). Out-of-the-box Video codecs: h261, theora. So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500. Do we need a workaround for this before a proper fix? (TCP support) TCP support. -- _ 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
Re: [Ekiga-devel-list] 3.2.5 release
Damien Sandras wrote: ..deleted Do we need a workaround for this before a proper fix? (TCP support) TCP support. Opal has the basic support for TCP, and has had for some time. To try it out, make sure you have a TCP listener on the same port as UDP listener (in fact, this is a requirement of the SIP RFC) We've done basic testing and it seems to work, but I am sure there are situations where it fails What is needed is more testing Craig -- --- Craig Southeren Post Increment – VoIP Consulting and Software cra...@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: craig_southe...@hotmail.com Mobile: +61 417231046 Jabber: cra...@jabber.org Science is the poetry of reality. Richard Dawkins ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 3.2.5 release
yannick wrote: Eugen Dedu a écrit : Hi, So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? The PDU1500 issue? Here is a report from a Ubnutu user (I know, I should not trust blindly a user, but i wont be able to test before tomorrow...): No I hadn't installed any non-free codecs (not knowingly anyway). I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty). Selected ekiga for installation. Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository). Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works. Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). Out-of-the-box Video codecs: h261, theora. So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500. Do we need a workaround for this before a proper fix? (TCP support) TCP support is the bug no 1 (in my opinion), but it is not for 3.2.5. Once 3.2.5 is released, we will see the next release goals. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 3.2.5 release
Craig Southeren wrote: Damien Sandras wrote: ..deleted Do we need a workaround for this before a proper fix? (TCP support) TCP support. Opal has the basic support for TCP, and has had for some time. To try it out, make sure you have a TCP listener on the same port as UDP listener (in fact, this is a requirement of the SIP RFC) We've done basic testing and it seems to work, but I am sure there are This is very great news! situations where it fails What is needed is more testing How can we test? How to create a TCP listener...? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 3.2.5 release
Eugen Dedu wrote: ..deleted We've done basic testing and it seems to work, but I am sure there are This is very great news! situations where it fails What is needed is more testing How can we test? How to create a TCP listener...? The same way a UDP listener is created, but use the string tcp$ipaddr:port instead of udp$ipaddr:port Craig -- --- Craig Southeren Post Increment – VoIP Consulting and Software cra...@postincrement.com.au www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax:+61 243656905 MSN: craig_southe...@hotmail.com Mobile: +61 417231046 Jabber: cra...@jabber.org Science is the poetry of reality. Richard Dawkins ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 3.2.5 release
yannick wrote: Eugen Dedu a écrit : Hi, So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? The PDU1500 issue? Here is a report from a Ubnutu user (I know, I should not trust blindly a user, but i wont be able to test before tomorrow...): No I hadn't installed any non-free codecs (not knowingly anyway). I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty). Selected ekiga for installation. Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository). Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works. Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). Out-of-the-box Video codecs: h261, theora. So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500. Do we need a workaround for this before a proper fix? (TCP support) A workaround would be to switch off some codecs by default (for initial installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). What do you think? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] 3.2.5 release
Le lundi 06 juillet 2009 à 18:53 +0200, Eugen Dedu a écrit : yannick wrote: Eugen Dedu a écrit : Hi, So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? The PDU1500 issue? Here is a report from a Ubnutu user (I know, I should not trust blindly a user, but i wont be able to test before tomorrow...): No I hadn't installed any non-free codecs (not knowingly anyway). I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty). Selected ekiga for installation. Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository). Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works. Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). Out-of-the-box Video codecs: h261, theora. So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500. Do we need a workaround for this before a proper fix? (TCP support) A workaround would be to switch off some codecs by default (for initial installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). What do you think? Isn't that already the case ? I need to check. -- _ 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
Re: [Ekiga-devel-list] 3.2.5 release
So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? The PDU1500 issue? Here is a report from a Ubnutu user (I know, I should not trust blindly a user, but i wont be able to test before tomorrow...): No I hadn't installed any non-free codecs (not knowingly anyway). I wanted to confirm this so I booted from clean live USB memory stick image (Jaunty). Selected ekiga for installation. Synaptic informs that the following are required: libgsm1, libopal3.6.1, libpt2.6.1, libpt2.6.1-plugins-alsa, libpt2.6.1-plugins-v4l2. (All of these come from the Main repository). Once above are installed: Ekiga has the same problem as described above (PDU exceed 1500) and same solution as you describe above also works. Out-of-the-box Audio codecs: G722, Speex(16kHz), PCMA, PCMU, G726-16, G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). Out-of-the-box Video codecs: h261, theora. So, in answer to your question, only using default packages from Ubuntu is sufficient for PDU to exceed 1500. Do we need a workaround for this before a proper fix? (TCP support) A workaround would be to switch off some codecs by default (for initial installation), for ex. G726-24, G726-32, G726-40, gsm, ms-gsm, Speex(8kHz). What do you think? Isn't that already the case ? I need to check. The default in Fedora certainly doesn't enable them by default and we don't do anything with that sort of config so I assume its the default. Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] 3.2.5 release
Hi, So we are preparing a new stable release. What are the blocking bugs? - picture in picture does not work sometimes - -d 4 warnings about too many consecutive I-frames, still investigating if it is harmful or not - initially greyed image, seems only cosmetic, still investigating Are there others? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
