Re: Two New Drafts

[[e-mail]]

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" <[e-mail]> on 03/09/2000 02:45:52 AM

To:   [e-mail]
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: [phone] | 1010 E. Arapaho, MS L-04
[e-mail]   | Fax: [phone] | Richardson, TX 75081 USA