[asterisk-users] DTMF digits falsely detected

Sat Sep 15 10:41:13 CDT 2012

On 9/15/2012 6:16 AM, Alec Davis wrote:
>  
>
>> -----Original Message-----
>> From: asterisk-users-bounces at lists.digium.com 
>> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of 
>> Vladimir Mikhelson
>> Sent: Saturday, 15 September 2012 5:56 p.m.
>> To: Asterisk Users Mailing List - Non-Commercial Discussion
>> Subject: Re: [asterisk-users] DTMF digits falsely detected
>>
>>
>> On 9/14/2012 11:04 PM, Matthew Jordan wrote:
>>> ----- Original Message -----
>>>> From: "Vladimir Mikhelson" <vlad at mikhelson.com>
>>>> To: "Asterisk Users Mailing List - Non-Commercial Discussion" 
>>>> <asterisk-users at lists.digium.com>
>>>> Sent: Friday, September 14, 2012 10:39:30 PM
>>>> Subject: Re: [asterisk-users] DTMF digits falsely detected
>>>>
>>>>
>>>> On 9/14/2012 10:11 PM, Matthew Jordan wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Vladimir Mikhelson" <vlad at mikhelson.com>
>>>>>> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
>>>>>> <asterisk-users at lists.digium.com>
>>>>>> Sent: Friday, September 14, 2012 9:24:41 PM
>>>>>> Subject: Re: [asterisk-users] DTMF digits falsely detected
>>>>>>
>>>>>>
>>>>>> On 9/14/2012 6:04 PM, Alec Davis wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: asterisk-users-bounces at lists.digium.com
>>>>>>>> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of 
>>>>>>>> Vieri
>>>>>>>> Sent: Saturday, 15 September 2012 8:45 a.m.
>>>>>>>> To: asterisk-users at lists.digium.com
>>>>>>>> Subject: [asterisk-users] DTMF digits falsely detected
>>>>>>>>
>>>>>> Can it be related to
>>>>>> https://issues.asterisk.org/jira/browse/ASTERISK-19610 ??
>>>>>>
>>>>>> -Vladimir
>>>>> Most likely not.  If the SIP peer is using rfc2833 DTMF, its most 
>>>>> likely related to r370252.
>>>>>
>>>>> Please file an issue on the issue tracker, 
>>>>> https://issues.asterisk.org/jira.
>>>>> Please include a pcap of the RTP stream and a DEBUG log with RTP 
>>>>> debug enabled, using 'rtp set debug on'.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --
>>>>> Matthew Jordan
>>>>>
>>>> Matt,
>>>>
>>>> I have created the issue.  See
>>>>
>> https://issues.asterisk.org/jira/browse/ASTERISK-20424?focusedComment
>>>> Id=197108#comment-197108
>>>>
>>>> Sorry, I will be unable to produce pcap and rtp debug as I 
>> have fixed 
>>>> the issue by uninstalling the Soft Phone I used for multiple years 
>>>> with no issues.
>>>>
>>>> -Vladimir
>>> Well, it'd be appreciated if someone who is experiencing 
>> this would be 
>>> willing to reproduce it and attach a pcap and DEBUG log to 
>> the issue.
>>> The bug fixed by that commit dealt with out of order DTMF; 
>> I suspect 
>>> that the problem is your soft phone is sending re-transmits 
>> of the end 
>>> event of the DTMF digit with an increasing timestamp.  The previous 
>>> behavior in Asterisk would most likely have been more 
>> tolerant of this 
>>> non-compliant scenario, but didn't handle the out of order 
>> packets as 
>>> well.
>>>
>>> Unfortunately, without evidence confirming that, there isn't much I 
>>> can do.
>>>
>>> --
>>> Matthew Jordan
>>>
>> Hopefully the initial poster still has the configuration to 
>> produce the files for you.
>>
>> Are you saying the DTMF logs I attached do not provide enough 
>> evidence to support the theory of the DTMF length being the 
>> cause of this issue?
>>
>> -Vladimir
>>
> Vladimir,
> 	What was the Softphone/Version you were using to get this to fail.
>
> 	I'm using an old version of X-Lite, V3.0 build 56125 and with
> asterisk 1.8.16.0 when in voicemail I was unable to get any errors. DTMF log
> below.
>   
> [2012-09-15 22:36:39.974909] DTMF[1706] channel.c: DTMF begin '1' received
> on SIP/alec-00000009
> [2012-09-15 22:36:39.974985] DTMF[1706] channel.c: DTMF begin ignored '1' on
> SIP/alec-00000009
> [2012-09-15 22:36:40.514978] DTMF[1706] channel.c: DTMF end '1' received on
> SIP/alec-00000009, duration 560                                  ms
> [2012-09-15 22:36:40.515037] DTMF[1706] channel.c: DTMF end passthrough '1'
> on SIP/alec-00000009
> [2012-09-15 22:36:41.014955] DTMF[1706] channel.c: DTMF begin '2' received
> on SIP/alec-00000009
> [2012-09-15 22:36:41.015009] DTMF[1706] channel.c: DTMF begin ignored '2' on
> SIP/alec-00000009
> [2012-09-15 22:36:41.459045] DTMF[1706] channel.c: DTMF end '2' received on
> SIP/alec-00000009, duration 460                                  ms
> [2012-09-15 22:36:41.459089] DTMF[1706] channel.c: DTMF end passthrough '2'
> on SIP/alec-00000009
> [2012-09-15 22:36:41.909042] DTMF[1706] channel.c: DTMF begin '3' received
> on SIP/alec-00000009
> [2012-09-15 22:36:41.909093] DTMF[1706] channel.c: DTMF begin ignored '3' on
> SIP/alec-00000009
> [2012-09-15 22:36:42.429177] DTMF[1706] channel.c: DTMF end '3' received on
> SIP/alec-00000009, duration 540                                  ms
> [2012-09-15 22:36:42.429236] DTMF[1706] channel.c: DTMF end passthrough '3'
> on SIP/alec-00000009
> [2012-09-15 22:36:42.849091] DTMF[1706] channel.c: DTMF begin '4' received
> on SIP/alec-00000009
> [2012-09-15 22:36:42.849185] DTMF[1706] channel.c: DTMF begin ignored '4' on
> SIP/alec-00000009
> [2012-09-15 22:36:44.489226] DTMF[1706] channel.c: DTMF end '4' received on
> SIP/alec-00000009, duration 1660                                 
>
>
>
Alec,

Thank you for looking into that.

X-Lite v3.0, build 41150, is what I switched to.

Interestingly in your log DTMF durations are even greater than in my
original sampling.  Well, maybe my "duration" theory is not right.  But
needed to exclude it first as it was on the surface.  I am assuming you
dialed the digits normally, i.e. did not try to push a button longer
than usual.

The Soft Phone I used originally was Minipax v2.8.5.  Please contact me
off-list if you need the Windows installation package as the maker's
site is down as of this moment.

Another interesting thing which our friend Matt apparently did not pay
attention to was the fact that dialing worked fine with Minipax, it was
the applications where problems started.  Sounds like his latest patch
was not applied consistently throughout the system.  Good news for now,
but could change in the future.

Thank you,
Vladimir