Subject: [dns-dir] FW: WG Review: Call Control UUI for SIP (cuss)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jun 2010 12:04:48 +0200

Please find below the proposed charter of the CUSS WG in RAI. Please
send your questions, comments and concerns before 6/29 COB. 

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Tuesday, June 22, 2010 8:00 PM
To: [email-masked]
Subject: WG Review: Call Control UUI for SIP (cuss) 

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area.  The IESG has not made any determination as
yet.
The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG
mailing list ([email-masked]) by Tuesday, June 29, 2010.  

Call Control UUI for SIP  (cuss)
--------------------------------------------------
Current Status: Proposed Working Group

Last modified: 2010-06-21

Chair(s):
  TBD

Real-time Applications and Infrastructure Area Director(s):
  Gonzalo Camarillo <[email-masked]>
  Robert Sparks <[email-masked]>

Real-time Applications and Infrastructure Area Advisor:
  Gonzalo Camarillo <[email-masked]>

Mailing Lists: TBD

Description of Working Group:

The Call Control UUI for SIP (CUSS) working group is chartered to define
a Session Initiation Protocol (SIP) mechanism for transporting
call-control related user-to-user information (UUI) between User Agents.
 
The mechanism developed in this working group is applicable 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. The behavior of SIP entities that support it is not significantly
   changed (as discussed in Section 4 of RFC 5727).
3. Generally only the User Agent Client (UAC) and User Agent Server
   (UAS) are interested in the information.
4. The information is expected to survive retargeting, redirection,
   and transfers.
5. SIP elements may need to apply policy about passing and screening
   the information.
6. Multi-vendor interoperability is important.

This mechanism is not applicable in the following situations:

1. The behavior of SIP entities that support it is significantly
   changed (as discussed in Section 4 of RFC 5727).
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 in
   consuming (beyond applying policy) the information.
4. There are specific privacy issues involved with the information
   being transported (e.g., geolocation or emergency-related
   information).

User data of the mechanism will be clearly marked with the application,
encoding, semantics, and content type, allowing policy to be applied by
UAs.  The working group will define the information that each
application must specify to utilize the mechanism. This type of
application-specific information will be specified in standards-track
documents.
 
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 to the PSTN-SIP
gateways.  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 since 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.

Even though interworking with the PSTN is an important requirement, call
control UUI can be exchanged between native SIP clients that do not have
any ISUP support. Therefore, existing SIP-T encapsulation-based
approaches defined in RFC3372 do not meet the requirements to transport
this type of information.

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
====================
 
Sep 10 - Problem statement and requirements document to IESG
(Informational)
Mar 11 - SIP call control UUI specification to IESG (PS)

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jun 2010 15:32:46 +0200

This is the mode of work that is being used by RAI for the last year or
so, and this is the result of their previous experience with SIPPING,
which was running in parallel a large number of items and many of them
were going nowhere. Now they use DISPATCH to approve and charter new
items and they create WG's to solve defined sets of problems, in some
cases smaller than the typical WG goals. 

Dan

> From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]] 
> Sent: Wednesday, June 23, 2010 4:22 PM
> To: Romascanu, Dan (Dan); [email-masked]; MIB Doctors 
> (E-mail); [email-masked]; [email-masked]
> Subject: RE: [OPS-DIR] FW: WG Review: Call Control UUI for SIP (cuss)
> 
> 
> Hi,
> 
> > The group will produce:
> It might be an old issue and already discussed earlier but I 
> still have some problems to understand why a workgroup is 
> necessary for such a (more or less) small issue?
> 
> I think a RAI area WG is still interesting for issues without 
> a home in existing RAI area workgroups. 
> 
> Cheers,
> Mehmet
> 
>  
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of ext Romascanu, Dan 
> > (Dan)
> > Sent: Wednesday, June 23, 2010 12:05 PM
> > To: [email-masked]; MIB Doctors (E-mail); [email-masked]; 
> > [email-masked]
> > Subject: [OPS-DIR] FW: WG Review: Call Control UUI for SIP (cuss)
> > 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of IESG Secretary
> > A new IETF working group has been proposed in the Real-time 
> > Applications and Infrastructure Area.  The IESG has not made any 
> > determination as yet.
> > The Call Control UUI for SIP (CUSS) working group is chartered to 
> > define a Session Initiation Protocol (SIP) mechanism for 
> transporting 
> > User data of the mechanism will be clearly marked with the 
> > application, encoding, semantics, and content type, 
> allowing policy to 
> > be applied by UAs.  The working group will define the 
> information that 
> > each application must specify to utilize the mechanism. 
> This type of 
> > 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 since 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.
> > 
> > Even though interworking with the PSTN is an important requirement, 
> > call control UUI can be exchanged between native SIP 
> clients that do 
> > not have any ISUP support. Therefore, existing SIP-T 
> > encapsulation-based approaches defined in RFC3372 do not meet the 
> > requirements to transport this type of information.
> > 
> > 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.
> > _______________________________________________
> > OPS-DIR mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ops-dir
> > 
>