As mentioned in a previous conversation, we've got a Cisco 2821 ISR running CME 4.0(2) which is connected to an Alcatel 4200 legacy PBX. The ISR is a gateway to the PSTN so the Legacy PBX sits behind it, connected via an E1 link (Primary Rate Interface).
In order for the Legacy PBX to reach the PSTN, it adds a prefix ("5432") to each call placed. The ISR then uses this prefix to match an outgoing dial-peer. This configuration has been tested and works fine.
The only snag is that there's a HUGE delay between the last digit being received from the Legacy PBX and the ISR actually placing the call.
On the Serial interface to the legacy PBX we need to run "isdn overlap-received" because the Legacy PBX sends the digits one by one. I've got the "interdigit timeout" on all concerned voice-ports set to 3 seconds. I've also tried playing around with several ISDN timers but no results.
I've tried changing the timeout values but I still get roughly a 15 second delay between the last digit being received and the actual call being placed.
the issue is related to the need for overlap dialing. If you can configure the outgoing DPs to not use T at least for most calls (this is possible for most countries despite contrary appearance), that should trigger a faster call, because you can configure "isdn sending-complete" on the port connected to PSTN.
Not to mention that you should be able to use # from any phone to indicate end of called number.
However, I would like to see a q931 trace and config, because ultimately, certain timers should kick in anyway.
I thought "isdn overlap-receiving" might have something to do with it...
I'll post a debug tomorrow morning because at the moment its pretty hectic (many calls in and out) to make any sense of the logs.
Ok. The ISDN timer that you want to play with to control interdigit timeout is T302. Please make sure you run an update IOS release like 12.4(11)XJ4 because ISDN bugs are still frequent in IOS.
I've had a look at the Serial port and the current IOS (12.4(11)T2) doesn't have a T302 timer:
router(config-if)#isdn timer ?
T-Activate Specify Timer T-Activate in milliseconds.
T200 Specify Timer T200 in milliseconds.
T203 Specify Timer T203 in milliseconds.
T301 Specify Timer T301 in milliseconds.
T303 Specify Timer T303 in milliseconds.
T306 Specify Timer T306 in milliseconds.
T309 Specify Timer T309 in milliseconds or 0 to Disable.
T310 Specify Timer T310 in milliseconds.
T321 Specify Timer T321 in milliseconds or 0 to Disable.
T3OOS Specify Timer T3OOS in milliseconds.
I have however run an "debug isdn q931" with "qsig decode" which I've attached to this post.
After point "040559", there's a 10 second delay before the rest of the output is shown.
PS: I've masked the calling number for privacy reasons.
I had forgot this, please configure T302 as a parameter for "isdn overlap-receiving". I suggest a value of like 3500.
The interaction with the Portoguese switch is interesting. I will save your trace as certain messages are not seen frequently.
I'll try this command during the customer's lunch hour as it will cause the least disruption.
For reference, the PSTN is connected to "Serial 0/2/1:15" and the Legacy PBX (Alcatel 4200E) is connected to "Serial 0/3/0:15".
As you can see, the Legacy PBX sends out the digits one by one (thus the need for "overlap-receiving").
Is the interaction with the PSTN different from most other countries? I must admit that I've never seen a log trace from any other ISDN<->PSTN interaction!
For sure you need to command on the interface connected to the PBX. It doesn't cause any disruption.
If the PRI has DID, you might need the command on the PSTN interface as well. Try calling from outside, from an analog line. You might see the overlap in there as well.
It is normal that the PBX dials in overlap. Most PBXs outside the US do that. The idea is that it makes calling faster, because the PSTN will send alerting as soon it has accumulated enough digits to route the call.
If you want to make the calling even faster, try configuring DPs without T.
For example, if you know that all cellphones number have fixed length, you can configure an additional DP for them.
You trace has some message that is not widely used, eg advice of charge, reject for facilities, etc.
I've applied the "isdn overlap-receiving T302 3500" command to the Serial port and according to the person at the customer's premisis, the waiting time seems to have been reduced to about 6 seconds.
Strangely enough, the user reports that no audiable "ringing" tone is heard before the call is established.
I asked him to test this for other phone numbers (mobile and land-line) and this happens for all calls.
Is there a way to insert some sort of "comfort" tone whilst the call is waiting to be established?
If you still has switchtype qsig, reconfigure as net5.
If still no ringback tone, under interface going to PBX, configure;
progress_ind setup enable 3
progress_ind setup enable 8
You can further reduce T302 timer and interdigit timeout (it seems like they sum up) to reduce post-dial delay.
I've configured the "progress_ind" under the "dial-peer" going into the PBX and from the PBX to the PSTN but still no ringback tone.
can you take again the trace with "debug isdn q931" and "debug vtsp tone" ?
I would also strongly recommend that you upgrade to either 12.4(11)XJ4 or 12.4(11)T3 before you do this.
Will do but I'll upgrade to a newer IOS revision before taking the debug.
I'll let you know sometime next week as I'll be doing this on-site!
I don't know if this is related but of all the incoming MSNs, two are forwarded to ISDN FAX machines which are in turn connected to the Legacy PBX.
I've tried sending a few faxes (incoming from the PSTN to the ISR, which is forwarded to the Legacy PBX) and they all get cut off around the 30 second mark. It will just about work with a 1 page long FAX but for 2+ pages they always get cut off.
I've run a debug and it seems the ISR is re-negotiating the bearer capability which arrives as "unrestricted digital". I've tried forcing the bearer-cap to "speech" or "3100hz" under both voice-ports but the incoming faxes still get cut off.
can you send "show controllers e1" and if you have any network-clock commands. You you don't and have E1 slips, that is the reason fax are failing.