[SR-Users] Kamailio dispatcher

[Evgeniy Spinov]

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.. at .4..(...(.........UINVITE sip:*44 at 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 at KAMAILIO_IP>
> > From: "2_101"<sip:2_101 at KAMAILIO_IP>;tag=ustdc
> > Call-ID: yuwofwddoaqozwh at localhost.localdomain
> > CSeq: 527 INVITE
> > Contact:<sip:2_101 at 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
> 
> 
>