Subject: RE: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions

From: "Nasir Khan" <[email-masked]>
Date: Mon, 4 Jul 2005 15:02:08 -0700

Rohan,

My question was motivated by practical considerations, but perhaps I
could not articulate it properly, my mistake. 

Yes. The UA will most certainly be rebooted, lose connectivity, upgraded
etc. By "infinite subscription" I meant the service that needs the UA to
always be subscribed (so if subscription ends by any reason, it will
have to re-subscribe). The few examples I stated in previous mail using
Presence Event package, Registration event package and SIP UA Profile
package need the UA to be constantly subscribed for those events.
(again, if subscription ends then refresh it etc.).  

I may be venturing into implementation details here (which may vary) but
I presume that most of the implementations consider dialogs to be
"active" objects and hence memory-resident for most part. 
So considering the fact that the subscriptions in examples above last as
long as the user is availing the service from the service provider and
there is very little notification traffic and that too triggered by
external stimulus in most part, I was suggesting to think about means
for dialog-less notifications, thus allowing for simpler
implementations. 

Thanks

Nasir Khan
BEA Systems, Inc.

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Sunday, July 03, 2005 9:15 AM
To: Nasir Khan
Cc: [email-masked]
Subject: Re: [Sip] RE: Stateless Notification and Non-Subscribe
subscriptions

Nasir,

There is no such thing in the real world of software as an infinite
subscription.  Sometime in the next 5, 10, or 20 years your user agent
will be unplugged, recycled, rebooted, reprogrammed, renumbered or
*something* will happen to it, and unless there is a state recovery
mechanism your notifier will leak memory like a sieve.  For most UAs
it is far more likely for the UA to change IP addresses and therefore
change its Contact address once a week or once a month.

Clearly you need to keep the target URI, an expiration time, and some
indicator of the "version" you are sending so the "subscriber" can
detect stale state.  PUBLISH uses an ETag for this and you can use the
CSeq in a SUB/NOT dialog.

The only additional piece of state left is a Call-ID and two tags
(which I only need for SUB/NOT).  I don't see any convincing analysis
that the Call-ID and tags create such a problem in a real
implementation that actually works (i.e. that is already storing an
expiration time and "version").

It is easy to remove state when you ignore the messy changes that
happen in the real world, but if things didn't change, we wouldn't
have jobs or interesting problems to work on.

thanks,
-rohan

On 7/1/05, Nasir Khan <[email-masked]> wrote:
> 
> Though I do not have a solution, I think that this is a problem which
> will become evident when more and more uses for SIP notification
> mechanism come to the fore.
> Arguably there will be cases where the use does not even warrant a SIP
> Notification event package.
> 
> The vexing problem is the case where the subscriptions have an
infinite
> life as in a few examples below.
> 
> - "Send me a notification with update to my UA when my user profile
> changes" (*which may happen once in months*) {SIP UA Profile
framework}
> - "Send me a notification when my buddy is in the vicinity of 2 miles"
> (*which may not happen in days*) {Presence event package}
> - "Send me notification when the administrator changes my registration
> state. (*which may not happen that frequently*) {Registration event
> package}
> 
> Etc.
> The state that is to be notified in such cases is typically resident
in
> a database (or some other persistent store), this data is being
modified
> by different agents, so in above three examples the agents could be
> (a) User changing his own profile going through the self admin website
> (b) Presence Server
> (c) Registrar Administrator
> All this state has nothing to do with dialog semantics, but will
result
> in unending subscriptions.
> 
> IMHO the "poor man's dialog" is not a bad tradeoff when you have to
> maintain these infinitely long subscription dialogs just because a
> notification may be generated once in a while. I was trying to think
of
> a Subscription Server(like a Registrar) with a Subscription data store
> (like an abstract location service) and taking the argument further
that
> Subscription having the capability of sending *out of dialog* NOTIFY
> (which is not the same thing as unsolicited NOTIFY when the UA is
> *expecting* such NOTIFIES).
> 
> 
> Thanks
> Nasir Khan
> BEA Systems, Inc.
> 
> 
> 
> 
> >I will second Dale. I think of REGISTER as creating a sort of "poor
> man's >dialog". Were we to start over I don't think you would see
> REGISTER again >in its current form, but it is grandfathered in now.
> >
> >Also, the way register works is based on the assumtion that REGISTER
> >messages will not be forked to different candidate registrars. If
that
> did >happen, then register refreshing would not work right. You can't
> make the >same assumption about subscriptions, so you need to retain
the
> route to the >server in order to properly refresh.
> >
> >I've been having other discussions with people about "implicit
> >subscription" or "unsolicited notification". These are all driven by
> the >same desire to get rid of some state or the messages that
establish
> it. For >instance lots of people want to avoid the subscription for
MWI.
> >
> >But as yet nobody has proposed a viable way to do it. Stuff has been
> >implemented to do this, but the cases I am aware of are hacks with
> major >limitations.
> >
> >I don't think a solution that requires "some" dyanmic state, but less
> that >a dialog, is an interesting solution.
> >
> >The most interesting case where I think it might be possible to come
up
> >with a solution is when the notifier knows a priori that it wants to
> notify >all registered contacts for its own AoR. In that case the
> notifier has >statically provisioned state about its own AoR and the
> need to notify that, >but no dynamic state. (The MWI is an example of
> this case.) But I haven't >yet found a good solution for even this
case.
> >
> >       Paul
> >
> >
> >Dale Worley wrote:
> >
> >From: Nasir Khan
> >
> >
> >By stateless notification I mean an entity subscribed to
> >certain events
> >gets the notifications when the event is generated *without* having
to
> >maintain any dialog state.
> >
> >
> >
> >This seems very difficult to do.  A publisher needs to keep a list of
> all
> >the subscribers to which it will send notifications.  And since the
> >publisher needs to be able to forget a subscription if it is not
> refreshed
> >after a while, the subscribers need to remember to refresh their
> >subscriptions.  Both of these require state.
> >
> >
> >The PUBLISH method avoids these problems, but in effect, by
> provisioning the
> >list of subscribers rather than constructing it dynamically.
> >
> >
> >Dale
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Avshalom Houri <[email-masked]>
Date: Tue, 5 Jul 2005 07:41:43 +0300

If the subscription will be for a contact
then I do not see any point in this.

It becomes more an implementation detail
and the server can off-load non-active

subscription to a database and release
memory.

I think that if do this it should be
a subscription for an AOR and the server

should notify the user in any possible
means it has. This way the user will be

notified even if the device that did
the subscription is not connected.

Anyway, I am still not sure we need
this type of subscription as it can be

achieve by other means as web interface.

Avshalom

"Nasir Khan"
<[email-masked]>

Sent by: [email-masked]

05/07/2005 01:02 AM

To

"Rohan Mahy" <[email-masked]>

cc

[email-masked]

Subject

RE: [Sip] RE: Stateless Notification
and Non-Subscribe subscriptions

Rohan,

etc. By "infinite subscription" I meant the service that needs
the UA to

implementations.

Thanks

Nasir Khan

BEA Systems, Inc.

-----Original Message-----

To: Nasir Khan

Cc: [email-masked]

subscriptions

Nasir,

indicator of the "version" you are sending so the "subscriber"
can

detect stale state.  PUBLISH uses an ETag for this and you can use
the

thanks,

-rohan

On 7/1/05, Nasir Khan <[email-masked]> wrote:

infinite

framework}

in

modified

result

of

that

that

the

establish

MWI.

up

case.

to