David,
I don't think there is a single right answer to all of your questions.
It depends highly on the details of how presence is being published by
the device and managed by the presence server. The following are some
considerations that impact this:
- is the device publishing presence status specific to this device,
or is it publishing info that might be pertinent to other
devices for this presentity?
- is the device using its own address as the contact when publishing,
or is it using the AOR as its contact?
- does the device *know* that that the presence server is subscribed
to the reg event package and making its own inference of open/closed
based on that?
- does the presence server compose reg event info with published info
in such a way that the reg event overrides earlier published info?
- does the act of unregistering a contact address mean it cannot be
reached directly?
If the device is using a gruu as its contact when publishing presence
then I suppose the presence server could attempt to use the reg event
subscription to determine when the gruu is no longer valid and alter the
presence accordingly. If gruus are not being used, then the server has
to make a judgment whether it believes the contacts it has been given
are only valid when registered. In some operating environments (e.g.
IMS) that is the case. In others it is not.
When in doubt I would be inclined to assume as little as possible - have
the presence stuff and the reg event stuff interact as little as possible.
Paul
David Viamonte wrote:
> 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
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
