Subject: Re: [SIP] Max-Forwards + Proxies

From: Sean Olson <[email-masked]>
Date: Thu, 22 Jun 2000 18:12:04 -0500 (CDT)

> Jonathan Rosenberg wrote:
> > 
> > Actually, this is in RFC2543 also.
> > 
> > I don't like this, in fact. I believe method-based special handling of
> > headers is confusing, and I would prefer that the response always be
> > 483, for any method. I guess the objective (for OPTIONS at least), is
> > to query a proxy for capabilities.

>              ^^^^^
> Is it?  How does a proxy know that this OPTIONS request is destined for
> it, and not for proxying downstream?  The RFC (and the bis updates)
> state that "Proxy and redirect servers simply forward the request with-
> out indicating their capabilities."  I simply assumed that a proxy will
> forward the request downstream and not respond upstream with _it's_ 
> capability set.

This is the point of the Max-Forwards: header usage in connection with
the OPTIONS method.

> 
> > Anyone object to having this sentence stricken?
> Not me, for one.  Anything stricken is good :-)
> 

It is nice to be able to specify that an OPTIONS/REGISTER be directed
to a particular node, at least for certain diagnostic purposes. I will
probably continue to support this behavior, even if it becomes
"non-standard". But I wouldn't mind if no one else implements it.

sean <[email-masked]>

> - vijay
> -- 
> Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
> IN Architecture and Internet Software Group
> Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-418
> Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2000 01:21:41 -0400

> "non-standard". But I wouldn't mind if no one else implements it.

I'm assuming by diagnostic you refer to the ability to tell if the proxy
is alive. You can still do that with the consistent behavior I am
proposing. It works exactly like traceroute; you set max-forwards to
some number, and the proxy who gets it when its zero returns an error.
If you get no response, you know that this particular device is down.
The difference is whether the Supported, Accept, Allow headers are
there. Allow and Accept don't make sense for proxies anyway.

Just trying to simplify things... special cases are annoying.

-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: (732) 741-7244
http://www.dynamicsoft.com

---

From: Neil Deason <[email-masked]>
Date: Fri, 23 Jun 2000 09:48:23 +0100

> there. Allow and Accept don't make sense for proxies anyway.

Also the Supported header which might be useful SHOULD
be included in the response according to 6.40.

> Just trying to simplify things... special cases are annoying.

I agree that simplification would be good in this area. There
doesn't seem to be any loss in saying that the standard response 
from a proxy/gateway recipient to any request containing 
Max-Forwards: 0 is 483.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK          
http://www.ubiquity.net

---

From: Shail Bhatnagar <[email-masked]>
Date: Fri, 23 Jun 2000 10:53:30 -0400

> from a proxy/gateway recipient to any request containing

I think we still need 2 special cases here 
    * A REGISTER destined for a proxy may have a Max-Forwards of 0
      (registrar/proxy should still process it )
    * A CANCEL for an existing call leg is allowed to have Max-Forwards
      value of 0

Shail

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 23 Jun 2000 09:53:11 -0500

Sean Olson wrote:
       ^^^^^
> > Is it?  How does a proxy know that this OPTIONS request is destined 
> > for it, and not for proxying downstream?  The RFC (and the bis 
> > updates) state that "Proxy and redirect servers simply forward the 
> > request without indicating their capabilities."  I simply assumed 
> > that a proxy will forward the request downstream and not respond 
> > upstream with _it's_ capability set.
> 

Oh, okay.  Kind of like the traceroute command with the TTL being 1
greater then the previous packet.  

I agree with Jonathan's belief that method-based special handling of
headers is confusing.  I had to re-read the Max-Forwards section of
the RFC before it sunk in that the semantics the authors wanted to
impose if (Max-Forwards == 0 && Request == OPTIONS) was to have the 
current proxy respond with _it's_ capabilities.

> "non-standard". But I wouldn't mind if no one else implements it.

