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?
I think I have heard that SIP-H.323 GWs fall into this category.
(As well as gateways to some other more proprietary protocols that shall
remain unnamed here.)
Paul
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
