Francois,
"Why not use that?" is the wrong question. It should be "Why do THEY
(the people out there) use or don't use { KPML, INFO, RFC2833, <some
proprietary solution>, ... }"
It is not up to us - the people participating in these IETF mailinglists
- to decide what gets used. We simply don't have any say in that.
In my limited perception of the world, people use INFO because it's
better known by them, supported by some devices, simpler to use, and low
overhead - you don't pay a performance penalty unless a key press (for
example) actually happens, which in some cases is rare (like for certain
telephony applications). People tend to think along the lines of "it's
defined in an RFC, therefore standard, seems supported by others (at
least by the list of devices on my mandatory interop list) -> ok to use"
and then add an item to their "supported standards" list on the product
data sheet
"We" can argue that it's wrong to use INFO, that it's lacking
contextually-adapted negotiations mechanisms, etc. but the reaction will
simply be: "What are you talking about, contextual bla-bla, it's working
fine for US and our purposes".
Pandorra's box that is INFO has been opened. It's out there, and there's
no stopping it. Let's go solve some real issues now
Regards,
Jeroen
Francois Audet wrote:
Hi Dean,
Can you tell me what is the difference between "contextually-adapted
INFO", and a "subscription embedded in the INVITE, with the NOTIFY
using the same dialog"? I don't see any advantage to the INFO approach.
It seems to me we already have a mechanism for asking for asynchroous
information with subscriptions. Why not use that?
-----Original Message-----
From: Dean Willis [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 21:20
To: Audet, Francois (SC100:3055)
Cc: Christer Holmberg; IETF SIP List
Subject: Re: What are we arguing about when we say INFO? (was
Re: [Sip] INFO)
On Oct 10, 2007, at 6:14 PM, Francois Audet wrote:
(d) they think it's a waste of resources to establish multiple
additional subscription dialogs (there may be other type
of data than
DTMF they are willing to receive) which in many cases may
not even be
used during the call (it can not be assumed that the one
sending the
subscription always knows exactly when it will receive
events). Maybe
DTMF is not the best example in the world (my fault - I
should have
been more generic), but I am sure there could be events
which would
not be used in a very high percentage of all calls, but still the
additional subscription dialog(s) would have to be
established - just
in case.
Maybe a way to subscribe to packages within an INVITE
dialog would be
suitable. You then would get the NOTIFYs withind the
dialog, and they
wouldn't be out-of-the-blue because you would have
subscribed to those
events explicitly with some Allow-Event in the INVITE.
Hmm. In-dialog event notification using INVITE as an explicit
subscription trigger. That works, mostly.
Other people would argue that the semantics are better
preserved with a a new SIP method that is defined to carry
whatever sort of blob we're talking about in the specific
context of the application usage.
We'd then add that method name to the list of supported
methods given in the Allow header field. Of course, this will
eventually give us "Really Big" Allow header fields, which
means the negotiation mechanism is broken. We need an easier
way for one end to ask "Hey, do you understand this?".
Others would say that the we're better off defining a session
protocol designed to transport the blobs in question, along
with SDP extensions to negotiate this protocol, NAT-traversal
hooks to allow us to talk about the connectivity of the
blob-transferral protocol, then do a reINVITE exchange to add
the new blob-session to the existing session.
Yet others would say that we already have a blob-transferral
protocol (MSRP), along with the nat traversal hooks and SDP
extensions needed to negotiate it, and should therefore push
the problem out one layer of protocol and make it an MSRP
problem. This begs the question of how MSRP negotiates as to
whether the context and content are agreed on both ends,
which AFAIK it does little better at than INFO.
So what's the difference?
All (assuming we figure out the MSRP context negotiation
problem) explicitly declare the understanding of and the
desire to receive messages within this dialog/session that
contain the data we've defined and assure that the
application context (the "what do I do with this stuff"
problem) is mutually understood.
The differences are that one approach is the extension of an
application protocol to support a new application, while two
others are extensions of existing transport protocols (SIP,
MSRP) to carry new payloads in contexts determined by the
applications. The last one implies the development of an
all-new transport protocol (or perhaps the modification of
some other protocol like RTP) as well as extension to our
descriptive protocol (SDP). These are very different things,
and part of the reason that SIP has gotten more complex than
I would like is that we haven't been operating with a clear
understanding of these differences.
Personally, I think that we've got a lot of complexity there
that we didn't really need. If SIP had been designed from the
ground-up as a transport protocol for arbitrary messages and
the application were a function of the message content, we'd
have a much clearer model of what to do. But it wasn't built
that way, so now we need some guiding principles on when each
sort of approach is appropriate. Without it, we're just going
to go around in circles on the "Is INFO harmful, and if so
why?" carousel.
Since I can't leave it hanging there, I'd like to propose
some rules of thumb:
1) If INFO had context negotiation, we'd have a complete
protocol and would quite possibly only need new SIP method
types if there was a need for a fundamental change to the SIP
state machine. Even without INFO, we have the same
functionality available, albeit at the overhead of an
additional dialog. So, I suggest we only introduce new SIP
methods if there's a need to change the underlying machine.
If we're just moving new data in application contexts, we can
do that without changing SIP itself. I really don't want to
keep the SIP WG around just so we can specify a new SIP
method for each application somebody dreams up.
2) Since SIP can provide for the transport of arbitrary data
and application context, we should only use "session"
transport of the data when that dataflow itself has
fundamentally different characteristics -- essentially, when
it is a long-lived and relatively continues flow, aka a
"stream". Quite possibly, this should extend to only
dataflows that have the properties of RTP -- time sensitive,
relatively loss insensitive, and so bulky we need them to be
as end-to-end as we can even if it means building more
infrastructure to make that happen. And yes, I think MSRP is
a misguided effort -- by the time we've built MSRP relays and
all the extra cruft, we've duplicated SIP's message proxy
operation, ICE, GRUU, STUN-relay, and so on. Personally, I'm
not even sure that this level of separation is a good idea.
Coaxial signaling and media have great advantages for
firewall traversal. But we have what we have. In short, use
RTP/MSRP for "sessions", and SIP event payloads (or
contextually-adapted INFO) for everything else.
3) There is no rule 3.
--
Dean
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
