Subject: [cuss] Kick starting the cuss WG

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 12 Aug 2010 16:49:45 -0500

Folks: While the veracity of the proof to the "is P = NP"
problem is being debated, we continue with more mundane
things, namely kick starting the cuss WG.

Gonzalo is on vacation for the next couple of weeks,
however, the current version of the charter he is looking at
is reproduced below.  It is not clear if this is exactly what
will get approved or not, but Gonzalo would like us to kick
start the working group now.  So, let's get started.

Alan has a a requirement draft [1] in dispatch.  I will kindly
like to request him to resubmit the draft as an individual
submission to the cuss wg.

[1] http://tools.ietf.org/html/draft-johnston-dispatch-sip-cc-uui-01

Enrico and I are thinking of organizing a virtual meeting
before Beijing to get the work going.  Details will follow on the
list after consultations with the AD, etc.

Here is the charter:

Call control UUI Service for SIP (cuss)
---------------------------------------

Chair(s):
  Vijay K. Gurbani <[email-masked]>
  Enrico Marocco <[email-masked]>

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: [email-masked]

Description of Working Group:

The Call control UUI Service 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) for
applications using SIP to establish media sessions.  The information
transported is essentially opaque to SIP, but is tagged with the
application that generated it and the encoding method.

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 special case, the application tag will indicate
ISDN UUI Service 1 interworking.

Call control UUI is a small piece of application information conveyed
between user agents during call control operations.  As a result, the
information must be conveyed with the INVITE transaction.  A goal is
to avoid a dependency on multipart MIME support. 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 working group will define guidelines for other applications to
utilize the mechanism and the information that each application must
specify to utilize the mechanism. New applications of the mechanism
will require a standards-track document.

The mechanism developed in this working group is applicable in the
following situations:

1. The information is generated and consumed by an application during
    session setup using SIP, 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. User Agent Clients (UAC) and User Agent Servers (UAS) are the
   generator and consumer of the UUI data.  Proxies may route
   based on the application tag.

4. Intermediary elements or proxies can remove or insert UUI
   information

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 adding or removing) the information.

4. There are specific privacy issues involved with the information
    being transported (e.g., geolocation or emergency-related
    information).

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.

- An application usage specification for the ISDN UUI Service.

Goals and Milestones
====================

Dec 10 - Problem statement and requirements document to IESG
          (Informational)

Jun 11 - SIP call control UUI specification to IESG (PS)

Jun 11 - ISDN UUI Service application usage specification to
          IESG (PS)

Thanks,

Vijay K. Gurbani and Enrico Marocco

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Aug 2010 19:00:57 -0400

Vijay K. Gurbani wrote:

> A goal is to avoid a dependency on multipart MIME support. 

I wonder how firm a goal this is.
SIP-T has been used for a long time in ways that require multipart MIME.
And RFC3261 has been updated by 5621 to *require* support for multipart.

Whatever the solution, it is going to require some sort of modification 
to the sending and receiving UAs, so lack of support now isn't a strong 
argument.

Certainly arguments can be made that a header might be a better solution 
to this problem. But I don't think a solution that uses a body should be 
off the table at this time.

> requirements to transport this type of information.

I'm sympathetic to this point. But what precisely is it about SIP-T that 
is objectionable here? Is it the arcane encoding? If so, the UUI syntax 
that has been previously proposed still has some of that. Or is it that 
using SIP-T *requires* inclusion of much other information that isn't 
germane to conveying UUI info?

