If the other end does not do 2833, than anything we do here is NOT going to work. This is because the other end will have to be modified to do whatever we decide to do here (like INFO packages). At that point, it could do 2833. In fact, if the argument is how to support low power / low capability devices, I would offer 2833 is insanely easier than anything in the SIP layer.
On 10/15/07 12:21 PM, "Hadriel Kaplan" <[EMAIL PROTECTED]> wrote: >> -----Original Message----- >> From: Eric Burger [mailto:[EMAIL PROTECTED] >> Sent: Monday, October 15, 2007 7:49 AM >> To: Christer Holmberg; Hadriel Kaplan >> Cc: IETF SIP List >> Subject: Unsolicited NOTIFY/INFO versus Solicited State Update >> >> 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? > > A PSTN gateway has no idea what the PSTN-side call goes to or came from. It > may or may not need DTMF. That PSTN GW has to subscribe for every call if it > (or the other end) doesn't do 2833, regardless if any DTMF get pressed. The > same for a SIP-H.323 gateway, a Skype-SIP gateway, etc. (for H.323 in > particular the probability of 2833 support is very low) > > And even for a SIP AS that knows it needs DTMF, for some applications a KPML > model will be more efficient than INFO, for others less... much less. > > -hadriel > 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
