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

[Alan Johnston <[e-mail]>]

This is an interesting question.  On first blush, it seems that due to  
3pcc type applications, the mechanism will need to be used in re- 
INVITEs. However, we will need to be very careful to define the  
semantics for true mid-call uses.

I don't think the charter needs to specify this much detail - the  
requirements document produced by the working group should include this.

Any comments on the charter text? I know I am looking forward to  
getting back to the mechanism discussion...

Thanks
Alan



On Nov 4, 2009, at 8:01 AM, Paul Kyzivat <[e-mail]> wrote:

> I always use 3pcc as a test case, because it presents problems  
> almost every time.
>
> Of course the problem with 3pcc is that one "side" may remain the  
> same, while the other "side" is replaced. The replacement typically  
> has no knowledge of the history of what went on before it joined. So  
> there usually needs to be some mechanism for it to be clued in about  
> that.
>
> I don't know if the same is true here or not. It depends on whether  
> the UUI information is viewed as transient, or as state of the  
> session.
>
>    Thanks,
>    Paul
>
> Sanjay Sinha (sanjsinh) wrote:
>> 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:[e-mail]] Sent: Wednesday,  
>> November 04, 2009 3:02 PM
>> To: Sanjay Sinha (sanjsinh); Alan Johnston; [e-mail]
>> 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:[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