[asterisk-r2] Sending DTMF 'f' ?

Amilcar Silvestre amilcar at vonix.com.br
Wed Mar 18 15:20:17 CDT 2009


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




More information about the asterisk-r2 mailing list