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

Paul Kyzivat <pkyzivat@cisco.com> Thu, 05 November 2009 00:10 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 BB90528C0DF for <dispatch@core3.amsl.com>; Wed, 4 Nov 2009 16:10:36 -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 U7sY9D8D2WZl for <dispatch@core3.amsl.com>; Wed, 4 Nov 2009 16:10:35 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 25E7A3A682B for <dispatch@ietf.org>; Wed, 4 Nov 2009 16:10:35 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjAHAFun8UpAZnwM/2dsb2JhbAAHxi6XcIQ9BA
X-IronPort-AV: E=Sophos;i="4.44,682,1249257600"; d="scan'208";a="66434688"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Nov 2009 00:10:56 +0000
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA50AuEV014049; Thu, 5 Nov 2009 00:10:56 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); Wed, 4 Nov 2009 19:10:56 -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); Wed, 4 Nov 2009 19:10:56 -0500
Message-ID: <4AF2180E.2070906@cisco.com>
Date: Wed, 04 Nov 2009 19:10:54 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Leon Portman <Leon.Portman@nice.com>
References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com> <4AF18822.4070603@cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5B7D@TLVMBX01.nice.com>
In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D6AF5B7D@TLVMBX01.nice.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Nov 2009 00:10:56.0087 (UTC) FILETIME=[71F12E70:01CA5DAC]
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: Thu, 05 Nov 2009 00:10:36 -0000

Leon Portman wrote:
> I will try to explain my case.
> 
> The use case for example is a customer is calling to an organization via SIP trunk with some UUI info from the hosted IVR session (business data). He is connected to an agent and then was put on hold, triggering REINVITE with updated SDP. And then transferred to another agent. Under assumption that UUI represents some kind business data state of the call (IVR selection, customer ID etc), this information has to be preserved during all session changes. It is not transient state that is delivered via INFO.
> Or even more complex, the call is transferred via SIP trunk to completely another PBX as another SIP session (B2BUA scenario).

So you are making the case that this is *state* that must remain 
synchronized over time, not just transient information for call 
establishment.

But that supports my argument that this is generalized 
application-application tunneling over sip.
As such it overlaps greatly with the charter for INFO.
We then end up with two mechanisms, one using headers and the other 
using bodies.
- INFO can build on the rich structure of MIME definitions
   but it can't be used until at least an early dialog is established

- The proposed UUI mechanism has to be embedded in headers,
   and has a much more limited representation mechanism built up.
   (But could you embed arbitrarily complex MIME bodies into a
   UUI header value?) It can be used earlier, and in contexts
   where INFO can't.

As best I can tell, in practice, the UUI stuff will only be used where 
the data formats are already established for use in legacy PSTN 
equipment. As that stuff gets cut over to SIP infrastructure we will be 
left with applications having to use encodings that are no longer at all 
natural. (E.g. need to find something that can encode/decode ASN.1 stuff 
in an application that uses it for nothing else.)

And this is all in spite of long resistance to using SIP for tunneling 
in general.

	Just grumbling,
	Paul

