[ previous ] [ next ] [ threads ]
 To :  yate@v...
 From :  Gerrit Jacobsen <g_jacobsen@y...>
 Subject :  formats behaviour ramblings [yate] Bug: codec negotiation media.cpp
 Date :  Sun, 4 Apr 2010 07:06:12 +0000 (GMT)
My previous message was truncated, so here again ..

Hi Yate team,

Further to the reported formats behaviour bug in SIP-SIP.

Looking through the previous conversations regarding the formats parameter it is fuzzy to me how the formats parameter is supposed to behave, when set in routing stage.

In below message Paul suggests to Alex that setting the formats parameter in routing applies to the incoming and outgoing leg.

Reading Pauls statement lterally would mean that if one sets the formats parameter in routing that this prevents transcoding, no matter whether any of the incoming or outgoing call legs support the codecs mentioned in formats.

Is this really intended ? I dont think so. In fact the parameter also doesnt act like that. The formats parameter behaves very different depending on the transport modules:

Incoming call on Wpcard in alaw, outgoing SIP, formats=ilibc20 set in routing stage then yate transcodes from alaw to ilibc20 - so in this case the formats parameter changes only the 
outgoing codec

Incoming call on H323 in g729, outgoing to SIP. The documentation suggests to remove all codecs but one  - so in this case the formats parameter supposed to fix the incoming codec.

Incoming call on SIP in alaw, outgoing to SIP, formats set to alaw and g729 in routing stage. In this case yate forces the incoming codec to the one  the outgoing SIP leg picked.  This seems to contradicts Pauls assertion regarding that formats applies to the incoming leg.

From the above it becomes clear that the behavior of formats is inconsistent.

So how to achieve the goals with yate?

1. one wants to minimize transcoding cases, if both sides support the same codec then that should be picked.
2. one has to ensure that if H323 is involved on the incoming or outgoing side only one codec is chosen for the H323 side, which has to be known already in routing stage.
3. yate should never pick a codec which is not supported by any of the call legs
4. One wants to connect a call always successfully if necessary with transcoding

Quite frankly I am clueless how to achive these goals consistently with regexroute and register modules as the meaning of the formats parameter seems to depend on the transport chosen.

IMVHO, it would be much better to have two formats parameters for incoming and outgoing call legs. The regfile and accfile modules also provide formats parameters and it is clear to the user that these formats parameters only apply to the side of the call party mentioned in the regfile and accfile.

The same logic, different formats sets for incoming and outgoing, should be available also for regexroute and register modules IMVHO. 

Pauls suggestion to apply an oformats parameter in call.execute  amounts to formats parameter only for outgoing. Is this really working consistently across all transport scenarios ? 

Cheers

Gerry




"Hi!

Setting a different set of formats on incoming and outgoing 
needs altering the call.execute message (post routing) since the 
formats set during routing apply to incoming (and by default to 
outgoing as well).

Do this (regexroute example):


[default]
...
; if G.729 is supported force it as the only allowed format
; and 
prepare outbound for transcoding
${formats}g729=;formats=g729;oformats=ilbc20

[extra]
; set a priority handler for call.execute
call.execute=25

[call.execute]
; if outbound formats are specified apply them
${oformats}.=;formats=${oformats}


You would probably need to refine the routing rule a little. You can do 
that 
part from a database and apply oformats (or whatever you like 
to name it) 
from regexroute.

Paul


On Tuesday 23 
September 2008 11:09:49 Alex Vostrikov wrote:
> Hi there,
>
> Is there any way to force transcoding from H323 (g729) to SIP (iLBC)
>
> Thank you in advance,
> alex
"

--- On Fri, 2/4/10, 
Gerrit Jacobsen  wrote:


>From: Gerrit Jacobsen 
>
>Subject: [yate] Bug: codec negotiation
> media.cpp
>To: yate@v...
>Date: Friday, 2 April, 2010, 
>18:38
>
>
>Hello yate team,
>
>there seems to be a bug/logic
> flaw in the SDP negotiation.
>
>Situation: Two SIP entities, SIP1 
>and SIP2 and yate
>SIP1 to SIP2 call, via yate, proxying RTP
>
>1.
> SIP1 INVITES to yate and announces alaw in SDP
>2. In route stage the
> formats parameter is set by regexroute or other routing module to 
>"g729,alaw"
>e.g.
>^\(.*\)$=sip/sip:@2...;
> xsip_auth_bye=false; formats=g729,alaw
>3. SIP2 sends 200ok and 
>accepts g729 codec in sdp
>
>and now comes the problem:
>4. Yate 
>sends 200ok with "g729" to SIP1
>This should not happen as SIP1 announced only alaw as 
>capability.
>
>5. SIP1 disconnects the call because it doesnt
> support G729.
>
>The problem does not happen when at point 2.
>the
> formats parameter is set to g729 only
> (instead of g729 and alaw). 
>Yate log then shows the line 
>"Debug(DebugInfo,"Not changing to '%s' from '%s' [%p]", 
>formats,m_formats.c_str(),this);"
>Yate then sends correctly at point 
>3. 200ok with alaw in SDP
>
>
>The problem seems to be in 
>media.cpp when the bug happens (two codecs in formats set) the 
>SDPMedia::update function concludes that only G729 should be used and 
>changes the formats to G729.
>
>
>bool SDPMedia::update(const 
>char* formats, int rport, int lport)
>{
>    
>DDebug(DebugAll,"SDPMedia::update('%s',%d,%d) 
>[%p]",formats,rport,lport,this);
>    bool chg = false;
>    String 
>tmp(formats);
>    if (m_formats != tmp) {
>        if 
>((tmp.find(',') < 0) && m_formats && 
>m_formats.find(tmp) < 0)
>            Debug(DebugInfo,"Not changing
> to '%s'
> from '%s' [%p]",
>                formats,m_formats.c_str(),this);
>       
> else 
>{                                                                                                 
> chg =
> 
>true;                                                                                        
> m_formats = tmp;
>            int q = m_formats.find(',');
>           
> m_format = m_formats.substr(0,q);
>        }
>    }
>
>Thanks 
>for looking into this.
>
>Cheers 
>
>Gerry
>
> 
>