[asterisk-r2] Sending DTMF 'f' ?

Wed Mar 18 16:33:38 CDT 2009

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