[ 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 06:46:32 +0000 (GMT)
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






      


      


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 <g_jacobsen@y...> wrote:

From: Gerrit Jacobsen <g_jacobsen@y...>
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