[Freeswitch-users] Freetdm bridge to SIP DTMF problem

[Jakub Ouhrabka]

For the archives: <param name="rfc2833-pt" value="101"/> in the SIP 
profile solved my issue. In git master this is the default now.

Another interesting param/var is sip_liberal_dtmf=true which can make 
dtmf working against non complaint sip implementation.

Regards,

Jakub

Dne 19.8.2011 13:17, Jakub Ouhrabka napsal(a):
> Hi,
>
> another self follow-up: It seems that I have problem even when bridging
> SIP channel to SIP channel - DTMF is not sent to the called party. So I
> guess it's not Sangoma/Wanpipe/libpri/FreeTDM related. DTMF is correctly
> decoded but not forwarded (according to tcpdump/wireshark).
>
>  From the log:
>
> 2011-08-19 11:12:41.757636 [DEBUG] switch_rtp.c:3302 RTP RECV DTMF 5:880
> 2011-08-19 11:12:41.757636 [DEBUG] switch_ivr_bridge.c:391 Send signal
> sofia/external/XXXXXX at XXXXX.XX:5060 [BREAK]
>
> It must some stupid error in configuration - is there anything I have to
> set in SIP profile, or in bridge or somewhere else? Or must the called
> party somehow advertise that it is capable of receiving DTMF?
>
> Thanks,
>
> Jakub
>
> Dne 18.8.2011 14:53, Jakub Ouhrabka napsal(a):
>> Hi,
>>
>> I've tried further: both dtmf-type info and rfc2833 are not working
>> (can't see it in packet dump). Only dtmf-type set to "none" together
>> with start_dtmf_generate is working as expected for me - dtmf is
>> generated inband.
>>
>> How to force freeswitch to forward dtmf from freetdm to sofia preferably
>> using rfc2833?
>>
>> Thank you for any hints,
>>
>> Jakub
>>
>> Dne 18.8.2011 12:51, Jakub Ouhrabka napsal(a):
>>> Hi,
>>>
>>> we've changed OpenZAP to FreeTDM sometime ago and from that time we're
>>> experiencing problems with DTMF.
>>>
>>> We're bridging incoming ISDN30 calls from Sangoma A108DE card + libri +
>>> FreeTDM to SIP outgoing calls. Freeswitch is recognizing DTMF correctly
>>> but DTMF is not send to outgoing SIP call - it's not present in RTP
>>> stream trace (we've setup RFC2833 DTMF signalling). When bridging the
>>> call back to ISDN30 DTMF works correctly.
>>>
>>> We're using latest versions of all software as of 1 month ago.
>>>
>>> Below are attached two snippets of logs: first is bridging back to
>>> ISDN30 where DTMF is sent to called party. Second is bridging to SIP
>>> where DTMF is not sent to the called party.
>>>
>>> We've tried it with both <action application="start_dtmf" /> on and off
>>> with no success.
>>>
>>> Any pointers how to investigate the issue?
>>>
>>> Thanks,
>>>
>>> Jakub
>>>
>>> Log snippets:
>>>
>>> ISDN30 to ISDN30 bridge - DTMF ok
>>>
>>> 2011-08-18 12:31:45.950158 [DEBUG] ftmod_wanpipe.c:1545 [s1c11][1:11]
>>> read wanpipe event 3
>>> 2011-08-18 12:31:45.950158 [DEBUG] ftmod_wanpipe.c:1415 [s1c11][1:11]
>>> Queuing wanpipe DTMF: 5
>>> 2011-08-18 12:31:45.950158 [DEBUG] ftdm_io.c:3504 [s1c11][1:11] Queuing
>>> DTMF 5 (debug = 0)
>>> 2011-08-18 12:31:45.950158 [DEBUG] mod_freetdm.c:733 Queuing DTMF [5] in
>>> channel FreeTDM/1:11/XXXXXXXXX
>>> 2011-08-18 12:31:45.970623 [DEBUG] switch_ivr_bridge.c:391 Send signal
>>> FreeTDM/1:5/XXXXXXXXX [BREAK]
>>> 2011-08-18 12:31:45.991084 [DEBUG] ftdm_io.c:3694 [s1c5][1:5] Generating
>>> DTMF [5]
>>>
>>> ISDN30 to SIP bridge - DTMF not forwarded
>>>
>>> 2011-08-18 12:34:05.287480 [DEBUG] ftmod_wanpipe.c:1545 [s1c29][1:29]
>>> read wanpipe event 3
>>> 2011-08-18 12:34:05.607708 [DEBUG] ftmod_wanpipe.c:1545 [s1c29][1:29]
>>> read wanpipe event 3
>>> 2011-08-18 12:34:05.607708 [DEBUG] ftmod_wanpipe.c:1415 [s1c29][1:29]
>>> Queuing wanpipe DTMF: 6
>>> 2011-08-18 12:34:05.607708 [DEBUG] ftdm_io.c:3504 [s1c29][1:29] Queuing
>>> DTMF 6 (debug = 0)
>>> 2011-08-18 12:34:05.607708 [DEBUG] ftmod_libpri.c:1586 -- Caught Event
>>> span 1 18 (KEYPAD_DIGIT)
>>> 2011-08-18 12:34:05.628171 [DEBUG] mod_freetdm.c:733 Queuing DTMF [6] in
>>> channel FreeTDM/1:29/XXXXXXXXXXXXXXX
>>> 2011-08-18 12:34:05.628171 [DEBUG] switch_ivr_bridge.c:391 Send signal
>>> sofia/external/XXXXXXX at XXXXXXX:5060 [BREAK]
>>>