Subject: RE: [sip-events] Re: [SIP] New SUBSCRIBE/NOTIFY draft available

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Oct 2000 11:45:10 -0500

> -----Original Message-----
> From: Adam B. Roach [mailto:[email-masked]]
> Sent: Monday, October 30, 2000 12:03 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [sip-events] Re: [SIP] New SUBSCRIBE/NOTIFY draft available
> 
> 
> >> My hope is that, once the events draft is complete, the presence
> >> draft will be somewhat thinner, and have the luxury of 
> concentrating
> >> on presence instead of event notification. If you feel that there
> >> are any generally applicable features included in the presence
> >> draft which I have failed to clearly incorporate in my 
> draft, please
> >> point them out.
> >
> >I believe that, in general, your draft is more or less the 
> distillation of
> >the presence draft, modulo the above issues plus one more.
> >
> >That additional issue centers around your statement:
> >
> >
> >     Since forking proxies pass all 200 responses upstream, it is
> >     expected that these "From" fields will not contain any 
> tags which
> >     are unknown to the subscriber. However, to make the subscription
> >     mechanism more robust, subscribers SHOULD be prepared to receive
> >     notifications with previously unknown tags in the "From" field.
> >
> >Your assumption here is false. For non-INVITE methods, there 
> is only a
> >single 200 OK passed upstream.
> 
> This was changed between the bis-00 and bis-01 drafts. I will
> update my draft to reflect this change.
> 
> Compare section 12.4, "Forking Proxies":
> 
>   "2xx: The proxy MUST forward the response upstream towards 
> the client,
>         without sending an ACK downstream."
> 
> ...versus...
> 
>   "2xx: If the request was an INVITE, the proxy MUST forward the
>         response upstream towards the client, without sending an
>         ACK downstream. For other requests, it should only forward
>         the response upstream if it has not forwarded any other
>         responses upstream."
> 

Sending only one 200 OK for a non-INVITE is not a feature we added by fiat;
sending multiple ones just doesn't work. It has to do with reliability.
Remember, for non-INVITE, request retransmissions are used to ensure
reliability, since they trigger response retransmissions. The client knows
to stop sending requests when its gotten the response. Now, say I send the
first 200 OK. The client gets this, and stops retransmitting the request,
since its now gotten a response. Now I try to send a second 200 OK, and it
gets lost. It never gets retransmitted. 

Multiple responses only work in the case of the three way handshake of the
INVITE method. Since new methods are treated as non-INVITE, well, SUBSCRIBE
can only have a single 200 OK. To tell you the truth, I rather like the
cleanness of this. Multiple 200 handling, with ACKs and these other rules
are complex. The non-INVITE handling is much cleaner and simpler. This is
good since there will be people (I hope) who implement SIP for presence and
never even do INVITE, since they only want IM and presence. I'd like the
solution for them to be as clean as possible.

> Note that this has the horrible, horrible side effect that I
> can receive a 6xx (or, in timeout situations, even 4xx-5xx
> responses) to a SUBSCRIBE request, never see a 200, and still 
> have valid outstanding subscriptions. I dislike this behaviour.

Not likely. Even though a proxy only sends one 200 response, it still sends
the best response it receives to all forked requests. As such, it will send
a 200 OK upstream so long as any one of the forked requests generated a 200
OK. It is possible that one branch never answered, and the proxy times out,
sending a 408 response upstream. This passes a 200 OK on the wire. In this
case, yes, a subscription does exist even though the UA thinks there is
none. This is fixed by having the UA retry the SUBSCRIBE if it timed out
initially. Also, the soft state nature of SUBSCRIBE will also eventually
clean things up in this rare case.

> 
> Why do we do something so radically different for INVITE than
> for anything else? Yes, I know it's needed for cleaner ACK
> handling, but what harm comes from *always* proxying 200-class 
> responses regardless of the method? As none of us know what the
> nature of future methods might be, I beleive this is folly.

I think I have answered this above.

> 
> >Besides this issue, and the ones above regarding call-leg specific
> >subscriptions, I believe there is nothing different between 
> the two (to put
> >it in Adam's terms, the presence draft is a concrete 
> implementation of the
> >abstract class defined in his draft, without overriding any 
> of its methods
> >:) ) I need to go over both with a fine tooth comb to be 
> sure, however.
> 
> Actually, I think the presence draft still has a bunch of behavior
> which I didn't capture, but still needs to be described somewhere. 
> The descripiton of presentities that serve as representives 
> of UAs for 
> the purpose of user presence is still a concept that needs to be 
> defined. 

Not sure what you mean. By simple definition, a presentity serve as
representatives of users for the purpose of presence; there is no protocol
implications of this definition. The SIP for presence draft does define the
notion of a presence agent, or PA, whose function can migrate from the
server to the client. Turns out that this is perfectly within the realm of
your draft. Remember, UA vs. proxy are LOGICAL roles, and all that this
capability is doing is saying that a server may act as a UA for one
SUBSCRIBE, and then as a proxy for the refresh. We simply describe how to
smoothly do this transition, your draft describes how a UA and proxy behave
for handling subscriptions and notifications.

Adam later writes:
> David Shrader writes:
> >What if the object being monitored ceases to exist? That is, 
> I choose to
> >monitor a call leg (from, to, call-id) and I am not a member 
> of that call
> >leg and the call ends. Does my subscription get cancelled?
> 
> This problem appears to be solved if we add a general mechanism by
> which notifiers can send a general "this subscription is now
> over" NOTIFY message, as has been proposed. I intend to add this
> mechanism to future version of the draft.
> 

Thats my preference. Remember, there are other types of entities we might
subscribe to whose subscription naturally terminates at some time. I'd
rather have a single, general solution for this rather than several ones
specific to the entity being subscribed to.

Sean Olson writes:
> One question on this. It was suggested that the Event: header was not
> needed because this information would need to be encoded in the
> body anyways. For this particular event:
> 
> 1) What Content-Type: will we use?
> 2) What will be placed in the body?
> 
> Or has it been decided that the Event: header is OK to leave in?

I'd prefer the Event header. Subscription data will often be XML, I suspect,
so the type may be difficult to use. Plus, I don't like tying the semantics
of the request to the syntax of the body. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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