[ 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 :  Mon, 3 May 2010 10:23:20 +0300
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