[SR-Users] Kamailio dispatcher

Wed Jun 15 09:47:09 CEST 2011


On 6/14/11 1:06 PM, Evgeniy Spinov wrote:
> On Mon, 2011-06-13 at 12:12 +0200, Daniel-Constantin Mierla wrote:
>
> Ok, still unsolved problem.
>
> I've changed failover part of the script to use ds_next_dst(). It does
> what it should and signalization works fine - calls are being connected.
> However I've got no audio and message in logs:
>
> 7(9917) ERROR: rtpproxy [rtpproxy.c:2211]: incorrect port 0 in reply
> from rtp proxy
>
> I've added force_rtp_proxy() after ds_next_dst() and message
> disappeared, however still no audio on the failover call.
>
> RTP Proxy runs on the same server and is fine for not failover calls.
> Success route script executes force_rtp_proxy() and fix_nated_contact()
> in curtain conditions and that's it.
>
> Am I missing something in my logic?
Try to do the rtpproxy thing in branch route -- anyhow this has nothing 
to with dispatcher.

Cheers,
Daniel

>
> Thank you.
>
>> 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
>>
>>
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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