Re: [sipcore] Bypassing out-of-service intermediate Proxy
<youssef.chadli@orange-ftgroup.com> Wed, 03 November 2010 12:14 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 F0B1D3A6A9D for <sipcore@core3.amsl.com>; Wed, 3 Nov 2010 05:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level:
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, 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 y25eLKx0uSrw for <sipcore@core3.amsl.com>; Wed, 3 Nov 2010 05:14:23 -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 E42383A6825 for <sipcore@ietf.org>; Wed, 3 Nov 2010 05:14:22 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4FB068B813E; Wed, 3 Nov 2010 11:27:58 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 529628B8039; Wed, 3 Nov 2010 10:59:39 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Nov 2010 10:58:26 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 03 Nov 2010 10:55:41 +0100
Message-ID: <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22022889B6@DC-US1MBEX4.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy
Thread-Index: ActKwqukakXd2CSyR9G+Afh4w9O9dQsxhaSAAAMmKZUA6UXXwA==
References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <CD5674C3CD99574EBA7432465FC13C1B22022889B6@DC-US1MBEX4.global.avaya.com>
From: youssef.chadli@orange-ftgroup.com
To: dworley@avaya.com, adam@nostrum.com
X-OriginalArrivalTime: 03 Nov 2010 09:58:26.0218 (UTC) FILETIME=[A89B90A0:01CB7B3D]
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: Wed, 03 Nov 2010 12:14:24 -0000
I understand that the usage of DNS to provide alternate server is a way to ensure redundancy. In such solution, to be able to handle SIP requests inside a SIP dialog and for which the proxy need to be "dialog statefull", there is a need to implement a mechanism that would allow the "alternate" server to share the same SIP dialog contexts. My idea is in case of unavailability of the next hop and in case no alternate server is returned by DNS (or alternate servers are unreachable too), instead of rejecting the request (which would make the call/session fails), the SIP Proxy may send it to the hop after the unreachable one in the Route. This alternative would be authorized only if the Proxy knows that it's better to bypass the unreachable node instead of rejecting the request. The SIP proxy may get this information via a URI parameter in the Route entry of the "unreachable" node for example Best regards, Youssef -----Message d'origine----- De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] Envoyé : vendredi 29 octobre 2010 20:22 À : CHADLI Youssef RD-CORE-ISS; adam@nostrum.com Cc : sipcore@ietf.org Objet : RE: [sipcore] Bypassing out-of-service intermediate Proxy ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of youssef.chadli@orange-ftgroup.com [youssef.chadli@orange-ftgroup.com] 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. ________________________________ 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
- [sipcore] Bypassing out-of-service intermediate P… youssef.chadli
- Re: [sipcore] Bypassing out-of-service intermedia… Adam Roach
- Re: [sipcore] Bypassing out-of-service intermedia… Worley, Dale R (Dale)
- Re: [sipcore] Bypassing out-of-service intermedia… youssef.chadli
- Re: [sipcore] Bypassing out-of-service intermedia… Worley, Dale R (Dale)
- Re: [sipcore] Bypassing out-of-service intermedia… youssef.chadli
- Re: [sipcore] Bypassing out-of-service intermedia… Paul Kyzivat
- Re: [sipcore] Bypassing out-of-service intermedia… youssef.chadli
- Re: [sipcore] Bypassing out-of-service intermedia… Paul Kyzivat
- Re: [sipcore] Bypassing out-of-service intermedia… youssef.chadli
- Re: [sipcore] Bypassing out-of-service intermedia… Paul Kyzivat
- Re: [sipcore] Bypassing out-of-service intermedia… Worley, Dale R (Dale)
- Re: [sipcore] Bypassing out-of-service intermedia… Christer Holmberg
- Re: [sipcore] Bypassing out-of-service intermedia… Paul Kyzivat
- Re: [sipcore] Bypassing out-of-service intermedia… Christer Holmberg
- Re: [sipcore] Bypassing out-of-service intermedia… Paul Kyzivat
- Re: [sipcore] Bypassing out-of-service intermedia… Christer Holmberg
- Re: [sipcore] Bypassing out-of-service intermedia… Worley, Dale R (Dale)
- Re: [sipcore] Bypassing out-of-service intermedia… Christer Holmberg