Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP

Paul Kyzivat <pkyzivat@cisco.com> Mon, 09 November 2009 16:19 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137103A6AE5 for <dispatch@core3.amsl.com>; Mon, 9 Nov 2009 08:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.595
X-Spam-Level:
X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 jasO27pJZPR0 for <dispatch@core3.amsl.com>; Mon, 9 Nov 2009 08:19:03 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 281B73A677D for <dispatch@ietf.org>; Mon, 9 Nov 2009 08:19:03 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAMPP90pAZnwN/2dsb2JhbADHUZZphD4E
X-IronPort-AV: E=Sophos;i="4.44,709,1249257600"; d="scan'208";a="268279296"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2009 16:19:29 +0000
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA9GJTs1001064; Mon, 9 Nov 2009 16:19:29 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:19:28 -0500
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:19:28 -0500
Message-ID: <4AF84110.90003@cisco.com>
Date: Mon, 09 Nov 2009 11:19:28 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Alan Johnston <alan@sipstation.com>
References: <4AF09BF6.9010902@sipstation.com> <EDC0A1AE77C57744B664A310A0B23AE2092E579D@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <4AF7B96F.1020905@sipstation.com>
In-Reply-To: <4AF7B96F.1020905@sipstation.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Nov 2009 16:19:28.0694 (UTC) FILETIME=[69684D60:01CA6158]
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 16:19:04 -0000

Comment at end

Alan Johnston wrote:

>> 3)    I am somewhat concerned that the focus now appears to be on SIP 
>> UA to SIP UA, rather than interworking with other signalling systems 
>> that also carry such information. Where we have a SIP UA talking to a 
>> SIP UA, For at least some of the usages where a SIP UA is talking to a 
>> SIP UA, we may well already have SIP mechanisms in place to support this. 
> 
> The previous charter text had an ISDN interworking focus, but the 
> consensus in the DISPATCH meeting was that there was strong interest in 
> UUI outside ISDN interworking.
> 
>> In general, we should be focussing on those existing usages 
>> transported in other protocols, and any new pure SIP usage should go 
>> through the normal SIP extension considerations. With the focus as it 
>> currently appears, we could end up spending years defining a fully 
>> proper solution, whereas I believe we need something quicker and 
>> potentially less than perfect for the SIP UA to SIP UA scenarios. Note 
>> that by SIP UA I am talking about a real SIP endpoint here, not the UA 
>> that may form part of an interworking gateway.
>>   
> This is an important scope issue for the charter.
> 
> I understand your concern.  I am hopeful that we will not end up with a 
> complicated solution and that the mechanism will work for both ISDN and 
> non-ISDN approaches.
> 
> I think that enough people care strongly about the ISDN interworking 
> case that if the mechanism discussions bog down, that the WG could 
> recharter to deliver two mechanisms - one for ISDN interworking and 
> another more  general mechanism.  However, I'd prefer not to start with 
> that approach until we have proven that a single mechanism is too complex.
> 
> Do others have an opinion on this?

My concern all along has been that if one focuses on ISDN interworking,
then what happens when the user that used to have an ISDN device decides 
to upgrade to a new SIP device, and we then have e2e sip connectivity?

The likely scenario is that *nothing* will change. The new device will 
be expected to emulate the behavior of the ISDN device including using 
the ISDN-style UUI mechanism, even though it is not "natural" in an 
all-sip environment.

OTOH, if you start with a UUI mechanism that is "sip-friendly" but can 
also be translated to the ISDN mechanisms when necessary, then the 
migration is much smoother. And you might avoid having ISDN-isms 
lingering after ISDN itself is gone.

The argument I hear against this is that the ISDN encoding itself is 
opaque - pure tunneling of bits. But the protocol discriminator is 
supposed to deal with that isn't it? The values that the discriminator 
can take on, and the encoding of the remainder for each discriminator 
value but be standardized somewhere.

I think a "natural" encoding for sip would have to consider each 
discriminator value, and what an appropriate encoding would be for that 
case.

	Thanks,
	Paul