[ previous ] [ next ] [ threads ]
 To :  yate@v...
 From :  Paul Chitescu <paulc@v...>
 Subject :  Re: [yate] fixed ? codec negotiation media.cpp
 Date :  Thu, 27 May 2010 18:57:48 +0300
Hi! Sorry for the delay!

SVN Rev 3347 fixes the intersection and codec order issues in SDP. It prevents 
answering with a codec that wasn't offered initially and also prefers the 
order set in the answer message.

Example: if INVITE offered "alaw,mulaw,gsm,speex" and in call.answered the 
formats are "gsm,amrnb,mulaw" then the SDP in 200 OK will accept "gsm,mulaw" 
and will start sending gsm.

However, this commit does not address transcoding as it's not clear if and 
where to make a decision in each possible scenario Yate is or can be used.

http://yate.null.ro/websvn/revision.php?repname=yate&path=%2Ftrunk%2F&rev=3347

Regards,

Paul


On Monday 03 May 2010 10:23:20 am 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
>