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

Leon Portman <Leon.Portman@nice.com> Wed, 04 November 2009 07:58 UTC

Return-Path: <Leon.Portman@nice.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 296053A67C0 for <dispatch@core3.amsl.com>; Tue, 3 Nov 2009 23:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
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 AFmeiBg7ZCAO for <dispatch@core3.amsl.com>; Tue, 3 Nov 2009 23:58:40 -0800 (PST)
Received: from mailil.nice.com (tlvexc07.nice.com [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id AEB183A68B0 for <dispatch@ietf.org>; Tue, 3 Nov 2009 23:58:39 -0800 (PST)
Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 4 Nov 2009 09:58:58 +0200
From: Leon Portman <Leon.Portman@nice.com>
To: Alan Johnston <alan@sipstation.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Date: Wed, 04 Nov 2009 09:58:56 +0200
Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP
Thread-Index: Acpcyf9cQc7Gv/u7RAyfnE5VWPs2QQAWmnAQ
Message-ID: <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com>
References: <4AF09BF6.9010902@sipstation.com>
In-Reply-To: <4AF09BF6.9010902@sipstation.com>
Accept-Language: en-US, he-IL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, he-IL
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 04 Nov 2009 07:58:41 -0000

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