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
