[Home]

Summary:ASTERISK-00010: DTMF inconsistency somewhere between rtp.c and channel.c?
Reporter:km (km)Labels:
Date Opened:2003-07-24 14:17:34Date Closed:2011-06-07 14:04:44
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:While attempting to debug why X-Lite was not properly sending DTMF to the voicemail application, I found that it was in fact an issue with asterisk.  The digits are being successfully received by process_rfc2833, however it takes a few digits before ast_waitfordigit() actually catches the digit.  I've got several debug printf's inside the process_rfc2833 and ast_waitfordigit() functions, and it seems to be pointing to some bug in between the two functions.  It may also have something to do with deferred dtmf?  It's hard for me to tell as I'm not too familiar with rtp.c/channel.c

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

   -- Playing 'vm-login'
Event: 00000005 (len = 4)
Event: 00000009 (len = 4)
Event: 00000004 (len = 4)
Digit=9 (57)
Event: 00000006 (len = 4)
Digit=4 (52)
Event: 00000002 (len = 4)
Digit=6 (54)
Digit= (0)
   -- Playing 'vm-password'
Event: 00000001 (len = 4)
Digit=2 (50)
Event: 00000002 (len = 4)
Digit=1 (49)
Event: 00000003 (len = 4)
Digit=2 (50)
Event: 00000004 (len = 4)
Digit=3 (51)
Digit= (0)
   -- Incorrect password '2123' for user '5946' (context = <any>)
   -- Playing 'vm-incorrect'
Digit=ÿ (-1)
WARNING[29712]: File app_voicemail2.c, Line 2167 (vm_execmain): Couldn't read username
 == Spawn extension (default, 8500, 2) exited non-zero on 'SIP/59462-a5f4'
Comments:By: km (km) 2003-07-24 14:19:00

In the above example, my username is 59462, and the password is 1234.

By: km (km) 2003-07-24 15:12:06

More weirdness:  Looks like it writes the pressed digit one digit behind the new digit?

Event: 00000009 (len = 4)
Event: 00000000 (len = 4)
Digit=9 (57)
Event: 00000005 (len = 4)
Digit=0 (48)
Event: 00000009 (len = 4)
Digit=5 (53)
Event: 00000004 (len = 4)
Digit=9 (57)
Event: 00000006 (len = 4)
Digit=4 (52)
Event: 00000002 (len = 4)
Digit=6 (54)
dtmfcount was 300
dtmfcount is 0
Digit=2 (50)
Digit= (0)

By: km (km) 2003-07-24 15:47:14

After adding another debug call inside of ast_rtp_read, it shows the digits correctly at that point.  The "Digit=x (y)" are the character and integer representations of what ast_waitfordigit sees.


   -- Playing 'vm-login'
Event: 00000005 (len = 4)
Digit in rtp.c=5 (53)
Event: 00000009 (len = 4)
Digit in rtp.c=9 (57)
Event: 00000004 (len = 4)
Digit in rtp.c=4 (52)
Digit=9 (57)
Event: 00000006 (len = 4)
Digit in rtp.c=6 (54)
Digit=4 (52)
Event: 00000002 (len = 4)
Digit in rtp.c=2 (50)
Digit=6 (54)
dtmfcount was 300
dtmfcount is 0
Digit=2 (50)
Digit=ÿ (-1)

By: km (km) 2003-07-24 15:52:46

Oddly enough, after adding a buttload of debug all over the place, the problem doesnt happen anymore -- maybe its a timing related issue...?  It'd still be nice if someone could point out where the error of my ways is

By: km (km) 2003-07-25 08:36:58

This apparently is an intermittent problem -- it began working yesterday afternoon (as per last bugnote) but now the system with the exact same configuration is back to not sending the pending DTMF digits in time.  X-Lite is definitely sending the digits at the right time, but it seems like Asterisk is holding the last digit?  I'm thinking it has something to do with the dtmfcount variable in rtp.c

By: nirsim (nirsim) 2003-07-25 09:16:48

Small addition to this issue, as I've noticed another problem with the combination X-Lite+Asterisk+DTMF. If you punch in a number which has
repetative numbers in it, it will enter the wrong number into the
asterisk. For example: '116694' comes up as '1694' in the asterisk console.
This is very problematic, not only for voicemail, but also for applications
where a SIP phone would be used as a calling-card access phone.

By: km (km) 2003-07-25 09:25:45

The repetitive key problem looks like it may be a piece of the same problem -- there is code that tries to detect a single keypress, and if there's multiple presses of the same key, it thinks it's supposed to be just 1 instance of that DTMF press, so it keeps only 1 digit queued of that number.  I worked around this problem by adding another rtp packet structure in process_rfc2833 that forces the send_dtmf.  Only problem is, with clients like xlite that say by default to produce 280 packets of the DTMF tone, you need to change the setting to send just 1 packet.  Otherwise, you get some pretty interesting DTMF sequences..

By: Mark Spencer (markster) 2003-07-26 11:47:18

I believe this may be related to X-lite's DTMF generation.  Can you confirm this bug only occurs with X-lite?  I believe their timestamps may be incorrect as well.

By: nirsim (nirsim) 2003-07-27 09:45:08

Well, I've tested the issue with SJ-phone, which apparently doesn't send DTMF's at all. However, when using an analog phone connected to a USB-FXO device (the one you gave me, mark) and running asterisk on my local box, this doesn't happen. It may well be an X-Lite problem, but when I checked it with a different GW it didn't happen. The new version of X-Lite enables control over the DTMF's, hadn't yet had time to play around with it.

By: km (km) 2003-07-27 10:46:18

Erik at X-Lite said that he's on the problem in regards to the rfc_2833 not being up to snuff.   As for the multiple digits, maybe the fixing of rfc_2833 in regards to the duration will also clear up the double-digit dilemma.

By: Mark Spencer (markster) 2003-08-02 22:04:27

Fixed in new versions of X-lite