Subject: Re: WG Review: Call Control UUI for SIP (cuss)

From: Alan Johnston <[email-masked]>
Date: Sat, 3 Jul 2010 09:33:36 -0400

Cullen,

Your characterization of this charter is inaccurate.  It is not about
transporting proprietary information in SIP but rather standardizing an
approach for applications to utilize SIP without having to have another 1000
SIP extensions and RFCs for every application that uses SIP.

Instead, it is about defining a standard mechanism so that *applications*
can transport information orthogonal to SIP in call control messages.  In
the past, we have had this conceit in SIP that SIP is the center of the
universe and needs to understand everything above and below it in the
protocol stack.  We have violated layering so many times and in so many
ways.  This mechanism is a first step towards rectifying this.  So if you
believe that SIP as a protocol needs to understand every piece of
information and every aspect of the applications that use it, I'm going to
argue with you.

Now we have one extremely well deployed and used application used in
enterprise communication today - the ISDN User to User Information service.
If we can't support this simple service in SIP - the idea that an
application can transport information opaque to the signaling protocol -
then we have failed as a standards body.  I don't want this to happen, and
enterprise users of SIP do not want this.

Now, is this ISDN User to User Information service the best way for an
application to use SIP?  Absolutely not!  The ISDN service requires
provisioning on both sides so that they correctly interpret and understand
the UUI.  And you have to take special care not to mix UUI between
applications.  That is why this working group is not just about the ISDN
service - that wouldn't be very interesting.  Instead, this charter is about
defining that application and allowing for new ones to be created.

New ones will need to write their own specs and define what their UUI is,
how it is encoded, etc.  This will clearly promote interoperability.  It
will be easy to transition current users of the ISDN User to User service to
this better service that takes advantage of the Internet and SIP fully.

Now the final piece of the puzzle is the discovery and negotiation piece.
This is totally absent in the ISDN service.  Once we see the other
applications, we will be able to design an appropriate discovery and
negotiation mechanism.

So hopefully we are agreed that this is where we want to end up with this
mechanism.  But we can't get there from here - we need to provide basic
support for the ISDN service first, then the ability to transition away from
it.  And doing it for one little application at a time, having to charter a
new working group for each one clearly would be a waste of everyone's time
and resources.

Many of us have worked hard on this approach over many years, and you have
been involved in this at every step of the way, in both SIPPING and
DISPATCH.  For you to just try to block even the formation of a working
group to address this at this eleventh hour is just not right.

Thanks,
Alan

-------- Original Message --------
> Subject: Re: WG Review: Call Control UUI for SIP (cuss)
> Date: Mon, 28 Jun 2010 20:24:23 +0200
> From: Cullen Jennings <[email-masked]>
> To: [email-masked] <[email-masked]>
> CC: IETF Discussion Mailing List <[email-masked]>
>
>
> As far as I can tell, the WG says they wants to transfer some
> information to achieve cross vendor interoperability. However, what I
> believe the charter is actually going to do is exactly the opposite of
> that. When you get your head around what this charter is proposing, it
> is going to form a more or less opaque container for transporting
> proprietary information in a SIP header. It's hard to imagine how this
> will help interoperability.
>
> If we wanted to have interoperability, the charter would say what
> information needs to be transferred and have the WG define a way to get
> it between systems in an operable way. What the charter for this WG
> actually says they are going to do is make a special container for
> transfer proprietary information.  There's not even willing to say what
> that proprietary information is used for other than things ISDN UUI
> which is a  non interoperable and fairly proprietary field in ISDN.
> Furthermore they have asserted that  existing containers such as SIP-T
> or SIP bodies can't be used for reasons that are hard to describe. (I
> reject the idea that because the call might not involved the PSTN, it
> can't use SIP-T).
>
> I think the folks that want to do this should get a much clear
> explanation of how this results in interoperability and why exist
> approach such as SIP-T will not work before this is chartered.
>
> I do think there is a need to standardize some important call control
> information used in call centers and related places. However, the "we
> need a standard container to exchange secret information WG" is a bad
> idea and violates the sprit of the SIP change process not to mention the
> mission of the IETF.
>
> In summary, I'm in favor of figuring out what the problems are people
> hope to solve with this WG and figuring out a way to write interoperable
> standards to achieve that. However, I think this charter should be
> rejected by the IESG and sent back to the drawing board. The RAI area
> has things of higher priority items to work on than a SIP header for
> transfer proprietary data.
>
>
>
> On Jun 22, 2010, at 10:00 , IESG Secretary wrote:
>
> > 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)
> > _______________________________________________
> > IETF-Announce mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf-announce
>
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 8 Jul 2010 21:35:02 -0600

On Jul 3, 2010, at 7:33 AM, Alan Johnston wrote:

> Many of us have worked hard on this approach over many years, and you have been involved in this at every step of the way, in both SIPPING and DISPATCH.  For you to just try to block even the formation of a working group to address this at this eleventh hour is just not right.

