On Mon, 2011-06-13 at 10:49 +0200, Daniel-Constantin Mierla wrote:
Hello,
On 6/12/11 9:56 PM, Spinov Evgeniy wrote:
Hello.
DCM> Hello,
DCM> to understand the scenario: DCM> - first branch has destination uri ($du) set
Exactly.
DCM> - it failed and gets to failure route where you call ds_next_domain() DCM> and $du s still the one from first branch?
Exactly. $du is being set by ds_select_dst() before t_relay() before any branch in main loop. In failure route after ds_next_domain() variable $du remains with old IP ( previous asterisk node ), while $rd variable is updated.
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.
I do not mind using ds_select_dst() however it seems to me, that in following scenario it will give me a false result: 1. Call 1 is coming 2. Routed to GW 1 3. Call 2 is coming 4. Routed to GW 2 5. Call 1 timed out to GW 1 and call is going to failure route, where ds_select_dst() is being called.
I guess ds_select_dst in this case will give GW 1 again in case of round-robin fashion.
Also, there is no end of gateways, as ds_select_dst() will always return one of the gateways, while when no gateways are alive - appropriate reaction should happen.
That's why ds_next_domain() is more suitable, as performing all the required actions without magic. Performed at least.
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.
Works for me.
DCM> What do you mean that "not any of the nodes receive the packet ..."?
Kamailio is standing before asterisks and relays packets to them. In case, when there is no ds_next_domain() - packet is routed correctly to the curtain node, defined by ds_select_dst(). While after ds_next_domain() none of the 2 nodes receives the packet and call terminates by the caller with "Request timeout". Looks like t_relay() sends packet somewhere to blackhole.
Can you look at sip trace with ngrep to see where they are sent? Probably to the first destination that failed.
Yes. It sends packet to previous gateway, while in INVITE another IP mentioned ( look at 1 and 2 strings ):
13:59:36.533705 IP KAMAILIO_IP.sip > GW1_IP.sip: UDP, length 1020 E....H..@.4..(...(.........UINVITE sip:*44@GW2_IP:5060 SIP/2.0 Record-Route: sip:KAMAILIO_IP;lr=on;ftag=ustdc;did=c4e.a81165f4;nat=yes Via: SIP/2.0/UDP KAMAILIO_IP;branch=z9hG4bKccae.c54a1682.1 Max-Forwards: 69 To: sip:*44@KAMAILIO_IP From: "2_101" sip:2_101@KAMAILIO_IP;tag=ustdc Call-ID: yuwofwddoaqozwh@localhost.localdomain CSeq: 527 INVITE Contact: sip:2_101@UAC_PUBLIC_IP:5061 Content-Type: application/sdp Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE Supported: replaces,norefersub,100rel User-Agent: Twinkle/1.4.2 Content-Length: 330
Looks like a bug.
Cheers, Daniel
Thank you.
DCM> Cheers. DCM> Daniel
DCM> On 6/10/11 6:43 PM, Evgeniy Spinov wrote:
Hello.
I had a Kamailio version of 3.0.3 and during this time configured a failover with simple routine. In short like this:
if (ds_next_domain()) { xlog(.....); if (!t_relay()) { xlog(.....); return; } return; } else { t_reply("503"); }
Then I've updated to 3.1.3 and was happy enough until I've discovered that my failover is not working anymore.
What is observed:
- It changes $rd variable, but not changing $du variable, is it ok?
- Not any of the nodes receive packet on t_relay after ds_next_domain().
- In route decision section, where t_on_reply() and t_on_failure() are
located I have the same t_relay() and it works fine, cause there is no any ds_next_domains().
Is it a bug or I'm doing something wrong?
Thanks in advance.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users