Ian,
We've had issues with this for years. We too have to use a lot of DTMF,
for automatically transversing remote IVR's. We've never had 100%
success. But we do pretty good now. There are multiple variables at play
here.
First there is the device ( ATA / Phone ) having it set to rfc2833 can
mean trouble, what you may want to do is use wireshark to see how the
device is sending it's RTP EV packets. Almost every device I have sends
them differently, both in numbers and the values in the ascending
packets. You'd think that when you hit the digit 2 on your phone it
would send one packet saying you hit the two.Not so! The device will
send a stream of packets depending on how quickly you hit the button,
and typically it will send a mininum of 3 or 4 with a very quick touch.
Each of these packets will have a value for the key you hit and then a
duration value, which will ascend as you hold it down ( or you'd think
so ). I have some sipura 2002's and pap2's which send very strange
packets, not ascending in values consistently, with like 3 packets of
the same duration, where as my polycoms will send a consistent pattern
with a consistent ascending value in the duration.
Second, asterisk's interpretation, conversion doesn't seem to be
consistent when converting rfc2833 to inband.
Third is the interconnects of your A-Z termination ( in your case this
may not be an issue ) where one provider when handing off the DTMF isn't
configured properly with the end termination point.
The way we got this to improve using asterisk was to set the dialing
devices to inband, tell asterisk in sip.conf that dtmfmode=auto and set
the trunk to dtmfmode=inband.
We still have issues with some destinations (overseas) due to the
carriers using compression, so for these destinations we have set up a
secondary trunk with a different DTMF mode to utilize rfc2833, relying
on asterisk to convert them.
I know in the past there has been issues with asterisk's handling of
dtmf, and we've not upgraded to the latest to see if this will help with
the issue. We're also setting up a test system using freeswitch to see
how it handles things.
Mike
Ian Darwin wrote:
Part N of my continuing saga.
A few months back I wrote of my problems getting dialing working with
an ATA. Two ATAs later, I have given up and replaced all the hardware.
It is now a standard PC (Celeron 1.2GHz) running "Asterisk Now" 1.0.2
with a cloned TDM410 (1 FXO) PCI card talking to my analog phone line,
and various (SIP and Unistim) phones inside.
Part of the complexity was and still is that we have an ALDS (Alt.
L.D. service) that we activate by dialing 10 digits, waiting for
dialtone, and dialing the actual 10-digit number.
There is some progress. I can fairly reliably have Asterisk dial numbers
both locally and over the ALDS. Incoming calls still work; this has
never been the problem.
But everything involving dialing from the phones while connected is
unreliable. E.g., dealing with IVR-based voicemail, scheduling, etc.
The setup, now, is
Analog ---- TDM400 FXO -- Asterisk -- internal phones
Most of the phones are on a full-duplex switch, because that is
providing POE for several of the phones.
Here is part of the sip.conf for one of the SIP phones:
[general]
realm=XXX
disallow=all
allow=ulaw
localnet=192.168.1.0/24
; Grandstream BT100 phone
[31]
type=friend
secret=XXX
context=internal
nat=no
host=dynamic
canreinvite=no
qualify=yes
mailbox=20
dtmfmode=rfc2833
The GS phone has these settings:
Send DTMF: in-audio X via RTP (RFC2833) via SIP INFO
DTMF Payload Type: 101 (that was the factory default)
-------------------------
Here is the zapata.conf:
[trunkgroups]
[channels]
; default
; usecallerid=yes
; hidecallerid=no
; callwaiting=no
; threewaycalling=yes
; transfer=yes
; echocancel=yes
; echotraining=yes
; increased, to let sending work.
toneduration=300
; last resort
relaxdtmf=yes
; define channels
context=incoming
---------------------------------
Unistim.conf isn't shown but it has no settings related to DTMF;
these phones always communicate over a local LAN and always send DTMF
out of band (according to chan_unistim anyway)
---------------------------------
And here's the local and ALDS dialing macros:
PSTN_DIALER=Zap/1
[macro-dial-outbound-local]
exten => s,1,SetCallerID("Darwin" <905-XXX-XXXX>)
exten => s,n,Dial(${PSTN_DIALER}/${ARG1},20)
exten => s,n,GotoIf($["${DIALSTATUS}" = "BUSY"]?busy:unavail)
exten => s,n(unavail),Congestion()
exten => s,n,Hangup()
exten => s,n(busy),Congestion()
exten => s,n,Hangup()
[macro-dial-outbound-worldline]
;exten => s,1,Dial(${PSTN_DIALER}/${WORLDLINE_ACCESS},10,D(wwwww${ARG1}))
exten => s,1,Dial(${PSTN_DIALER}/${WORLDLINE_ACCESS}wwwwww${ARG1}))
exten => s,n,GotoIf($["${DIALSTATUS}" = "BUSY"],busy)
exten => s,n(busy),Congestion()
exten => s,n,Hangup()
---------------------------------------
Summary: dialing via either of these macros works, but anytime we send
DTMF from any keypad, it's unreliable. Dialing "9" by itself, for
example, dials Worldline's number, where sending 10 digits should work.
I wonder if this is related to why the first attempt at
dial-outbound-worldline didn't work?
Using an analog phone on the same phone line works 100%, btw.
Thoughts? Further information needed?
Many thanks if you can help.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mike Ashton
Quality Track Intl
Ph: 647-722-2092 x 301
Cell: 416-527-4995
Fax: 416-352-6043
QTI CONFIDENTIAL AND PROPRIETARY INFORMATION
The contents of this material are confidential and proprietary to Quality Track
International, Inc.
and may not be reproduced, disclosed, distributed or used without the express
permission of an authorized representative of QTI.
Use for any purpose or in any manner other than that expressly authorized is
prohibited.
If you have received this communication in error, please immediately delete it
and all copies, and promptly notify the sender.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
