Outbound Zap calls failing, "Sent deferred digit string"

[KLGIT]

So I got my system up and running. Using PIAF 1.4, with updates etc.

I have an Astribank catching outbound calls from a Mitel SX200.
PIAF routes the long distance calls via VoIP/SIP provider. This part works well. However, I'm trying to get the system to route local calls back out the Astribank over the PSTN lines.
I get a long pause, then a "sorry, we are unable to complete your call as dialed message". I'm pretty sure that response is from the PSTN.

Here's what I believe to be the relevant section from the logs...

[2009-04-23 19:40:28] VERBOSE[7694] logger.c: -- Executing [s@macro-dialout-trunk:19] Dial("Zap/16-1", "ZAP/25/5551212|300|") in new stack
[2009-04-23 19:40:28] DEBUG[7694] chan_zap.c: Dialing '5551212'
[2009-04-23 19:40:28] DEBUG[7694] chan_zap.c: Deferring dialing...
[2009-04-23 19:40:28] VERBOSE[7694] logger.c: -- Called 25/5551212
[2009-04-23 19:40:29] DEBUG[7694] chan_zap.c: Sent deferred digit string: T555121
[2009-04-23 19:40:30] DEBUG[7694] chan_zap.c: Engaged echo training on channel 25
[2009-04-23 19:40:32] DEBUG[7694] chan_zap.c: Echo cancellation already on
[2009-04-23 19:40:32] VERBOSE[7694] logger.c: -- Zap/25-1 answered Zap/16-1
[2009-04-23 19:40:32] DEBUG[7694] chan_zap.c: Took Zap/16-1 off hook
[2009-04-23 19:40:32] DEBUG[7694] chan_zap.c: master: 16, slave: 25, nothingok: 0
[2009-04-23 19:40:32] DEBUG[7694] chan_zap.c: Stopping tones on 16/0 talking to 25/0
[2009-04-23 19:40:32] DEBUG[7694] chan_zap.c: Stopping tones on 25/0 talking to 16/0
[2009-04-23 19:40:32] DEBUG[7694] chan_zap.c: Making 25 slave to master 16 at 0
[2009-04-23 19:40:32] DEBUG[7694] chan_zap.c: Added 41 to conference 9/16
[2009-04-23 19:40:32] DEBUG[7694] chan_zap.c: Added 32 to conference 9/25
[2009-04-23 19:40:32] VERBOSE[7694] logger.c: -- Native bridging Zap/16-1 and Zap/25-1
[2009-04-23 19:40:52] DEBUG[7694] chan_zap.c: Unlinking slave 25 from 16
[2009-04-23 19:40:52] DEBUG[7694] chan_zap.c: Removed 41 from conference 9/16
[2009-04-23 19:40:52] DEBUG[7694] chan_zap.c: Removed 32 from conference 9/25
[2009-04-23 19:40:52] VERBOSE[7694] logger.c: -- Hungup 'Zap/25-1'

Why "Deferring Dialing"?
What is that T in front of the number after "Sent deferred digit string"?
Why is the last digit missing in the deferred digit string?

I have more of the logs, I can send/post if anyone thinks it's important.

NOTE: No, I am not trying to dial the movie number, I replaced the real, valid local number, in the post with the movie number.

Any ideas?

Thanks!

 

[KLGIT]

Weird behaviour on the part of Asterisk

OK, so I finally figured this out. I would have figured it out a LOT faster if Asterisk's log messages made any sense.

In looking at the original logs, it had the line about "sent deferred digit string...." and in each of those lines the digits sent would be shown, but the LAST digit would be cut off.
eg. When dialling 5551212, you would see a deferred digits string of 555121 with the final 2 missing. In playing with the system I found that yes digits were missing and the telco would eventually time out waiting for a valid phone number.
Because the Asterisk logs CLEARLY IMPLY that the last digit is the problem, I wen off on all sorts of tangents trying to solve this problem.
Eventually, out of desperation, I bought a butt set and hooked it directly to one of my output lines in monitor mode and listened to the dial sequence. I then realized that it was trying to dial before the line had settled and it was actually the FIRST digit getting dropped. Argghh..
The solution then was obvious. I had to use ww as my dial string prefix. I already had one 'w' in there which is the other reason I didn't think this was the issue right away.
The other reason I didn't catch this is that the system worked fine when hooked to one our our standard analogue B1 lines. But the DOD lines apparently need more time to settle for some reason.

Now the system works just fine. Both local and LD calls are handled and routed as they should be.

I have to say, the misleading information in the Asterisk logs caused me to waste days looking in the wrong direction. Very frustrating.

Now my next problem is handling the long dial times for local calls. Oh well, one problem at a time.