Re: third alternative (was RE: [Sip] RE: Identity after reinvite)

David R Oran <oran@cisco.com> Fri, 19 November 2004 14:43 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06571 for <sip-web-archive@ietf.org>; Fri, 19 Nov 2004 09:43:28 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVA1p-00061E-Fh for sip-web-archive@ietf.org; Fri, 19 Nov 2004 09:46:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV9vG-0001gV-Ay; Fri, 19 Nov 2004 09:39:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV9mg-00084q-Lj for sip@megatron.ietf.org; Fri, 19 Nov 2004 09:30:46 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05470 for <sip@ietf.org>; Fri, 19 Nov 2004 09:30:45 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV9pV-0005ix-Py for sip@ietf.org; Fri, 19 Nov 2004 09:33:43 -0500
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Nov 2004 06:32:38 -0800
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAJEU63O006520; Fri, 19 Nov 2004 06:30:06 -0800 (PST)
Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAJEUNEr000793; Fri, 19 Nov 2004 06:30:23 -0800
In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597089952@stntexch03.cis.neustar.com>
References: <24EAE5D4448B9D4592C6D234CBEBD597089952@stntexch03.cis.neustar.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <8393BB1D-3A37-11D9-8BE3-000A95C73842@cisco.com>
Content-Transfer-Encoding: 7bit
From: David R Oran <oran@cisco.com>
Subject: Re: third alternative (was RE: [Sip] RE: Identity after reinvite)
Date: Fri, 19 Nov 2004 09:30:08 -0500
To: "Peterson, Jon" <jon.peterson@neustar.biz>
X-Mailer: Apple Mail (2.619)
IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1100874624.293188"; x:"432200"; a:"rsa-sha1"; b:"nofws:1504"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"E3GSNOygrtu3kb0kTqeBZIn9qbEWTvmtlTcwcR+Xgoi+n7raOyQFbAlhaBFsa" "ca99NrBOKS2hb3dFI0EAMsUABbNn5emOjQQ7VDOfm6WA9Z6YHin12cnZ0dHL6" "8OiDPXmy/ahgiKNldLM/kg0O+isU0W0trT2SplGsjx6RSxAJM="; c:"From: David R Oran <oran@cisco.com>"; c:"Subject: Re: third alternative (was RE: [Sip] RE: Identity after reinv" "ite)"; c:"Date: Fri, 19 Nov 2004 09:30:08 -0500"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: 7bit
Cc: 'Cullen Jennings' <fluffy@cisco.com>, "'sip@ietf.org'" <sip@ietf.org>, 'Paul Kyzivat' <pkyzivat@cisco.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: 7bit

On Nov 18, 2004, at 3:46 PM, Peterson, Jon wrote:
>> One solution to this would be for for the biloxi.com server to act as 
>> a
>> b2bua, relaying the call to carol. Maybe that is a *model* to 
>> consider,
>> with hopes of finding a better implementation. That is also roughly 
>> the
>> model when a gateway is being used. We already know that in the 
>> gateway
>> case the connected party on the far side of the gateway can change, 
>> and
>> there are desires to convey that info.
>>
>
> (weep)
>
> Maybe we could at least consider redirection before we start 
> suggesting that
> this is a B2BUA problem.
>
Redirection is generally cleaner than retargeting, but does not satisfy 
the "Monica property". It may be that a B2BUA is inescapable in those 
cases anyway.

> I really think that the problem of mid-call changes in connected-party 
> is a
> very different case, and much more specialized than what we're 
> concerned
> with here. We're talking here about assuring the identity of the first 
> and
> second parties to a dialog at the time of dialog establishment. I'd 
> like to
> think that the ultimate solutions to the mid-call 'identity update' 
> sort of
> problems are more along the transfer/replaces line of thinking.
>
I tend to agree. It would be much cleaner if all 
identity/connected-party changes devolved to a flavor of transfer 
(except the Monica cases I mention above).

Dave.
> Jon Peterson
> NeuStar, Inc.
>
>> 	Paul
>>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip