[OpenSIPS-Users] Nathelper ping does not consistently ping all contacts

[Bogdan-Andrei Iancu]

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:22505 at 192.168.1.117:7945 
> <http://sip:22505@192.168.1.117:7945> Q=
> Expires:: 1401
> Callid:: c3bfd2f5-50aff633 at 192.168.1.117 
> <mailto:c3bfd2f5-50aff633 at 192.168.1.117>
> 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 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> 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/users@lists.opensips.org/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
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


-- 
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110708/5e829c46/attachment-0001.htm>