For better or worse, the AD's voice do strongly impact others thinking on the many subjects at IETF. As an individual contributor, my review in IETF LC pretty much my current thoughts on it. However, if I had sent that same review when I was an AD this charter would have been very unlikely to get a fair shake at moving forward so I just would not have sent that email while I was AD. The ADs often can't express their own opinions because and instead have to just try and measure community consensus and go with that even if it does not match what they think is best. Really this is the first chance I've had to express an opinion on this where I was not one of the RAI AD. 

There discussion that has happened since my initial review has made me wish I had said a bit more about SIP-T in my first email. I'm not really proposing that someone should have to implement all of ISUP processing and SIP-T just to pass around the UUI field but from a thought experiment point of view, this does not sound like it is going to provide anything that we would not get if we did implement SIP-T to pass this data. It seems this will have all the limitations of SIP-T combined with the interoperability limitations of UUI in ISDN. I want to be clear, I'm not trying to stop us from doing some work that helps supports uses cases such as the one Laura sent to the list. I just don't see this charter as leading to any improvement in interoperability. If we agree that in theory we could more or less do this with SIP-T thought that is not a practical path from an implementation point of view, then I can see a path of some middle ground. If we don't agree on that then we probably need to think about what we need to add to the charter regardless of if I agree with or not that high lights the additional part of this problem that makes it so SIP-T can't solve it. 

The other things that has happened in this discussion is that I was assuming that the proponents of this felt that proxies needed to modify the data. From the email that came out it's became clear that not everyone believed that. If there was consensus on changing this such that UUI information is not meant for proxies, then I can start to see ways to rewrite the charter to have it reflect what I think people want to do. If the consensus is proxies need to look at this, I have a hard time seeing how it is not involved in call control.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 14 Jul 2010 18:10:48 +0300

Hi,

thanks for your comments on the charter proposal. Per the comments
received, we will modify bullet 5 as follows so that it is clearer:

OLD:

NEW:
5. SIP elements may need to apply policy about passing and filtering
   UUI.  The included application, encoding, semantics, and content
   information will allow endpoint or intermediary SIP elements to
   allow or block UUI based on the type and originator, not based on
   the actual UUI data, which may be end-to-end encrypted by the
   application.

Further discussions on this topic should happen on the mailing list of
this WG.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 14 Jul 2010 11:25:58 +0300

Hi,

OLD:

NEW:

Cheers,

Gonzalo

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Jul 2010 08:06:00 -0600

I don't think this resolves the issue. The issue is if this information is used for a call control. Basically do proxies need to be able to look at this to make decision about what they are going to do. We at least need a Yes/No answer to this question from the proponents of this work and the charter to make that clear. 

On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote:

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

Cullen Jennings

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 15 Jul 2010 17:32:02 +0300

Hi Cullen,

the charter already says that the information "may be end-to-end
encrypted by the application". Therefore, proxies will not make any
decision (related or unrelated to call control) based on its contents
because the contents may simply not be available to the proxy.

Do you want the charter to be even more explicit about this?

Thanks,

Gonzalo

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Thu, 15 Jul 2010 10:07:42 -0400

Cullen the answer to your question is No.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Thursday, July 15, 2010 10:06 AM
To: Gonzalo Camarillo
Cc: DISPATCH list; IESG IESG; IETF-Discussion list
Subject: Re: WG Review: Call Control UUI for SIP (cuss)

I don't think this resolves the issue. The issue is if this information
is used for a call control. Basically do proxies need to be able to look
at this to make decision about what they are going to do. We at least
need a Yes/No answer to this question from the proponents of this work
and the charter to make that clear. 

Cullen Jennings

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Jul 2010 11:27:32 -0600

OK - that removes a large part of the issues I raised. Let me see if I can propose some text that we could all agree on.

Cullen

PS - Just to be clear these emails are all in my individual contributor role. That was clear when it was IETF LC comment but given this is all cross posted to dispatch, just wanted to be clear.

Cullen Jennings

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Thu, 15 Jul 2010 13:40:35 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]

>From the discussion, it seems that proxies will not make call control decisions based on the *contents* of UUI, but they may make call control decisions (specifically, rejection) based on the *presence* of UUI.  So whether the anser is Yes or No depends on exactly how you phrase the question.

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 15 Jul 2010 17:31:39 +0200

At least from my perspective (which is from supporting the capabilities of the ISDN User-to-User service) the answer is No. This is information above the SIP layer in an application, and to look at the contents, one must come out above the SIP layer into that application. 

It could be conditional that the SIP message itself is not processed if the information is not there, and the SIP request therefore rejected, but this has nothing to do with the contents. And personally, I do not believe that bit will every happen at a proxy, but will be at the recipient UA.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Thursday, July 15, 2010 3:06 PM
> To: Gonzalo Camarillo
> Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss)
> 
> 
> I don't think this resolves the issue. The issue is if this 
> information is used for a call control. Basically do proxies 
> need to be able to look at this to make decision about what 
> they are going to do. We at least need a Yes/No answer to 
> this question from the proponents of this work and the 
> charter to make that clear. 
> 
> 
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>