Asterisk DTMF 有时会被忽略(但仅限于某些人)
我有一个非常奇怪的问题,甚至不知道从哪里开始寻找。
我们使用 AGI 和 Java 库来呈现 IVR,但用户抱怨他们的按键被忽略。
在我的 sip.conf 的 general 部分下,我定义了如下 DTMF(“relax”行被注释掉):
dtmfmode = rfc2833
;relaxdtmf=yes
我已与提供商确认它应该是rfc2833,因为这是他们专门为我们配置的。
我在 logger.conf 中为我的 messages 文件打开了 dtmf 调试级别:
messages => notice,warning,error,dtmf
我现在看到这样的行:
DTMF[8744] channel.c: DTMF begin '1' received on SIP/veracity-00005052
DTMF[8744] channel.c: DTMF begin ignored '1' on SIP/veracity-00005052
DTMF[8744] channel.c: DTMF end '1' received on SIP/veracity-00005052, duration 270 ms
DTMF[8744] channel.c: DTMF end passthrough '1' on SIP/veracity-00005052
DTMF[8741] channel.c: DTMF begin '1' received on SIP/veracity-00005056
DTMF[8741] channel.c: DTMF begin ignored '1' on SIP/veracity-00005056
DTMF[8741] channel.c: DTMF end '1' received on SIP/veracity-00005056, duration 415 ms
DTMF[8741] channel.c: DTMF end passthrough '1' on SIP/veracity-00005056
事实上,它说, “忽略”让我担心,但我没有阅读任何信息或论坛帖子表明这是不需要的行为。
接收输入的 Java 代码如下所示。基本上,它会执行键返回的任何数字,或者 - 如果它为零 - 重播菜单。
char key = 0;
if ( validOptions.contains( "1" ) )
key = agiChan.streamFile( menu( "menu1" ), validOptions );
if ( validOptions.contains( "2" ) && key == 0 )
key = agiChan.streamFile( menu( "menu2" ), validOptions );
if ( validOptions.contains( "3" ) && key == 0 )
key = agiChan.streamFile( menu( "menu3" ), validOptions );
if ( !validOptions.contains( "1" ) && !validOptions.contains( "2" ) && key == 0 )
key = agiChan.streamFile( menu( "menu4" ), validOptions );
if ( key == 0 )
key = agiChan.waitForDigit( 5000 );
return key;
我对此感到不知所措,尤其是因为并不是每个人都会发生这种情况。我应该从哪里开始寻找/调试这样的东西?
先感谢您!
I have a very strange problem and don't even know where to begin to look.
We're using AGI and the Java libraries to present an IVR but have gotten complaints from the users that their keypresses are being ignored.
In my sip.conf, under the general section, I have DTMF defined like this (the "relax" line being commented out):
dtmfmode = rfc2833
;relaxdtmf=yes
I've confirmed with the provider that it should be rfc2833 as that is what they specifically configured for us.
I turned on dtmf debug level in my logger.conf to my messages file:
messages => notice,warning,error,dtmf
I now see lines like these:
DTMF[8744] channel.c: DTMF begin '1' received on SIP/veracity-00005052
DTMF[8744] channel.c: DTMF begin ignored '1' on SIP/veracity-00005052
DTMF[8744] channel.c: DTMF end '1' received on SIP/veracity-00005052, duration 270 ms
DTMF[8744] channel.c: DTMF end passthrough '1' on SIP/veracity-00005052
DTMF[8741] channel.c: DTMF begin '1' received on SIP/veracity-00005056
DTMF[8741] channel.c: DTMF begin ignored '1' on SIP/veracity-00005056
DTMF[8741] channel.c: DTMF end '1' received on SIP/veracity-00005056, duration 415 ms
DTMF[8741] channel.c: DTMF end passthrough '1' on SIP/veracity-00005056
The fact that it says, "ignored" concerns me but I haven't read any info or forum posts that would indicate this is unwanted behavior.
The Java code that receives the input looks like this. Basically it acts whatever digit gets returned by key or-- if it's zero-- replays the menu.
char key = 0;
if ( validOptions.contains( "1" ) )
key = agiChan.streamFile( menu( "menu1" ), validOptions );
if ( validOptions.contains( "2" ) && key == 0 )
key = agiChan.streamFile( menu( "menu2" ), validOptions );
if ( validOptions.contains( "3" ) && key == 0 )
key = agiChan.streamFile( menu( "menu3" ), validOptions );
if ( !validOptions.contains( "1" ) && !validOptions.contains( "2" ) && key == 0 )
key = agiChan.streamFile( menu( "menu4" ), validOptions );
if ( key == 0 )
key = agiChan.waitForDigit( 5000 );
return key;
I'm at a loss on this one, especially since it doesn't happen for everyone. Where would I even start looking/debugging something like this?
Thank you in advance!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
是的,它通常来自提供商端,因为信号是从提供商发送/接收的,请始终尝试使用不同的 dtmf 模式。
Yes, it's generally from the providers end because the signal is sent/received from the providers, always try using different dtmf modes.