On 6/13/11 12:03 PM, Evgeniy Spinov wrote:
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:
- Call 1 is coming
- Routed to GW 1
- Call 2 is coming
- Routed to GW 2
- 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.
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.
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.
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