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
