There is one major downside to this. If we are sending stuff in the dialog, it really ought to have some relation to the dialog, not just be included there because the dialog happened to exist.....then you end up with people wanting to route the dialog to a centralised point where you can extract this piggy-backed information ... Then you end up with a stimulus protocol between this UE and this centralised server where the dialog contains absolutely no knowledge of the state of the session.
Providing an in dialog mechanism makes it much harder to to stop this happening. Regards Keith > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 11, 2007 5:20 AM > To: Francois Audet > Cc: IETF SIP List; Christer Holmberg > 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
