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:[email protected]:5060,
to=sip:[email protected]: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:[email protected]:5060;transport=udp
May 25 14:01:01 ser01 /usr/local/sbin/opensips[10257]:
INFO:core:XS_OpenSIPS__Message_log: SIP To URI:
<sip:[email protected]: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:[email protected]:5060,
to=sip:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]: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:[email protected]:5060;user=phone> to
<sip:[email protected]:5060;user=phone> r-uri
<sip:[email protected]: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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
