[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-02 22:09 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

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

---------------------------------------------------------------------- 
 (0118808) vmikhelson (reporter) - 2010-03-02 22:09
 https://issues.asterisk.org/view.php?id=16664#c118808 
---------------------------------------------------------------------- 
Re: 0118798

May213,

Thank you for the disconnect issue analysis. I have captured several
packet traces which definitely showed the H.245 Round TripDelayRequest
messages being ignored by Asterisk's H323 channel.

I do not think fixing this falls into a "new feature request" category. It
is a major oversight in the channel design. See
http://www.packetizer.com/in/q43.html

The inner workings of the underlying H323 protocol are mostly not
configurable on Avaya IPOffice 403. And even if they were I would not
suggest to disable the required portion of the protocol.

In some implementations, like for example Cisco ATA 188, the feature is
not enabled by default but is easily settable.

If you still think that IRC is a better place to discuss fixing this issue
please let me know how I can reach you there.

Thank you,
Vladimir 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-02 22:09 vmikhelson     Note Added: 0118808                          
======================================================================