[Home]

Summary:ASTERISK-08693: DTMF translation from rfc2833 to inband is not reliable (no native bridging)
Reporter:mdu113 (mdu113)Labels:
Date Opened:2007-01-30 17:45:27.000-0600Date Closed:2007-07-11 19:58:46
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 2833-to-inband-still-bad.txt
( 1) crash10844.txt
( 2) dtmf_problem.log
Description:If asterisk translates DTMF from rfc2833 to inband because bridged peers have different DTMF modes and digits are dialed quickly then some digits get lost.
sip.conf:
[general]
disallow=all ; First disallow all codecs
allow=ulaw ; Allow codecs in order of preference
[pbx2]
type=friend
username=pbxtest
permit=66.114.83.0/255.255.255.192
deny=0.0.0.0/0.0.0.0
host=66.114.83.12
context=pbxes
sendrpid=yes
dtmfmode=inband
nat=yes
[xyz011101]
type=friend
username=xyz011101
md5secret=7c7bad2e3d3bb30bbfb413ec14755db2
context=xyz
host=dynamic
dtmfmode=rfc2833
callerid=111
mailbox=111@xyz
mohsuggest=xyz

Attached file has debugging output of the following scenario:
xyz011101 calls pbx2
pbx2 answers. asterisk performs generic bridging
xyz011101 sends digits '*13' in a quick succession. All digits recognized by asterisk
pbx2 recognized only * and 3.
First digit is always recognized then it's quite random. From the above example the remote peer could recognize * and 1 or * and 3 or just *.
If the digits are send with 2-3 seconds interval between them then they seem to be reliably recognized.


****** ADDITIONAL INFORMATION ******

This is a follow-up of issue 8936 which made DTMF translation possible.
DTMF translation from inband to rfc2833 seems to work fine.
Comments:By: mdu113 (mdu113) 2007-01-31 12:00:46.000-0600

It actually doesn't seem to be SIP related.
I think the core itself cannot generate inband DTMF properly.
If I have asterisk execute
Dial(<num>@<peer>,180,D(w*w1w3))
and the codec negotiated is ulaw and dtmfmode negotiated is inband the peer still recognizes only first digits reliably. Subsequent digits are most often not recognized.
Please let me know if you want me to repost it under 'Core Asterisk' section or if you need me to supply any additional debug.
Thanks.
By: mdu113 (mdu113) 2007-01-31 17:41:07.000-0600

Don't know if it's gonna help you.
I did some more experimenting and it seems to be somehow timing related.
If I install ztdummy and enable internal timing in asterisk then it works like 80-90% of times. Still not good enough, but much-much better.
By: Serge Vecher (serge-v) 2007-02-05 10:34:14.000-0600

the revision you are reporting is lower that that of the changes committed in 8936. Is this an issue with the latest 1.4 branch (r > 53.1K)?
By: mdu113 (mdu113) 2007-02-05 11:15:09.000-0600

Yes, it exists in 53120.
As I said I don't believe it's SIP related and I don't think it's issue 8936 related. It's just that working on that issue I noticed this problem.
I've spent some time investigating the problem and here are my findings:
- the correctness of generated tones very much depends on the rate at which
they have to be generated. I.e. if you dial digits slowly you have better chances they are transmitted properly.
- when there's no internal timing inband DTMF generation is just unusable. In my experiments I had to allow several seconds between digits to have them recognized
- with internal timing enabled the situation is much better, but the problem is still occuring if you dial digits particularly fast. My guess is that if the request to play out the next digit appear before asterisk finish playing the previous digit they get somehow mixed up. Also I noticed that when asterisk generated tone correctly the following line appear in debug.log:
[Feb  5 12:09:55] DEBUG[5002] channel.c: Auto-deactivating generator
If this line didn't appear in the log then in my experiments the digit is 100% not recognized by the peer.
Hope this helps.
By: Serge Vecher (serge-v) 2007-03-20 14:22:01

what's the status with 1.4.2?
By: mdu113 (mdu113) 2007-03-21 16:25:32

I see no changes as of current svn branch 1.4, revision 59089. The problem's still there
By: Russell Bryant (russell) 2007-04-23 13:01:18

