[OpenSER-Devel] [ openser-Bugs-1810097 ] [pua_usrloc] Don't create new PUBLISH if an old one exists

[SourceForge.net]

Bugs item #1810097, was opened at 2007-10-09 12:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1810097&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Iñaki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: [pua_usrloc] Don't create new PUBLISH if an old one exists

Initial Comment:
pua_usrloc has an issue with SIP devices that publish their state, since the PUBLISH is generated twice:

1) By the REGISTER by pua_usrloc module.
2) By the PUBLISH sent by the device.

If for example the user sets "Online" - "Away" status and after a while the device refreshes the REGISTER, then its state will just be "Online" (the state pua_usrloc generates). And there will be two presence entries in "presentity" table.

I suggest pua_usrloc to generate a PUBLISH that corresponds to current published status of the device, by looking for an entry in the "presentity" table. If it exists then pua_usrloc could replicate the existing PUBLISH, or maybe it could just update "
expires" and "received_time" fields.

An issue could appear when a presence supporting device starts:
- It generates a REGISTER and because there wasn't a "presentity" entry pua_usrloc will generate a PUBLISH.
- After some seconds device will send a PUBLISH so there will be two entries in "presentity".
- What about then in the next REGISTER? How will know pua_usrloc which entry must replicate?
Maybe pua_usrloc could include a tag in its PUBLISH and detect its own PUBLISH'es from device PUBLISH's.

Is it feasible? If there other way to avoid generating PUBLISH for devices supporting presence?

Regards.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1810097&group_id=139143