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