I would buy the efficiency argument if we were talking about 100,000 seat call centers. However, even for a 10,000 seat call center, we are talking about a pretty trivial number of messages compared to the total interaction.
On 10/15/07 11:52 AM, "Jeroen van Bemmel" <[EMAIL PROTECTED]> wrote: > Eric, > > It's not that the "receiver" of DTMF events does not know it is > interested, it's that the SUBSCRIBE/NOTIFY model forces the receiver to > always subscribe, even if in 99% of the calls the other side is not > expected to press any key during mid-call. > > For example, there exist call center applications in which pressing a > digit (say '1') indicates that the caller is annoying and should be > placed on a blacklist. In this scenario the DTMF event is rare; INFO > would be more efficient in this case (if supported of course). > > In other scenario's (such as IVR systems) DTMF events are common; then > SUBSCRIBE/NOTIFY may make more sense (overhead becomes less significant > compared to total) > > Regards, > Jeroen > > Eric Burger wrote: >> A few times I have seen a comment stating the endpoint interested in >> potentially receiving DTMF notifications may not know whether or not it >> needs DTMF. As such, the endpoint would be forced to always issue a >> SUBSCRIBE, even if it will not be interested in DTMF. >> >> Could someone please describe a scenario in which the endpoint does NOT >> KNOW, a'priori, it will be interested in DTMF? >> >> All the ones I can think of, like supplemental dial digits, ACD, register >> recall, and return to application are all known to the AS or Proxy driving >> the interaction. >> >> What else is out there? >> >> >> On 10/10/07 12:20 PM, "Christer Holmberg" <[EMAIL PROTECTED]> >> wrote: >> >> >>> Hi, >>> >>> >>>>> Ignorning the reason why people are using INFO is not going >>>>> to make things better either... >>>>> >>>>> I think most people are aware of KPML etc - we don't need to >>>>> tell them that. >>>>> >>>> I seriously don't think people are using INFO because they think it's >>>> better than KPML. >>>> >>>> I think peopled use to use INFO because (a) they implemented it before >>>> RFC 2833, and (b) because it was difficult for them to implement >>>> RFC 2833 when it got implemented and (c) KPML didn't exist at that time. >>>> >>> (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. >>> >>> 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... >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I believe at this point, this is an imaginary issue. >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> >> Notice: This email message, together with any attachments, may contain >> information of BEA Systems, Inc., its subsidiaries and affiliated >> entities, that may be confidential, proprietary, copyrighted and/or >> legally privileged, and is intended solely for the use of the individual or >> entity named in this message. If you are not the intended recipient, and have >> received this message in error, please immediately return this by email and >> then delete it. >> >> >> _______________________________________________ >> 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 >> >> > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ 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
