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

[Alan Johnston <[e-mail]>]

Keith,

Thank you for your careful read and comments on the charter text.

See my comments below.  Your last point below is very important and it 
would be great to get some opinions from others.

Thanks,
Alan

DRAGE, Keith (Keith) wrote:
> 1)	"4. The information is expected to survive retargeting, redirection, and retargeting." 
>
> "retargeting" appears twice.
>   

Yes, and the information must survive if the retargeting happens twice, 
too ;-)

> 2)	"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."
>
> This could imply that the existing protocol discriminator, which does carry information about the content, is lost. I hope that is not true.
>   

No, we will not loose the protocol discriminator.  I didn't think it 
provided that much information about the content, but whatever 
information it provides will be available.

> 3)	I am somewhat concerned that the focus now appears to be on SIP UA to SIP UA, rather than interworking with other signalling systems that also carry such information. Where we have a SIP UA talking to a SIP UA, For at least some of the usages where a SIP UA is talking to a SIP UA, we may well already have SIP mechanisms in place to support this. 

The previous charter text had an ISDN interworking focus, but the 
consensus in the DISPATCH meeting was that there was strong interest in 
UUI outside ISDN interworking.

> In general, we should be focussing on those existing usages transported in other protocols, and any new pure SIP usage should go through the normal SIP extension considerations. With the focus as it currently appears, we could end up spending years defining a fully proper solution, whereas I believe we need something quicker and potentially less than perfect for the SIP UA to SIP UA scenarios. Note that by SIP UA I am talking about a real SIP endpoint here, not the UA that may form part of an interworking gateway.
>   
This is an important scope issue for the charter.

I understand your concern.  I am hopeful that we will not end up with a 
complicated solution and that the mechanism will work for both ISDN and 
non-ISDN approaches.

I think that enough people care strongly about the ISDN interworking 
case that if the mechanism discussions bog down, that the WG could 
recharter to deliver two mechanisms - one for ISDN interworking and 
another more  general mechanism.  However, I'd prefer not to start with 
that approach until we have proven that a single mechanism is too complex.

Do others have an opinion on this?

> regards
>
> Keith
>
>   
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Alan Johnston
>> Sent: Tuesday, November 03, 2009 9: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
>>
>>