Dear SIP implementors,

A question comes to my mind regarding the correct implementation of a Presence use-case. I would appreciate your feedback about the below description.

1. a user switches on a SIP device that incorporates Presence Source functionality.
2. the handset registers against a SIP network (e.g.: IMS)
3. the handset updates her Presence status (basic PIDF, status --> open) towards the Presence Server.

Let's assume that the Presence Server subscribes to the Reg. event package about the subscriber, so it knows when the user is registered or not.

Now, the question comes when the user gracefully switches off the device:

4. The handset sends a new PUBLISH message towards the Presence Server (basic PIDF, status --> closed)
5. The handset unREGISTERs from the SIP/IP Core

Is the correct message sequence 4 AND 5? Is 5 enough? The point is: if the handset knows that it is going to unregister, should it send a PUBLISH message first to politely inform the Presence Server?

On the other hand: if the Server becomes aware that the client unregistered in step 5 (due to the reg event package), isn't that enouh?
Is the Presence Server allowed to update the PIDF document implementing the logic "unregisterd from the SIP network --> unavailable for the service"?

I don't find any document that clearly specifies the correct behavior in such case, although section 4.3 in RFC3903 indicates that the Presence Source is responsible for refreshing previous publications...

Let us assume that the Presence Source device only implements step 5 but not step 4. In that case, when the Presence server sends a NOTIFY message towards subscribed watchers, could it send the corresponding PIDF document updating the <status><basic> element to "closed", even though the handset didn't explicitly implement step 4?

Your assistance will be more than welcome!

Thanks,

David

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to