What about application/nss format?
(ITU-T Recommendation Q.1980.1, "The Narrowband Signalling Syntax (NSS) 
- Syntax Definition")

IIUC that can be used to convey anything that SIP-T can, and is carried 
in a body part as SIP-T is, but the syntax is user friendly and you only 
have to specify the parts you want. I know of applications that are 
using it to meet the same needs that this wg is addressing.

>   based on the application tag.

I don't understand what this means for proxies? What application tag?
Is it trying to say that proxies may route on the UUI value? Or that 
they may *not* route on the UUI value? Or is it perhaps suggesting that 
a proxy could route on the presence of UUI data but not on the 
particular value of that data?

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Thu, 12 Aug 2010 20:15:10 -0500

Paul,

See my comments below.

- Alan -

On Aug 12, 2010, at 6:00 PM, Paul Kyzivat <[email-masked]> wrote:

> Whatever the solution, it is going to require some sort of  
> modification to the sending and receiving UAs, so lack of support  
> now isn't a strong argument.
>
> Certainly arguments can be made that a header might be a better  
> solution to this problem. But I don't think a solution that uses a  
> body should be off the table at this time.

We will be having the discussion, but a body just doesn't meet the  
requirements as well as a header. Also, nothing we do in the WG  
prevents anyone from using a body if it meets their specific needs.   
SIP can carry any body without needing to be extended.

> I'm sympathetic to this point. But what precisely is it about SIP-T  
> that is objectionable here? Is it the arcane encoding? If so, the  
> UUI syntax that has been previously proposed still has some of that.  
> Or is it that using SIP-T *requires* inclusion of much other  
> information that isn't germane to conveying UUI info?

Requiring two SIP UAs to add an ISUP stack so that they can exchange a  
small piece of non- ISUP information makes no sense at all.   However,  
if someone already has ISUP and SIP-T and they are happy with it, then  
they can use that mechanism. They can safely ignore the work of this WG.

> (ITU-T Recommendation Q.1980.1, "The Narrowband Signalling Syntax  
> (NSS) - Syntax Definition")
>
> IIUC that can be used to convey anything that SIP-T can, and is  
> carried in a body part as SIP-T is, but the syntax is user friendly  
> and you only have to specify the parts you want. I know of  
> applications that are using it to meet the same needs that this wg  
> is addressing.
>

Sure - if your UAs already support NSS, then this might make sense.   
However, this is not a reasonable solution to introduce a whole other  
protocol just to transport a piece of UUI.  Let's not do protocol  
layering overkill.

I think there's already a MIME type for NSS so again no work is needed  
if anyone chooses to transport NSS bodies.

> they may *not* route on the UUI value? Or is it perhaps suggesting  
> that a proxy could route on the presence of UUI data but not on the  

If you read the whole charter, it says that the UUI will be tagged by  
the application that generated it. In other words, what type of info  
is being carried. Proxies can route based on what types of UUI may be  
present but would not normally inspect the contents of the UUI, as it  
is end-to-end in nature.

>    Thanks,
>    Paul
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Aug 2010 09:44:27 -0400

Alan,

Several places below you say something to the effect of "nothing about 
this work prevents you from using alternative approach X if you support it".

The problem with that is interoperability. If there are alternative ways 
to accomplish the same thing, and all are optional then it becomes a 
guessing game to decide what will work. And since there is an 
expectation that the UUI info can be conveyed in the INVITE, there is no 
opportunity to negotiate which mechanism to use.

So ISTM there should end up being as few mechanisms as possible, and 
senders had better use all that they support in order to maximize interop.

More inlline.

Alan Johnston wrote:
>> modification to the sending and receiving UAs, so lack of support now 
>> isn't a strong argument.
>>
> requirements as well as a header. Also, nothing we do in the WG prevents 
> anyone from using a body if it meets their specific needs.  SIP can 
> carry any body without needing to be extended.

Well, a bird in the hand is worth two in the bush.
If there is *already* a mechanism that uses a body, and it is "good 
enough", then it may be preferable to inventing yet another mechanism 
that uses a header.

If there is something that must be done, but can't reasonably be done 
with a body, then that can tip the balance. But I'm at least hearing 
from people who seem to be getting what they need using a body-based 
approach.

Certainly I think this is worthy of further study as part of getting 
this done.

And if the end result is multiple "standard" ways of expressing the same 
UUI info, then I hope the result will also provide some guidance on when 
to use which one to facilitate interop.

>> that is objectionable here? Is it the arcane encoding? If so, the UUI 
>> syntax that has been previously proposed still has some of that. Or is 
>> it that using SIP-T *requires* inclusion of much other information 
>> that isn't germane to conveying UUI info?
> 

I agree that requiring a complete ISUP stack is excessive.
If that's the point, then I agree.

>> applications that are using it to meet the same needs that this wg is 
>> addressing.
> 

Is NSS necessarily a "whole other protocol"?
Wouldn't it be feasible for a UA with limited needs to simply implement 
the part of NSS that is needed for UUI info, yet work within the syntax 
of NSS? (IOW, perhaps this group could define a "profile" of NSS usage.)

> if anyone chooses to transport NSS bodies.

That is the "bird in the hand".

> the application that generated it. In other words, what type of info is 
> being carried. Proxies can route based on what types of UUI may be 
> present but would not normally inspect the contents of the UUI, as it is 
> end-to-end in nature.

OK, Sorry!
I didn't catch the connection between those two.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 Aug 2010 10:58:15 +0200

> present but would not normally inspect the contents of the 
[JRE] This smells a bit like caller preferences. Is there any particular reason we can't use/extend caller preferences to accomplish what we need here, rather than introducing a different tagging mechanism?

John