Bogdan, I'm really not sure where that garbage is coming from. It almost seems like some weird artifact from printing to syslog.. I had it print out the length, and I see lines like this:
pinging contact: sip:208.xx.xxx.130:7538??z len: 23 "sip:208.xx.xxx.130:7538" is 23 characters long, so the '??z' shouldn't be printed... -- James On Fri, Jul 8, 2011 at 6:12 PM, James Lamanna <jlama...@gmail.com> wrote: > 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 <bog...@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@192.168.1.117:7945 Q= >> Expires:: 1401 >> Callid:: c3bfd2f5-50aff633@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 <bog...@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@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" > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users