Plenty of IWF devices do SIP-2833 to/from H.245-UII to make DTMF work (AFAIK, all of them do). That requires media to go through the IWF-box, but that's life today. Of course if there were a SIP signaling path for DTMF, then media could go direct. But that's crazy talk. ;) And those same IWF devices also do SIP-INFO to/from H.245-UII, for cases where the SIP side needs signaling-path DTMF.
-hadriel > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 18, 2007 2:23 PM > To: [EMAIL PROTECTED] > Cc: sip@ietf.org > Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update > > 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 _______________________________________________ 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
