Subject: [sipcore] Bypassing out-of-service intermediate Proxy

From: <[email-masked]>
Date: Thu, 2 Sep 2010 18:56:21 +0200

Hi all,

I have a question regarding routeing of SIP requests and usage of ROUTE.

When a proxy or UA fails to send a SIP request to the next hop (because
this latter is not reachable) is it allowed to bypass this hop and send
the request to the hop whose URI is next in ROUTE header.

According to section 21.5.4 of RFC 3261, this proxy behaviour seems
allowed. See text in bold below:

Any opinions on this?

21.5.4 503 Service Unavailable

The server is temporarily unable to process the request due to a
temporary overloading or maintenance of the server.  The server MAY
indicate when the client should retry the request in a Retry-After
header field.  If no Retry-After is given, the client MUST act as if it
had received a 500 (Server Internal Error) response.

A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
attempt to forward the request to an alternate server.  It SHOULD NOT
forward any other requests to that server for the duration specified in
the Retry-After header field, if present.

Servers MAY refuse the connection or drop the request instead of
responding with 503 (Service Unavailable).

Youssef CHADLI
Orange Labs

---

From: Adam Roach <[email-masked]>
Date: Thu, 02 Sep 2010 12:16:30 -0500

[as participant]

This is talking about failing over to an alternate server that serves 
the same function, not a proxy further down the path. This is a bit 
clearer if you look at section 4.3 of RFC 3263.

Trying to fail "around" the server by going to the next network element 
in the route would *not* be compliant with RFC 3261 behavior.

/a

On 9/2/10 11:56 AM, [email-masked] wrote:
> When a proxy or UA fails to send a SIP request to the next hop 
> (because this latter is not reachable) is it allowed to bypass this 
> hop and send the request to the hop whose URI is next in ROUTE header.
>
> */21.5.4 503 Service Unavailable/*
>
>
> /The server is temporarily unable to process the request due to a 
> header field.  If no Retry-After is given, the client MUST act as if 
> it had received a 500 (Server Internal Error) response./
>
> /A client (proxy or UAC) receiving a 503 (Service Unavailable)* SHOULD 
> attempt to forward the request to an alternate server.*  It SHOULD NOT 
> forward any other requests to that server for the duration specified 
> in the Retry-After header field, if present./
>
> /Servers MAY refuse the connection or drop the request instead of 
> responding with 503 (Service Unavailable)./
>
>
> Youssef CHADLI
> Orange Labs
>
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 2 Sep 2010 13:58:37 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]

When a proxy or UA fails to send a SIP request to the next hop (because this latter is not reachable) is it allowed to bypass this hop and send the request to the hop whose URI is next in ROUTE header.

According to section 21.5.4 of RFC 3261, this proxy behaviour seems allowed. See text in bold below:

Any opinions on this?
_________________________________________

It is an interesting and novel idea, but I am sure that nobody has considered it to be correct behavior.

However, there is an alternative technique that achieves the effect you desire:  When a proxy adds a Record-Route header for itself, it should not use its hostname, but rather a DNS name with a set of SRV records that specify itself (at high priority) and one or more alternative proxies (at lower priority).  This will cause later requests in the same dialog to be routed through itself (as long as it remains functional) but if it fails, the upstream element can send the request to one of the alternative proxies.

Dale