[asterisk-bugs] [Asterisk 0016664]: [patch] Random DTMF duplicate emulation on bridged OOH323 channel on outgoing calls
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Mar 2 23:32:50 CST 2010
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 23:32 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
======================================================================
----------------------------------------------------------------------
(0118811) vmikhelson (reporter) - 2010-03-02 23:32
https://issues.asterisk.org/view.php?id=16664#c118811
----------------------------------------------------------------------
Re: 118799
May213,
It works better with patch.
Specifically, I do not see "WARNING[10429]: chan_ooh323.c:1054
ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10"
in the middle of DTMF dialing. That allows to dial faster without loosing
digits.
It seems like calls originated on DAHDI lines work as they should with no
missing digits or repetitions.
Calls originated on SIP lines repeat almost every digit 2 times except "*"
which is passed correctly.
Please take a look at the Avaya IPOffice log. The string dialed was
"*7352#"
18975mS CMLineRx: v=9
CMCapabilityAck
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Product Unknown
19002mS PRN: Unhandled Facility
21136mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[*]
Product Unknown
Display [ThinkPad T60p]
22789mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[7]
Product Unknown
Display [ThinkPad T60p]
31836mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[3]
Product Unknown
Display [ThinkPad T60p]
32111mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[3]
Product Unknown
Display [ThinkPad T60p]
32673mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[5]
Product Unknown
Display [ThinkPad T60p]
32946mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[5]
Product Unknown
Display [ThinkPad T60p]
33882mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[2]
Product Unknown
Display [ThinkPad T60p]
34154mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[2]
Product Unknown
Display [ThinkPad T60p]
35616mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[#]
Product Unknown
Display [ThinkPad T60p]
35884mS CMLineRx: v=9
CMInformation
Line: type=IPLine 9
Call: lid=9 id=1 in=2
Keypad[#]
Product Unknown
Display [ThinkPad T60p]
Thank you,
Vladimir
Issue History
Date Modified Username Field Change
======================================================================
2010-03-02 23:32 vmikhelson Note Added: 0118811
======================================================================
More information about the asterisk-bugs
mailing list