On Mon, 2011-06-13 at 12:12 +0200, Daniel-Constantin Mierla wrote: > > 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: > > 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. > 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. Changed to ds_next_dst() and it worked. The one thing, which confused me is that this was working before 3.1 in 3.0 version. Thanks for detailed explanation. Now I've got it. > > >> 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(). I guess mention of this will be welcome in docs. Cause I've got my working example somewhere from Internet. I guess kamailio beginners may do the same and it will not work without any visible reason. > > Cheers, > Daniel > > > _______________________________________________ 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