Summary:	ASTERISK-04862: [patch] Failure to send Out of Band DTMF (rfc2833) key indications via h.323 - will receive, but not send
Reporter:	pbd (pbd)	Labels:
Date Opened:	2005-08-19 14:32:27	Date Closed:	2008-01-15 15:48:33.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-chan_h323_dtmf.patch ( 1) dtmf-bug.log ( 2) dtmf-bug-fullog.log ( 3) h323.conf
Description:	Per Jeremy's request, this will be long and involved to read- it's a very specific, highly reproduceable, protocol/functionality violation.  First, the symptoms: 1. Call is initiated through Asterisk via any channel (I've tested both a hard SIP phone (7960) and an IAX softphone, via the NuPhone chan_h323 driver to an h.323 endpoint- for my tests, Cisco Callmanager.   2. h.323 is set up to use out of band signalling- dtmfmode=rfc2833, dtmfcodec setting irrelevant.  Note that a simple switch to inband is out of the question for my application, and untested- I have to use a compressed codec in the final application, so I have to use out of band signalling. 3. Once the call connects, voice quality is good, bidirectional, and shows no problems.   4. dtmf tones originated on the non-asterisk endpoint appear as events to the chan_h323 channel driver, and show up in the debug channel output- asterisk treats them appropriately. 5. dtmf tones originated on the asterisk endpoint (from either test client) appear in the debug channel output, but do NOT translate into the channel driver sending PDU's to the remote endpoint, and are in fact not transmitted. This is the bug. Note, I've tried several clients, phones, etc.  Problem is 100% reproduceable as of CVS-HEAD of 8/18/05.  Problem is not exhibited if I switch from h.323 to SIP for the connection- my situation prevents that configuration for production, this system is still in test.  I have not tried this in -STABLE, I do not have an environment where I can easily, since the h.323 channel driver in the 1.0.X releases is not functional for my application- only -HEAD is. I've attached my h323.conf, and a log (h.323 trace 8, debug channel) showing the problems.  If you look at the log, starting at timestamp 16:15:17, you will see first the attempt to send '1-2-3-4' from the Asterisk side in the channel debug, with no PDU generation information, then '1-2-3-4' sent from the Callmanager side, showing PDU catches and events generated. Any suggestions warranted.
Comments:	By: jerjer (jerjer) 2005-08-19 14:46:10 Show us the whole picture.  Turn on everything on the console line in logger.conf and issue a logger reload. Then make sure you are running with Set Verbose 3 By: pbd (pbd) 2005-08-19 15:12:10 Fullog attached- all the bells and whistles turned on, for a SIP hardphone (I can do same for IAX softphone if someone would like- result is the same). By: pbd (pbd) 2005-08-22 17:41:02 Ok, I've done a lot more digging into this one than I really wanted to, and this is really the first time I've gotten traction in reading the source.  I'm not ready to produce a patch at this time, however, I do have a suggested workaround that I'd like feedback from someone more knowledgeable than I on. Two things are happening- one is my implementation, Callmanager does not seem to want to announce rfc2833 capabilities in it's PDUs- in either direction.  Received  dtmf is coming in as tone, being caught in the channel driver, and sent up the line to Asterisk.   Unfortunately, I think I've caught a logic bug in chan_h323 that prevents rfc2833 dtmf from ever being sent out from asterisk on an h.323 trunk.  In oh323_digit, there is an if statement that essentially prevents asterisk from doing anything unless the options have been set to inband- the else clause is remarkably devoid of any functionality that's likely to send the dtmf on.  By reworking that if statement (removing it and the else clause), dtmf begins to work outbound from asterisk.   The oh323 stack, however, prevents rfc2833 from sending in my case- callmanager doesn't show it as an allowed codec- but it does fall back to inband.  Not useable for compressed codecs, unfortunately, but still functional. Can someone else with more experience back me up on this one before I submit a patch? By: Michael Jerris (mikej) 2005-08-24 01:29:46 are you seeing anything like on ASTERISK-4866 with strange timestamps? By: Michael Jerris (mikej) 2005-08-24 01:30:18 also, we are talking about chan_h323 driver here arn't we? By: pbd (pbd) 2005-08-24 06:47:35 Yes, I'm with chan_h323, and no, I've not seen the timestamp issue you're describing in 4993.  Given that it's attempting an RTP dtmf transfer, I'm assuming you're sending inband- so I've been ignoring it, as I'm configured to (attempt) to send rfc2833. By: David James (davidj) 2005-09-02 23:20:11 This effects SIP as well By: pbd (pbd) 2005-09-03 00:01:12 Perhaps it's an issue with copied code from one channel driver to another, then- because I've been running my pseudo-patch in test for a couple of weeks with no issues- and the only changes I've made was to chan_h323.  If I use SIP and eliminate h323 from the path entirely, I've never seen the problem- but my testing wasn't as extensive there.  I did originally have an issue on the SIP side of my call, but that was resolved through careful examination and correction of the relevant configs- there's a lot of things you need to make sure are configured before rfc2833 works properly- it's simple on the Asterisk side, but my SIP hardphone (7960) took a little RTFM on my part before it worked. Anyone want to confirm or deny this in the h323 driver?  If I catch a break, I'll post my patch- but it's so trivial, I'd still like someone with more experience in the guts of * to check out my analysis before I put my feet to it. By: Michael Jerris (mikej) 2005-09-03 07:16:02 If you have a patch, I would say the best approach is to file a disclaimer and put it out here to be reviewed. By: pbd (pbd) 2005-09-05 17:00:13 Patch uploaded that castrates the logic in oh323_digit- it will now send dtmf through regardless of the rfc2833 setting in h323.conf.  This should be safe- during initialization, the oh323 stack is initialized with our intentions on inband vs rfc2833, and the stack will do the right thing if possible- it will then fall back to inband if available using codec matching logic.  In other words, the logic removed by this patch has no purpose, so we should be safe in removing it.  Please test and report result. disclaimer is NOW on file (it wasn't when I opened this bug) By: jerjer (jerjer) 2005-09-14 23:16:12 applied to cvs -head. By: jerjer (jerjer) 2005-09-14 23:16:25 not in -stable By: Digium Subversion (svnbot) 2008-01-15 15:48:33.000-0600 Repository: asterisk Revision: 6613 U   trunk/channels/chan_h323.c ------------------------------------------------------------------------ r6613 | jeremy | 2008-01-15 15:48:33 -0600 (Tue, 15 Jan 2008) | 2 lines castrate the logic in oh323_digit to pass DTMF no matter what. (issue ASTERISK-4862) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6613