Subject: RE: [Simple] Hand over of subscriptions handling from server to P UA

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Feb 2001 11:54:13 -0500

Sorry for the delayed response... I just cannot keep up with email volumes
any longer.

>-----Original Message-----
>From: Nicolas Dramais [mailto:[email-masked]]
>Sent: Tuesday, February 06, 2001 4:38 AM
>To: SIMPLE LIST
>Subject: [Simple] Hand over of subscriptions handling from server to PUA
>
>
>  
>Just a question for my good understanding of the
draft-rosenberg-impp-presence-00.txt : 
>imagine the following scenario: 
>1)Principal A registers and uploads to his/her proxy/presence server a list
of pre-granted 
>watchers to his/her presentity's presence service. 
>2)A's registration expires. (A went off-line). 
>3)Principal B sends a SUBSCRIBE to sip:[email-masked] 
>proxyA knows that A is not currently registered and decides to act as A's
Presence Agent. 
>proxyA checks the list of pre-granted watchers for A and finds in it B's
sip uri. 
>B's subscription request is directly accepted by the server in the name of
A and a 
>subscription is instantiated at server level for a duration specified in
the header field 
>of the 200 OK response sent by the server to B. 
>4)Principal C sends a SUBSCRIBE to sip:[email-masked] 
>proxyA knows that A is not currently registered and decides to act as A's
Presence Agent. 
>proxyA checks the list of pre-granted watchers for A but doesn't find C's
sip uri. 
>C's subscription request is temporarily accepted (202 OK) and the
subscription request is 
>stored at server level as 'pending authorization' to be submitted (with a
QAUTH method) to 
>Principal A's approval as soon as A becomes available. 
>5)Principal A registers again and is available for communications. Via
his/her REGISTER 
>request, the server is signified that A is willing to handle SUBSCRIBE and
QAUTH methods 
>(along with INVITE and MESSAGE methods). 
>C's pending subscription request is submitted (with a QAUTH method) by the
server to 
>principal A and A approves it. 
>A's presentity sends a 200 OK directly to C and a subscription for C is
instantiated at PUA 
>level. 

This is the problem. It wouldn't do that. The QAUTH request is not from C to
A; its from the server to A. The response, therefore, goes only to the
server. So, at this point, both B and C's subscription to A are active AT
THE SERVER.

>At this current time, there are thus 2 subscriptions active for A's
presentity presence 
>service : 
>one granted for B and instantiated at server level and one granted for C
and instantiated 
>at PUA level. 

See above; they are both at the server. 

>Suppose principal A changes his/her communications status
(description="open" for INVITE 
>methods changes to description="inuse"). 
>Question: 
>Q1)Does the draft imply that A has to send two NOTIFY : one directly to C
(subscription 
>handled at PUA level) and one to proxyA which relays it to B (subscription
handled at 
>server level) ? 
>This statement implies thus that proxyA has to subscribe to principal A's
presentity 
>presence service. 

This inconsistency is resolved by my explanation above.

>Q2)Or is it so that when principal A becomes available again, a kind of
subscription 
>transfer mechanism has to take place between the server and A's PUA so that
A's PUA 
>repatriates all subscriptions instantiated at server level. 

The transfer of subscriptions happens during refresh. The best way to think
about it is as follows. At any time, the presence server can simply discard
the subscription completely, so that it knows nothing about it any longer.
Furthermore, the presence server can act as a proxy for a SUBSCRIBE request,
forwarding it to the user rather than terminating. The process of
"transferring" a subscription from the server to the PUA by the server
dropping its active subscription AND acting as a proxy at the instant a
subscription refresh message arrives.

In essence, the transfer of control is not a protocol issue, but rather an
implementation behavior that is possible because of the soft-state nature of
subscriptions, and because of the routing capabilities of SIP.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com