[Home]

Summary:ASTERISK-08575: dtmf digits are not transmited reliably from h323
Reporter:pj (pj)Labels:
Date Opened:2007-01-13 17:33:14.000-0600Date Closed:2007-02-10 03:28:43.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_h323
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have two asterisk boxes running SVN-branch-1.4-r50727,
when sending dtmf fast, all digits are not reliably transmited to another asterisk,
when sending with about 1sec pauses it's processed correctly.
codecs settings (gsm/alaw) on iax channel or jitterbuffer settings has no effect to this issue.

****** ADDITIONAL INFORMATION ******

"source" asterisk receives dtmf "724" from h323 channel and sends to iax channel to target asterisk, but digit "2" isn't corrently acknowledged:

bill*CLI-- Received user input tone (7) from remote
Tx-Frame Retry[000] -- OSeqno: 201 ISeqno: 089 Type: DTMF_B  Subclass: 7
  Timestamp: 294627ms  SCall: 00009  DCall: 00020 [192.168.38.20:4569]
Rx-Frame Retry[ No] -- OSeqno: 089 ISeqno: 202 Type: IAX     Subclass: ACK
  Timestamp: 294627ms  SCall: 00020  DCall: 00009 [192.168.38.20:4569]
Tx-Frame Retry[000] -- OSeqno: 202 ISeqno: 089 Type: DTMF_E  Subclass: 7
  Timestamp: 294945ms  SCall: 00009  DCall: 00020 [192.168.38.20:4569]
Rx-Frame Retry[ No] -- OSeqno: 089 ISeqno: 203 Type: IAX     Subclass: ACK
  Timestamp: 294945ms  SCall: 00020  DCall: 00009 [192.168.38.20:4569]

bill*CLI-- Received user input tone (2) from remote
Tx-Frame Retry[000] -- OSeqno: 203 ISeqno: 089 Type: DTMF_B  Subclass: 2
  Timestamp: 294957ms  SCall: 00009  DCall: 00020 [192.168.38.20:4569]
Rx-Frame Retry[ No] -- OSeqno: 089 ISeqno: 204 Type: IAX     Subclass: ACK
  Timestamp: 294957ms  SCall: 00020  DCall: 00009 [192.168.38.20:4569]

bill*CLI-- Received user input tone (4) from remote
Tx-Frame Retry[000] -- OSeqno: 204 ISeqno: 089 Type: DTMF_B  Subclass: 4
  Timestamp: 295307ms  SCall: 00009  DCall: 00020 [192.168.38.20:4569]
Rx-Frame Retry[ No] -- OSeqno: 089 ISeqno: 205 Type: IAX     Subclass: ACK
  Timestamp: 295307ms  SCall: 00020  DCall: 00009 [192.168.38.20:4569]






"target" asterisk receives "724" digits, but digit "2" is ignored:

Rx-Frame Retry[ No] -- OSeqno: 241 ISeqno: 101 Type: DTMF_B  Subclass: 7  
  Timestamp: 331147ms  SCall: 00009  DCall: 00020 [192.168.36.134:30112]
Tx-Frame Retry[-01] -- OSeqno: 101 ISeqno: 242 Type: IAX     Subclass: ACK
  Timestamp: 331147ms  SCall: 00020  DCall: 00009 [192.168.36.134:30112]
Rx-Frame Retry[ No] -- OSeqno: 242 ISeqno: 101 Type: DTMF_E  Subclass: 7  
  Timestamp: 331940ms  SCall: 00009  DCall: 00020 [192.168.36.134:30112]
Tx-Frame Retry[-01] -- OSeqno: 101 ISeqno: 243 Type: IAX     Subclass: ACK
  Timestamp: 331940ms  SCall: 00020  DCall: 00009 [192.168.36.134:30112]
                                                                         
Rx-Frame Retry[ No] -- OSeqno: 243 ISeqno: 101 Type: DTMF_B  Subclass: 2  
  Timestamp: 332017ms  SCall: 00009  DCall: 00020 [192.168.36.134:30112]
