Hi James,
thanks a lot for the feedback.
The log you added does not show anything wrong - the path fields may be
missing and the so called contact part (returned by usrloc) is either
the received URI (if present), either the contact URI (if not received URI).
What looks scary are the trailing chars for the URI....but the question
is if the bogus contact happens because it get bogus when returned by
usrloc (by get_all_mem_contacts) function or because the received URI
was bogusly saved in ursloc from the beginning via the
fix_nated_registered() function
Regards,
Bogdan
On 07/01/2011 05:58 PM, James Lamanna wrote:
Hi Bogdan,
Unfortunately I've found that it doesn't fix the entire problem.
I have a contact now that is online, that still isn't getting pinged
for some reason.
I think there's something subtle in get_all_mem_contacts in dlist.c.
I haven't tried to see if this problem still manifests itself if the
usrloc mode is DBONLY (its a production server).
But as an example, I have this contact online (from opensipsctl ul show):
AOR:: 22505
Contact:: sip:[email protected]:7945
<http://sip:[email protected]:7945> Q=
Expires:: 1401
Callid:: [email protected]
<mailto:[email protected]>
Cseq:: 63708
User-agent:: Linksys/SPA962-6.1.3(a)-000e08d21b47
Received:: sip:x.x.x.x.:1024
State:: CS_SYNC
Flags:: 0
Cflag:: 192
Socket:: udp:opensips.ip:5060
Methods:: 5183
I've added a print in nathelper.c:
@@ -3648,8 +3650,11 @@
continue;
}
}
-if (curi.proto != PROTO_UDP && curi.proto != PROTO_NONE)
+LM_INFO("pinging contact: %*s %*s\n", path.len, path.s, c.len, c.s);
+if (curi.proto != PROTO_UDP && curi.proto != PROTO_NONE) {
+LM_ERR("dumping contact: %*s %*s\n", path.len, path.s, c.len, c.s);
continue;
+}
if (curi.port_no == 0)
curi.port_no = SIP_PORT;
proto = curi.proto;
I see these prints for a while for this contact:
Jun 30 12:30:53 frontend1 /usr/local/sbin/opensips[7087]:
INFO:nathelper:nh_timer: pinging contact: (null)
sip:208.90.185.166:7945??z <http://208.90.185.166:7945??z>
And then it just stops.
Restarting Opensips doesn't bring it back either.
unfortunately I haven't had time to digest the code in dlist.c to
figure out what is actually going on in there with the 2 indices.
Thanks.
-- James
On Fri, Jul 1, 2011 at 7:29 AM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hi Andrew,
Thanks God for mentioning this - the initial report from James
missed me, and I was not aware of the bug and the fix - I just
fixed it right now on the SVN trunk and 1.6
Thanks and regards,
Bogdan
On 07/01/2011 06:45 AM, Andrew Pogrebennyk wrote:
James,
On 01.07.2011 06:42, James Lamanna wrote:
Hi,
I've noticed after a period of time, Nathelper will stop
sending pings to some contacts.
I've verified that the contact is still registered (it is
even in the location table) but the ping process appears
to skip some contacts for unknown reasons.
maybe see if this fixes the problem for you:
http://www.mail-archive.com/[email protected]/msg16200.html
?
Could someone please look into this? I have phones behind
NAT that stop being able to receive calls because
firewalls close down the UDP mapping
since this feature is not working properly.
--
Bogdan-Andrei Iancu
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
