[OpenSIPS-Users] EC2 and rapidly repeated invites
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Jun 17 12:16:22 CEST 2014
Hi Kurtis,
Removing the routeid value does not affect at all the rule matching
(routeid is not involved in the matching logic at all, it is something
to be used after the matching was done).
So, check the rules you have in DR (to be sure they serve your scope) -
also check the debug log of OpenSIPS to understand why the matching
fails (if still the case).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 17.06.2014 03:18, Kurtis Heimerl wrote:
> Hello!
>
> Here's the followup issue. Removing the routeid from the rule is
> causing opensips to return a 503 "No rules matching the URI" code to
> the Invite. It does not repeat the invite though, so this may be
> progress.
>
> Here's the cmd for adding the rule that I'm using:
>
> opensipsctl dr addrule 0 $MSISDN '' 1 '' 1 '' 'Route to testbox'
>
> Gateway 1 is defined correctly as:
> pgsql_query: /usr/bin/psql -A -q -t -P fieldsep='' -h localhost -U
> postgres opensips -c 'select * FROM dr_gateways ORDER BY gwid; '
> 611$SERVERNAME0TEST20test box
>
> So it seems routeid must be set in order to forward the message?
>
>
>
> On Sun, Jun 15, 2014 at 9:09 PM, Kurtis Heimerl <kheimerl at endaga.com
> <mailto:kheimerl at endaga.com>> wrote:
>
> Hi Bogdan,
>
> This was indeed the issue. I guess setting a routeid *and* a gw
> causes it to send out route in two different directions?
>
> Anyhow, thanks so much for the direction. I'm sure I'll come back
> with new issues.
>
>
> On Wed, Jun 11, 2014 at 10:48 PM, Bogdan-Andrei Iancu
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
> Hi Kurtis,
>
> Do you use any routeid in the rule definitions ? maybe that's
> the looping cause.....Be sure it is set to NULL.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 12.06.2014 03:14, Kurtis Heimerl wrote:
>> Thanks so much Bogdan, that line is super helpful.
>>
>> I can't yet figure out why it's looping though. Here's what
>> the log now shows:
>>
>> Jun 11 23:59:32 ip-172-31-27-53 /usr/sbin/opensips[5836]:
>> [Script Trace][line 149][me][route 4] -> (INVITE from IP,
>> ruri=sip:NAME at HOST)
>> Jun 11 23:59:32 ip-172-31-27-53 /usr/sbin/opensips[5836]:
>> [Script Trace][line 273][me][core if] -> (INVITE from IP,
>> ruri=sip:NAME at HOST)
>> Jun 11 23:59:32 ip-172-31-27-53 /usr/sbin/opensips[5836]:
>> [Script Trace][line 270][me][module do_routing] -> (INVITE
>> from IP, ruri=sip:NAME at HOST)
>> Jun 11 23:59:32 ip-172-31-27-53 /usr/sbin/opensips[5836]:
>> [Script Trace][line 273][me][core if] -> (INVITE from IP,
>> ruri=sip:NAME at HOST)
>> Jun 11 23:59:32 ip-172-31-27-53 /usr/sbin/opensips[5836]:
>> [Script Trace][line 270][me][module do_routing] -> (INVITE
>> from IP, ruri=sip:NAME at HOST)
>> ... (repeated dozens of times)
>> Jun 11 23:59:32 ip-172-31-27-53 /usr/sbin/opensips[5836]:
>> CRITICAL:core:eval_expr: too many expressions (101)
>> Jun 11 23:59:32 ip-172-31-27-53 /usr/sbin/opensips[5836]:
>> WARNING:core:do_action: error in expression (l=273)
>>
>> This seems to indicate an issue with my routing logic.
>> However, I can't see where I'm infinitely recursing. Here's
>> the dialplan:
>>
>> route{
>> script_trace( 1, "$rm from $si, ruri=$ru", "me");
>>
>> if (!mf_process_maxfwd_header("70")) {
>> sl_send_reply("483","Too Many Hops");
>> exit;
>> }
>>
>> #kurtis
>> if (is_method("INVITE")) {
>> setflag(1); # do accounting
>> route(4); # Call our dynamic route.
>> }
>>
>> if (has_totag()) {
>> ... (default from here)
>>
>> and my custom route 4, which i've tried to poke at to remove
>> the recursion, but failed.
>>
>> route[4] {
>> if (!do_routing("0")) {
>> send_reply("503", "No Rules matching the URI");
>> }
>> exit;
>>
>> # route(relay);
>> }
>>
>> Any guidance? I can't see how I'm causing it to recurse, but
>> I've done this in opensips before so I'm not surprised.
>>
>> Thanks for all of your help!
>>
>>
>>
>>
>> On Tue, Jun 10, 2014 at 6:08 AM, Bogdan-Andrei Iancu
>> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>> Hi Kurtis,
>>
>> On a first look, it seems your script doing doing a kind
>> of looping (maybe a recursive call of a route or so) - at
>> least this is what the log errors tell.
>>
>> You can try the script_trace() function to understand how
>> your script is executed:
>> http://www.opensips.org/Documentation/Script-CoreFunctions-1-11#toc42
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 09.06.2014 01:37, Kurtis Heimerl wrote:
>>> Hello mailing list,
>>>
>>> I've been working on setting up OpenSIPS on an EC2
>>> instance, routing traffic between nexmo and our gateway,
>>> a FS instance on a public IP. I was kindly directed to
>>> an earlier thread on OpenSIPs and EC2
>>> (http://lists.opensips.org/pipermail/users/2010-April/012393.html)
>>> but have come to an issue I think is unrelated.
>>>
>>> Here's the current architecture:
>>> Nexmo -> EC2 NAT -> OpenSIPs -> EC2 NAT -> FS
>>>
>>> I started with a walkthrough on the website
>>> (http://www.unixnews.net/2010/09/dynamic-routing-with-opensips.html)
>>> which roughly seems to be working. I've configured the
>>> gateway, the routes, and so on. When I call my Nexmo
>>> number, it successfully routes to FS and rings but, when
>>> answered, never connects, failing after 30 seconds. This
>>> is, as expected, the OK never reaching Nexmo and the RTP
>>> negotiation never starting. I started poking around in
>>> wireshark and ran into another issue: OpenSIPs is
>>> forwarding 9 invites in rapid succession (less than a
>>> second) rather than just the one it received! FS *seems*
>>> to handle this correctly (482 Request Merged) but it
>>> makes the SIP trace an enormous mess and completely
>>> unreadable.
>>>
>>> The opensips log is a mess, but isn't particularly useful:
>>> Jun 8 21:55:51 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]:
>>> ERROR:signaling:sig_send_reply_mod: failed to send reply
>>> with tm module
>>> Jun 8 21:55:51 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: ERROR:tm:add_uac: maximum
>>> number of branches exceeded
>>> Jun 8 21:55:51 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: ERROR:tm:t_forward_nonack:
>>> failure to add branches
>>> Jun 8 21:55:51 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: ERROR:tm:w_t_relay:
>>> t_forward_nonack failed
>>> Jun 8 21:55:51 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: ERROR:tm:_reply_light: failed
>>> to generate 500 reply when a final 500 was sent out
>>> Jun 8 21:55:51 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]:
>>> ERROR:signaling:sig_send_reply_mod: failed to send reply
>>> with tm module
>>> Jun 8 21:55:51 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: incoming reply
>>> Jun 8 21:55:51 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: incoming reply
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: CRITICAL:core:eval_expr: too
>>> many expressions (101)
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: WARNING:core:do_action: error
>>> in expression (l=272)
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: CRITICAL:core:eval_expr: too
>>> many expressions (101)
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: WARNING:core:do_action: error
>>> in expression (l=283)
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: CRITICAL:core:eval_expr: too
>>> many expressions (101)
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: WARNING:core:do_action: error
>>> in expression (l=285)
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18082]: new branch at
>>> sip:18178184971 at gadogado.banatao.berkeley.edu
>>> <mailto:sip%3A18178184971 at gadogado.banatao.berkeley.edu>
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18083]: message repeated 5 times: [
>>> incoming reply]
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18083]:
>>> CRITICAL:tm:t_should_relay_response: pick_branch failed
>>> (lowest==-1) for code 482
>>> Jun 8 21:56:55 ip-172-31-27-53
>>> /usr/sbin/opensips[18083]: incoming reply
>>>
>>> Does anyone have any idea what would cause OpenSIPs to
>>> forward an invite 9 times in less than a second? Fixing
>>> that should allow me to move onto figuring out why it's
>>> not forwarding the 200 OK back to Nexmo.
>>>
>>> Thanks!
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140617/06e1b841/attachment-0001.htm>
More information about the Users
mailing list