Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite

Paul Kyzivat <pkyzivat@cisco.com> Thu, 11 November 2010 14:41 UTC

Return-Path: <pkyzivat@cisco.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 748DB3A695D for <sipcore@core3.amsl.com>; Thu, 11 Nov 2010 06:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.143
X-Spam-Level:
X-Spam-Status: No, score=-110.143 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, 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 QEzCasCclLpz for <sipcore@core3.amsl.com>; Thu, 11 Nov 2010 06:41:36 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0F89D3A68A0 for <sipcore@ietf.org>; Thu, 11 Nov 2010 06:41:36 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEqP20xAaMHG/2dsb2JhbACiQ3GlB5tYhUoEhFiGAIML
X-IronPort-AV: E=Sophos;i="4.59,183,1288569600"; d="scan'208";a="618200786"
Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2010 14:42:04 +0000
Received: from [10.75.233.107] (hkidc-vpn-client-233-107.cisco.com [10.75.233.107]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oABEg03w008522; Thu, 11 Nov 2010 14:42:02 GMT
Message-ID: <4CDC00B6.2020803@cisco.com>
Date: Thu, 11 Nov 2010 22:41:58 +0800
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Taisto Qvist <taisto.qvist@ericsson.com>
References: <613AADD0FA18314792D9A3F64FE2FB740D35B051A7@ESESSCMS0351.eemea.ericsson.se> <4CDA712B.6030300@cisco.com> <613AADD0FA18314792D9A3F64FE2FB740D35B056A3@ESESSCMS0351.eemea.ericsson.se>
In-Reply-To: <613AADD0FA18314792D9A3F64FE2FB740D35B056A3@ESESSCMS0351.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite
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, 11 Nov 2010 14:41:37 -0000

On 11/11/2010 5:05 PM, Taisto Qvist wrote:

>>      A UAS MAY send as many provisional responses as it likes.  Each of these MUST
>>      indicate the same dialog ID.  However, these will not be delivered reliably.
>>
>> Which implies to me, that a *single* UAS can not send multiple 1xx
>> with different tags?
>
> Perhaps this is a matter of terminology.
> If you prefer, consider the same box to contain multiple UAs, each of which received a forked copy of the request. Then each returns a single response with a unique to-tag.
> There are a number of cases where this is a viable strategy for handling various problems.
>
> [TQ]
> It most certainly is. But when I read that paragraph it doesnt indicate a generic endpoint which consists of multiple UAS:es that received several forked requests.
> Too me, it claims that a single UAS, that has received a *single* request, can respond to that single transaction, with multiple provisional responses, creating
> multiple early dialogs by using different tags. That seems to completely contradict rfc3261.
>
> But maybe I'm just beeing a bit to literal, although for interoperability reasons, I think that maybe we should be :-)

The way to think of this (its a conceptual model, not a real one) is 
that the UA may choose to virtually fork the request to several of its 
evil twins. Then each one of those can independently handle the request, 
with its own to-tag.

The fact that the forking happened without any message passing is 
irrelevant to the UAC - it all looks to the same as if the forking 
really happened.

	Thanks,
	Paul