[SIP Beyond VoIP] Permanent presence State Usage
ag at ag-projects.com
Thu Jan 10 14:03:58 CET 2013
An XCAP client only can push an XCAP document using XCAP protocol. In this case it will push pidf-manipulation containing presence information, this information is persistently stored in the XCAP server once uploaded and is available to the Presence Agent serving the user that published the document.
A SIP client can Publish presence information using SIP protocol and as long as it publishes something and is refreshing it, the Presence Agent that aggregates all presence information in behalf of the same user should discard any pidf-manipulation stored by the corresponded XCAP client of the same user. That pidf-manipulation is meant to be used only when no active SIP client publishes.
This was already pretty clear in the standards, I am just rephrased it.
Nobody stops you to only push pidf-manipulation, but not knowing how many clients publish and how the presence agent behaves you are simply gambling for how things will behave outside of your client.
On Jan 10, 2013, at 1:32 PM, pres ruless wrote:
> I had an initial investigation about permanent presence state.
> According to RCS 5.1 spec clients can send PUBLISH SIP messages for service capability and pidf-manipulation for presence publication.
> When i searched the permanent presence state RFC its main aim seems to set presence information once a user does not have o active devices capable of publishing availability. Examples related to permanent presence state directed me to think that this is a one of the options that client may choose.
> Here is the question ? Does an XCAP client both use SIP PUBLISH and pidf-manipulation document for publishing presence state or it must only use pidf-manipulation document?
> Please let me know your approach/understanding and give a light to my way.
> Thanks in advance...
> SIPBeyondVoIP mailing list
> SIPBeyondVoIP at lists.ag-projects.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SIPBeyondVoIP