Tx-Frame Retry[-01] -- OSeqno: 101 ISeqno: 244 Type: IAX     Subclass: ACK
  Timestamp: 332017ms  SCall: 00020  DCall: 00009 [192.168.36.134:30112]
                                                                         
Rx-Frame Retry[ No] -- OSeqno: 244 ISeqno: 101 Type: DTMF_B  Subclass: 4  
  Timestamp: 332938ms  SCall: 00009  DCall: 00020 [192.168.36.134:30112]
Tx-Frame Retry[-01] -- OSeqno: 101 ISeqno: 245 Type: IAX     Subclass: ACK
  Timestamp: 332938ms  SCall: 00020  DCall: 00009 [192.168.36.134:30112]
Rx-Frame Retry[ No] -- OSeqno: 245 ISeqno: 101 Type: DTMF_E  Subclass: 4  
  Timestamp: 332941ms  SCall: 00009  DCall: 00020 [192.168.36.134:30112]
Tx-Frame Retry[-01] -- OSeqno: 101 ISeqno: 246 Type: IAX     Subclass: ACK
  Timestamp: 332941ms  SCall: 00020  DCall: 00009 [192.168.36.134:30112]

Comments:By: Tilghman Lesher (tilghman) 2007-01-13 22:13:03.000-0600

Which H.323 driver are you using?
By: pj (pj) 2007-01-14 03:45:11.000-0600

I'm using original chan_h323 from asterisk tree,
but keep in mind, that this issue is probably not related to h323 (digits are received correctly from h323, as you can see - "Received user input tone (4) from remote" - is debug from chan_h323),
but dtmf digits are incorrectly transmited over IAX to another box....

for all correctly transmited digits asterisk sends and acknoledges IAX event "DTMF_B" and "DTMF_E", but for incorrectly transmited digits asterisk sends and acknoledges only IAX event "DTMF_B" (event "DTMF_E" is completely missing), look at debug output.
By: Tilghman Lesher (tilghman) 2007-01-14 09:18:01.000-0600

What I'm concerned with is whether this is the fault of the IAX driver or the H323 driver.  The IAX driver probably generated each event as was queued from the H323 driver.  The real question is, when we receive a beginning DTMF event without a corresponding ending DTMF event, what is the proper course of action?

Your second Asterisk box (receiving IAX frames):  is that one 1.2 or 1.4?
By: Joshua C. Colp (jcolp) 2007-01-15 12:56:15.000-0600

A channel driver should *not* queue a begin dtmf frame without an end. If it is, then something is wrong. If the duration of DTMF or it's begin/end is not known, then the channel driver should queue only an end - and the core will compensate.
By: pj (pj) 2007-01-16 07:25:10.000-0600

