Hey Mike, Thanks for the thorough explanation of all the stuff you've done. No wonder DTMF is such a royal pain.
Those tips should come in handy. Jim -- Jim Van Meggelen [EMAIL PROTECTED] http://www.oreillynet.com/pub/au/2177 "A child is the ultimate startup, and I have three. This makes me rich." Guy Kawasaki -- Mike Ashton wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
