Hello Paul and list,

any updates on this?

Best Regards
  Chris

G.Jacobsen wrote:
> Paul,
> 
>> We're fixing this on Thursday 22nd.
> 
> I cant see it in SVN yet. Or did you mean Thursday 22nd July 2010 ?
> 
> Gerry
> 
> 
> 
> 
> ----- Original Message ----- 
> From: "Paul Chitescu" 
> To: 
> Sent: Monday, April 19, 2010 6:26 PM
> Subject: Re: [yate] fixed ? codec negotiation media.cpp
> 
> 
>> Hi!
>>
>> We're fixing this on Thursday 22nd.
>>
>> We don't intend yet to implement cost ordering as the costs set in the
> codec
>> modules are not correct.
>>
>> Paul
>>
>>
>> On Wednesday 14 April 2010 05:46:14 am Gerrit Jacobsen wrote:
>>> Hello yate team,
>>>
>>> has the codec negotiation issue been fixed? I cant identify it in SVN.
>>>
>>> Thanks for your great work.
>>>
>>> Gerry
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Gerrit Jacobsen 
>>> To: Paul Chitescu ; yate@v...
>>> Sent: Tue, 6 April, 2010 8:35:22
>>> Subject: Re: [yate] Bug: codec negotiation media.cpp
>>>
>>>
>>> Paul,
>>>
>>> "What do you think about creating an intersect between the INVITEd
> codecs
>> and
>>> those set in routing? If the resulting set is not empty that
>>> set would be
>>> replaced in the answer."
>>>
>>> Yes, but because there is only one codec chosen for connecting the
> incoming
>> leg. Yate should take into account the order.
>>> IMVHO there should be these steps:
>>> 1. Determine the intersect between codecs from the INVITE and those set
> in
>> formats during routing, ordered by the order of the formats set in
> routing.
>>> 2. Remove all codecs from the intersect where there is no transcoding
>> possible from the already connected outgoing call leg.
>>> 3a). In case the intersect is not empty, the top ordered codec from the
>> intersect should be used for connecting the incoming leg.
>>> 3b) If the intersect is empty then the logic should follow the same as
> if
>> there was no codec set in formats, ideally picking the same codec as the
>> outgoing call leg to minimize transcoding.
>>> Also I would consider to hardcode "oformats" as the currently proposed
>>> method with setting manually in "call.execute" is hard to
>>> understand. I think that formats which are manually set should act as
>> filters / intersect for incoming call legs and determine the
>>> order of codecs. oformats should determine offered formats in outgoing
> legs.
>>> Regarding transcoding. There is one more point regarding the transcode
>> function in regexroute. Currently transcode orders the codecs in the order
> as
>> possible transcodings were found,"originating codec1, possible
> transcoding1 of
>> codec1, possible transcoding2 of codec1, originating codec2, possible
>> transcoding1 of codec2, possible
>>> transcoding2 of codec2"
>>>
>>> This function would be more useful if it would order the codecs by
> computing
>> costs, first the orginal input codecs where there is no transcoding
> necessary,
>> then codecs with only one transcoding necessary and then double
> transcodings.
>>>
>>> Thank you for your work on the formats issue.
>>>
>>> Cheers,
>>>
>>> Gerry
> 
> 

-- 
Christian Beyerlein
Systemadministrator

First Telecom GmbH
Lyoner Str. 15
60528 Frankfurt/Main

Sitz der Gesellschaft: Frankfurt am Main
Handelsregister: Amtsgericht Frankfurt am Main, HRB 56145
Geschäftsführer: Frank Hartmann, Dieter Plassmann