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
