[asterisk-bugs] [Asterisk 0016664]: [patch] 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:                     ready for testing
Asterisk Version:           SVN 
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-03-03 19:11 CST
====================================================================== 
Summary:                    [patch] 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

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

---------------------------------------------------------------------- 
 (0118928) vmikhelson (reporter) - 2010-03-03 19:11
 https://issues.asterisk.org/view.php?id=16664#c118928 
---------------------------------------------------------------------- 
Re: 0118916

May213,

The reason I asked about 0.9 was their "What is New" listed some
interesting enhancements. There was no talk about multi-threading though.

Since they are H.323 version 6 compliant I thought maybe the
RoundTripReqPacket processing was in there.

Unfortunately I cannot use the current trunk since the latest version
available with AsteriskNOW is 1.6.0.25.

Is it practical to expect that Addons 1.6.0.5 will have any of your
enhancements included?

Thank you,
Vladimir 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-03 19:11 vmikhelson     Note Added: 0118928                          
======================================================================