Subject: Re: [SIP] New SUBSCRIBE/NOTIFY draft available

From: [email-masked]
Date: Wed, 25 Oct 2000 14:49:57 -0500

Hi Adam,

Few comments :

   What is the difference between registering (REGISTER) for an event and
   subscribing (SUBSCRIBE) to an event?
       I REGISTER to a proxy server to receive INVITE for my calls or do I
SUBSCRIBE to my proxy server to NOTIFY me of my calls.
       I see myself registering to receive invites to calls, receive voice mail
notifications, and other notifications and similarly I see myself subscribing to
these things       also.

   All messages can be combined into one message and similary all headers can be
   broken into different messages.
       INFO method I can see used for carrying various informational messages
during a call.
       All what I am trying to say is did we give enough thoughts in this case
whether a header would suffice or a new message is required.

   As you mentioned it is a fine line between whether a new message or a new
   header is suitable.
       Did we do go through the process of deciding whether a new header is more
suitable than a new message in case of SUBSCRIBE?
       If not, should we do that or not.

   The reason why I ask this question is if tomorrow I come up with a new
   concept what would be the deciding factors for enhancing REGISTER,SUBSCRIBE
   or adding a new method.

   Just like we teardown a session with a BYE method. Can we also teardown
   subscriptions using BYE/NOTIFY method.

Thanks,

Anoop

"Adam B. Roach" <[email-masked]> on 10/25/2000 12:21:00 PM

Sent by:  "Adam B. Roach" <[email-masked]>

To:   Anoop Tripathi/MW/US/3Com
cc:   [email-masked], [email-masked]
Subject:  Re: [SIP] New SUBSCRIBE/NOTIFY draft available

>   Was using a header in INVITE/REGISTER requests as a replacement of SUBSCRIBE
>   request considered?

No, this didn't come up as a suggestion so far. The SUBSCRIBE method
dates back to February of 1998 (in spirit, at least), and has been
incorporated into PINT and the "SIP for Presence" work. The intent
of my draft was to provide a framework which allows multiple uses
of the SUBSCRIBE and NOTIFY methods in such a way that the different
uses didn't get in the way of each other. Using any method other
than "SUBSCRIBE" would leave the current drafts somewhat orphaned.

>   So far I could only see two cases of using SUBSCRIBE. One
>   during call. In that case we could send the subscribe information in
>   INVITE/RE-INVITE requests. Second as part of registration. You register to
>   Proxy, Voice-mail server etc and subscribe to events. So what is the
>   motivation behind having a separate request?

The short answer is: the same reason "INFO" isn't defined as "BYE" with
a "Just-Kidding:" header.

"SUBSCRIBE" isn't what "INVITE" means, in any remote sense; neither is
it what "REGISTER" is intended to mean. It has been pointed out that
all methods could be generalised to one method (e.g. replace "BYE"
with "INVITE" and a special header indicating that you are inviting
the other party to end the current session.)

Defining such a system would be quite easy. It would also be patently
ridiculous.

Since asyncronous event subscription is a distinct action which has
no ties to any of the other defined or proposed actions, it seems
reasonable to define a new method.

>   By defining SUBSCRIBE/NOTIFY requests are we trying to achieve the similar
>   functionality that exists in MEGACO/H.248.

Not really. the H.248 event notification, as I understand it, is
more appropriate for terminal/endpoint events (e.g. hookflash,
digit collection, etc). The SIP event notification has so far
been proposed for tasks such as call status, user presence,
and message waiting indication.

>   Is DTMF digit collection a valid usage of this scheme?

That's a religious issue. Search your own soul and figure out
what's true for you. If you want to read evangelical screeds on
both sides of the issue, check the SIP working group mailing
list archives.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

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

---

From: hammer michael <[email-masked]>
Date: Thu, 26 Oct 2000 11:50:31 -0700

My initial impression (I need to study in detail) was that these methods 
could be both session (call) associated and non-session (non-call) 
associated.  Thus they may exist outside the scope of any session defined 
by event between INVITE and BYE, and could in fact span multiple 
sessions.  Like subscription to mail-lists, they exist longer than any 
given thread of messages.

I would suspect that the intent to communicate for a specific purpose could 
be registered, and if able to be discovered, could be subscribed to by 
those virtually wandering by.  I assume that the purposes would be 
addressed in the message body and addressed by the IMPP folks.

What is not clear to me is that assuming that someone has registered their 
presence, and another is interested in subscribing/initiating 
communications to that person, and the former's identity is not already 
known in some form to the latter, how does the latter search/browse to find 
the former?  Is this assumed to be a directory operation outside the scope 
of SIP and IMPP?

Mike

---

From: David Shrader <[email-masked]>
Date: Thu, 26 Oct 2000 22:44:22 -0400

I was also thinking that a BYE would cancel a subscription. At least in the
context of an interaction begun with an INVITE, maybe that is erroneous.
When SUBSCRIBE is outside the context of a call, it is not so clear if BYE
is appropriate since the SUBSCRIBE, expires 0, ... method would work like
cancelling a registration.

On another note, is there really even a need for the Event: header. Wouldn't
it be more flexible to simply state that if no Event: header is present,
then you are subscribing to any events that the object desires to expose?

----------------------------
David Shrader
Master Consultant, Inc.
[email-masked]
http://www.EyeForTheFuture.com

> From: [email-masked]
> Date: Wed, 25 Oct 2000 14:49:57 -0500
> To: "Adam B. Roach" <[email-masked]>
> Cc: [email-masked], [email-masked]