Yes, I agree.
> -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 11, 2007 16:54 > To: Dean Willis; Audet, Francois (SC100:3055) > Cc: IETF SIP List; Christer Holmberg > Subject: RE: What are we arguing about when we say INFO? (was > Re: [Sip] INFO) > > 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
