Re: [Sip] Changing route set in SIP outbound

"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 07 February 2011 22:11 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2813A6EA8 for <sip@core3.amsl.com>; Mon, 7 Feb 2011 14:11:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3qRXlFCm7SpX for <sip@core3.amsl.com>; Mon, 7 Feb 2011 14:11:25 -0800 (PST)
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 305873A6EFE for <sip@ietf.org>; Mon, 7 Feb 2011 14:11:23 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEf9T02HCzI1/2dsb2JhbAClJXOgZwKYaoVaBIR6ijU
X-IronPort-AV: E=Sophos;i="4.60,438,1291611600"; d="scan'208";a="231312058"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Feb 2011 17:11:27 -0500
X-IronPort-AV: E=Sophos;i="4.60,438,1291611600"; d="scan'208";a="595278018"
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Feb 2011 17:11:26 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.215]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 7 Feb 2011 17:11:26 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Avshalom Houri <AVSHALOM@il.ibm.com>, "sip@ietf.org" <sip@ietf.org>
Date: Mon, 07 Feb 2011 17:11:24 -0500
Thread-Topic: [Sip] Changing route set in SIP outbound
Thread-Index: AcurWnai1dk3z8n9SsmNgTGsfRYPxAbuMCAK
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B220A176851@DC-US1MBEX4.global.avaya.com>
References: <OF9E7C0622.288AC539-ONC225780D.005405A1-C225780D.0054B652@il.ibm.com>
In-Reply-To: <OF9E7C0622.288AC539-ONC225780D.005405A1-C225780D.0054B652@il.ibm.com>
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: "fluffy@cisco.com" <fluffy@cisco.com>, "rohan@ekabal.com" <rohan@ekabal.com>, "francois.audet@skypelabs.com" <francois.audet@skypelabs.com>
Subject: Re: [Sip] Changing route set in SIP outbound
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2011 22:11:35 -0000

________________________________________
From: sip-bounces@ietf.org [sip-bounces@ietf.org] On Behalf Of Avshalom Houri [AVSHALOM@il.ibm.com]

Assume that the first SIP proxy that is part of the route set (in SIP outbound)
crashes and immediately restarts, or a backup proxy takes over. Is there any way to keep the dialog alive if either of the
endpoints senses this failure and recreates a connection or the dialog is doomed and needs to be
fully recreated again? The issue is that the route set includes the connection information, which is no longer valid.
________________________________________

Here's an idea:  When an outbound REGISTER reaches the registrar, it records the ob URI that the edge proxy created in a hidden location in the registration.  As part of the Path, it inserts an ob URI that it creates that contains the registrar's hostport, and a representation of the SIP user-part and sip-instance.  Now, when a new INVITE is sent to the phone, or otherwise when the ob URI is used, the request goes to the registrar, which then forwards it to one or another of the real ob URIs for the phone.  Indeed, I think that the phone's GRUU can be used for the new ob URI.  All that lets the selection of the flow to use to reach the phone to be made on a request-by-request basis.

Dale