> Thanks
> 
> Leon
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: Wednesday, November 04, 2009 3:57 PM
> To: Leon Portman
> Cc: Sanjay Sinha (sanjsinh); Alan Johnston; dispatch@ietf.org
> Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP
> 
> 
> 
> Leon Portman wrote:
>> Actually I was thinking that if UUI was presented during the original INVITE, if it is going to be required to be presented during RE_INVITES as well, especially if it represents some client state information
> 
> Can you explain more about this?
> 
> The charter seems to spend its time explaining that this is governed by 
> the needs for session setup. If this is a mechanism that is also 
> intended for use after the session is established, then I think more 
> explanation is required.
> 
> As described, this is just plain tunneling, pure and simple.
> And INFO (expecially with the new Info-Package work) is yet another 
> mechanism for tunneling. The rationale for not using INFO for UUI is 
> that it is needed during session establishment. Clearly that doesn't 
> apply after the session is established.
> 
> Of course its a mess to have two mechanisms with overlapping purposes. 
> It would be silly to use two mechanisms to transport the same 
> information, depending on when in the lifetime of the session the info 
> was being transported. But I'm having difficulty drawing a clear 
> distinction between the applicability of the two mechanisms.
> 
> 	Thanks,
> 	Paul
> 
>> Leon
>>
>> -----Original Message-----
>> From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] 
>> Sent: Wednesday, November 04, 2009 11:18 AM
>> To: Leon Portman; Alan Johnston; dispatch@ietf.org
>> Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP
>>
>> I think UUI is carried during session setup and teardown, and hence
>> re-Invite scenario may not be applicable here.
>>
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
>> Behalf Of Leon Portman
>> Sent: Wednesday, November 04, 2009 1:29 PM
>> To: Alan Johnston; dispatch@ietf.org
>> Subject: Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for
>> SIP
>>
>> Only one comment, does it also supposed to support re-invite (for SRTP
>> re-keying or media updates) scenarios as well?
>>
>> Thanks
>>
>> Leon
>>
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
>> Behalf Of Alan Johnston
>> Sent: Tuesday, November 03, 2009 11:09 PM
>> To: dispatch@ietf.org
>> Subject: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP
>>
>> All,
>>
>> Here is some updated charter text for CCUS.  Comments are most welcome.
>>
>> Thanks,
>> Alan
>>
>> - - - - -
>>
>> The Call Control UUI for SIP  (CCUS) working group is chartered to 
>> define a SIP mechanism for transporting call control related 
>> user-to-user (UUI) information between User Agents.
>>
>> The mechanism developed in this working group is generally appropriate 
>> in the following situations:
>> 1. The information is generated and consumed by an application using SIP
>>
>> during session setup but the application is not necessarily even SIP
>> aware.
>> 2. SIP behavior is unchanged.
>> 3. Generally only the UAC and UAS are interested in the information.
>> 4. The information is expected to survive retargeting, redirection, and 
>> retargeting.
>> 5. SIP elements may need to apply policy about passing and screening the
>>
>> information.
>> 6. Multi-vendor interoperability is important.
>>
>> This mechanism is not appropriate in the following situations:
>> 1. SIP behavior is changed.
>> 2. The information is generated and consumed at the SIP layer by SIP 
>> elements.
>> 3. SIP elements besides the UAC and UAS might be interested and consume 
>> the information.
>> 4. There are specific privacy or cross-RAI issues involved with the 
>> information being transported.
>>
>> User data of the mechanism will be clearly marked with the application, 
>> encoding, semantics, and contents of the data, allowing policy to be 
>> applied by UAs.  The working group will define the information which 
>> each application must specify in a standards-track document to utilize 
>> the mechanism.
>>
>> One important application of this mechanism is interworking with the 
>> ISDN User to User Information Service.  This application defined by 
>> ITU-T Q.931, is extensively deployed in the PSTN today, supporting such 
>> applications as contact centers, call centers, and automatic call 
>> distributors (ACDs).  A major barrier to the movement of these 
>> applications to SIP is the lack of a standard mechanism to transport 
>> this information in SIP.   For interworking with ISDN, minimal 
>> information about the content of the UUI is available.  In this case 
>> only, the content will just indicate ISDN UUI Service 1 interworking 
>> rather than the actual content.
>>
>> Call control UUI is user information conveyed between user agents during
>>
>> call control operations.  As a result, the information must be conveyed 
>> with the INVITE transaction, and must survive proxy retargeting, 
>> redirection, and transfers.  The mechanism must utilize a minimum of SIP
>>
>> extensions as it will need to be supported by many simple SIP user 
>> agents such as PSTN gateways.  The mechanism must interwork with the 
>> existing ISDN service but should also be extensible for use by other 
>> applications and non-ISDN protocols.
>>
>> While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI
>>
>> can be generated by a number of protocols that are not ISUP, and as such
>>
>> it is architecturally unreasonable to interwork these protocols at the 
>> SIP / ISUP gateway. That is, existing SIP-T approaches defined in 
>> RFC3372 do not meet the requirements.
>>
>> Mechanisms based on the SIP INFO method, RFC2976, will not be considered
>>
>> by the working group since the UUI contents carry information that must 
>> be conveyed during session setup at the user agent - the information 
>> must be conveyed with the INVITE transaction.  The information must be 
>> passed with the session setup request (INVITE), responses to that 
>> INVITE, or session termination requests.  As a result, it is not 
>> possible to use INFO in these cases.
>>
>> The group will produce:
>>
>> - A problem statement and requirements document for implementing a SIP 
>> call control UUI mechanism
>>
>> - A specification of the SIP extension to best meet those requirements.
>>
>> Goals and Milestones
>> ====================
>>
>> Mar 10 - Problem statement and requirements document to IESG 
>> (Informational)
>> Aug 10 - SIP call control UUI specification to IESG (PS)
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>