*67 issue

[fisamo]

It's likely that the PAP recognizes *67 as a "feature code" that's been disabled. So if you dial it and pause, it matches something 'known' to be invalid. If you dial 66 and pause, that is not recognized until the PAP figures out that you're not going to dial any more digits and then sends what you've dialed (in case you had set it up as an outbound route).

[Xponder1]

It's likely that the PAP recognizes *67 as a "feature code" that's been disabled. So if you dial it and pause, it matches something 'known' to be invalid. If you dial 66 and pause, that is not recognized until the PAP figures out that you're not going to dial any more digits and then sends what you've dialed (in case you had set it up as an outbound route).

Support says that its all handled on their end and they do not use any features of the ATA. As Tim said above you dial *67number and it works. What they did fix was the time out. When I dialed *67 before in about 1.5 seconds it would give a fast busy. So if you dialed *67 and then looked down to read a number it was at a fast busy. They set the timeout to 3 seconds instead of that 1.5.

Tim, you need to remember that anyone coming from a pots line is going to expect it to go back to a dial tone after dialing *67. In fact when I had the 502 it worked that way. So any documentation on the feature should say that you dial it all at once.

I found this post http://www.dslreports.com/forum/r191...cy-not-working. that I found of interest in this discussion. I understand what works for one company may not work for another but the last reply there seems to indicate there is a feature in the PAP2 that if put to use would allow it to work like most people are used to (while still working the current way as well) and still send it to VOIPo's servers all at once. Might at least be worth looking in to. Less confusing = more satisfied customers. Having it return to a dial tone to me confirms that you used the feature and would be what most folks would expect.

[burris]

This is what makes me believe that this may be run by the server.

Looking at my backup SPA2102 that mirrors the provisioning config on the PAP2T, I see the following...

The Vertical Service Activation Codes field although almost totally filled, don't have a *67 in that field...
The Supplementary Service Subscription fields all show the server activation fields set to yes...with the exception of Block CID Ser set to 'no'.
With this as it is, my *67 works as Tim indicated, and all the other services work as well..

As I indicated, I haven't used the wait for dial tone POTS routine for the 5 years I have had VOIP because I have always had cordless phones and was used to the cell phone procedure..

For me, I don't know how it could be any better.