[SR-Users] Kamailio dispatcher

[Daniel-Constantin Mierla]

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.

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.

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

Cheers,
Daniel

>
> Thank you.
>
> DCM>  Cheers.
> DCM>  Daniel
>
> DCM>  On 6/10/11 6:43 PM, Evgeniy Spinov wrote:
>>> Hello.
>>>
>>> I had a Kamailio version of 3.0.3 and during this time configured a
>>> failover with simple routine. In short like this:
>>>
>>> if (ds_next_domain()) {
>>>        xlog(.....);
>>>        if (!t_relay()) {
>>>                xlog(.....);
>>>                return;
>>>        }
>>>        return;
>>> } else {
>>>        t_reply("503");
>>> }
>>>
>>> Then I've updated to 3.1.3 and was happy enough until I've discovered
>>> that my failover is not working anymore.
>>>
>>> What is observed:
>>> - It changes $rd variable, but not changing $du variable, is it ok?
>>> - Not any of the nodes receive packet on t_relay after ds_next_domain().
>>> - In route decision section, where t_on_reply() and t_on_failure() are
>>> located I have the same t_relay() and it works fine, cause there is no
>>> any ds_next_domains().
>>>
>>> Is it a bug or I'm doing something wrong?
>>>
>>> Thanks in advance.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>
> --
> Best regards,
>   Spinov Evgeniy. Intalisan. Development team.
>
>   Phone:   +971  4 326-22-69     Skype:  karator
>   Mobile:  +971 55 774-04-87     ICQ:    136613603
>   Website: www.intalisan.com
>
>
> _______________________________________________
> 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