Agreed. Basically there can be 3 scenario:
1. A---------------C (the signaling and media path ) --->2833 is best. 2. A---------------B (the signaling and media path ) C which is a proxy, and in neither path needs the DTMF (SUBSCRIBE/NOTIFY is best) 3. A---------------C------------B (signaling path) A--------------------B (media path) C needs the DTMF events, cannot use 2833 and SUBSCRIBE/NOTIFY is okay but not necessarily the best approach due to the overhead of additional dialogs (whose duration is tightly linked to the INVITE dialog). INFO definitely looks attractive here. Similarly, the recent draft on rtcp-summary defines a complex SUBCRIBE/NOTIFY mechanism, which again covers all scenarios gracefully. However, for scenario 1 and 3 some other mechanism would be better. I see the need for being able to implicitly SUBSCRIBE for certain events in the INVITE/200 OK itself. Whether we get those notifications in an INFO or a NOTIFY does not matter that much. I could even use the RTCP summary if it was in the BYE/200 (where it logically belongs). -Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw -----Original Message----- From: Brian Stucker [mailto:[EMAIL PROTECTED] Sent: Friday, October 12, 2007 1:03 PM To: Dean Willis; DRAGE, Keith (Keith) Cc: IETF SIP List; Francois Audet; Christer Holmberg Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO) > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Friday, October 12, 2007 11:45 AM > To: DRAGE, Keith (Keith) > Cc: IETF SIP List; Audet, Francois (SC100:3055); Christer Holmberg > Subject: Re: What are we arguing about when we say INFO? (was > Re: [Sip] INFO) > > > On Oct 11, 2007, at 6:54 PM, DRAGE, Keith ((Keith)) wrote: > > > 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. > > That's back to the question of "Is SIP an application protocol or a > transport protocol"? > > Should the SIP-layer software be aware of and coupled to the state of > the application that's using SIP? > > If so, then the proper design model is to build a new SIP request > method for every new piece of application functionality. You forgot about supported. > > So for example, DTMF: Using this model of SIP extension, we might > define a new "DTMF" method. It would look just like DTMF-over-INFO, > except the name of the method would be DTMF. > It clearly resolves the INFO-context question, because now we KNOW > we're getting dialog- related DTMF over it, and we know what to do > with it. We know what we can transport in DTMF-requests, because the > RFC that defines the DTMF extension method will also define exactly > what payload format to use. INVITE Supported: foo Allow: INFO Accept: application/foo 200 OK Supported: foo Allow: INFO Accept: application/foo ... INFO Content-Type: application/foo [DTMF] Where is this broken? > > This too is a clean solution to the problem, although it embodies a > different design philosophy than the same-dialog NOTIFY. > > This leads back to my question: What is the right extension modality > for SIP? Until we have an answer here, we're going to keep going back > and forth on this. MAKE A DECISION, PEOPLE! You can't feasibly make a clean one. There will always be SDP vs. non-SDP extension modalities. > > Now for the bad news: People are still having this argument about HTTP > (we had it during XCAP in the GET/PUT vs POST > debate) even though the real world has proven dramatically by example > that HTTP is a transport protocol and is protocol-wise completely > decoupled from the state of the application (see AJAX as an example). > > -- > 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 _______________________________________________ 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
