Re: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP
"Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com> Wed, 04 November 2009 11:44 UTC
Return-Path: <sanjsinh@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 2170D3A68BB for <dispatch@core3.amsl.com>; Wed, 4 Nov 2009 03:44:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level:
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 HaNfXWPmCjM8 for <dispatch@core3.amsl.com>; Wed, 4 Nov 2009 03:44:14 -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 A30543A6966 for <dispatch@ietf.org>; Wed, 4 Nov 2009 03:44:14 -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: ApoEAJP38EqrR7H+/2dsb2JhbADEfJg+hD0E
X-IronPort-AV: E=Sophos;i="4.44,679,1249257600"; d="scan'208";a="266010018"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 04 Nov 2009 11:44:35 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA4BianK024940; Wed, 4 Nov 2009 11:44:36 GMT
Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 05:44:35 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 04 Nov 2009 05:44:33 -0600
Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA0C00A1@XMB-RCD-101.cisco.com>
In-Reply-To: <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP
Thread-Index: Acpcyf9cQc7Gv/u7RAyfnE5VWPs2QQAWmnAQAALE5EAAAHpdwAAEirDQ
References: <4AF09BF6.9010902@sipstation.com> <07465C1D981ABC41A344374066AE1A2C37D6AF5828@TLVMBX01.nice.com> <00FC4AA684E90E4DA2FF71021CD5A6CA0C005E@XMB-RCD-101.cisco.com> <07465C1D981ABC41A344374066AE1A2C37D6AF594B@TLVMBX01.nice.com>
From: "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com>
To: Leon Portman <Leon.Portman@nice.com>, Alan Johnston <alan@sipstation.com>, dispatch@ietf.org
X-OriginalArrivalTime: 04 Nov 2009 11:44:35.0575 (UTC) FILETIME=[2EAD5070:01CA5D44]
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 11:44:30 -0000
Do you mean same IE that was present in initial INVITE needs to be presented in Re-Invite as well? If the information does not change, then I do not see any value in carrying the same payload in re-Invite. But if there is a new IE, then yeah it can be presented in re-Invite. I am not sure if there can be a new UU IE after the call is setup and before call termination. Sanjay -----Original Message----- From: Leon Portman [mailto:Leon.Portman@nice.com] Sent: Wednesday, November 04, 2009 3:02 PM To: Sanjay Sinha (sanjsinh); Alan Johnston; dispatch@ietf.org Subject: RE: [dispatch] Updated CCUS Charter Text - Call Control UUI for SIP 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 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] Updated CCUS Charter Text - Call Contr… Alan Johnston
- Re: [dispatch] Updated CCUS Charter Text - Call C… Leon Portman
- Re: [dispatch] Updated CCUS Charter Text - Call C… Sanjay Sinha (sanjsinh)
- Re: [dispatch] Updated CCUS Charter Text - Call C… Leon Portman
- Re: [dispatch] Updated CCUS Charter Text - Call C… Elwell, John
- Re: [dispatch] Updated CCUS Charter Text - Call C… Sanjay Sinha (sanjsinh)
- Re: [dispatch] Updated CCUS Charter Text - Call C… Paul Kyzivat
- Re: [dispatch] Updated CCUS Charter Text - Call C… Paul Kyzivat
- Re: [dispatch] Updated CCUS Charter Text - Call C… Leon Portman
- Re: [dispatch] Updated CCUS Charter Text - Call C… Alan Johnston
- Re: [dispatch] Updated CCUS Charter Text - Call C… Sanjay Sinha (sanjsinh)
- Re: [dispatch] Updated CCUS Charter Text - Call C… Paul Kyzivat
- Re: [dispatch] Updated CCUS Charter Text - Call C… DRAGE, Keith (Keith)
- Re: [dispatch] Updated CCUS Charter Text - Call C… DRAGE, Keith (Keith)
- Re: [dispatch] Updated CCUS Charter Text - Call C… DRAGE, Keith (Keith)
- Re: [dispatch] Updated CCUS Charter Text - Call C… DRAGE, Keith (Keith)
- Re: [dispatch] Updated CCUS Charter Text - Call C… Alan Johnston
- Re: [dispatch] Updated CCUS Charter Text - Call C… Paul Kyzivat