OK, let's do this: do a complete test with the UAC registering and
re-registering after the first registration expires. And for this test
please provide:
1) the SIP pcap
2) complete debug (log level 4) logs from opensips
3) the out of the "ul_dump" and "pres_phtable_list" MI cmds after each
re
Hi Andrew,
OK, interesting progress here. So, the FIFO process blocks as it is
trying to send an IPC JOB to an UDP process which looks like also being
blocked.
Could you attach with GDB to the that UDP blocked process too ? (you
have its PID in the printing of the pt[x] in first gdb)
Regar
Interestingly, where I usually see a range of continued messages from
a process continually in the debug log, they appear to stop for this
PID at 3:47am, and that process seems blocked on a tcp/tls send:
Oct 8 03:47:39 hvprxy osips[2639896]: DBG:core:get_dummy_sip_msg:
reusing the static sip msg
Hi,
Procs had restarted; but repeated the exercise and it's pid 48 this time.
(gdb) bt full
#0 0x7f6fe6d48297 in __libc_write (fd=fd@entry=203,
buf=buf@entry=0x7ffed7680050, nbytes=nbytes@entry=24) at
../sysdeps/unix/sysv/linux/write.c:26
resultvar = 18446744073709551104
__ar
I am assuming , perhaps incorrectly that a phone that is continuously
registered should never have the presentity deleted. Is this how pua_usrloc is
supposed to work.
Hash_clean runs every 95 seconds. If ther countdown is less than 95 seconds
the presentity should be refreshed sometime during t
From the timeline that was attached previously
Oct 4 07:27:38 [674854] DBG:pua:print_ua_pres: p=[0x7f0e44f57308]
pres_uri=[sip:3...@bogus.com]
Oct 4 07:27:38 [674854] DBG:pua:print_ua_pres: etag=[a.
1633196620.366952.1663.0] id=[146183bd-a708bacf@192.168.1.5]
Oct 4 07:27:38 [674854] DBG:p
OK, getting closer :). Let's see who is the proc ID 46.
In GDB, just do
> p pt[46]
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
OpenSIPS eBootcamp 2021
https://opensips.org/training/OpenSIPS_eBootcamp_2021/
On 10/7/21 3:37 PM, Andrew Yage
