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

[Paul Kyzivat <[e-mail]>]

Dean Willis wrote:
> Dale Worley wrote:
> 
>> But how to maintain the state that user foo@bar wants notification of 
>> X?  In
>> practice this is often done by provisioning (foo goes to a web page to
>> update his list of notifications), because the overhead cost of having an
>> obsolete notification request in the database is small.  But we might 
>> want
>> to use some variant of SUBSCRIBE to maintain notifications.
>>  
>>
> I'd like to counter-propose a "subscription aggregator" -- that is, 
> allow a single SUBSCRIBE request to establish a dialog upon which 
> notifications for multiple event
> sources might occur.

Whether this is useful depends on your goals. THis is a little like an 
RLS on steroids. Like an RLS, it does not in general reduce the total 
amount of work done in the system as a whole - instead it moves the 
place where some of the work is done and also somewhat increases the 
total amount of work done.

It reduces the amount of work that must be done by the watchers. It does 
nothing to the amount of work that must be done by the notifiers. And it 
increases the amount of work that must be done by the "subscription 
aggregator". (From nothing to somewhat more than the total of what would 
otherwise have been done by the watchers.)

But I think one of the goals here is to reduce the load on the servers.

> One might then define a metapackage that includes, for example, 
> subscription to reg-event, mwi, config, presence resource-list, and all 
> the other things that a UA might subscribe to on startup.

I thing this would require defining a new event type 
('multiple-events'?), together with the content type used by it. The 
content type would have to be able to embed the notification content for 
any of the aggregated event types.  Not rocket science - definitely 
could be done.

> Jonathan has proposed making REGISTER create a dialog for the servicing 
> of subscriptions. I think an aggregator would be much cleaner.

I agree it is "cleaner" in the sense that it doesn't change the 
semantics of anything currently existing. But we will have to agree on 
what our goals are before we can decide what is "better".

	Paul

> Now, as o how it might work -- the set of subscriptions to be aggregated 
> should be defined dynamically. One idea would be to use the body of the 
> SUBSCRIBE request to contain a URI list, with each such URI representing 
> a resource to be SUBSCRIBEd to. This approach is consistent with the URI 
> list work:
> see 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-subscribe-03.txt 
> 
> 
> Another approach would be to use a server-contained list that would be 
> modified using XCAP. This is closer to the orignal resource-list work.
> 
> -- 
> Dean
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip