[ previous ] [ next ] [ threads ]
 To :  "Paul Chitescu" <paulc@v...>, <yate@v...>
 From :  "G.Jacobsen" <g_jacobsen@y...>
 Subject :  Re: [yate] fixed ? codec negotiation media.cpp
 Date :  Fri, 28 May 2010 18:59:22 +0300
Thank you Paul,

is there a chance that this bugfix will be backported into the stable branch
2 ?

Gerry



----- Original Message ----- 
From: "Paul Chitescu" 
To: 
Sent: Thursday, May 27, 2010 6:57 PM
Subject: Re: [yate] fixed ? codec negotiation media.cpp


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