I make some other test: receive call from h323 channel and capture digits,
from debug chan_h323 I see all digits, but correctly recognized are onlu some, look at debug (received are all digits 1-9, but recognized are only 1,4,7,8,9...
when I type digits slowly digits are recognized OK.


[Jan 16 14:15:59] NOTICE[14206]: rtp.c:780 process_rfc3389: Comfort noise support incomplete in Asterisk (RFC 3389). Please turn off on client if possible. Client IP: 192.168.40.5
[Jan 16 14:15:59]       -- Received user input tone (1) from remote
[Jan 16 14:15:59]     -- Stopped music on hold on H323/ip$192.168.40.7:53018/639
[Jan 16 14:15:59]       -- Received user input tone (2) from remote
[Jan 16 14:15:59]       -- Received user input tone (3) from remote
[Jan 16 14:16:00]       -- Received user input tone (4) from remote
[Jan 16 14:16:00]       -- Received user input tone (5) from remote
[Jan 16 14:16:01]       -- Received user input tone (6) from remote
[Jan 16 14:16:01]       -- Received user input tone (7) from remote
[Jan 16 14:16:01]       -- Received user input tone (8) from remote
[Jan 16 14:16:02]       -- Received user input tone (9) from remote
bill*CLI>
bill*CLI>
bill*CLI>
[Jan 16 14:16:08]     -- Invalid extension '14789' in context 'testik' on H323/ip$192.168.40.7:53018/639
[Jan 16 14:16:08]   == CDR updated on H323/ip$192.168.40.7:53018/639
[Jan 16 14:16:08]     -- Executing [i@testik:1] Playback("H323/ip$192.168.40.7:53018/639", "invalid") in new stack


capabilities nogotiated with my h323 peer (ci$co gw->callmanager->asterisk):

[Jan 16 14:13:10] Peer capability is UserInput/hookflash <44>
[Jan 16 14:13:10] Peer capability is UserInput/basicString <45>
[Jan 16 14:13:10] Peer capability is UserInput/dtmf <46>
[Jan 16 14:13:10] Peer capabilities = 0x8 (alaw), ordered list is (alaw)
[Jan 16 14:13:10]       -- Started logical channel: sending G.711-ALaw-64k
By: Serge Vecher (serge-v) 2007-01-17 08:46:21.000-0600

what's the dtmfmode setting for the peer?
By: pj (pj) 2007-01-17 15:00:17.000-0600

it's default ie. "rfc2833",
when I set "inband" it doesn't detect any digits.
on ci$co gw (connected to asterisk/chan_h323 via callmanager) I tried on voip dial-peer:
dtmf-relay h245-alphanumeric
or
dtmf-relay h245-signal
or
dtmf-relay rtp-nte
I tried also connecting gateway directly to asterisk (ie. without callmanager in path) but nothing helps solve this issue :-(


By: pj (pj) 2007-01-18 02:46:23.000-0600

right now, tested with calling chan_h323 from callmanager/ip phone, same result - dtmf digits must be typed slowly to be recognized correctly.

and because issue is probably related to chan_h323, not IAX, please change subject line and/or category.
By: Russell Bryant (russell) 2007-01-18 10:55:43.000-0600

The log output you show isn't quite complete.  On the transmit side, there is a DTMF_BEGIN and DTMF_END for the 7.  However, only a BEGIN for the 2 and 4.  On the receive side, there is an END showing for the 4, but still not the 2.  In the full output,  is a DTMF_END sent and received for the 2 as well?
By: pj (pj) 2007-01-18 11:06:36.000-0600

I wrongly pasted debug output, missing END for sending "4" but it was OK, only digit "2" was recognized wrong.
but as I wrote after, problem is probably not in IAX, but in chan_h323, my last test shows digits processing on only one server where I receive call from chan_h323 and test what digits are received...
By: pj (pj) 2007-01-20 11:25:13.000-0600

I tried with asterisk 1.2.10 and dtmf is working fine, all digits are recognized correctly (no matter if quickly or slowly typed),
so, I can confirm, that dtmf bug is in chan_h323 in 1.4 branch.
By: Paul Cadach (pcadach) 2007-01-22 03:03:30.000-0600

This is known issue. I'll try to fix it at begin of February.
By: pj (pj) 2007-02-06 09:52:51.000-0600

it's february, any progress with fixing this issue?
By: Paul Cadach (pcadach) 2007-02-06 23:35:50.000-0600

Nope. I'm trying to get some test environment... Also, there was a change related to variable length DTMF, so I should verify it too, probably it will be easily fixable now. Also, I should check status of my internal production installation - as I remember I updated something there related to DTMF...
By: Paul Cadach (pcadach) 2007-02-10 03:28:42.000-0600

Fixed by revision 53881 in 1.4 branch and revision 53885 in trunk.

If you still have issues, feel free to re-open bug and provide full possible debugging information:
core set debug 2
core set verbose 3
h323 set debug
h323 set trace 5
rtp debug


WBR,
Paul.