Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Nov 2001 02:05:04 -0500

This thread ended abruptly, but its really important, and I'd like to see it
terminate.

I think there is consensus that we need some kind of header in the NOTIFY to
convey some kind of state. A few proposals were floated, to use the Reason
header we've discussed in other contexts, or a new header. To me, the most
important thing to understand is what are the semantics we are trying to
convey.

First, does this header convey the status of the susbcription or the
SUBSCRIBE transaction? This was also debated in this thread. I think we
should convey the status of the susbcription, not the transaction. The
transaction itself has already terminated. Although the final response code
may not be reliably delivered to the UAC because of forking, its not clear
what the value of sending it in the NOTIFY would be. It opens up a very
large can of worms for mapping everything we do with responses, into the
NOTIFY request. For example, if I got a SUBSCRIBE with a body I didn't
understand, would I send a 200 OK to that, and then a NOTIFY like:

NOTIFY 
Status: 415 I dunno
Accept: application/new-filter-type

And then the subscriber retries the SUBSCRIBE using only this filter-type. 

Do we want to go this far? This will require a serious redefinition of many
of the headers and processing rules, to map response processing to request
processing. I'm not sure we should go that far, and I don't know where to
draw the line. This would be optimizing a lot of processing for the forking
case, which is a mistake, I think. Also, you are now faced with the problem
of mapping the status in the NOTIFY to a specific SUBSCRIBE transaction.

So, what would we do in this case above, where some of the notifiers can't
process the NOTIFY because the body is of the wrong type? So long as ONE of
them can process the type, the subscription will succeed there, and you'll
get back the 200 OK from that one, and then a NOTIFY. If none of them
supports the type, you'll get back a 415, and can then try again. So, if the
function you want is for the SUBSCRIBE to succeed at any one of the
recipients, it is OK to not worry about this problem. If, however, the goal
is to create successful subscriptions at all elements that received the
forked SUBSCRIBE, I think that this is a bigger problem, and I am not sure
we should try to tackle that.

I think it makes much more sense to have NOTIFY convey the state of the
subscription. This natually aligns with what NOTIFY is for (state of the
thing the subscription refers to). Furthermore, the states of the
subscription are more easily enumerable (and watcherinfo defines them, as
has been pointed out). We clearly have a need to know this state at the
subscriber, even for non-forking cases, whereas knowing the state of the
transaction, above, is only needed for forking (the SUBSCRIBE response
itself is sufficient for the non-forking case).

Thus, we only need a header to convey those states. I see little value in
this case of using sip response codes, since this will only be a source of
confusion about how to map a particular response code to a particular
subscription state. I would prefer a header defined specifically to convey
subscription states.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
  
-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Friday, November 09, 2001 12:53 PM
To: Michael Hammer
Cc: Paul Kyzivat; Jonathan Rosenberg; 'James Undery'; 'Fairlie-Cuninghame,
Robert'; [email-masked]; [email-masked]
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

Thanks Mike, 
(I can read either format as I use Outlook.) 
I think I'm seeing where you are coming from with the Reason header. My
thinking was that the Subscription-Status code be limited only to the actual
status of the subscription itself, and speak nothing about the service the
subscription may be providing. 
To my mind, the state of the resource that the subscription is tracking can
be any arbitrary value, and is described in the NOTIFY message body as is
currently put forth. 
The state of the subscription watching the resource, however, can only be in
a finite number of states. Borrowing from the watcherinfo draft (which I
think expresses these states very adequately), the subscription can only be:
- Pending (202) 
- Active (183, 200) 
- Terminated (301, 302, 401, 402, 403, 408, 486, 487, 500, 503, 603,) 
And that's it. I feel that we can easily map the SIP response codes, which
are well known and understood, to describe these states adequately, and thus
using the Reason header may be more than what we really need. To me, the
reason for the notify is contained in the message body. The status of the
subscription itself is contained in the Subscription-Status header. If there
is no message body to the NOTIFY, this would be because the resource being
watched only has 1 state to it, and does not require any information about
it's current properties to be sent to the watcher (as they can all be
implied from simply receiving the notification). If this is not the case,
and the resource is more complex, then a message body must always be
included to describe it's properties at the time the notification was sent
(ie. the reason for sending it is because the properties of the watched
resource changed, not because the subscription changed).
I can definitely see us subscribing to the state of a registration. It's
already being proposed in the 3GPP forum. However, in the case of
subscribing to a registration, we  should (in my mind) transport the reason
for sending the notify in the message body as the resource being watched is
the registration.
Regards, 
Brian Stucker 
Nortel Networks 

