Subject: Re: [Simple] PS = back-to-back PA + registrar?

From: "Li Hua Tang" <[email-masked]>
Date: Thu, 21 Feb 2002 17:23:27 +0800

Sorry for my slow response. I just come back from vacation.

                    Jonathan                                                                   
                    Rosenberg             To:     Li Hua Tang/China/IBM@IBMCN                  
                    <jdrosen@dynami       cc:     [email-masked], Hong         
                    csoft.com>             Cai/China/IBM@IBMCN, Wei BJ Lu/China/IBM@IBMCN      
                                          Subject:     Re: [Simple] PS = back-to-back PA +     
                    2002-02-12             registrar?                                          
                    05:06                                                                      

>Li Hua Tang wrote:
>
> Hi all,
>
> It's generally accepted that a PS is a combined PA/Proxy/Registrar.
> During
> our work we find that it's difficult for PS to change the role from
> proxy
> to PA or otherwise, when the presentity changes status from online to
> offline or otherwise. (In our understanding, PS acts as a proxy if the
> presentity is online and acts as a PA when the presentity goes offline.)

>It should work. Can you identify specific problems?

Yes, you are right. It can work. According to the latest version of
draft-itef-sip-events-03, we find how the PS can notify the watcher to
generate a new subscription when a presentity change status from offline to
online (using header "Subscription-State" and reason code). A new SUBSCRIBE
request is received, so the PS can change the role from PA to proxy. That's
what once troubled us.

There is still a problem we are not satisfied. In normal conditions, or if
the requests are always record-routing, all is ok. What we are concerned is
what would PS do if the presentity crashes. PS as a proxy (which doesn't
maintain transactions) can't initiate NOTIFY request to the watcher to make
it know that the presentity is now not available. Only when the watcher
sends out refreshing SUBSCRIBE (directly to the presentity, like re-INVITE)
and gets no response (or 481 response if the presentity comes online again
during this period), the watcher can know the change. So the watcher may
generate a new subscription and PS can handle it again. It's a very passive
way.

If a Proxy+PA+Registrar model is taken, a new SUBSCRIBE request is the only
trigger for PS to change role between proxy and PA. The key problem is
whether, when and how the watcher sends this new subscription.
>
> Maybe a back-to-back PA + registrar is a better combination. It can hide
> the complexity for PS to handle the subscriptions. Assume once the
> presentity comes online, it registers to the PS, with or without the
> presence documents or CPL. PS generates a subscription to this
> registered
> presentity (not considering the third party registration) and gets
> presence
> info from the notification created by the presentity. All the presence
> info
> are stored in the backstage database and updated with the notifications.
> When a watcher invokes a subscription to the PS, the PS can access to
> this
> database to get current presence info of the specific presentity. It's a
> simple model. The PS is an end presentity to any watcher and also an end
> watcher for any presentity. It can low down the number of transactions
> exsiting in the PS.
> Another advantage of this model is that through this way the PS can
> provide
> flexible features to higher application level. For example, all the
> presence info are available from the PS.

>This is certainly a valid model. It has been discussed on the list, and
>is certainly allowed. The specification does not mandate implementation
>architectures, it merely provides tools. I don't think there is anything
>in the spec that would prevent this from working adequately well. Maybe
>just a mention encouraging user agents to support it....

> A question puzzles me in this condition. If a subscription with
> buddylist
> event package is received, the PS handles it acting as a PA, not a BLSS.
> Is
> it reasonable?

>A BLSS is a type of PA; its one that handles that particular event
>package.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Feb 2002 13:46:30 -0500

inline.

Li Hua Tang wrote:

> generate a new subscription and PS can handle it again. It's a very

Correct. This is an inherent limitation of the end-system based
notification model. There will be a delay, equal to the refresh interval
of SUBSCRIBE, to detect the failure of a PA. If a network server is used
(and made reliable itself, through state replication or whatever means
are needed), the watcher can be notified of the change as quickly as the
PA can know. That depends on the subscription refresh interval.

-Jonathan R.