Correct, but only really for the purposes of signaling. Remember, in the context of SIP, it is H.323 on the other side. If it cannot take RFC2833 on the SIP side, it is a boat anchor.
-- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is. ----- Original Message ----- From: Paul Kyzivat <[EMAIL PROTECTED]> To: Eric Burger Cc: IETF SIP List <sip@ietf.org> Sent: Thu Oct 18 11:11:52 2007 Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update Eric Burger wrote: > Is it the gateway is doing DTMF -> H.245 mapping, or is it just for > doing compressed codec transport? I know next to nothing about H.323. My understanding is that it thinks DTMF must travel in the signaling path for H.323, and I gather that means using H.245. Paul > On 10/15/07 8:24 AM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote: > > > > > 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 > > > > > > 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. 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
