[usa2k]

Well, I am new to Voxilla forums, and will likely be here more frequently.

I've seen a number of familiar names here, and it will take a while to catch up a bit ...

. . . first post . . . . here it goes . . .

Welcome USA2K.

prayer, In a traditional (legacy) telephony environment your telephone connected through would you can look at as a long extension cord to a 'switch'. All the dialing plans, rules, translations, etc. Are embedded in the switch.

In the case of VoIP your switch port is extended to your home (The telephone adapter) and the switch still resides at the service provider. Other than by way of deployment topology the technology has not changed a great deal.

The rules (Dial plan) that accept digits and in some cases provide a mask (some alteration to what you have dialed) for the switch are embedded within the telephone adapter in a VoIP deployment and in the Trunk card (what the line plugs into from your home to the phone company in a legacy world) when considering your 'old' style phone company. Unlike the typical VoIP adapter with two ports a trunk card can have up to 768 however the job of each is much the same.

In a legacy world the dial plans are stored in memory on these trunk cards and are considerable in size. With the VoIP adapters available today however the memory space is pretty limited and the complexity of the dial plans is as well.

In a legacy world a dial plan might consider an area code only in applying a rule, while in another area the NPA / NXX (Area code / prefix). With the ability to get that granular they can control the number of digits that are looked for by what you are dialing, digit by digit.

With the limited memory capacity and relatively simplistic algorithms available in a VoIP device (as they exist today) we can not get that granular and in those cases need to settle on a simpler approach in order to maintain a PSTN 'feel' and provide for a consistent user experience.

Throughout our development cycle we made every attempt to keep 7, 10, and 11 digit dialing available however with the differences in telephone adapters, the rules they will accept, etc. This became an increasing challenge. Attempting to maintain varied rules (this adapter can do these things, and is probably set like XX, while this adapter can only handle this, unless you also have this

[PhoneBoy]

I know at one point you had talked about giving customers the choice of *either* 7 or 10 digit dialing, but not both at the same time. This is probably needed to emulate the PSTN look and feel in areas with overlay codes. Is that still on the books?

It is not a priority however it is still on the project list somewhere. I would not look for this functionality anytime soon. The problem is that we would programatically need to change the way we profile hardware and allow for multiple profiles for each brand / and even firmware version in some cases. Then we would need to apply a specific list of profiles to a specific piece of hardware, to a specific account. The reason being is that again firmware changes can cause a dial plan change, not every user with that hardware will have the same version of firmware. Additionally not all features in a dial plan will work with other features. While the added functionality sounds simple enough it had proven to be a pretty complex task (to handle all the variables) and we have other more important issues to address with regards to development at the present time.

[usa2k]

Wondering . . . . . . . . . . . . if a user configurable 10 or 7 choice on the portal would simplify the complexity?

. . . . _ . . . . 7 digit dialing, prefix 1-734
. . . . X . . . . 10 digit dialing

And like I've said before, with the user in control, you can pick a suitable 7 digit dialing default in spite of the actual number. That makes it a more powerful feature. If you make it exclusive 10 OR 7, then your delay is moot.

If the DTA 2102 were the only device that was deployed then this would not be so bad. At present time we deploy about a dozen devices with our service. We have private label clients that sell residential service under their own name and we provide all switching, transport, billing, provisioning, etc. We also have the Enterprise side.

We would have to build logic that would be 'aware' of each device, what the provisioning scripts would look like depending upon the dialing pattern selected, which devices could be provisioned in such a way and which devices could not. We would need to know how to automatically control the availability, in real-time, of when to display this feature as an option (some hardware can not be remotely provisioned for things like this, or can not accept these types or parameters).