Subject: RE: [Sip] Question of looseroute draft

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Jan 2002 17:34:59 -0500

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 4:23 PM
> To: [email-masked]
> Subject: [Sip] Question of looseroute draft
> 
> 
> 
> Hi,
> 
> A cople of questions/clarifications on the looseroute draft.
> 
> First, assume that a UAC inserts a preloaded route in the 
> initial INVITE
> request, and the message is then received by a proxy. Now, 
> for whatever
> policy/management/whatever reason the proxy is not allowed, 
> or does not
> want to, forward the request to the next node in the node. 
> Should there
> be a specific response code to indicate that to the client, or can an
> existing code be used? Also, would it be useful to somehow in the
> response include the Route header which caused the error response, so
> that the client can (if possible) try another route (if available)?

Adding such a thing would definitely be new behavior.
The existing response codes should be sufficient. Consider
the case where Route is not involved. A request goes out,
traverses a few proxies getting its Request-URI rewritten,
and runs into one of the conditions you mention above. What
response, and how much information is returned then? Here's
a specific example:

A UA sends an invite to sip:[email-masked]. A proxy at 
bigplace.com forwards the request to sip:[email-masked].
But callcenter.net doesn't have an agent57, so it 404s. 
The original UA gets no information about agent57 being the failpoint.

> 
> Second, just to clarify, my understanding of the draft is that it is 
> allowed for a proxy to insert a preloaded route in a request 
> it receives
> from a client, as long as it doesn't remove/modify any possible Route
> headers in the received message? The UAC may have no idea 
> which proxies,
> ie which route, the request shall "visit", so...

Yes - more specifically, a proxy can push values onto the front of the
route stack.

> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Jan 2002 09:03:32 +0200

Hi,

>>initial INVITE request, and the message is then received by a proxy. Now,
>>for whatever policy/management/whatever reason the proxy is not allowed,
>>or does not want to, forward the request to the next node in the node.
>>Should there be a specific response code to indicate that to the client, or can an

True, but that is a little different case, because now the message has
at least been sent to callcenter.net, which then doesn't find the user.

My case was when a proxy process the route, and the finds out that the
next hop is a "forbidden" hop (ie the proxy is not allowed to - for
whatever reason - send the message to callcenter.com in the first
place), so it won't even try to send the message there. I don't think
404 is the right code in that case. Maybe 485?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jan 2002 15:35:00 -0500

> 404 is the right code in that case. Maybe 485?

Let me make sure I understand. You want to know what a proxy should do 
if the next Route header is one it is not willing to honor? For example, 
if bigplace.com is administratively forbidden from sending to 
callcenter.com, but callcenter.com was in a Route header received in a 
request sent to bigplace.com?

In other words, you are worrying about the case where a user has 
constructed a loose route through elements which, as a result of 
administrative policy, cannot be visited in that order.

The answer is clear; it can loose route the request to whatever elements 
it is allowed to send to. If, for some reason, it cannot loose route it 
somewhere, but cannot honor the route, well, I think 403 is fine.

I will furhter add that this case just shouldn't happen. One cannot 
arbitrarily insert loose routes. A route set needs to be TOLD to you, 
either through headers (like Record-ROute, Path) or through 
administrative configuration when you know what those headers should be. 
Any other case won't work for many reasons.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Jan 2002 00:49:56 +0200

Hi,

>administrative policy, cannot be visited in that order.

Yes.
 
>Any other case won't work for many reasons.

Yes, but that administrative configuration may not be up to date with
things like temporary network failures etc, proxies temporary taken out
of service, temporary new routes because of those issues, etc etc etc.
In a mobile world the server may also be "out of reach" for certain
periods... Also, if Record-Route was used to tell me the route, I may
have received it who-knows-when, and it may not more valid anymore...  

That actually brings another question: should be allow expires
parameters in R-R too (like in Contact)?

I think 403 is fine, and I guess the Retry-After header could be
included to tell when the client may try again - IF the route is valid
as such. The question is that if it should be mentioned in the draft?

Regards,

Christer Holmberg
Ericsson Finland