13 Jun
2011
13 Jun
'11
1:12 p.m.
On 6/13/11 12:03 PM, Evgeniy Spinov wrote:
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..@.4..(...(.........UINVITE sip:*44@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@KAMAILIO_IP>
From: "2_101"<sip:2_101@KAMAILIO_IP>;tag=ustdc
Call-ID: yuwofwddoaqozwh(a)localhost.localdomain
CSeq: 527 INVITE
Contact:<sip:2_101@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
On Mon, 2011-06-13 at 10:49 +0200, Daniel-Constantin
Mierla wrote:
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.
Hello,
On 6/12/11 9:56 PM, Spinov Evgeniy wrote:
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. 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.
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.