[SR-Users] Kamailio dispatcher

[Daniel-Constantin Mierla]

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.

>> 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().

Cheers,
Daniel



-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda