IETF Logo Mail Archive

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

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 18 November 2010 20:29 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 77CFB3A6834 for <sipcore@core3.amsl.com>; Thu, 18 Nov 2010 12:29:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.462
X-Spam-Level:
X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 kNt8mQqpe-rr for <sipcore@core3.amsl.com>; Thu, 18 Nov 2010 12:29:33 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 705783A6811 for <sipcore@ietf.org>; Thu, 18 Nov 2010 12:29:33 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJcb5UyHCzI1/2dsb2JhbACiV3GmJQKZHoVLBIRaiSY
X-IronPort-AV: E=Sophos;i="4.59,218,1288584000"; d="scan'208";a="250806975"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Nov 2010 15:30:20 -0500
X-IronPort-AV: E=Sophos;i="4.59,218,1288584000"; d="scan'208";a="540470483"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Nov 2010 15:30:20 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 18 Nov 2010 15:30:20 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Thu, 18 Nov 2010 15:30:19 -0500
Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy
Thread-Index: Act7Xx3W16gFkXjRTOqfHfUoU6Sk1wBuYItAApFaf6A=
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B2202288A33@DC-US1MBEX4.global.avaya.com>
References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <CD5674C3CD99574EBA7432465FC13C1B22022889B6@DC-US1MBEX4.global.avaya.com><9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com>, <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB853526421410221B4E3@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, 18 Nov 2010 20:29:36 -0000

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

If you take the example of a SIP Server which is inserted in the SIP path only to provide a supplementary service in case this latter is requested by the user ( e.g. call transfer), I think that the user will not be satisfied if it's call does not succeed just because the network is not able to provide this service...
_______________________________________________

If we are considering how Route is handled, the question is not the failure of the call to be connected, but rather once the call is established, if the server fails, ensuring that later in-dialog requests (e.g., REFER, BYE) succeed.

But in practice, devices that provide supplementary services are usually B2BUAs (even if they could be implemented as proxies, or nearly so), and the proposed mechanism will not rescue a call from a failed B2BUA.

Dale

v2.23.0 | Report a Bug | By Email