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
