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

[Peter Robinson <pbrobinson gmail com>]

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.

Peter

Peter