Re: [Ekiga-devel-list] Testing for 3.2.6
e schmidbauer a écrit : I would recommend compiling ekiga with celt 0.6.1 The git version of celt is incompatible with freeswitch. Hi, As the responsible guy packaging Ekiga *for the ekiga project* (i'm not an ubuntu packager) for Ubuntu, and as CELT is a moving target until it reach 1.0, my policy for the packages will probably be as follow: Take the version of libcelt in the latest released ubuntu, OR (exclusive) the actual dev tree of ubuntu and backport it to previous ubuntu release. For now the situation in ubuntu is as follow: * intrepid (libs): The CELT codec runtime library [universe] 0.3.2-1: amd64 i386 * jaunty (libs): The CELT codec runtime library [universe] 0.5.1-0ubuntu1: amd64 i386 * karmic (libs): The CELT codec runtime library [universe] 0.6.1-1: amd64 i386 And for now, I do not package CELT, neither the official ubuntu package. I've some work to do first on packaging the OPAL codecs (split them in several packages because of a nasty bug related to MTU size and UDP packets), then I will use the libcelt in karmic and backport it, thus you're lucky, I'll use libcelt version 0.6.1. Best regards, Yannick ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Testing for 3.2.6
Hi Yannick, As the responsible guy packaging Ekiga *for the ekiga project* (i'm not an ubuntu packager) for Ubuntu, and as CELT is a moving target until it reach 1.0, my policy for the packages will probably be as follow: Take the version of libcelt in the latest released ubuntu, OR (exclusive) the actual dev tree of ubuntu and backport it to previous ubuntu release. For now the situation in ubuntu is as follow: * intrepid (libs): The CELT codec runtime library [universe] 0.3.2-1: amd64 i386 * jaunty (libs): The CELT codec runtime library [universe] 0.5.1-0ubuntu1: amd64 i386 * karmic (libs): The CELT codec runtime library [universe] 0.6.1-1: amd64 i386 And for now, I do not package CELT, neither the official ubuntu package. I've some work to do first on packaging the OPAL codecs (split them in several packages because of a nasty bug related to MTU size and UDP packets), then I will use the libcelt in karmic and backport it, thus you're lucky, I'll use libcelt version 0.6.1. I'm the package maintainer for both celt and ekiga in Fedora. As the celt bitstream isn't frozen yet and is still open for change I initially enabled in Fedora and then dropped it until the bitstream is stable. Because of that the only way celt is guaranteed to work if its between the versions of ekiga linked against the same version of celt. Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Testing for 3.2.6
On Thu, Aug 27, 2009 at 1:48 PM, yannicksev...@free.fr wrote: Peter Robinson a écrit : Hi Yannick, As the responsible guy packaging Ekiga *for the ekiga project* (i'm not an ubuntu packager) for Ubuntu, and as CELT is a moving target until it reach 1.0, my policy for the packages will probably be as follow: Take the version of libcelt in the latest released ubuntu, OR (exclusive) the actual dev tree of ubuntu and backport it to previous ubuntu release. For now the situation in ubuntu is as follow: * intrepid (libs): The CELT codec runtime library [universe] 0.3.2-1: amd64 i386 * jaunty (libs): The CELT codec runtime library [universe] 0.5.1-0ubuntu1: amd64 i386 * karmic (libs): The CELT codec runtime library [universe] 0.6.1-1: amd64 i386 And for now, I do not package CELT, neither the official ubuntu package. I've some work to do first on packaging the OPAL codecs (split them in several packages because of a nasty bug related to MTU size and UDP packets), then I will use the libcelt in karmic and backport it, thus you're lucky, I'll use libcelt version 0.6.1. I'm the package maintainer for both celt and ekiga in Fedora. As the celt bitstream isn't frozen yet and is still open for change I initially enabled in Fedora and then dropped it until the bitstream is stable. Because of that the only way celt is guaranteed to work if its between the versions of ekiga linked against the same version of celt. That's indeed a short and clear description of the issue with CELT. Thank you :-) Peter BTW, Peter, we do have a nasty bug in Ekiga (see: http://bugzilla.gnome.org/show_bug.cgi?id=341518#c8 ) From what I can see in your package in F11, people do have the exact same situation with Fedora as described in the above URL. The proper fix is to add TCP support but it will take some times (hopefully in Ekiga 3.4.x) . Until then a possible workaround is to package some codecs outside OPAL and make them available as suggest (i do not know the terminology in RPM packages) to Ekiga. Only splitting the G726 audio codec will free at least 100 bits in the INVITE and will make calls work for most people with the default installation (it will prevent reaching the standard MTU size 1500, thus will prevent split/or refusing of UDP packets in most cases.). In most cases, G726 is not mandatory for interoperability. Yes, I have seen it. Fortunately we don't enable all the codecs by default and we don't have celt enabled nor ones with patent issues such has H.264 and strip out iLBC because of other licensing issues so I think that allows us to mostly not see the issue too much. Peter Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Testing for 3.2.6
Peter Robinson a écrit : On Thu, Aug 27, 2009 at 1:48 PM, yannicksev...@free.fr wrote: Peter Robinson a écrit : Hi Yannick, As the responsible guy packaging Ekiga *for the ekiga project* (i'm not an ubuntu packager) for Ubuntu, and as CELT is a moving target until it reach 1.0, my policy for the packages will probably be as follow: Take the version of libcelt in the latest released ubuntu, OR (exclusive) the actual dev tree of ubuntu and backport it to previous ubuntu release. For now the situation in ubuntu is as follow: * intrepid (libs): The CELT codec runtime library [universe] 0.3.2-1: amd64 i386 * jaunty (libs): The CELT codec runtime library [universe] 0.5.1-0ubuntu1: amd64 i386 * karmic (libs): The CELT codec runtime library [universe] 0.6.1-1: amd64 i386 And for now, I do not package CELT, neither the official ubuntu package. I've some work to do first on packaging the OPAL codecs (split them in several packages because of a nasty bug related to MTU size and UDP packets), then I will use the libcelt in karmic and backport it, thus you're lucky, I'll use libcelt version 0.6.1. I'm the package maintainer for both celt and ekiga in Fedora. As the celt bitstream isn't frozen yet and is still open for change I initially enabled in Fedora and then dropped it until the bitstream is stable. Because of that the only way celt is guaranteed to work if its between the versions of ekiga linked against the same version of celt. That's indeed a short and clear description of the issue with CELT. Thank you :-) Peter BTW, Peter, we do have a nasty bug in Ekiga (see: http://bugzilla.gnome.org/show_bug.cgi?id=341518#c8 ) From what I can see in your package in F11, people do have the exact same situation with Fedora as described in the above URL. The proper fix is to add TCP support but it will take some times (hopefully in Ekiga 3.4.x) . Until then a possible workaround is to package some codecs outside OPAL and make them available as suggest (i do not know the terminology in RPM packages) to Ekiga. Only splitting the G726 audio codec will free at least 100 bits in the INVITE and will make calls work for most people with the default installation (it will prevent reaching the standard MTU size 1500, thus will prevent split/or refusing of UDP packets in most cases.). In most cases, G726 is not mandatory for interoperability. Yes, I have seen it. Fortunately we don't enable all the codecs by default and we don't have celt enabled nor ones with patent issues such has H.264 and strip out iLBC because of other licensing issues so I think that allows us to mostly not see the issue too much. Good :) Thank you for the fast reply. Peter Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Testing for 3.2.6
yannick a écrit : Hi, With Eugen, we started our testing for 3.2.6: Results available here http://wiki.ekiga.org/index.php/Pre-release_test#Ekiga_3.2.6_Pre-tests We were not able to finish the testing due to computer hardware issue. We will probably continue tomorrow. We did a bit more today but it is not finish yet... see the URL for latest test results. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Testing for 3.2.6
I would recommend compiling ekiga with celt 0.6.1 The git version of celt is incompatible with freeswitch. On Wed, Aug 26, 2009 at 10:52 AM, yannicksev...@free.fr wrote: yannick a écrit : Hi, With Eugen, we started our testing for 3.2.6: Results available here http://wiki.ekiga.org/index.php/Pre-release_test#Ekiga_3.2.6_Pre-tests We were not able to finish the testing due to computer hardware issue. We will probably continue tomorrow. We did a bit more today but it is not finish yet... see the URL for latest test results. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Testing for 3.2.6
Hi, With Eugen, we started our testing for 3.2.6: Results available here http://wiki.ekiga.org/index.php/Pre-release_test#Ekiga_3.2.6_Pre-tests We were not able to finish the testing due to computer hardware issue. We will probably continue tomorrow. Broken features are: * call-in notification * Call Hold * Call Transfer * Call Forwarding on always (and probably all types of call forwarding) * DTMFs Support and some more minor stuff, see the wiki and we will report also some bugs/crashs on bugzilla we found. Best regards, Yannick ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
