The Panasonic KX-TA624 series PBXes (and similar models) support a DTMF
integration feature that can be enabled for dedicated voice mail ports.
What I want to do is connect an X100P FXO port to a jack on the
Panasonic and make use of the Panasonic's DTMF call progress tones that
it provides in DTMF integration mode.
The integration works well when a Panasonic extension is forwarding into
one of the VM ports and Asterisk picks it up; in this mode, after
Asterisk picks up the call, the Panasonic sends #6XXX, where XXX is the
voice mailbox. When a user presses a message waiting button, the
Panasonic will send #6*XXX, and that also works fine. (It is necessary
to delay answering by one second if the Panasonic is set to use the
double-ring cadence.)
Problems start when Asterisk dials an extension into the Panasonic. When
the FXO port picks up and dials an extension on the Panasonic station
port, the Panasonic will return the following indications as DTMF digits:
1 Ringback
2 Busy
3 Reorder
4 DND
5 Answer (recipient has answered)
6 Forwarded to other VM port
7 Forwarded to other VM port, but VM busy
8 Forwarded to non-VM extension
9 Confirmation (for turning message waiting lights on or off)
#9 Recipient has disconnected
This seems to be something that would best be implemented within
chan_zap.c, but there's a problem. When Asterisk has finished dialing,
the Panasonic returns 1-4 or 6-9 before Asterisk can detect the tone.
I'd say it takes 200 ms or less for the Panasonic to return the DTMF digit.
Is there any other approach that would work that wouldn't require diving
into the internals?
In this example, we're dialing Panasonic extension 104, and the
Panasonic sends a DTMF 1 to indicate ringing, but the 1 is never
received by chan_zap. It doesn't matter whether or not I have echo
cancellation enabled.
Here's the debug output, where an IAX extension is calling out on a Zap
channel into the Panasonic:
Oct 1 23:21:02 DEBUG[22774] chan_zap.c: Dialing '104'
Oct 1 23:21:02 DEBUG[22774] chan_zap.c: Deferring dialing...
Oct 1 23:21:02 DEBUG[22774] channel.c: Set channel Zap/1-1 to read format slin
Oct 1 23:21:02 DEBUG[22774] channel.c: Set channel IAX2/103-1 to write format
slin
Oct 1 23:21:02 DEBUG[22774] channel.c: Set channel IAX2/103-1 to read format
slin
Oct 1 23:21:02 DEBUG[22774] channel.c: Set channel Zap/1-1 to write format slin
Oct 1 23:21:02 DEBUG[22774] app_queue.c: Device 'IAX2/103' changed to state
'2' (In use)
Oct 1 23:21:02 DEBUG[22774] app_queue.c: Device 'Zap/1' changed to state '2'
(In use)
Oct 1 23:21:02 DEBUG[22774] app_queue.c: Device 'Zap/1' changed to state '2'
(In use)
Oct 1 23:21:02 DEBUG[22774] chan_iax2.c: Ooh, voice format changed to 2
Oct 1 23:21:02 DEBUG[22774] channel.c: Set channel IAX2/103-1 to read format
slin
Oct 1 23:21:02 DEBUG[22774] chan_zap.c: Dropping frame since I'm still dialing
on Zap/1-1...
[ repeated many times... ]
Oct 1 23:21:02 DEBUG[22774] chan_zap.c: Exception on 20, channel 1
Oct 1 23:21:02 DEBUG[22774] chan_zap.c: Got event Hook Transition Complete(12)
on channel 1 (index 0)
Oct 1 23:21:02 DEBUG[22774] chan_zap.c: Dropping frame since I'm still dialing
on Zap/1-1...
[ repeated many times... ]
Somewhere in here, the DTMF 1 sent by the Panasonic is lost.
Oct 1 23:21:03 DEBUG[22774] chan_zap.c: Exception on 20, channel 1
Oct 1 23:21:03 DEBUG[22774] chan_zap.c: Got event Dial Complete(9) on channel
1 (index 0)
Oct 1 23:21:03 DEBUG[22774] chan_zap.c: Enabled echo cancellation on channel 1
Oct 1 23:21:03 DEBUG[22774] channel.c: Set channel IAX2/103-1 to read format
slin
Oct 1 23:21:03 DEBUG[22774] channel.c: Set channel Zap/1-1 to write format slin
Oct 1 23:21:03 DEBUG[22774] channel.c: Set channel Zap/1-1 to read format slin
Oct 1 23:21:03 DEBUG[22774] channel.c: Set channel IAX2/103-1 to write format
slin
Oct 1 23:21:03 DEBUG[22774] chan_iax2.c: Answering IAX2 call
Oct 1 23:21:03 DEBUG[22774] app_queue.c: Device 'Zap/1' changed to state '2'
(In use)
Oct 1 23:21:03 DEBUG[22774] app_queue.c: Device 'IAX2/103' changed to state
'2' (In use)
Oct 1 23:21:04 DEBUG[22774] chan_zap.c: Write returned -1 (Resource
temporarily unavailable) on channel 1
[ repeated... ]
Here, the destination extension answers, and the Panasonic sends a 5:
Oct 1 23:21:07 DEBUG[22774] chan_zap.c: DTMF digit: 5 on Zap/1-1
Oct 1 23:21:07 DEBUG[22774] chan_zap.c: Write returned -1 (Resource
temporarily unavailable) on channel 1
[ repeated during conversation... ]
Now, the extension has disconnected, and the Panasonic sends #9:
Oct 1 23:21:12 DEBUG[22774] chan_zap.c: DTMF digit: # on Zap/1-1
Oct 1 23:21:12 DEBUG[22774] chan_zap.c: DTMF digit: 9 on Zap/1-1
The Zap channel doesn't disconnect until the Panasonic sends reorder
tone, which triggers Asterisk's busy detection.
Russ
_______________________________________________
--Bandwidth and Colocation sponsored by Easynews.com --
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
