Subject: [Sip] Question of looseroute draft

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Jan 2002 00:22:48 +0200

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)?

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...

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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 17 Jan 2002 10:28:40 -0500

> >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.
> 
> 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?

Ok, to getting a little closer to your case, bigplace discovers that
callcenter.net has no DNS records at the moment or is configured to
not leave the company over anything but TLS (which callcenter.net
doesn't support) or learns that it is about to be taken out of service.
There are appropriate response codes for those, and they aren't all 
the same. My point is that whatever would have been appropriate in
the absence of Route will still be appropriate in the presence of
Route.