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

[James Lamanna]

Hi Bogdan,
I've been monitoring it (I wrote myself a script that checks the AORs
in memory against syslog).
I haven't seen any issues lately.
The trailing garbage is weird as well. In the DB, the contacts look ok.
I haven't tracked down where that is coming from yet.

-- James

On Fri, Jul 8, 2011 at 8:42 AM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
> 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 Q=
> Expires:: 1401
> Callid:: 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
>
> 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>
> 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
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS eBootcamp - 2nd of May 2011
> OpenSIPS solutions and "know-how"