[Asterisk-Users] chan_zap vs. Panasonic DTMF integration

[Russ Price]

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