[asterisk-r2] Sending DTMF 'f' ?

Wed Mar 18 16:29:40 CDT 2009

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