[Freeswitch-users] DTMF issues/question
Marc Lewis
marc at avvatel.com
Thu Sep 11 15:51:53 PDT 2008
This is outbound, the diagram would look something like:
phone -> sofia profile internal -> sofia profile external -> my sip
proxy (openser for routing)-> term provider
Inbound from PSTN works fine. All DTMF digits are recognized in
voicemail, IVR's, etc. Phones also have no problems with DTMF for their
voicemail, etc.
The problems arise when trying to send to other IVR's. My last tests
have been to call my two different banks and american express. None of
the three of them recognized the DTMF tones.
- Marc
Brian West wrote:
> Is this inbound or outbound ?
>
> PSTN -> YOU
>
> YOU -> PSTN
>
> Which way and what makes you think you're dtmf isn't working. I just
> want to make sure we are on the same page.
>
>
> /b
>
> On Sep 11, 2008, at 5:34 PM, Marc Lewis wrote:
>
>> I've got logging turned up, and it appears that FS is doing the right
>> thing, but PointOne (my termination provider) isn't honoring it.
>>
>> I am doing transcoding on some calls (GSM or G726-32 on the phone,
>> PCMU always out to PointOne).
>>
>> If you want to test, I would be happy to add your IP to my proxy's
>> trusted IP list for a time so you can route calls out through it.
>> Contact me off-list and I can get you (or Brian) set up on it.
>>
>>
>> This was testing with dtmf-type set to rfc2388 for both my internal
>> and external sofia profiles. Phones register on internal and calls
>> go out through external. Here are the logs from a couple of digits:
>>
>> 2008-09-11 14:39:48 [DEBUG] switch_core_io.c:734
>> switch_core_session_write_frame() Engaging Write Buffer at 320 bytes
>> to accomodate 640->320
>> 2008-09-11 14:39:56 [DEBUG] switch_rtp.c:1201 do_2833() Send start
>> packet for [3] ts=2394311623 dur=160/160/2000 seq=42444
>> 2008-09-11 14:39:56 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=320/320/2000 seq=42445
>> 2008-09-11 14:39:56 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=480/480/2000 seq=42446
>> 2008-09-11 14:39:56 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=640/640/2000 seq=42447
>> 2008-09-11 14:39:56 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=800/800/2000 seq=42448
>> 2008-09-11 14:39:56 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=960/960/2000 seq=42449
>> 2008-09-11 14:39:56 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=1120/1120/2000 seq=42450
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=1280/1280/2000 seq=42451
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=1440/1440/2000 seq=42452
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=1600/1600/2000 seq=42453
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=1760/1760/2000 seq=42454
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [3] ts=2394311623 dur=1920/1920/2000 seq=42455
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send end
>> packet for [3] ts=2394311623 dur=2080/2080/2000 seq=42456
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send end
>> packet for [3] ts=2394311623 dur=2080/2080/2000 seq=42457
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send end
>> packet for [3] ts=2394311623 dur=2080/2080/2000 seq=42458
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1201 do_2833() Send start
>> packet for [7] ts=2394314503 dur=160/160/2000 seq=42465
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=320/320/2000 seq=42466
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=480/480/2000 seq=42467
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=640/640/2000 seq=42468
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=800/800/2000 seq=42469
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=960/960/2000 seq=42470
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=1120/1120/2000 seq=42471
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=1280/1280/2000 seq=42472
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=1440/1440/2000 seq=42473
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=1600/1600/2000 seq=42474
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=1760/1760/2000 seq=42475
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send middle
>> packet for [7] ts=2394314503 dur=1920/1920/2000 seq=42476
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send end
>> packet for [7] ts=2394314503 dur=2080/2080/2000 seq=42477
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send end
>> packet for [7] ts=2394314503 dur=2080/2080/2000 seq=42478
>> 2008-09-11 14:39:57 [DEBUG] switch_rtp.c:1143 do_2833() Send end
>> packet for [7] ts=2394314503 dur=2080/2080/2000 seq=42479
>>
>> - Marc
>>
>>
>> Anthony Minessale wrote:
>>> 2833 is the default.
>>> INBAND is not a function of the sip module it's implemented on top
>>> of the abstraction layer.
>>>
>>> Are you doing trans coding or different ptimes between the 2 legs?
>>>
>>> you might want to turn up the debug log "press f8" and you will
>>> pretty verbose logging of the 2833.
>>> also consider taking a pcap of the network traffic.
>>>
>>> What is the provider? 2833 is notoriously done wrong to the point
>>> that doing it exactly right can put you at a disadvantage.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 11, 2008 at 4:58 PM, Marc Lewis <marc at avvatel.com
>>> <mailto:marc at avvatel.com>> wrote:
>>>
>>>
>>> I've been having a problem getting DTMF passed through from
>>> registered
>>> phones to my termination provider. Sometimes it works, sometimes it
>>> doesn't. My provider is set for rfc2833.
>>>
>>> In looking through the mod_sofia.conf.xml file, and the sofia
>>> sources,
>>> it appears that the only two options for DTMF are info and rfc2833.
>>> I've tried various combinations and the only thing that ever
>>> seems to
>>> even sometimes work is if pass-rfc2833 is set to true. I've
>>> tried this
>>> with Linksys SPA 942 phones, Grandstream GXP 2000 phones and
>>> Cisco 7940
>>> phones. Doesn't seem to make a difference. I've also tried various
>>> dtmf-durations and that didn't seem to have an effect either.
>>>
>>> However, after doing various searches it appears that not explicitly
>>> setting a dtmf-type in a sofia profile, it defaults to using
>>> inband DTMF.
>>>
>>> Is this correct? If inband DTMF is the default, then I will have my
>>> termination provider switch my account over to using inband
>>> instead of
>>> rfc2833.
>>>
>>> - Marc
>>>
>>> --
>>> Marc Lewis
>>> Avvatel Corporation
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-users mailing list
>>> Freeswitch-users at lists.freeswitch.org
>>> <mailto:Freeswitch-users at lists.freeswitch.org>
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>>
>>>
>>> --
>>> Anthony Minessale II
>>>
>>> FreeSWITCH http://www.freeswitch.org/
>>> ClueCon http://www.cluecon.com/
>>>
>>> AIM: anthm
>>> MSN:anthony_minessale at hotmail.com
>>> <mailto:MSN%3Aanthony_minessale at hotmail.com>
>>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>>> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>>> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>>
>>> FreeSWITCH Developer Conference
>>> sip:888 at conference.freeswitch.org
>>> <mailto:sip%3A888 at conference.freeswitch.org>
>>> iax:guest at conference.freeswitch.org/888
>>> <http://iax:guest@conference.freeswitch.org/888>
>>> googletalk:conf+888 at conference.freeswitch.org
>>> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> pstn:213-799-1400
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Freeswitch-users mailing list
>>> Freeswitch-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
>>
>> --
>> Marc Lewis
>> Avvatel Corporation
>>
>> _______________________________________________
>> Freeswitch-users mailing list
>> Freeswitch-users at lists.freeswitch.org
>> <mailto:Freeswitch-users at lists.freeswitch.org>
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>
> Brian West
> sip:brian at freeswitch.org
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
--
Marc Lewis
Avvatel Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20080911/2b104768/attachment-0002.html
More information about the FreeSWITCH-users
mailing list