-----Original Message----- 
From: Michael Hammer [mailto:[email-masked]] 
Sent: Friday, November 09, 2001 10:45 AM 
To: Stucker, Brian [NGB:B635:EXCH] 
Cc: Paul Kyzivat; Jonathan Rosenberg; 'James Undery'; 
'Fairlie-Cuninghame, Robert'; [email-masked]; [email-masked] 
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01 

(Trying to resend in plain text, sorry for hitting the wrong button.) 
Brian, 
I may have confused the original discussion of Reason header with the new 
need related to the Sub-Status header.  Whether we call it a status or a 
reason, the intent appears to be to provide more detail with element under 
consideration.  In the case of original Reason code, it was aimed toward 
the session, in the case of the Subscription-Status, it is about the 
Subscription. 
My question would then be whether to have two headers specific to each 
element or one header whose values would indicate which element is given 
added detail. 
In your view, would one ever request a Subscription for Notification about 
the status of a Session or Registration, or just to independent information 
services? 
Mike 

At 12:07 AM 11/9/2001 -0600, Brian Stucker wrote: 
>I guess I don't follow how ISUP cause codes have much bearing on the 
>status of a subscription. Maybe you can explain a bit more? 
> 
>The Subscription-Status header that I'm proposing would be an offshoot of 
>the sipfrag used in the REFER method, only as a header to avoid the 
>complexity of multi-part MIME types, etc. 
> 
>Brian 
>-----Original Message----- 
>From: Michael Hammer [mailto:[email-masked]] 
>Sent: Thursday, November 08, 2001 3:51 PM 
>To: Paul Kyzivat 
>Cc: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'James Undery'; 
>'Fairlie-Cuninghame, Robert'; [email-masked]; [email-masked] 
>Subject: Re: [Sipping] Immediate NOTIFIES change in sip-events-01 
> 
>One caution on using Response codes versus Reason codes:  If you collect 
>all the cause codes used in ISUP, it would likely be more than 100.  That 
>could upset the numbering scheme.  This would argue for using the Reason 
>codes.  It was also pointed out before that these are needed in the 
>requests not the responses. 
> 
>Mike 
> 
>At 05:18 PM 11/7/2001 -0500, Paul Kyzivat wrote: 
>>There has already been discussion in other threads of need for a Reason 
>>header, at least for use in ACK and CANCEL. The need here for NOTIFY 
>>seems similar. (One of my reasons for wanting it is that sometimes an 
>>ACK is really a NACK, but there is currently no way to indicate this. 
>>Similarly, here we have a NOTIFY that is sometimes used for something 
>>quite different than its normal function.) 
>> 
>>I don't believe the Reason header was ever fully elaborated, but I think 
>>the discussion was around something similar to response codes, but that 
>>there might need to be new ones added. 
>> 
>>         Paul 
>> 
>> > Brian Stucker wrote: 
>> > 
>> > It seems that the real problem is coming down to trying to convey too 
>> > much in the NOTIFY message body. 
>> > 
>> > Really you need to convey two pieces of information: 
>> > 
>> > - The state of the subscription. 
>> > - The state of the resource being watched by that subscription. 
>> > 
>> > I would argue that we should keep the immediate NOTIFY to preserve the 
>> > 3-way handshake mechanism but add (as has been suggested) a separate 
>> > header that keeps track of the subscription state. 
>> > 
>> > Borrowing from the watcherinfo draft, I think it's fair to say that 
>> > our subscriptions can be in a finite number of states, and that those 
>> > states can be mapped to a SIP response code. So can we... 
>> > 
>> > Always send a 200 OK to the SUBSCRIBE, followed by an immediate 
>> > NOTIFY. Within that NOTIFY, we include a new mandatory header called 
>> > "subscription-status". 
>> > 
>> > The content of this header is simply the appropriate SIP response code 
>> > and reason. For instance: 
>> > 
>> > A successful subscripton request would be: 
>> > 
>> > SUBSCRIBE, 200 OK, and... 
>> > 
>> > NOTIFY [email-masked] SIP/2.0 
>> > Subscription-Status: 200 OK 
>> > 
>> > If later, the subscription needed to be cancelled... 
>> > 
>> > NOTIFY [email-masked] SIP/2.0 
>> > Subscription-Status: 487 Request Terminated 
>> > 
>> > etc. 
>> > 
>> > Make the reason code mandatory, and the reason phrase optional. 
>> > 
>> > Subscription-Status = Status-Code SP Reason-Phrase CRLF 
>> > 
>> > The Status-Code should probably be catgorized to a more definite set 
>> > of subscription states. Borrowing from the watcherinfo draft: 
>> > 
>> > - Pending     (182) - instead of 202. 
>> > - Active      (200) 
>> > - Terminated  (4xx, 5xx, 6xx) 
>> > 
>> > 3xx response codes are not allowed in the Subscription-Status, and if 
>> > the final (non-2xx) response can be determined by processing the 
>> > SUBSCRIBE, it is returned instead of the 200 OK to the SUBSCRIBE 
>> > itself. 
>> > 
>> > The NOTIFY message body then only contains information on the actual 
>> > resource being watched. 
>> > 
>> > Thoughts? 
>> > 
>> > Brian Stucker 
>> > Nortel Networks 
>> > 
>> > -----Original Message----- 
>> > From: Jonathan Rosenberg [mailto:[email-masked]] 
>> > Sent: Wednesday, November 07, 2001 2:31 PM 
>> > To: 'James Undery'; Stucker, Brian [NGB:B635:EXCH]; 
>> > 'Fairlie-Cuninghame, 
>> > Robert'; [email-masked] 
>> > Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01 
>> > 
>> > I think James is right here. I don't have a problem with keeping the 
>> > 202, 
>> > but the mapping of SUB/NOT to the INVITE handshake is by now quite 
>> > clear: 
>> > 
>> > INVITE            SUB/NOT 
>> > ------            ------- 
>> > 
>> > INVITE  <----->    SUBSCRIBE 
>> > 1xx     <----->     final response to SUBSCRIBE 
>> > final resp     <------>   NOTIFY 
>> > ACK           <------>  final response to NOTIFY 
>> > 
>> > From this it is clear that we need, within NOTIFY, to convey the full 
>> > set of 
>> > information which would be possible to be conveyed in the final 
>> > response to 
>> > an INVITE. Treating the absence of a body of NOTIFY to imply pending 
>> > is one 
>> > way, but it covers only one case. I think a more generic mechanism, 
>> > through 
>> > some header, like Subscription-Status or something, that has a 
>> > response code 
>> > and reason phrase, is much better and more generic. 
>> > 
>> > Now, if we take this one step further, it should, in theory, be 
>> > allowed to 
>> > CANCEL a SUBSCRIBE after I get a final response to the SUBSCRIBE, and 
>> > the 
>> > result of that would be to cause all subscriptions that have not 
>> > generated a 
>> > NOTIFY yet (because the subscription wasn't authorized) to immediately 
>> > send 
>> > a NOTIFY with a Subscription-Status of 487. Once you allow this kind 
>> > of 
>> > cancellation, then it no longer becomes neccesary to have an immediate 
>> > 
>> > NOTIFY, for the same reason you don't need to send a 2xx to INVITE 
>> > immediately. I'm not proposing that, but I think it is important to 
>> > consider 
>> > how closely we do, or do not, wish to align the two mechanisms 
>> > together. 
>> > 
>> > -Jonathan R. 
>> > 
>> > --- 
>> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave. 
>> > Chief Scientist                             First Floor 
>> > dynamicsoft                                 East Hanover, NJ 07936 
>> > [email-masked]                     FAX:   (973) 952-5050 
>> > http://www.jdrosen.net                    PHONE: (973) 952-5000 
>> > http://www.dynamicsoft.com 
>> > 
>> > 
>> > > -----Original Message----- 
>> > > From: James Undery [mailto:[email-masked]] 
>> > > Sent: Wednesday, November 07, 2001 8:35 AM 
>> > > To: 'Brian Stucker'; 'Fairlie-Cuninghame, Robert'; [email-masked] 
>> > > Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01 
>> > > 
>> > > 
>> > > Hi 
>> > > 
>> > > This still doesn't cover Robert's point, i.e. you will only 
>> > > see one final 
>> > > response and potentially multiple NOTIFYs. Your FSMs are 
>> > > already overly 
>> > > simplified because of ignoring this complexity. 
>> > > 
>> > > My personally favoured solution would be to include optional 
>> > > subscription 
>> > > status info in NOTIFYs as a header. e.g. Replace 
>> > > Subscription-Expires with 
>> > > something like a Subscription-State header that contained 
>> > > status (optional), 
>> > > expires and expiry-reason (optional) parameters. 
>>_______________________________________________ 
>>Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping 
>>This list is for NEW development of the application of SIP 
>>Use [email-masked] for questions on current sip 
>>Use [email-masked] for new developments of core SIP 
>_______________________________________________ Sipping mailing list 
>http://www1.ietf.org/mailman/listinfo/sipping This list is for NEW 
>development of the application of SIP Use [email-masked] 
>for questions on current sip Use [email-masked] for new developments of core
SIP 

_______________________________________________ 
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping 
This list is for NEW development of the application of SIP 
Use [email-masked] for questions on current sip 
Use [email-masked] for new developments of core SIP 

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Tue, 20 Nov 2001 15:44:22 -0600

> we should try to tackle that.

Replace "SUBSCRIBE" with "INVITE." This is a general problem.

Fast-forward a few years; I send an INVITE with SDP-NG as the body.
It forks to your mobile phone, your work phone, and your spiffy new
home phone. Your mobile and work phones send 415 responses. Your
home phone (which is nowhere near you) sends 180, and ultimately
a 200 (at which point the built-in answering machine fires up).

Replace 415 with any 400-class response that isn't a final
failure (401, for example). What happens here? You have your
service set up to reach you at three destinations, but it isn't
working!

The problem you describe isn't specific to SUBSCRIBE. In fact, it's
far more annoying in the INVITE case than it can ever hope to be
for SUBSCRIBE.

I think this problem needs to be solved -- but it certainly shouldn't
be solved in a way that is specific to SUBSCRIBE.

/a

---

From: [email-masked]
Date: Tue, 20 Nov 2001 16:00:27 -0600

I agree with Jonathan's analysis of the situation.

As it stands, we have a mechanism which allows us to convey
whether the subscription is active: is Subscription-Expires > 0?
We also have a way to indicate roughly why this value
is anything other than what the subscriber might expect.

Is this sufficient? I think it is. The reason codes seem better
geared towards conveying transaction state (like they do in
REFER). I agree with Jonathan that we want to convey subscription
state, not transaction state.

This still leaves the authentication issues, to which the reason
codes offered an incomplete solution. As I previously
argued, authentication through a forking proxy is a general
problem which impacts INVITE (and all other methods) at least
as severely as it does SUBSCRIBE. I am loathe to solve a general
problem in a method-specific manner.

Perhaps I don't understand the problem that people are trying
to solve here, but I think the current mechanism (Subscription-Expires
with an optional reason parameter) accomplishes what is necessary to
make things go.

If someone has additional requirements that aren't fulfilled by this
scheme, please explain the problem you see with the current draft.

/a