Subject: [SIP] Re: Two New Drafts

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:12 +0530

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.

[email-masked] wrote:
>
> 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.

--
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

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip