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