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

From: "Nasir Khan" <[email-masked]>
Date: Sat, 9 Jul 2005 14:43:29 -0700

I think PUBLISH solves a lot of problems that I highlighted about long
lasting subscriptions with little notification traffic. 
In order to address the issue of installing such a subscription one
could argue for a new method like REGISTER (say SUBSCRIBE FOR PUBLISH)
that installs this dialog-less subscription at the NOTIFIER (which the
NOTIFIER may delegate to an abstract subscription store). The "SUBSCRIBE
for PUBLISH" may install that subscription for an AoR and when the event
is to be generated the NOTIFIER may send a PUBLISH using the regular SIP
routing mechanism (potentially looking up a location service or presence
information).
As Dale wrote below "SUBSCRIBE is optimized for the situation where
subscriptions are relatively short lived, and the state they receive
changes quite frequently." 
We need a mechanism that could be optimized for subscriptions that are
long lived and state changes very infrequently. 
So SUBSCRIBERS can have the option to use regular SUBSCRIBE or
"SUBSCRIBE for PUBLISH", the latter if correctly implemented may just
result in a subscription record at the NOTIFIER end and nothing more. 

Thanks

Nasir Khan
BEA Systems, Inc. 

Dale Worley wrote:
>>From: Aki Niemi [mailto:[email-masked]]
>>
>>I agree this is a major deficiency in the SIP events framework. It is
>>partly due to the fact that the SUBSCRIBE method is overloaded to do
>>initial subscriptions, refreshes, as well as fetches within dialogs.
>>Therefore, the notifier will always generate a NOTIFY upon
>>receiving a
>>SUBSCRIBE, even though the subscriber may already have that state and
>>thus doesn't actually need it.
> 
> 
> More exactly, SUBSCRIBE is optimized for the situation where
subscriptions
> are relatively short lived, and the state they receive changes quite
> frequently.  The "dialog state" event package is the sort of thing
SUBSCRIBE
> works well for.
> 
> 
>>I don't see much benefit in this. Simply changing the method from a
>>dialog creating one to a non-dialog-creating one doesn't solve the
>>actual problem of being able to maintain subscriptions with little (or
>>no) overhead.
> 
> 
> In terms of message traffic, replacing SUBSCRIBE with PUBLISH helps a
great
> deal.  Because SUBSCRIBE maintains a dialog, every time the UA's
address
> changes, it has to refresh the subscription.  With PUBLISH, those
overhead
> messages are eliminated, at the cost of increased routing effort for
every
> notification.

Agree.

> In the end, there's no way to maintain a subscription without
maintaining a
> record that the subscription exists.  The protocol question is how to
> minimize the number of overhead messages.

There is also the issue of minimizing the *amount* of state. For a 
server that already operates on behalf of a particular set of AORs, the 
subscription state can be as small as one bit (publish to the AOR or 
not), up to complete dialog state plus subscription state:
- from tag, to tag, dialog id
- local and remote CSeq
- route set
- local and remote target URI
- event id
- event parameters
- subscription expiration timer
- subscription filters

_______________________________________________
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: Aki Niemi <[email-masked]>
Date: Sun, 10 Jul 2005 12:41:08 +0300

Inline.

> lasting subscriptions with little notification traffic. 

Let's not get stuck on method names here. Whether state is delivered 
using NOTIFY, PUBLISH, or INFO makes no difference here. PUBLISH doesn't 
solve your problems any more than INFO or MESSAGE does. Less, in fact, 
because in most cases PUBLISHes sent to the AoR already have a place to 
go, namely the compositor for that event package that in many cases is a 
network based server. So UAs or end user devices will actually never end 
up seeing those messages.

> routing mechanism (potentially looking up a location service or presence

Ok, so the requirement is to be able to subscribe using an AoR instead 
of a more volatile contact address. Perhaps a GRUU can solve this issue?

Another requirement I gather from this is to minimize the amount of 
state kept per subscription. Are you saying that the current amount, 
i.e., dialog state, is too much? How so? You're bound to have to store 
at least some state for these subscriptions, at a minimum the 
subscriber's address of record.

And no-where is it mandated that subscriptions, as they are currently 
specified, have to be stored in volatile memory. You are free to store 
the state wherever you want, including non-volatile storage or an 
"abstract subscription store". This is an implementation issue.

> changes quite frequently." 

Right, and we may have some work to do to make the long-lasting 
subscriptions work better. We already have such event packages as the 
certificate event, in which subscriptions are measured in days, instead 
of hours.

> result in a subscription record at the NOTIFIER end and nothing more. 

Right. So let's articulate the requirements and start working on 
improving on SIP events to solve them.

I don't see PUBLISH as a silver bullet here.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 11 Jul 2005 16:20:43 +0300

All,

I've submitted a new I-D that discusses in detail some of the issues 
that have also come up in this thread, as well as proposes some 
potential solutions. Until it appears in the archives, you can fetch a 
copy at:

http://people.nokia.net/~aki/drafts/draft-niemi-sipping-subnot-issues-00.txt

Also: please direct discussion of the draft over to SIPPING, as I think 
it belongs there more than in SIP.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jul 2005 09:36:13 -0400

> routing mechanism (potentially looking up a location service or presence

Subscribing using an AOR for a contact just creates new problems. There 
may be multiple contacts registered for that AOR, so a message (e.g. 
PUBLISH) addressed to the AOR may (or may not) be forked to all the 
registered contacts, and the forking may be serial or parallel. Once one 
fork succeeds there is no reason to believe an attempt will be made to 
deliver the message to the other contacts.

For instance, if you have two phones registered for the same AOR, and a 
MWI status was PUBLISHed to the AOR, it might just get to one of the phones.

For this technique to be useful, we need a way to ensure that all valid 
candidate contacts are attempted. Its especially tricky if you want to 
ensure delivery to all contacts, or have the sender learn of the failures.

There could still be a solution down this path. But it will require a 
bunch of work.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jul 2005 10:07:39 -0400

>    In certain conditions, the overhead induced by having to maintain
>    subscriptions becomes prohibitively high for subscribers. 

Not just subscribers. Notifiers too.

I find it interesting to see what you chose to include and omit as 
requirements. My reaction is that I think there need to be more 
requirements. That may mean that there will need to be a range of 
different behaviors in order to satisfy everyone.

In general I would characterize what I hear as a desire to minimize some 
metric over the system that includes the "subscribers", "publishers", 
and any intermediaries. The optimization may include some or all of the 
elements in the system. (E.g. state storage in subscribers may not be 
important.)

The following are a couple that I have heard expressed one way or another:

- "subscriber" doesn't want to subscribe at all, or maintain any
   subscription state. Would rather just handle "notifications"
   as context free events. Expects notifications to be delivered to
   it as result of external configuration that it has no involvement
   with.

- "notifier" doesn't want to maintain any state about those interested
   it. It prefers to just "publish" interesting info about itself to
   one place. (Note that this can be achieved by publishing to an
   event state agent which carries the rest of the load.)

	Paul