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

"Worley, Dale R (Dale)" <dworley@avaya.com> Fri, 29 October 2010 18:20 UTC

Return-Path: <dworley@avaya.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 E36D53A69FF for <sipcore@core3.amsl.com>; Fri, 29 Oct 2010 11:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.843
X-Spam-Level:
X-Spam-Status: No, score=-101.843 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, USER_IN_WHITELIST=-100]
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 K3MqTHQkxajb for <sipcore@core3.amsl.com>; Fri, 29 Oct 2010 11:20:32 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9C2573A69C4 for <sipcore@ietf.org>; Fri, 29 Oct 2010 11:20:31 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,260,1286164800"; d="scan'208";a="215962274"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Oct 2010 14:22:06 -0400
X-IronPort-AV: E=Sophos;i="4.58,260,1286164800"; d="scan'208";a="534432196"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Oct 2010 14:22:05 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 29 Oct 2010 14:22:05 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "youssef.chadli@orange-ftgroup.com" <youssef.chadli@orange-ftgroup.com>, "adam@nostrum.com" <adam@nostrum.com>
Date: Fri, 29 Oct 2010 14:22:04 -0400
Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy
Thread-Index: ActKwqukakXd2CSyR9G+Afh4w9O9dQsxhaSAAAMmKZU=
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22022889B6@DC-US1MBEX4.global.avaya.com>
References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr> <4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <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 18:20:33 -0000

________________________________________
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