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

From: <[email-masked]>
Date: Fri, 29 Oct 2010 19:46:31 +0200

Thanks for this answer.

I understand that the intention of this text in RFC 3261 is to fail over to an alternate server that serves the same function. Though, it's not explicitly stated.

However, I did not find any text in RFC 3261 that would make forbidden failing over to a proxy further down the path.  Moreover, I did not see any problem to such behaviour.

Youssef 
________________________________

De : Adam Roach [mailto:[email-masked]] 
Envoyé : jeudi 2 septembre 2010 19:17
À : CHADLI Youssef RD-CORE-ISS
Cc : [email-masked]
Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy

[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: 

	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 

	_______________________________________________
	sipcore mailing list
	[email-masked]
	https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 29 Oct 2010 14:22:04 -0400

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

If a particular URI is included in a Route header, then there is some important function the server with that URI is to perform.  If one element ignores this URI and sends the request to the next URI in the Route header, presumably the function of the skipped server will not be performed.

In all cases that I have heard about, the correct way to provide alternate servers for a failed server is to construct a DNS SRV name which maps to the primary and alternate server as is desired.

For instance, if functionA is to be serviced by serverA but in an emergency the request can be routed to serverB, and if functionB is serviced by serverB, then we construct two SRV names:

functionA    SRV   serverA  priority=1
functionA    SRV   serverB  priority=2

functionB    SRV   serverB priority=1

and use this Route header:

Route:  sip:functionA, sip:functionB

If an element has a request with this Route header, it will send the request to sp:functionA using the RFC 3263 rules, viz., attempt to send to serverA, and if that fails, attempt to send to serverB.

Dale