[SR-Users] Kamailio dispatcher

[Evgeniy Spinov]

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.


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

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