I have voip set up and working a treat. Or at least I think so.

I've added a DigitMap entry to automatically redirect some calls through the normal BT phone line.

I've added Prefix Number = 01, Mode = None, Min Len = 5, Max Len = 25, Interface = PSTN.

I've done the same for a prefix of 07 for mobiles.

It appears to try and work. The number dials, I get a boop-boop sound, then the tones of the number repeat again, then the Draytek clicks and I get a normal sounding disl tone. It's like it's dialing the numbers for me on the PSTN network, but before it's switched the line over.

if I prefix the number with #0 then it works fine and the number gets dialled. If I choose one of the VOIP interfaces it seems to work fine. VOIP1 doesn't have credit and I get warned about that. VOIP2 does and the call gets made. PSTN should just work, as far as I can see.

I must be missing something. I have a 2820Vn with v3.3.0 f/w and am in the UK.

Please help. I'm sooo close.

Thanks, Mike...

let's just summarise the problem here

here is what we know:-

1. The problem blocks calls that should be routed to the PSTN Line - ie 999 Emergency Calls

2. The problem is consistent and repeatable

3. Calls made with a prefix of #0 work and are placed using the PSTN line

4. Calls made using either a Digit Map or PSTN relay fail - silence two slow beeps silence PSTN dial tone

5. Two videos have been produced demonstrating the problem

6. The problem is not caused by a unit to wall cable problem - the cable does not discriminate between #0 and PSTN relay/Digit Map calls

7. Pressing #0 requires a significant delay before the PSTN dial tone is available

8. The problem is evident in two units

9. the problem is persistent following a Restore to Factory

10. Copies of the current config (in which the issue is repeated) have been provided to Tech Support

11. Screen shots of current (in which the issue is repeated) have been provided to Tech Support

12. There is a significant delay between dialling #0 and getting a PSTN line it would be logical to suggest that the same delay is evident when using Digit Map or PSTN Relay.

13. When using the Digit Map or PSTN Relay options to deflect a call to PSTN the number is dialed, long pause, two slow beeps, long pause, then PSTN dial tone

14. If the PSTN line is totally removed, calls using PSTN relay or Digit Map still go through to generate two slow beeps but it obviously not going to get a dialtone as the unit is not connected to the PSTN.

Now for the extrapolation...

It is obvious from 14 above that the unit is not detecting a dialtone, it is just waiting for a predetermined period before sending the dial sequence.

In light of 12, 13 and 14 above it would appear that when using the PSTN Relay or Digit Map there is insufficient time to secure a PSTN dial tone and the number is being dialled BEFORE a dial tone is achieved and that is why the calls are failing.

So, either the unit needs to actually detect a dialtone before dialling or dialtone wait cycle has to be extended.

This problem is not within my ability to implement. The unit is faulty.

My unit behaves in exactly the same way - I too believe that this is a firmware/hardware issue now that I've sorted the incorrect cable problem.

A fix would surely be the ability to insert a pause character at the front of a dialplan number, and/or to detect the PSTN dial tone after receiving ~0or a dialplan number and before dialling the rest (PSTN) of the number??

PS - Admin - can the 3 threads covering this issue be merged and made a sticky please?