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

["DRAGE, Keith (Keith)" <[e-mail]>]

I concur with Paul here.

Keith 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, November 04, 2009 1:57 PM
> To: Leon Portman
> Cc: [e-mail]
> 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:[e-mail]]
> > Sent: Wednesday, November 04, 2009 11:18 AM
> > To: Leon Portman; Alan Johnston; [e-mail]
> > 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: [e-mail] 
> [mailto:[e-mail]] On 
> > Behalf Of Leon Portman
> > Sent: Wednesday, November 04, 2009 1:29 PM
> > To: Alan Johnston; [e-mail]
> > 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: [e-mail] 
> [mailto:[e-mail]] On 
> > Behalf Of Alan Johnston
> > Sent: Tuesday, November 03, 2009 11:09 PM
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> > 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>