IETF Logo Mail Archive

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

<youssef.chadli@orange-ftgroup.com> Fri, 29 October 2010 17:44 UTC

Return-Path: <youssef.chadli@orange-ftgroup.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30843A694C for <sipcore@core3.amsl.com>; Fri, 29 Oct 2010 10:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level:
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGWPkzWg37CX for <sipcore@core3.amsl.com>; Fri, 29 Oct 2010 10:44:39 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id E3D493A67FC for <sipcore@ietf.org>; Fri, 29 Oct 2010 10:44:38 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 775F38B8005; Fri, 29 Oct 2010 19:47:18 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 6C9A28B8002; Fri, 29 Oct 2010 19:47:18 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Oct 2010 19:46:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7791.38F68DC2"
Date: Fri, 29 Oct 2010 19:46:31 +0200
Message-ID: <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4C7FDBEE.6080305@nostrum.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy
Thread-Index: ActKwqukakXd2CSyR9G+Afh4w9O9dQsxhaSA
References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr> <4C7FDBEE.6080305@nostrum.com>
From: <youssef.chadli@orange-ftgroup.com>
To: <adam@nostrum.com>
X-OriginalArrivalTime: 29 Oct 2010 17:46:30.0864 (UTC) FILETIME=[384BB500:01CB7791]
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2010 17:44:42 -0000

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

v2.8.10 | Report a Bug | By Email