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
register.
Post the files on some external server, please do not attache to the email.
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 6:33 PM, Rob Dyck wrote:
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 the next interval. But what
actually seems to be happening the presentity is deleted before the phone
reregisters. When the phone registers a new presentity is created because
there is no presentity to refresh.
On Wednesday, October 6, 2021 11:52:02 P.M. PDT Bogdan-Andrei Iancu wrote:
So the contact is registered for 600 seconds and the it looks like PUA
is storing the presentity also for ~600 secs. So they are in sync when
comes to the expiration, right ?
If so, for this example, after how many seconds do you see the logs
telling you that the presentity (from pua) was deleted ?
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/6/21 6:52 PM, Rob Dyck wrote:
pres_phtable_list doesn't give us the expiry unfortunately.
example --
{
"pres_uri": "sip:[email protected]",
"event": 1,
"etag_count": 1,
"etag": "a.1633479391.910806.347.0"
}
The debug messages give us a clue however.
ct 6 08:24:22 [910805] REGISTER Contact "No Name"
<sip:[email protected]:5061>;expires=600
Oct 6 08:24:22 [910805] DBG:pua_usrloc:pua_set_publish: set send publish
Shortly after we get --
Oct 6 08:25:22 [910807] DBG:pua:print_ua_pres: p=[0x7faef2bb9560]
pres_uri=[sip:[email protected]]
Oct 6 08:25:22 [910807] DBG:pua:print_ua_pres:
etag=[a.1633479391.910806.347.0] id=[[email protected]]
Oct 6 08:25:22 [910807] DBG:pua:print_ua_pres: flag=[1] event=[1]
Oct 6 08:25:22 [910807] DBG:pua:print_ua_pres: countdown=[541]
expires=[1633534463] desired_expires=[1633534462
countdown=[541] this seems reasonable given that this was 60 seconds
after the register.
On Tuesday, October 5, 2021 11:43:37 P.M. PDT Bogdan-Andrei Iancu wrote:
Hi Rob,
After the device gets registered for the first time (and before
expiring), if you do a "opensips-cli -x mi pres_phtable_list", do you
see the expiring matching the value from the "opensips-cli -x mi
ul_dump" ?
Best 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/4/21 6:57 PM, Rob Dyck wrote:
Context opensips-3.2.2
I am trying out module pua_usrloc. I think that it is expiring
presentities
while the phone's registration is still valid. Then the phone
re-registers
and the presentity has to be recreated. This creates too much
churn which
could be avoided.
See attached time line.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
