Subject: Re: Two New Drafts

From: [email-masked]
Date: Fri, 10 Mar 2000 14:23:26 +0530

Hi,
responses embedded and preceded by ARC>

>The draft does not mention what happens when multiple SUBSCRIBE requests
>arrive from the same user. In REGISTER,
>     they replace old ones if the SIP url is same and additive otherwise.
>However, in SUBSCRIBE, I think it would make sense to make it additive
>only, since the same SIP url can subscribe to multiple events using  diff.
>subscription messages. Is this correct ?

That sounds good, except possibly for the same "call leg". I think the
part that needs to be clarified is: if a user sends a SUBSCRIBE
which has the same Call-ID, From, and To as a previous request,
does it add events or override them?  I'm leaning towards overrriding
events, since there is no easy way to remove events otherwise. Note well
that this wouldn't apply to other subscriptions with different Call-IDs,
which would (of course) remain additive.

ARC> Somehow, I feel Call-ID and suscription should not be tied together.
This is primarily
ARC> because callid is generated by a terminal and a user has no control
over it.
ARC> However, a subscription is for a user, not a terminal. so if I
subscribe to a set of services
ARC> today, if I travel tomorrow, I want to walk into a Cyber Cafe, log in
using some applet based
ARC> sip client that will generate a different Call-ID from my old desktop
one an still be able to
ARC> access my old subscription list and add/del from it without having to
know the Call-Id - which
ARC> in many cases, I never get to see as a user.
ARC> but the moment the backend notifier works on Call-ID - then I would
never be able to 'Add' to
ARC> my list since Ill be using a different Call-ID in all probability,
neither will I be able to
ARC> somehow retrieve the old one, since match will never be true.
ARC> This is why I feel subscription should not be linked to a call - id.

(Incidentally, I like your example. I have recently had
discussions with several different groups of people who
wanted to know how one would go about, for example, having
a light blink on your phone and/or have a distinctive dial
tone when a message is waiting).

ARC> Well, we actually had exactly the above requirement once, and we did
it my adding
ARC> an Event like field with more or less the same semantics as we
discussed above.

>Event =  1#(eventid ; duration)
>event = token       // Does it need to be broken ?
>duration = deltaseconds | SIP-Date

I don't really like this. Beyond the problems with using
commas for separators *and* having commas appear in
the duration (if the SIP-Date format is used), I'm trying to
keep it as congruent as possible with REGISTER, since the
semantics for that are already well defined -- and code is
already written to handle it.  For the above situation, I'd
propose that you either: a) send all three REGISTER messages,
with different Call-IDs, in a single UDP packet, or b) send
a single REGISTER for all three events with an expires of 2
hours. At the end of the 2 hours, re-SUBSCRIBE for just B
and C (expires in one hour), and one hour later, re-SUBSCRIBE
for just C. (A variation on this theme would be to subscribe
for 4 hours, override it in 2, and then again one hour later;
I prefer this method, since it eliminates the chances of missing
events -- although it counts on the addition vs. replacement
semantics I describe above).

ARC> I assume where ever you mentioned REGISTER above , you meant SUBSCRIBE
ARC> Again, solution 1 is to me, a kind of loose workaround. And the other
solutions
ARC> force the client to maintain time differentiators actively since it
must physically
ARC> maniuplate subscriptions to implement the common requirement above.
Rather, The
ARC> Notifier is actually already implementing a timer list which can
notify users
ARC> based on differential time values maybe, so why force the client into
maintain the
ARC> differential list also ? To me it seems to be much cleaner for the
client to specify
ARC> it once, and forget about it, as the notifier server is there just to
remind him anyway
ARC> so why bog him down with keeping track of such requests ?
ARC> The only -ve point seems to be parsing for commas (which is a non
issue for good parsers)
ARC> - but if that really is a problem, maybe we could work at a simpler
expiry type ?
ARC> However, I dont feel parsing should be the reason to adopt the
alternate methods suggested
ARC> above. What do you/others feel abt it ?

I must have been somewhat unclear. I am not proposing that one
use REGISTER itself to cancel a subscription; merely that one
use the same *mechanism*, with a SUBSCRIBE method. For
example, let's say that I want to cancel the subscription(s)
above. I could do so by sending:

ARC> Sorry, I misinterpreted, then. Seems fine to me.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Mar 2000 23:29:24 -0500

I think we are once again jumping the gun a bit. There are some much
bigger issues to address with a generic sip subscription/notification
mechanism:

1. what entities are generating the notifications? It can be a UA, or it
could be a proxy or registrar.

2. What are the types of events we want to support subscriptions for? I
know Adam has tried to keep that the subject of future extensions.
Problem is, this issue has a strong impact on the addressing, event
description and scaling capabilities. I don't think we can leave this to
future extensions without having the "base" version have nothing but two
methods. That doesn't really help much. I think we can define reasonably
broad classes of events. Certainly we aren't interested in supporting
events like "let me know when the coffee machine is done".

3. To whom does one address a subscription? If we address it to a user,
what does that mean? Are we asking for a subscription to that users
registration state? 

Also, before we get to far with architecture and design issues, there is
the question about whether this concept, in general, is something the
working group is interested in pursuing.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com