Subject: [SIP] Re: Two New Drafts

From: Manoj Bhatia <[email-masked]>
Date: Mon, 08 May 2000 17:26:11 -0400

Hi Jonathan

Can we at least draw some consensus on the 'Meesage Waiting Indication(MWI)'
event in Voice mail context ?

Further, in one of the threads on this list, Henning says that we must adopt
drafts/discussion on PINT to decide on MWI.

Also, there is some concern that whether SUBSCRIBE -  a new SIP method
should be used for sending subscription requests or is REGISTER a good way of
doing that ?

My concern is that very soon you may have interop problems with SUBSCRIBE/
REGISTER method being used by vendors in different ways .

Is SUBSCRIBE/NOTIFY the de facto way for MWI implementation ?

Is a voice mail server supposed to act as  a UA keeping track of dynamic
subscription requests all the time and updating its database on time
or should it depend on the proxy /registrar to take the burden of MWI
by using the Contact/Registration details of the UA ?

Comments welcome...

thanks
-manoj

Jonathan Rosenberg wrote:

> 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

--
Manoj Bhatia                           |        |         |
[email-masked]                       |       :|:       :|:
7025 Kit Creek Road, P.O. Box 14987    |     :|||||:   :|||||:
Research Triangle Park, NC 27709       |   .:|||||||:.:|||||||:.
919-392-3873      fax: 919-392-6801    |  C i s c o S y s t e m s

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 May 2000 18:40:56 -0400

> event in Voice mail context ?

I think there is a clear need for subscription and notification events
for many things, including message waiting indication. The question is
how to structure this in the most general way. I really don't want a
specific and separate spec just for MWI, as it seems to narrow.

> drafts/discussion on PINT to decide on MWI.

To me, what this means is that:

1. we use the SUBSCRIBE and NOTIFY methods
2. the body is used to define the object being subscribed to

> should be used for sending subscription requests or is REGISTER a good
> way of doing that ?

Definitely not REGISTER. Its semantics are completely different. It
updates a binding, in a server, of the address in the To with the
addresses in the Contact. I don't see at all how this accomplishes MWI.

> REGISTER method being used by vendors in different ways .

You should absolutely not be using REGISTER for this.

> Is SUBSCRIBE/NOTIFY the de facto way for MWI implementation ?

I think it is clearly the basis. The question, again, is how to do this
generally.

Some of the questions in my mind are:

1. how do we handle addressing? I.e., what is the entity that is being
subscribed to, in the request URI, for mwi? Is it even a SIP URL?

2. What is the format of the content in the body for mwi? Is there a
format which is more generic than just mwi?

3. What is the format of the content in notifications?

4. security issues - how do you prevent attacks whereby I subscribe to
some events, and list someone else in the Contact, say, to receive the
notifications?

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[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

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 10 May 2000 17:45:07 -0700

Jonathan,

I'm proposing some strawman answers to your questions below...

At 03:40 PM 5/10/00 , Jonathan Rosenberg wrote:
>...
> > Can we at least draw some consensus on the 'Message Waiting
> > Indication(MWI)'

What about an explicit UNSUBSCRIBE method (pint), vs. using SUBSCRIBE with 
an "Expires: 0" header(subscribe/notify draft)?

Why is a body strictly needed if you can express the symantics clearly in 
the Request-URI and an Event header?  for example:

         Event: mailbox-summary

>You should absolutely not be using REGISTER for this.

I wholeheartedly agree!

>subscribed to, in the request URI, for mwi? Is it even a SIP URL?

I could imagine any of the following:

sip:[email-masked]
sip:[email-masked]
sip:[email-masked]?Accept-Contact=*,feature=voice-mail
mailto:[email-masked]  (if my voicemail is stored on my email server)

In the first case, the event relates to a user who has a SIP presence.
In the next, the event relates to my account on my voicemail server.
In the third, the event relates to my "voice-mail" SIP feature.
In the fourth, the event relates to my mail account.

I think that generically this could be left to implementation, but that the 
WG should provide guidelines.  Recommended SIP URI naming conventions in 
general are still pretty undefined.

>format which is more generic than just mwi?

Generically, I think we want "message summary" information.

Alternatively, we may want to know only that there are new messages or not 
(simple boolean status, like biff). While this is very simple and good 
enough for some UAs, I don't want this to be the only recommended way to do 
MWI.

A message summary would enable much richer uses, like this message on my 
display:

"You have 3 new, and 7 old voice messages"  or   " *3*/7 voice, *25*/270 
email "

Does anyone else have thoughts on this?

>3. What is the format of the content in notifications?

Manoj, Ilya, and Shail proposed a simple plain-text format.  Does anyone 
have specific complaints about it?

I originally proposed an XML-based format, but it required a much heavier 
parser.

Does anyone have an alternate proposal?

>some events, and list someone else in the Contact, say, to receive the

The same way we prevent unauthorized third-parties from REGISTERing with 
someone else in Contact to receive their invites.  ;-)

thanks,
-rohan

---

From: Dean Willis <[email-masked]>
Date: Thu, 11 May 2000 11:30:54 -0500

Just as a reference point, there is an excellent paper on the Cambridge
Event Architecture in the March 2000 "Computer". This included discussion of
general issues around asynchronous event classification, roles, and use of
certificates for identification and authorization in a role-membership
model.

While the implementation may be heavily IPRed (I believe Nortel underwote
some of the work), I think some of the general concepts and nomenclature
would be helpful to our discussion.

I don't have the time at the moment to digest it fully, but it may be that
some of our more studiouscompanions might wish to review this material and
report on its applicability.

--
Dean

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
> Sent: Wednesday, May 10, 2000 5:41 PM
> To: Manoj Bhatia
> Cc: [email-masked]; Adam B. Roach; [email-masked];
> [email-masked]
> Subject: [SIP] Re: Two New Drafts
>
>
>
>
> Manoj Bhatia wrote:
> >
> > Hi Jonathan
> >