I'm not sure if there is a better way to achieve this.  I don't think
having a new request header will help in any way.

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2000 11:38:34 -0400

>       (registrar/proxy should still process it )

Why? I really don't like method specific processing of Max-Forwards; I
think this will introduce oddball effects, where the topology of the
proxies may effect whether registrations can placed in a server or not. 

>     * A CANCEL for an existing call leg is allowed to have Max-Forwards

Also, why?

-Jonathan R.

---

From: Neil Deason <[email-masked]>
Date: Fri, 23 Jun 2000 16:43:03 +0100

> proxies may effect whether registrations can placed in a server or not.

I agree. If you make an exception for REGISTER though why not
INVITE? If a proxy receives an INVITE and it knows from it's
location service that the response would be a 3XX redirect then
why not return this.

> >     * A CANCEL for an existing call leg is allowed to have Max-Forwards

Yeah, this seems like allowing an unnecessarily odd way of doing
a CANCEL. For me the simplicity of 483 for all methods, which
allows the apparent fault diagnosis of the Max-Forwards tracing,
still wins out.

Cheers,
Neil.

---

From: Shail Bhatnagar <[email-masked]>
Date: Fri, 23 Jun 2000 11:51:18 -0400

I don't have a problem with this simplification - but the spec says
an incoming request with Max-Forwards of 0 MUST NOT be forwarded.
It does not say that the request cannot be locally processed and a 
response returned. Since REGISTER (for the registrar) and CANCEL
will be absorbed by the proxy, I thought it is okay to process these
requests. 
The relevant statement in the spec should be appropriately changed -

request MUST NOT be forward and MUST NOT be processed.

Thanks,
Shail

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2000 15:35:34 -0400

> request MUST NOT be forward and MUST NOT be processed.

That is the proposal; as I said, I think it is very confusing otherwise. 

-Jonathan R.

---

From: Shail Bhatnagar <[email-masked]>
Date: Fri, 23 Jun 2000 15:42:16 -0400

Jonathan Rosenberg wrote:
> That is the proposal; as I said, I think it is very confusing >otherwise.

I thought behavior of registrars/redirect servers closely matches
user agents, in terms of request handling. Of course
there are differences. Per this proposal, a user agent will process a
request with Max-Forwards of 0 but registrars/redirect servers and
proxies will not. Is my understanding correct ??

Thanks,
Shail

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jun 2000 14:05:24 -0400

> proxies will not. Is my understanding correct ??

No. Any server (UA, proxy, redirect, registrar) receiving a request with
Max-Forwards zero responds with a 483 and does not process.

-Jonathan R.

---

From: Shail Bhatnagar <[email-masked]>
Date: Mon, 26 Jun 2000 15:44:16 -0400

> Max-Forwards zero responds with a 483 and does not process.

Okay, so any proxy should not forward a request with incoming
Max-Forwards 1, since if it forwards it, Max-Forwards will become
0 and the downstream guy will return 483.

Right ??

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jun 2000 16:22:25 -0400

> 0 and the downstream guy will return 483.

I suppose so, yes.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Jun 2000 16:33:35 -0400

> > 0 and the downstream guy will return 483.

But that would defeat the whole point of being able to figure out the
downstream capabilities, returned in the 483. Thus, a proxy should *not*
try to be too smart. After all, if IP routers did this, traceroute
wouldn't work...

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jun 2000 23:46:23 -0400

> try to be too smart. After all, if IP routers did this, traceroute

I was assuming that the proxy wouldn't say anything useful in the 483.
If it does contain a Supported header, then yes, you are right. Sooo,
seems like in general it is NOT a good idea to drop the request with
Max-Forwards 1. 

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Jun 2000 08:14:45 -0400

> -Jonathan R.

Another semi-interesting question is whether it is useful for any server
that returns a final response to include a "Server" header. That way,
one could find out which types of servers are along the path. (I suspect
that some people are including this in the Via header comment, but even
so, that information doesn't get back to the UAC.)
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs