[OpenSIPS-Users] Inbound call failures from Verizon VoIP servers
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Thu May 27 16:05:59 CEST 2010
Hi Chris,
I see the call from Verizon has a maddr param that points to your server
(I guess). Try removing the maddr param from RURI before handling the
call. I suspect the maddr triggers the loop.
Regards,
Bogdan
Chris Stone wrote:
> Starting early this morning, inbound calls from one our upstream
> providers started failing. We have all of out inbound calls routed
> through our opensips server as well as calls between our Asterisk
> servers. Been working great for the last couple of years, until now.
> Inbound calls from our other provider (Dash) work fine as well as
> calls between Asterisk servers and outbound calls through both Dash
> and Verizon.
>
> The error messages in the opensips server logs were that the messages
> from Verizon were too big. The relevant part of the opensips.cfg file
> we has was:
>
> route{
>
> if (!mf_process_maxfwd_header("10")) {
> xlog("L_ERR", " <$rm> from <$fu> to <$tu> r-uri <$ru> src_ip
> <$si> [483 - Too Many Hops]\n");
> sl_send_reply("483","Too Many Hops");
> exit;
> }
>
> if (msg:len >= 2048 ) {
> xlog("L_ERR", " <$rm> from <$fu> to <$tu> r-uri <$ru> src_ip
> <$si> [513 - Message is too big - greater than 2048 bytes]\n");
> sl_send_reply("513", "Message is too big - greater than 2048 bytes]");
> exit;
> };
> .....snip...
> }
>
> The packets from Verizon are between 1200 and 1300 bytes - well under
> the 2048 noted. Packets from Dash are usually just under 1k. Message
> seems deceiving...
>
> I changed the config to:
>
> route{
>
> if (!mf_process_maxfwd_header("32")) {
> xlog("L_ERR", " <$rm> from <$fu> to <$tu> r-uri <$ru> src_ip
> <$si> [483 - Too Many Hops]\n");
> sl_send_reply("483","Too Many Hops");
> exit;
> }
>
> if (msg:len > 16384 ) {
> xlog("L_ERR", " <$rm> from <$fu> to <$tu> r-uri <$ru> src_ip
> <$si> [413 - Message is too big - greater than 16384 bytes]\n");
> sl_send_reply("413", "Message is too big - greater than 16384 bytes]");
> exit;
> };
> .....snip...
> }
>
> Not we're getting a message of 'too many hops'. Upped the debug to 9
> (usually have it at 3) and really didn't see anything different.
>
> What I do see on a good call (from Dash) is:
>
> May 25 14:01:01 ser01 /usr/local/sbin/opensips[10257]:
> ORIGINAL-INVITE [method=INVITE,
> from=sip:+13035922947 at 208.94.157.10:5060,
> to=sip:17204441111 at 66.28.179.85:5060;transport=udp,
> src_ip=208.94.157.10]
> May 25 14:01:01 ser01 /usr/local/sbin/opensips[10257]:
> INFO:core:XS_OpenSIPS_log: Method is INVITE
> May 25 14:01:01 ser01 /usr/local/sbin/opensips[10257]:
> INFO:core:XS_OpenSIPS_log: RURI is
> sip:17204497115 at 66.28.179.85:5060;transport=udp
> May 25 14:01:01 ser01 /usr/local/sbin/opensips[10257]:
> INFO:core:XS_OpenSIPS__Message_log: SIP To URI:
> <sip:17204497115 at 66.28.179.85:5060>
> May 25 14:01:01 ser01 /usr/local/sbin/opensips[10257]:
> INFO:core:XS_OpenSIPS__Message_log: SQL STATEMENT: SELECT route_id
> FROM routes WHERE dest_number = '7204497115' AND enabled = 1
> May 25 14:01:01 ser01 /usr/local/sbin/opensips[10257]:
> INFO:core:XS_OpenSIPS__Message_log: SQL query says to send call for
> 7204497115 to route id 2
> May 25 14:01:01 ser01 /usr/local/sbin/opensips[10257]:
> [method=INVITE, from=sip:+13035922947 at 208.94.157.10:5060,
> to=sip:17204441111 at 66.28.179.85:5060;transport=udp,
> src_ip=208.94.157.10] => route(in to voip01)
>
> On a failed call (from Verizon), I see:
>
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10269]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10270]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10254]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10258]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10273]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10265]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10256]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10272]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10263]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10255]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10259]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10253]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10266]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10254]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10275]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10273]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10260]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10256]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10262]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10263]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10257]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10274]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10268]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10274]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10266]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10274]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10275]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10274]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10260]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10274]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10262]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10274]: new branch at
> sip:+13034770910 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10257]: incoming reply
> May 25 14:01:19 ser01 /usr/local/sbin/opensips[10274]: <INVITE> from
> <sip:+17208880000 at 199.173.94.152:5060;user=phone> to
> <sip:+13034771111 at 65.243.172.235:5060;user=phone> r-uri
> <sip:+13034771111 at ser.axint.net:5060;user=phone;transport=UDP;maddr=66.28.179.85>
> src_ip <66.28.179.85> [483 - Too Many Hops]
>
> Almost looks like things are going in a loop some how - and all of a
> sudden without any changes to our config script.
>
> Anybody seen this before and/or have any suggestions where to look now?
>
> Thanks!
>
>
> Chris
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
Bogdan-Andrei Iancu
www.voice-system.ro
More information about the Users
mailing list