Subject: [Sipping] comments on draft-johnston-sipping-cc-uui-07

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 22 Mar 2009 20:29:16 -0400

While I agree that INFO does not solve the problem raised in this draft, 
I think the problem space is sufficiently similar that it is worth 
looking at what we did for INFO-events, and whether similar things would 
be needed here.

Both INFO and UUI are similar in that:

  * they carry information that is opaque to intermediaries; the 
intermediaries just carry the data
  * the information is 'application oriented' in nature
  * the contents themselves can be lots of different things, oftentimes 
not even standardized

For INFO, we all seemed to agree that what we needed was some clear way 
of carrying meta-data about the content. In particular:

   * an 'event-like' parameter for typing the data
   * content-type to allow decode
   * content length

It seems to me that, all of the same reasons we wanted a framework for 
INFO, apply here too. Are we not concerned that an INVITE might get 
forwarded somewhere not quite intended, and something will get that UUI 
and not know what to do with it? Or worse, mis-parse it and do the wrong 
thing?

Is there a need for some kind of scoping? A way to have proxies or SBCs 
remove UUI when it leaves a perimeter of trust, ala spec-T?

I understand that these features are not present in ISDN; however, SIP 
networks are not the same as circuit networks, and the likelihood that 
UUI 'escapes' and goes somewhere unintended seems much higher to me in 
SIP. I can see lots of uses for this mechanism, and would hate this turn 
into our next INFO-disaster.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 Mar 2009 11:06:23 -0500

Jonathan,

Thanks for your comments on the draft.  See my responses below.

Thanks,
Alan

Jonathan Rosenberg wrote:
> While I agree that INFO does not solve the problem raised in this 
> draft, I think the problem space is sufficiently similar that it is 
> worth looking at what we did for INFO-events, and whether similar 
> things would be needed here.

I agree this is a useful exercise.

> For INFO, we all seemed to agree that what we needed was some clear 
> way of carrying meta-data about the content. In particular:
>
> INFO, apply here too.

Well, lets analyze this a little more.  I'd say there are two main 
classes of "users" of INFO.  The first is the SIP-T usage which INFO was 
originally designed for.  The second class is the flood of other 
applications that sent application data essentially unrelated to call 
signaling in a SIP dialog.  This includes DTMF, conference control, etc.

I think the main problem with INFO was that we tried to use the same 
mechanism for both.  I don't believe there are any issues with the SIP-T 
usage of INFO - the event-like framework isn't needed for this.  Rather, 
its usage within a SIP-T trust domain for ISTN/ISUP interworking seems 
to work well.

For the other applications, for sure there is a huge mess and we need to 
add the meta-data to try to fix things.

> Are we not concerned that an INVITE might get forwarded somewhere not 
> quite intended, and something will get that UUI and not know what to 
> do with it? Or worse, mis-parse it and do the wrong thing?

If you agree at all with my analogy above, you can see that we need to 
be clear about the "user" of the UUI.  If it is the ISDN interworking 
that this work is constrained to, per our work and last call in SIPPING, 
then this is not a huge problem.  If the user is a wider set of 
applications that might want to exchange user data over SIP, then this 
will be huge problem.

Since this mechanism is narrowly scoped to ISDN interworking, I think 
the solution is to define a different mechanism for non-ISDN 
applications, and this mechanism will definitely require all the 
meta-data.  In fact, I'd argue the security requirements are radically 
different.

For this ISDN application, we can't actually include any meta-data.  
This information will be either generated by or consumed by ISDN 
gateways, so this meta-information can not be populated or consumed.  In 
fact, I'd argue even stronger that to include this information is 
essentially a layer violation - SIP does not and should not know what 
the ISDN UUI information is.

>
>
> Is there a need for some kind of scoping? A way to have proxies or 
> SBCs remove UUI when it leaves a perimeter of trust, ala spec-T?

I would agree that this will definitely happen in practice - it is a 
natural SIP-T usage.

> SIP. I can see lots of uses for this mechanism, and would hate this 
> turn into our next INFO-disaster.

Right, and we can avoid this by keeping our narrow focus on ISDN 
interworking.  Only devices that understand this service will use this 
header field - no other applications will attempt to use this and cause 
interop problems.

Perhaps we should start work on a new set of requirements for this more 
general, more SIPish user information - called User-Info, perhaps?

Thanks,
Alan