[asterisk-bugs] [Asterisk 0016664]: Random DTMF duplicate emulation on bridged OOH323 channel on outgoing calls

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16664 
====================================================================== 
Reported By:                vmikhelson
Assigned To:                may213
====================================================================== 
Project:                    Asterisk
Issue ID:                   16664
Category:                   Addons/chan_ooh323
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.6.0.20 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-01-21 00:44 CST
Last Modified:              2010-01-24 15:02 CST
====================================================================== 
Summary:                    Random DTMF duplicate emulation on bridged OOH323
channel on outgoing calls
Description: 
In majority of cases DTMF tones are duplicated by Asterisk when bridging a
SIP or DAHDI channel with OOH323 channel on outgoing calls.

In case of a normal DTMF processing the following sequence is observed:

[Jan 20 19:59:56] DTMF[21084]: channel.c:2855 __ast_read: DTMF begin '9'
received on SIP/464-00000012
[Jan 20 19:59:56] DTMF[21084]: channel.c:2865 __ast_read: DTMF begin
passthrough '9' on SIP/464-00000012
[Jan 20 19:59:56] DTMF[21084]: channel.c:2783 __ast_read: DTMF end '9'
received on SIP/464-00000012, duration 120 ms
[Jan 20 19:59:56] DTMF[21084]: channel.c:2823 __ast_read: DTMF end
accepted with begin '9' on SIP/464-00000012
[Jan 20 19:59:56] DTMF[21084]: channel.c:2839 __ast_read: DTMF end
passthrough '9' on SIP/464-00000012

In case of a problematic DTMF processing it looks like that:

[Jan 20 19:18:54] DTMF[20916]: channel.c:2855 __ast_read: DTMF begin '9'
received on SIP/464-00000011
[Jan 20 19:18:54] DTMF[20916]: channel.c:2865 __ast_read: DTMF begin
passthrough '9' on SIP/464-00000011
[Jan 20 19:18:54] DTMF[20916]: channel.c:2783 __ast_read: DTMF end '9'
received on OOH323/172.17.135.2:1720-9915, duration 0 ms
[Jan 20 19:18:54] DTMF[20916]: channel.c:2809 __ast_read: DTMF begin
emulation of '9' with duration 100 queued on OOH323/172.17.135.2:1720-9915
[Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
Don't know how to indicate condition 20 on ooh323c_o_21
[Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
Don't know how to indicate condition 20 on ooh323c_o_21
[Jan 20 19:18:54] DTMF[20916]: channel.c:2932 __ast_read: DTMF end
emulation of '9' queued on OOH323/172.17.135.2:1720-9915
[Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
Don't know how to indicate condition 20 on ooh323c_o_21
[Jan 20 19:18:54] DTMF[20916]: channel.c:2783 __ast_read: DTMF end '9'
received on SIP/464-00000011, duration 120 ms
[Jan 20 19:18:54] DTMF[20916]: channel.c:2823 __ast_read: DTMF end
accepted with begin '9' on SIP/464-00000011
[Jan 20 19:18:54] DTMF[20916]: channel.c:2839 __ast_read: DTMF end
passthrough '9' on SIP/464-00000011
[Jan 20 19:18:55] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate:
Don't know how to indicate condition 20 on ooh323c_o_21

====================================================================== 

---------------------------------------------------------------------- 
 (0117110) vmikhelson (reporter) - 2010-01-24 15:02
 https://issues.asterisk.org/view.php?id=16664#c117110 
---------------------------------------------------------------------- 
Another noticeable symptom.

In case Asterisk establishes an outgoing OOH323 connection with described
DTMF problems the connection hangs up at exactly 394 seconds. The end point
on another end of the H.323 link is unaware about the connection drop and
does not send a busy signal or otherwise indicate the conversation
termination to a user.


[Jan 22 19:17:27] VERBOSE[19618] logger.c:     -- Called
352 at 172.17.135.2:1720
[Jan 22 19:17:27] VERBOSE[19618] logger.c:     --
OOH323/172.17.135.2:1720-10ec is ringing
[Jan 22 19:17:30] VERBOSE[19618] logger.c:     --
OOH323/172.17.135.2:1720-10ec answered SIP/435-00000001
[Jan 22 19:17:30] WARNING[19618] chan_ooh323.c: Don't know how to indicate
condition 20 on ooh323c_o_3
[Jan 22 19:24:04] VERBOSE[19618] logger.c:     -- Executing
[h at macro-dialout-trunk:1] Macro("SIP/435-00000001", "hangupcall,") in new
stack
[Jan 22 19:24:04] VERBOSE[19618] logger.c:     -- Executing
[s at macro-hangupcall:1] GotoIf("SIP/435-00000001", "1?skiprg") in new stack
[Jan 22 19:24:04] VERBOSE[19618] logger.c:     -- Goto
(macro-hangupcall,s,4)



[Jan 22 19:24:22] VERBOSE[19639] logger.c:     -- Called
352 at 172.17.135.2:1720
[Jan 22 19:24:23] VERBOSE[19639] logger.c:     --
OOH323/172.17.135.2:1720-ee44 is ringing
[Jan 22 19:24:27] VERBOSE[19639] logger.c:     --
OOH323/172.17.135.2:1720-ee44 answered SIP/435-00000002
[Jan 22 19:24:27] WARNING[19639] chan_ooh323.c: Don't know how to indicate
condition 20 on ooh323c_o_4
[Jan 22 19:31:01] VERBOSE[19639] logger.c:     -- Executing
[h at macro-dialout-trunk:1] Macro("SIP/435-00000002", "hangupcall,") in new
stack
[Jan 22 19:31:01] VERBOSE[19639] logger.c:     -- Executing
[s at macro-hangupcall:1] GotoIf("SIP/435-00000002", "1?skiprg") in new stack
[Jan 22 19:31:01] VERBOSE[19639] logger.c:     -- Goto
(macro-hangupcall,s,4) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-01-24 15:02 vmikhelson     Note Added: 0117110                          
======================================================================