[OpenSIPS-Users] Inbound call failures from Verizon VoIP servers

[Chris Stone]

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