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

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:adam@nostrum.com] 
Envoyé : jeudi 2 septembre 2010 19:17
À : CHADLI Youssef RD-CORE-ISS
Cc : sipcore@ietf.org
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, youssef.chadli@orange-ftgroup.com 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
	sipcore@ietf.org
	https://www.ietf.org/mailman/listinfo/sipcore