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

Christer Holmberg <> Mon, 29 November 2010 06:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FC343A6BF9 for <>; Sun, 28 Nov 2010 22:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.463
X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vhvARSgZmse2 for <>; Sun, 28 Nov 2010 22:45:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 45BA03A6BFC for <>; Sun, 28 Nov 2010 22:45:07 -0800 (PST)
X-AuditID: c1b4fb3d-b7b8cae0000016b1-95-4cf34c37b1a8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 17.4E.05809.73C43FC4; Mon, 29 Nov 2010 07:46:15 +0100 (CET)
Received: from ([]) by ([]) with mapi; Mon, 29 Nov 2010 07:46:15 +0100
From: Christer Holmberg <>
To: Paul Kyzivat <>
Date: Mon, 29 Nov 2010 07:42:54 +0100
Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy
Thread-Index: AcuPcQ2LO/H5UYixQPOKlQtg+raSVgAH5kno
Message-ID: <>
References: <><>, <> <><> <> <> <> <>, <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>, "" <>
Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Nov 2010 06:45:24 -0000


>>Not exactly the same case that Youssef is talking about, but every now and then I have had discussions that 
>>it would be useful to be able to re-negotiate the route set (not only the local/remote targets, but also the 
>>record-routes) during a dialog. E.g. in Outbound cases it could be used to move ongoing dialogs from a 
>>failed flow to another (it is not always possible to achieve it by using domain names and DNS).
>>A problem is of course backward compability, becuase you would need to ensure that every intermediary 
>>that wants to remain in the route set inserts Record-Route in every re-INVITE/UPDATE (or whatever 
>>request is used to re-negotiate the route set).
>>No, I did not suggest that we start work on such functionality :)
>We already have a way to do that: INVITE with Replaces.

Sure, but that requires the establishment of a new session. 

Because I don't think it's allowd to send a re-INVITE, in order for a session to replace "itself", is it?