Re: comments on draft-johnston-sipping-cc-uui-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


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.

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.


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.

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


Thanks,
Jonathan R.




_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux