Subject: Re: Two New Drafts

From: [email-masked]
Date: Thu, 9 Mar 2000 09:42:55 +0530

Hi,

some questions:

1. 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 ?

2. What do I do when I want to send a subscription like:

" I want to be notifed when user A sends me a voice mail for the next 3 hrs
AND when user B sends me a voice mail for the next 2 hrs "

Do I send two different SUBSCRIBEs like

SUBSCRIBE .....
event: voice-mail <PS how do I say user A ?>
Expires: <3hrs>
Call-ID: XXXXXXX

and

SUBSCRIBE .....
event: voice-mail <PS how do I say user B ?>
Expires: <2hrs>
Call-ID: YYYYY

Now in above, I feel the event header should be broken up more so I dont
have to put in the entire event in one token only (although Im not sure how
much of break up would satisfy everyone - maybe something like cp-params of
Caller&Callee preferences ?)

Maybe we could have event as token *(; value)  where value = token | token
"=" token
where the first token mentions the primary service like "voice-mail",
"terminal-free" etc and the second set of tokens to be a description about
the primary event which the server supporting the event would understand.

Then w could do: event: voice-mail;user="A" or something

Further, If I wanted to sent multiple subscriptions as one ordered set
(like I want to be notified of voicemails from A,B,C for a duration of
2,3,4 hrs) , then the only way I see it either break it up into 3 SUBSCRIBE
(requiring then that I have 3 call ids to correlate) or that  I do one
request with 3 Event Headers and 3 Expires headers and do something like
first Event matches first Expires - which again does not seem to be good.

Would it make sense, then to  define Event as minimally

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

3. REGISTER with Exp : 0 I guess unregisters a user from the registrar (or
certain contacts from the registrar) - however, subscribing to
a notificaton service, imho, is different from registering for normal sip
operations and hence I feel REGISTER should not be used to
delete SUBSCRIBEs - I would wanyt to subscribe, unsubscribe from
notifications often without wanting to touch my registration at all -
hence I feel UNSUBSCRIBE is better that overloading REGISTER

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

"Adam B. Roach" <[email-masked]> on 03/09/2000 02:45:52 AM

To:   [email-masked]
cc:

Subject:  Two New Drafts

There are two new drafts on the IETF web site. The first
one is an attempt at formalising a general, extensible
event notification for SIP using SUBSCRIBE and NOTIFY.

The second draft demonstrates an application of this
event notification (using an auto-call-back service),
along with callflows.

---------------------------------------------------------------------------
Title: Event Notification in SIP

Abstract:

     This document describes an extension to the Session Initiation
     Protocol (SIP) [1] . The purpose of this extension is to provide
     a generic and extensible framework by which SIP nodes can request
     notification from remote nodes indicating that certain events
     have occured.

     Concrete uses of the mechanism described in this document may be
     standardized in the future.

http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.
txt
---------------------------------------------------------------------------
Title: Automatic Call Back Service in SIP

Abstract:

     This document describes a proposed implementation of an Automatic
     Call Back (ACB) service using SIP. This service is somtimes
     refered to as "camp on extension," "call again," "automatic
     redial," and "automatic recall."

http://search.ietf.org/internet-drafts/draft-roach-sip-acb-00.txt

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

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 9 Mar 2000 09:45:15 -0600 (CST)

[email-masked] writes:
>The draft does not mention what happens when multiple SUBSCRIBE requests

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.

I don't think it would be too onerous to require user agents
to send a full list of events for each call-related subscription,
since they're already having to maintain a tubload of state
information about the call. Any comments on this from other
people?

>AND when user B sends me a voice mail for the next 2 hrs "
...
>Then we could do: event: voice-mail;user="A" or something

This certainly makes it more flexible. The ability to add 
parameters to a particular event type would save future 
extensions from having to worry about adding new headers.

SUBSCRIBE .....
Call-ID: [email-masked]
Event: voice-mail;from=sip:[email-masked]
Expires: 7200

SUBSCRIBE .....
Call-ID: [email-masked]
Event: voice-mail;from=sip:[email-masked]
Expires: 10800

(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).

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

SUBSCRIBE .....
Call-ID: [email-masked]
Event: voice-mail;from=sip:[email-masked],
       voice-mail;from=sip:[email-masked],
       voice-mail;from=sip:[email-masked]
Expires: 14400
Date: Thu, 09 Mar 2000 15:00:00 GMT

SUBSCRIBE .....
Call-ID: [email-masked]
Event: voice-mail;from=sip:[email-masked],
       voice-mail;from=sip:[email-masked]
Expires: 7200
Date: Thu, 09 Mar 2000 17:00:00 GMT

SUBSCRIBE .....
Call-ID: [email-masked]
Event: voice-mail;from=sip:[email-masked]
Expires: 3600
Date: Thu, 09 Mar 2000 18:00:00 GMT

When thinking about this, also consider that the server
may reduce the "Expires" header down to some uniform
smaller value anyway. If you're going through the trouble
of breaking it up into three separate Call-IDs, all of which
get turned down to expire in one hour by the server, what
are you gaining?

>hence I feel UNSUBSCRIBE is better that overloading REGISTER

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:

SUBSCRIBE .....
Call-ID: [email-masked]
Event: voice-mail
Expires: 0
Date: Thu, 09 Mar 2000 15:30:00 GMT