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

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 02 September 2010 18:15 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 8CB733A6AC1 for <sipcore@core3.amsl.com>; Thu, 2 Sep 2010 11:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.413
X-Spam-Level:
X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, 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 g5SlLUuTHIbK for <sipcore@core3.amsl.com>; Thu, 2 Sep 2010 11:15:17 -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 6B8D33A6B71 for <sipcore@ietf.org>; Thu, 2 Sep 2010 11:01:11 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,308,1280721600"; d="scan'208";a="205719410"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Sep 2010 14:01:40 -0400
X-IronPort-AV: E=Sophos;i="4.56,308,1280721600"; d="scan'208";a="511596502"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Sep 2010 14:01:39 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 2 Sep 2010 14:01:39 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "youssef.chadli@orange-ftgroup.com" <youssef.chadli@orange-ftgroup.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Date: Thu, 02 Sep 2010 13:58:37 -0400
Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy
Thread-Index: ActKv8TggzTYUuFvQcWqPQhNQ1ErbQACLLNl
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C05@DC-US1MBEX4.global.avaya.com>
References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@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
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: Thu, 02 Sep 2010 18:15:18 -0000

________________________________________
From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of youssef.chadli@orange-ftgroup.com [youssef.chadli@orange-ftgroup.com]

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?
_________________________________________

It is an interesting and novel idea, but I am sure that nobody has considered it to be correct behavior.

However, there is an alternative technique that achieves the effect you desire:  When a proxy adds a Record-Route header for itself, it should not use its hostname, but rather a DNS name with a set of SRV records that specify itself (at high priority) and one or more alternative proxies (at lower priority).  This will cause later requests in the same dialog to be routed through itself (as long as it remains functional) but if it fails, the upstream element can send the request to one of the alternative proxies.

Dale