Re: [Ekiga-devel-list] Testing for 3.2.6

[yannick <sevmek free fr>]

Peter Robinson a écrit :
> On Thu, Aug 27, 2009 at 1:48 PM, yannick<sevmek 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
> 
>