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.
Hello,
to understand the scenario: - first branch has destination uri ($du) set - it failed and gets to failure route where you call ds_next_domain() and $du s still the one from first branch?
What do you mean that "not any of the nodes receive the packet ..."?
Cheers. Daniel
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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.
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.
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@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
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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..@.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.
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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:
- Call 1 is coming
- Routed to GW 1
- Call 2 is coming
- Routed to GW 2
- 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
On Mon, 2011-06-13 at 12:12 +0200, Daniel-Constantin Mierla wrote:
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:
- Call 1 is coming
- Routed to GW 1
- Call 2 is coming
- Routed to GW 2
- 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.
Changed to ds_next_dst() and it worked. The one thing, which confused me is that this was working before 3.1 in 3.0 version.
Thanks for detailed explanation. Now I've got it.
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().
I guess mention of this will be welcome in docs. Cause I've got my working example somewhere from Internet. I guess kamailio beginners may do the same and it will not work without any visible reason.
Cheers, Daniel
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?
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:
- Call 1 is coming
- Routed to GW 1
- Call 2 is coming
- Routed to GW 2
- 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
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:
- Call 1 is coming
- Routed to GW 1
- Call 2 is coming
- Routed to GW 2
- 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
On Wed, 2011-06-15 at 09:47 +0200, Daniel-Constantin Mierla wrote:
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
It's done on the branch route, however it seems that branch route is not being executed when the failure branch route is being ran. Anyhow, when the call is not passing through failure route and ds_next_dst() it is fine, no errors. When it goes there, error with rtp proxy in logs and no audio. When I add force_rtp_proxy() on success of t_relay() in failure route it gives no errors, but still no audio.
I do not know where issue is related, and what is wrong, especially when this scenario worked before.
Just to avoid misunderstanding, providing you a failure and a normal branches of the script. Failure route:
if (is_method("INVITE") && (isbflagset("6") || isflagset(5))) { unforce_rtp_proxy(); }
... ( checks for different errors and messages output is skipped, not related to this issue anyway )
if( ds_next_dst() ) { xlog( "L_NOTICE", "[$Tf] $ci Next gateway $fU -> $tU via $du\n" ); if( !t_relay() ) { xlog( "L_INFO", "[$Tf] $ci -- ERROR - Can not t_relay()\n" ); return; }; return; } else { xlog( "L_INFO", "[$Tf] $ci No more routes available \n" ); t_reply("503", "Service unavailable -- no more gateways" ); exit; };
And success route completely:
if ((isflagset(5) || isbflagset("6")) && status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } if (isbflagset("6")) { fix_nated_contact(); }
Thank you.
On 6/15/11 10:50 AM, Evgeniy Spinov wrote:
On Wed, 2011-06-15 at 09:47 +0200, Daniel-Constantin Mierla wrote:
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
It's done on the branch route, however it seems that branch route is not being executed when the failure branch route is being ran.
do t_on_branch() in failure route as well.
Cheers, Daniel
Anyhow, when the call is not passing through failure route and ds_next_dst() it is fine, no errors. When it goes there, error with rtp proxy in logs and no audio. When I add force_rtp_proxy() on success of t_relay() in failure route it gives no errors, but still no audio.
I do not know where issue is related, and what is wrong, especially when this scenario worked before.
Just to avoid misunderstanding, providing you a failure and a normal branches of the script. Failure route:
if (is_method("INVITE") && (isbflagset("6") || isflagset(5))) { unforce_rtp_proxy(); }... ( checks for different errors and messages output is skipped, not related to this issue anyway )
if( ds_next_dst() ) { xlog( "L_NOTICE", "[$Tf] $ci Next gateway $fU -> $tU via$du\n" ); if( !t_relay() ) { xlog( "L_INFO", "[$Tf] $ci -- ERROR - Can not t_relay()\n" ); return; }; return; } else { xlog( "L_INFO", "[$Tf] $ci No more routes available \n" ); t_reply("503", "Service unavailable -- no more gateways" ); exit; };
And success route completely:
if ((isflagset(5) || isbflagset("6"))&& status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } if (isbflagset("6")) { fix_nated_contact(); }Thank you.
On Thu, 2011-06-16 at 12:06 +0200, Daniel-Constantin Mierla wrote:
On 6/15/11 10:50 AM, Evgeniy Spinov wrote:
On Wed, 2011-06-15 at 09:47 +0200, Daniel-Constantin Mierla wrote:
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
It's done on the branch route, however it seems that branch route is not being executed when the failure branch route is being ran.
do t_on_branch() in failure route as well.
Tried that - nothing changes. Getting "incorrect port 0 in reply from rtpproxy" and no audio.
Cheers, Daniel
Anyhow, when the call is not passing through failure route and ds_next_dst() it is fine, no errors. When it goes there, error with rtp proxy in logs and no audio. When I add force_rtp_proxy() on success of t_relay() in failure route it gives no errors, but still no audio.
I do not know where issue is related, and what is wrong, especially when this scenario worked before.
Just to avoid misunderstanding, providing you a failure and a normal branches of the script. Failure route:
if (is_method("INVITE") && (isbflagset("6") || isflagset(5))) { unforce_rtp_proxy(); }... ( checks for different errors and messages output is skipped, not related to this issue anyway )
if( ds_next_dst() ) { xlog( "L_NOTICE", "[$Tf] $ci Next gateway $fU -> $tU via$du\n" ); if( !t_relay() ) { xlog( "L_INFO", "[$Tf] $ci -- ERROR - Can not t_relay()\n" ); return; }; return; } else { xlog( "L_INFO", "[$Tf] $ci No more routes available \n" ); t_reply("503", "Service unavailable -- no more gateways" ); exit; };
And success route completely:
if ((isflagset(5) || isbflagset("6"))&& status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } if (isbflagset("6")) { fix_nated_contact(); }Thank you.
-
Daniel-Constantin Mierla -
Evgeniy Spinov -
Spinov Evgeniy