I made a change in the 1.4 branch and trunk in revisions 61763 and 61764 that may help this issue.  I made it so all digits passing through Asterisk are forced to have a reasonable minimum length.  Give it a try and see if it helps.  Thanks!
By: Russell Bryant (russell) 2007-05-01 13:45:13

Feel free to reopen this issue if you are still having problems.

Thanks!
By: mdu113 (mdu113) 2007-05-01 15:10:43

Testing with revision 62497. The problem still exists.
The only change I actually see is that the following line:

DEBUG[5002] channel.c: Auto-deactivating generator

does now appear as many times as the number of digits i dialed, but only
the 1st digit is reliably recognized by the peer. Subsequent digits quite often get lost if I dial them fast enough.

Also with internal timing disabled it's still just unusable.
By: Russell Bryant (russell) 2007-05-02 14:15:57

I have created a branch with some changes that have *significantly* improved things in my local testing.  I would really appreciate it if you would give them a try before I merge them into 1.4 and trunk.

svn co http://svn.digium.com/svn/asterisk/team/russell/inband_dtmf asterisk-1.4-inband_dtmf
By: mdu113 (mdu113) 2007-05-02 15:52:45

Now it just segfaults for me at the moment i dial a digit.
crash10844.txt - is gdb backtrace.
In this case call leg 1 (originating) has dtmf mode rfc2833 and call leg 2 has dtmf mode inband, so asterisk is supposed to do translation.
By: Russell Bryant (russell) 2007-05-02 16:37:31

I'm very sorry!  I made a one character typo when I moved my patch to the branch.  It should be fixed now (revision 62783).


By: mdu113 (mdu113) 2007-05-02 17:26:40

No problem.
With internal timing enabled I do see a significant improvement now. I did manage to make it lose digits several times, but I had to try really hard, so I believe it's much better now and good enough for most practical uses. Thanks for your work.
Without internal timing it's as bad as it was before. Is it supposed to work without internal timing?
By: Russell Bryant (russell) 2007-05-02 17:39:41

Well, I'm glad it's better.  I'll go ahead and merge those changes into 1.4 and trunk.

Ideally, it would still work without the internal timing option.  I'll have to keep looking to figure out why that makes it worse.  I'm going to keep this open while I work on that part.

Thanks for all of the testing!
By: Russell Bryant (russell) 2007-05-02 18:00:20

The changes from my inband_dtmf branch have been merged into 1.4 and trunk in revisions 62789 and 62791.
By: mdu113 (mdu113) 2007-05-09 11:17:32

Unfortunately another dtmf problem showed up that i believe might be related to your last change. The bad thing is that it's very intermittent and hard to replicate. SVN revision is 63196. Here's the story.
I installed asterisk r63196 in a testing environment and tested it. I was unable to find any problems. Everything seemed to work fine.
Then I installed it on a production server. In the beginning everything seemed to work fine as well, but in about 10 hours a very nasty bug showed up.
When people make a call and after call is answered all they hear is never ending dtmf tone. After asterisk restart it returned back to normal, but I had to roll back to previous version anyway.
As you can guess I didn't have an opportunity to collect detailed debug. In uploaded file dtmf_problem.log is what I was able to find in the log.
It appears that for some reason asterisk is sending 'DTMF begin 4', but never sending 'DTMF end'. Also I know for sure that in this direct call between 2 extensions in the office no dtmf digits were dialed by human. Asterisk decided to send it on itself.
Now I'm trying to experiment with it in a testing environment and unable to replicate it again.
I understand that this is a very vague bug report, but this is all info I have.
I just hope that someone familiar with code will be able to get an idea what's  wrong. Thanks.
By: Russell Bryant (russell) 2007-05-09 14:46:35

I think it has been fixed in the 1.4 branch and trunk in revisions 63698 and 63699.  Give it a try
By: mdu113 (mdu113) 2007-05-09 17:20:20

Thanks.
It's compiled and as before seems to run fine in a testing environment.
I'm kind of reluctant to move it to production right away after what has happened this morning.
I'm going to keep running it in a testing environment for a week or 2.
Then I'll report back.
Also it would be great if someone else could test it and report their findings.
By: Russell Bryant (russell) 2007-05-10 17:05:55

I'm fairly certain that this is all fixed now.  Feel free to re-open if you come across a problem.  Thanks!