[ previous ] [ next ] [ threads ]
 To :  yate@v...
 From :  Paul Chitescu <paulc@v...>
 Subject :  Re: [yate] fixed ? codec negotiation media.cpp
 Date :  Mon, 19 Apr 2010 18:26:57 +0300

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.


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 
> 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