> (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
