Hello, On 6/12/11 9:56 PM, Spinov Evgeniy wrote: is any particular reason to use ds_next_domain() after ds_select_dst()? ds_next_domain() is the pair for ds_select_domain, in older versions it happened that $du was reset automatically internally even by ds_next_domain() due to execution of a core function which was no longer needed in 3.1. A quick solution if you need ds_select_dst() in combination with ds_next_domain() is to call resetdsturi() in failure route. I will think about and see if it is consistent to call it internally. Can you look at sip trace with ngrep to see where they are sent? Probably to the first destination that failed. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda

On 6/13/11 12:03 PM, Evgeniy Spinov wrote: ds_select_dst()/ds_next_dst() and ds_select_domain()/ds_next_domain() consume the already-tried destinations -- in any of the cases, none of gateways will be tried two times. ds_*_dst() sets $du and $ds_*_domain() sets $ru -- this is the difference between them. When you do first ds_select_dst() you set $du and when then you do $ds_next_domain() you set $ru -- if you would do $ds_next_dst() then $du will be set with the new gateway address. This is not a bug in sip routing as long as $du is set, then it is the field used for sip routing no matter you have in $ru -- $du is the internal outbound proxy address overwriting request-uri address. Maybe will be safe to introduce resetdsturi() in case of ds_next_domain() to be safe in combinations like ds_select_dst()+ds_next_domain(). Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda

On Mon, 2011-06-13 at 12:12 +0200, Daniel-Constantin Mierla wrote: Ok, still unsolved problem. I've changed failover part of the script to use ds_next_dst(). It does what it should and signalization works fine - calls are being connected. However I've got no audio and message in logs: 7(9917) ERROR: rtpproxy [rtpproxy.c:2211]: incorrect port 0 in reply from rtp proxy I've added force_rtp_proxy() after ds_next_dst() and message disappeared, however still no audio on the failover call. RTP Proxy runs on the same server and is fine for not failover calls. Success route script executes force_rtp_proxy() and fix_nated_contact() in curtain conditions and that's it. Am I missing something in my logic? Thank you.

On Wed, 2011-06-15 at 09:47 +0200, Daniel-Constantin Mierla wrote: It's done on the branch route, however it seems that branch route is not being executed when the failure branch route is being ran. Anyhow, when the call is not passing through failure route and ds_next_dst() it is fine, no errors. When it goes there, error with rtp proxy in logs and no audio. When I add force_rtp_proxy() on success of t_relay() in failure route it gives no errors, but still no audio. I do not know where issue is related, and what is wrong, especially when this scenario worked before. Just to avoid misunderstanding, providing you a failure and a normal branches of the script. Failure route: if (is_method("INVITE") && (isbflagset("6") || isflagset(5))) { unforce_rtp_proxy(); } ... ( checks for different errors and messages output is skipped, not related to this issue anyway ) if( ds_next_dst() ) { xlog( "L_NOTICE", "[$Tf] $ci Next gateway $fU -> $tU via $du\n" ); if( !t_relay() ) { xlog( "L_INFO", "[$Tf] $ci -- ERROR - Can not t_relay()\n" ); return; }; return; } else { xlog( "L_INFO", "[$Tf] $ci No more routes available \n" ); t_reply("503", "Service unavailable -- no more gateways" ); exit; }; And success route completely: if ((isflagset(5) || isbflagset("6")) && status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } if (isbflagset("6")) { fix_nated_contact(); } Thank you.

On Thu, 2011-06-16 at 12:06 +0200, Daniel-Constantin Mierla wrote: Tried that - nothing changes. Getting "incorrect port 0 in reply from rtpproxy" and no audio.