Yeah, that's what I meant when I said in an earlier email: "But I think that is something that could be standardized away if we needed to. One way could be to define an Event package type model for it. One could argue Info is essentially a Notify, except in a subscription implicitly created by, and tied to the dialog from, an Invite."
But Adam didn't seem to like it. Not sure why. Adam? -hadriel > -----Original Message----- > From: Francois Audet [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 10, 2007 7:14 PM > To: Christer Holmberg; Dean Willis > Cc: IETF SIP List > Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] > INFO) > > > > (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. > > I know many people will hate this idea but, I do agree with Christer > that subscribing to an event package "just in case" when it normally > is not used is quite a huge overhead and explain why people just > use INFO instead. > > > > I still strongly think it would be much better to describe > > the issues/advantages/disadvantages with BOTH INFO and > > events, and study what possible needs to defined related to > > negotiation etc, instead of just ignoring the real world and > > providing flexibility to people using SIP for their applications... > > I think the idea above would address this and avoid the INFO pitfalls. > > > > _______________________________________________ > 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
