[asterisk-r2] Sending DTMF 'f' ?

Wed Mar 18 16:39:42 CDT 2009

Moises,

No actions from manager here.

I'm suspecting that this comes from the hardware DTMF detection in the  
echo cancelation module in the board (Sangoma A104D), altough i've  
never seem this happened, and I have at lest 60 others boxes with R2  
and hardware dtmf detection using sangoma. Works like a charm. I've  
turned it off. Let us see if the problem persists.

Regards,
Amilcar.

On Mar 18, 2009, at 5:33 PM, Moises Silva wrote:

> No is not enough to see DAHDI/3-1, because that message is printed by
> the core, but the core may have dequeued this DTMF digit from other
> source than a read() in chan_dahdi.c, as I said, it may have come from
> the manager (which is capable of enqueueing DTMF in any channel), and
> there is other ways to fake incoming DTMF.
>
> Moy
>
> On Wed, Mar 18, 2009 at 5:29 PM, Amilcar Silvestre <amilcar at vonix.com.br 
> > wrote:
>> The "DTMF Down " message will only be seem if i turn DEBUG level to
>> the logs. DMTF only is not sufficient. Doing it now.
>>
>> Amilcar.
>>
>> On Mar 18, 2009, at 5:23 PM, Amilcar Silvestre wrote:
>>
>>> Moises,
>>>
>>> DTMF begin 'f'received on DAHDI/3-1 doesn't mean that the DTMF is
>>> coming from DAHDI??
>>>
>>> No DTMF Down anywhere in the logs.
>>>
>>> Amilcar.
>>>
>>> On Mar 18, 2009, at 5:15 PM, Moises Silva wrote:
>>>
>>>> I still fail to see the log where this DTMF comes from chan_dahdi.c
>>>>
>>>> Did you just miss it?
>>>>
>>>> Can you check your log and see if you can find a message like:
>>>>
>>>> DTMF Down 'f'
>>>>
>>>> in chan_dahdi?? otherwise somehow that DTMF is received from
>>>> somewhere
>>>> else, perhaps a manager application or something like that?
>>>>
>>>> On Wed, Mar 18, 2009 at 4:51 PM, Amilcar Silvestre <amilcar at vonix.com.br
>>>>> wrote:
>>>>> Moises,
>>>>>
>>>>> The log from console, with dtmf debug enabled is:
>>>>>
>>>>> [Mar 18 17:49:59] DTMF[3411]: channel.c:2279 __ast_read: DTMF  
>>>>> begin
>>>>> 'f' received on DAHDI/3-1
>>>>> [Mar 18 17:49:59] DTMF[3411]: channel.c:2289 __ast_read: DTMF  
>>>>> begin
>>>>> passthrough 'f' on DAHDI/3-1
>>>>> [Mar 18 17:49:59] WARNING[3411]: rtp.c:2205  
>>>>> ast_rtp_senddigit_begin:
>>>>> Don't know how to represent 'f'
>>>>>
>>>>> Amilcar.
>>>>>
>>>>> On Mar 18, 2009, at 4:47 PM, Amilcar Silvestre wrote:
>>>>>
>>>>>> Hi Moyses,
>>>>>>
>>>>>> Ok, I've enabled DTMF debugging, and here's what i've got:
>>>>>>
>>>>>> [Mar 18 17:34:12] NOTICE[2690] chan_dahdi.c: MFC/R2 call has been
>>>>>> accepted on chan 10
>>>>>> [Mar 18 17:34:12] NOTICE[2690] chan_dahdi.c: Call accepted on
>>>>>> forward
>>>>>> channel 10
>>>>>> (...)
>>>>>> [Mar 18 17:39:51] DTMF[2705] channel.c: DTMF begin 'f' received  
>>>>>> on
>>>>>> DAHDI/10-1
>>>>>> [Mar 18 17:39:51] DTMF[2705] channel.c: DTMF begin passthrough  
>>>>>> 'f'
>>>>>> on
>>>>>> DAHDI/10-1
>>>>>> [Mar 18 17:39:51] WARNING[2705] rtp.c: Don't know how to  
>>>>>> represent
>>>>>> 'f'
>>>>>> (...)
>>>>>> [Mar 18 17:40:17] DTMF[2705] channel.c: DTMF begin 'f' received  
>>>>>> on
>>>>>> DAHDI/10-1
>>>>>> [Mar 18 17:40:17] DTMF[2705] channel.c: DTMF begin passthrough  
>>>>>> 'f'
>>>>>> on
>>>>>> DAHDI/10-1
>>>>>> [Mar 18 17:40:17] WARNING[2705] rtp.c: Don't know how to  
>>>>>> represent
>>>>>> 'f'
>>>>>> (...)
>>>>>> [Mar 18 17:40:24] DTMF[2705] channel.c: DTMF begin 'f' received  
>>>>>> on
>>>>>> DAHDI/10-1
>>>>>> [Mar 18 17:40:24] DTMF[2705] channel.c: DTMF begin passthrough  
>>>>>> 'f'
>>>>>> on
>>>>>> DAHDI/10-1
>>>>>> [Mar 18 17:40:24] WARNING[2705] rtp.c: Don't know how to  
>>>>>> represent
>>>>>> 'f'
>>>>>> (...)
>>>>>> [Mar 18 17:40:44] DTMF[2705] channel.c: DTMF begin 'f' received  
>>>>>> on
>>>>>> DAHDI/10-1
>>>>>> [Mar 18 17:40:44] DTMF[2705] channel.c: DTMF begin passthrough  
>>>>>> 'f'
>>>>>> on
>>>>>> DAHDI/10-1
>>>>>> [Mar 18 17:40:44] WARNING[2705] rtp.c: Don't know how to  
>>>>>> represent
>>>>>> 'f'
>>>>>> [Mar 18 17:40:45] DTMF[2793] channel.c: DTMF begin 'f' received  
>>>>>> on
>>>>>> DAHDI/12-1
>>>>>> [Mar 18 17:40:45] DTMF[2793] channel.c: DTMF begin passthrough  
>>>>>> 'f'
>>>>>> on
>>>>>> DAHDI/12-1
>>>>>> [Mar 18 17:40:45] WARNING[2793] rtp.c: Don't know how to  
>>>>>> represent
>>>>>> 'f'
>>>>>> (...)
>>>>>> [Mar 18 17:43:05] NOTICE[2705] chan_dahdi.c: Chan 10 - Far end
>>>>>> disconnected. Reason: Forced Release
>>>>>> [Mar 18 17:43:05] NOTICE[2705] chan_dahdi.c: MFC/R2 call
>>>>>> disconnected
>>>>>> on chan 10
>>>>>> [Mar 18 17:43:05] NOTICE[4775] chan_dahdi.c: MFC/R2 call end on
>>>>>> chan
>>>>>> 10
>>>>>>
>>>>>> And this is happening in two different telcos.
>>>>>>
>>>>>> Yes, I've patched asterisk. The patch is that from googlecode for
>>>>>> 1.4.23, with a very tiny modification to make the channel returns
>>>>>> the
>>>>>> hangupcause.
>>>>>>
>>>>>> Amilcar.
>>>>>>
>>>>>>
>>>>>> On Mar 18, 2009, at 4:32 PM, Moises Silva wrote:
>>>>>>
>>>>>>> Hum, I see what you mean. But, MFC and DTMF use different pair  
>>>>>>> of
>>>>>>> frequencies and F does not even exist in DTMF. Please enable  
>>>>>>> dtmf
>>>>>>> debugging in your logger.conf and try to reproduce, I'd expect  
>>>>>>> to
>>>>>>> see
>>>>>>> clearly if chan_dahdi/chan_zap is the one detecting a MF digit  
>>>>>>> and
>>>>>>> wrongly sending it down to the core as DTMF digit.
>>>>>>>
>>>>>>> Did you patched that asterisk yourself?
>>>>>>>
>>>>>>> From a quick look at the code, the 'f' frame subclass is also  
>>>>>>> used
>>>>>>> for
>>>>>>> FAX, so that f does not necessarily refers to the MF F tone.
>>>>>>>
>>>>>>> Moy
>>>>>>>
>>>>>>> On Wed, Mar 18, 2009 at 4:20 PM, Amilcar Silvestre <amilcar at vonix.com.br
>>>>>>>> wrote:
>>>>>>>> Hi Moises,
>>>>>>>>
>>>>>>>> I've already recorded the call using mixmonitor on the sip  
>>>>>>>> side.
>>>>>>>> The
>>>>>>>> same on the recorded file. Mixmonitor only records the sip  
>>>>>>>> side,
>>>>>>>> and
>>>>>>>> the far end is muted.
>>>>>>>>
>>>>>>>> And the problem only occurs on the R2 links. PRI works ok (same
>>>>>>>> box).
>>>>>>>>
>>>>>>>> Seems that, after it enters on the function
>>>>>>>> ast_rtp_senddigit_begin
>>>>>>>> in
>>>>>>>> rtp.c, the function returns 0 (it doesn't have the "f" digit  
>>>>>>>> for
>>>>>>>> DTMF,
>>>>>>>> the digit 'f' is related to MFC). After it returns 0, the audio
>>>>>>>> from
>>>>>>>> DAHDI stops been redirected to the sip end point.
>>>>>>>>
>>>>>>>> Amilcar.
>>>>>>>>
>>>>>>>> On Mar 18, 2009, at 4:08 PM, Moises Silva wrote:
>>>>>>>>
>>>>>>>>> I think you should try to post this in asterisk-users, this is
>>>>>>>>> not
>>>>>>>>> an R2 issue.
>>>>>>>>>
>>>>>>>>> Having said that, it would be a good idea to reproduce, and
>>>>>>>>> then,
>>>>>>>>> when
>>>>>>>>> you have a call like that, use dahdi_monitor or ztmonitor to
>>>>>>>>> verify
>>>>>>>>> the audio is getting into the board correctly, then you can
>>>>>>>>> monitor
>>>>>>>>> the RTP traffic on the SIP side of the call and see if  
>>>>>>>>> Asterisk
>>>>>>>>> is
>>>>>>>>> still sending the audio correctly, if it does, then the  
>>>>>>>>> problem
>>>>>>>>> is
>>>>>>>>> definitely not even in Asterisk.
>>>>>>>>>
>>>>>>>>> On Wed, Mar 18, 2009 at 3:54 PM, Amilcar Silvestre <amilcar at vonix.com.br
>>>>>>>>>> wrote:
>>>>>>>>>> Douglas,
>>>>>>>>>> If you meant the CAS bits, is 1101.
>>>>>>>>>> If you mean the configuration of the link:
>>>>>>>>>> signalling=mfcr2
>>>>>>>>>> mfcr2_variant=br
>>>>>>>>>> mfcr2_get_ani_first=no
>>>>>>>>>> mfcr2_max_ani=10
>>>>>>>>>> mfcr2_max_dnis=4
>>>>>>>>>> mfcr2_category=national_subscriber
>>>>>>>>>> mfcr2_logdir=span1
>>>>>>>>>> mfcr2_logging=all
>>>>>>>>>> mfcr2_metering_pulse_timeout=500
>>>>>>>>>> Regards,
>>>>>>>>>> Amilcar.
>>>>>>>>>>
>>>>>>>>>> On Mar 18, 2009, at 3:50 PM, Douglas Fischer wrote:
>>>>>>>>>>
>>>>>>>>>> What do you have in your start bits? (zapata.conf)
>>>>>>>>>>
>>>>>>>>>> 2009/3/18 Amilcar Silvestre <amilcar at vonix.com.br>
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I have a box using asterisk 1.4.23.2, and OpenR2 1.1.0. The
>>>>>>>>>>> board
>>>>>>>>>>> is a
>>>>>>>>>>> Sangoma A104D, From times to times, it shows this message:
>>>>>>>>>>>
>>>>>>>>>>> WARNING[31548] rtp.c: Don't know how to represent 'f'
>>>>>>>>>>>
>>>>>>>>>>> Seems to be something related to sending a DTMF digit. After
>>>>>>>>>>> this
>>>>>>>>>>> message, the caller (an internal SIP endpoint) doens't hear
>>>>>>>>>>> anything
>>>>>>>>>>> more from the called (far end, coming from a R2 link), but  
>>>>>>>>>>> the
>>>>>>>>>>> far
>>>>>>>>>>> end
>>>>>>>>>>> keeps receiving the audio from the SIP end point.
>>>>>>>>>>>
>>>>>>>>>>> The message comes with no intervention from the user on SIP
>>>>>>>>>>> end
>>>>>>>>>>> point.
>>>>>>>>>>>
>>>>>>>>>>> Does anyone knows what is happening?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Amilcar.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>>> digital.com--
>>>>>>>>>>>
>>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Douglas Fernando Fischer
>>>>>>>>>> Engº de Controle e Automação
>>>>>>>>>> _______________________________________________
>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>> digital.com--
>>>>>>>>>>
>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>>> digital.com--
>>>>>>>>>>
>>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> "I do not agree with what you have to say, but I’ll defend to
>>>>>>>>> the
>>>>>>>>> death your right to say it." Voltaire
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>>> digital.com--
>>>>>>>>>
>>>>>>>>> asterisk-r2 mailing list
>>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>>> digital.com--
>>>>>>>>
>>>>>>>> asterisk-r2 mailing list
>>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> "I do not agree with what you have to say, but I’ll defend to  
>>>>>>> the
>>>>>>> death your right to say it." Voltaire
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> --Bandwidth and Colocation Provided by http://www.api-
>>>>>>> digital.com--
>>>>>>>
>>>>>>> asterisk-r2 mailing list
>>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>> http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> --Bandwidth and Colocation Provided by http://www.api- 
>>>>>> digital.com--
>>>>>>
>>>>>> asterisk-r2 mailing list
>>>>>> To UNSUBSCRIBE or update options visit:
>>>>>>  http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> --Bandwidth and Colocation Provided by http://www.api- 
>>>>> digital.com--
>>>>>
>>>>> asterisk-r2 mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>>  http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> "I do not agree with what you have to say, but I’ll defend to the
>>>> death your right to say it." Voltaire
>>>>
>>>> _______________________________________________
>>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>>
>>>> asterisk-r2 mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>>  http://lists.digium.com/mailman/listinfo/asterisk-r2
>>>
>>>
>>> _______________________________________________
>>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>>
>>> asterisk-r2 mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-r2
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-r2 mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-r2
>>
>
>
>
> -- 
> "I do not agree with what you have to say, but I’ll defend to the
> death your right to say it." Voltaire
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-r2 mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-r2