Subject: [SIP] Re: Provisional Response Draft

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:32 +0530

Anders Kristensen wrote:
>
> "K. K. Ramakrishnan" wrote:
> >
> > I also appreciate the need to not have special casing for methods -
> > but is this extra messaging coming about because we chose to
> > have the PRACK as a "method"? On the issue of backwards compatibility,
> > couldn't we say that proxies shouldn't be creating transaction state
> > for things it doesn't understand?
>
> This proposal is itself not backwards compatible.  Also, it doesn't seem
> quite right - it would mean, for example, that proxies cannot fork on
> requests they do not know. This seems like a big limitation.

I agree completely here with Anders. The spec clearly defines handling
for unknown requests as if they were BYE.

As one of the design principles of SIP, we've really tried to make it a
fairly general purpose protocol. Many of the features and capabilities
have broad applicability and usage. Often, the result of this kind of a
decision is a tradeoff- messages are a little bigger, or more
information is sent, when its not always needed. I'd really like to keep
with that design philosophy. Having special case methods to cover every
new case, and requiring tons of Proxy-Requires to make it all work, ends
up resulting in a tangled mess of a protocol that doesn't interoperate.
Please, lets stick with the request-response model for all new methods.

-Jonathan R.

--
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

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

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:15 +0530

Rohan Mahy wrote:
>
> Hi,
>
> At 12:09 PM 3/9/00 , Jonathan Rosenberg wrote:
> >All requests are responded to. period.
>
> I never debated this.  The user agents will always have an opportunity to
> respond.
>
> I agree with [email-masked], that proxies shouldn't keep state
for
> methods they don't understand.  They can simply forward messages for
these
> unknown methods on to the user agents or the next proxy.

If you want to build your proxy that way, fine. But I think it is asking
to much to mandate that unknown methods be forwarded statelessly. The
spec as written does not mandate this.

> So what I hear Jonathan saying is that because some proxies MIGHT keep
> state for new methods, then we need 200 OK, so that we don't break them.
> Correct?  I am personally curious how many proxies would break.
>
> Also, I hear Jonathan saying that new methods should be processed in the
> same way, and that this encourages simplicity.  Aside from the comment
> above, is there another motivation for this?

Yes. It leads to a clean architectural implementation. It means I can
build a base transaction mechanism that handles retransmissions and
provisional responses and stuff without detailed message semantics, and
then build semantic processing on top of this. It is this same
motivation which has led me to conclude that transactions must be kept
independent; so that, for example, if I send a BYE for an INVITE that
hasn't been answered, the UAS should still answer the INVITE.

The issue of allowing stateful proxies for unknown methods is a big one
as well. It means that SIPs routing and searching capabilities can be
reused for other services (i.e., other methods) with existing proxies. I
think this is not to be dismissed so lightly.

While there are clear advantages to keeping the 200 OK to PRACK, the
only advantage I have heard to date for dropping it is message
efficiency. In general, I firmly believe that generality and broad
applicability are far more important design goals than message
efficiency. I discuss this in more detail in the draft I recently
submitted entitled "Guidelines for Authors of SIP Extensions".

-Jonathan R.

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:11 +0530

Anders Kristensen wrote:
>
> > 2. Lets keep transactions independent. We went through a similar thing
> > with CANCEL, and the state machines were confusing until we decided to
> > make CANCEL a mini-transaction that does nothing but ask the UAS to
> > quickly answer the request. I think we will see confusion in the PRACK
> > processing if its operation becomes dependent on events in other
> > transactions.
>
> It is certainly simpler to just always complete according to the
> original plan, so to speak. Interestingly, though, one might have
> thought it to be OK for the UAS to stop retransmitting reliable,
> un-PRACK'ed responses when it sends a final response. The theory here
> would be that this is so because either
>   1) the reliable response has been lost before reaching the UAC, and so
> there's no observable difference anywhere in the network from it never
> having been sent, or
>   2) the UAS did receive the reliable response so no retransmission are
> needed anyway.
>
> The only snag I can see is that some proxy somewhere may in fact be
> clever and act upon certain reliable responses, thus destroying
> assumption 1) above, so it would appear to be prudent for the UAS to
> retransmit as per the draft even in this case.

Its not so much the proxy, as the UAC. If the UAS sent the response
reliably, its probably because it contained some information that was
important for the UAC to see. Otherwise, it wouldn't have sent it
reliably in the first place.

-Jonathan R.

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:18 +0530

Anders Kristensen wrote:
>
> The draft talks about when it's OK to generate new reliable responses
> for a transaction, but it doesn't seem to say anything about whether
> final responses can be generated by a UAS which has outstanding
> unacknowledged reliable responses.
>
> I believe the UAS must be allowed to generate a final response at any
> time.

Yes, agreed.

>
> The question is what happens with existing 'orphan' reliable responses
> and corresponding PRACKS. They can either terminate normally, i.e. the
> UAS continue retransmitting those reliable responses as it would have
> done had a final response not been sent and likewise the UAC still
> PRACKS them, or else maybe they could be terminated somehow - the UAS
> stops retransmitting them, and the UAC never PRACKS anything for which
> it has received a final response.

Hmm. Good question. I tend to lean towards having those orphaned
provisional responses still be PRACKED. Here's my reasoning:

1. These responses were sent reliably since they contain some important
and useful information. It may be that this information is no longer
useful once the final response is sent, but then again, it may be that
it is still useful. So, if the user tries to send a provisional response
reliably, lets always deliver it. Let the application decide whether its
useful after a final response.

-Jonathan R.
>
> Anders
>
> --
> Anders Kristensen <[email-masked]>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:12 +0530

Rohan Mahy wrote:
>
> Section 4.2.3 (The OPTIONS Method) goes on to say that user agents MAY
> respond to OPTIONS.  I would infer from this (and a quick skim of Section
> 12) that there is no requirement for a proxy to respond to a method it
> doesn't understand.
>
> Is there still any compelling reason to require the 200 OK after PRACK?

Well, perhaps you should read the rest of the sentence. There are words
after "MAY respond to this request". Lets be specific here. This section
says:

> The server is being queried as to its capabilities. A server that
>    believes it can contact the user, such as a user agent where the user
>    is logged in and has been recently active, MAY respond to this
>    request with a capability set. A called user agent MAY return a
>    status reflecting how it would have responded to an invitation, e.g.,
>
>
>
>
> Handley, et al.             Standards Track                    [Page 29]
>
> RFC 2543            SIP: Session Initiation Protocol          March 1999
>
>
>    600 (Busy). Such a server SHOULD return an Allow header field
>    indicating the methods that it supports. Proxy and redirect servers
>    simply forward the request without indicating their capabilities.
>
>    This method MUST be supported by SIP proxy, redirect and user agent
>    servers, registrars and clients.

That is it MAY respond with a capability set, or MAY respond with a
status reflecting how it would have responded to the invitation. The MAY
is a choice among how the response is formulated, NOT on whether a
response is sent.

By not having the 200 OK to PRACK, we break the transactional model of
the protocol. This means proxies and UAs have all this extra state
laying around. It means spurious CANCELs and responses might get sent.
It means we probably need a Proxy-Require, and I really don't want to do
that, because it means compatibility is broken.

-Jonathan R.