[chengbowang]

I have SPA 1001 with BV, and I am BYOD and managing the device by myself. I used the wizard to set my SPA, ererything works fine except the voice mail. when I dial *86, just dial tone, no reponse.
My dial plan is like below.

( 0 | 00 | 011,xx. | < : 1202 >[2-9]xxxxxx | 1xxxxxxxxxx | 1900! | *xx | [3469]11 |#xx#)

I verified that this dial plan is working with speed dial 100.

So what's wrong with my dial plan or any other things?

[bob-teatow]

Same problem in another thread. The wizard is apparently buggy. Use Broadvoice's recommended procedures to set up your SPA!

[mberlant]

There is nothing wrong with your Dial Plan, just a few things that could stand to be cleaned up. Let's look at your Dial Plan elements.

0 = Local Operator assistance. Since BV does not offer this service, this element is useless. Harmless, but useless.

00 = Long Distance Operator assistance. Same as above. Harmless, but useless.

011,xx. = International dialing. I assume here that you want to introduce a second Dial Tone after dialing 011. I presume this is your way of reminding yourself that you are dialing an international call. I would change it to 011,[2-9]xxxxx. , though, to further minimize the chance of ambiguity and misdial.

< : 1202 >[2-9]xxxxxx = 7 digit dialing to Area Code 202. I would add S0 (capital ess, zero) to the end of this element, so the call is processed immediately upon receipt of the seventh digit.

1xxxxxxxxxx = North American Numbering Plan dialing. To reduce the chance of misdial, I would change this to 1[2-9]xx[2-9]xxxxxxS0 .

1900! = Block 900 calls. Even though I'm pretty sure that 900 calls are inaccessible from BV, this is cheap insurance.

*xx = Send Vertical Service Codes through. This will only work if you delete the corresponding Service Code from the Regional page of the web interface. Many people choose this method. Many others change it to <:*>*xxS0 , so that they can continue to use these Service Codes with their Line 2 providers.

[3469]11 = x11 service codes. I would put S0 at the end of this element to forward the call upon receipt of the third digit. But - Personally, I would drop the entire element to 611S0 and set up translation elements for the others. For example, I would create an element <911S0:1202aaabbbb> , where aaabbbb is the ordinary telephone number for your either your local police station or DC Emergency Services, since BV does not yet offer 911 service. Likewise, I would program 311 and 411 in the same manner if I wanted to use those numbers.

#xx# = Speed Dial 100. The # at the end is redundant. This is because the SPA will only process a # as a dialable character at the very beginning of a dial string. If # is dialed any time after the first position it is treated as a forwarding character, forcing the SPA to submit the dialed digits for processing.

That's it. Good luck to you.

Michael

[chengbowang]

thanks a lot. I will try it when I am at home this evening.

[chengbowang]

Also, now the new dial plan will be like that:
(011,[2-9]xxxxx.|< : 1202 >[2-9]xxxxxxS0|1[2-9]xx[2-9]xxxxxS0|1900!|<911S0:1202 + local police number>|#xx|<:*>*xxS0 )

I know the local police number (7-digit),so just put it in, it should work.
Now I get the idea. Why *86 is not working with BV voice mail. The reason is *86 is used by SPA regional Vertical Service Activation Codes.

thanks again.
I will test it this evening and report the result.

[PhoneBoy]

Originally Posted by bob-teatow

Same problem in another thread. The wizard is apparently buggy.

Can you please explain how the Wizard is buggy?

[chengbowang]

verified it.
The new dial plan works great.
Local 7 dial works.
011 - international dials works with two dial tones.
speed 8 dial works,also speed dial 100.
Also *86 is working for the voice mail system.
Didn't check 911, because I dare not call them just to verify my phone is working. :wink:

Thanks a lot. This forum really helps me a lot.
Thanks again.
mberlant, you are the man!!

[bob-teatow]

The bug is that the BV wizard should (I think) pass *xx codes through to BV that BV handles.
Instead it passes *86 to the SPA, which doesn't do what the user expects.

Sure you can argue about whether this is a bug or a feature. But in my expert opinion - the law of least surprize trumps any rational argument

I do have a question though. Which *xx codes are handled "better" by the SPA than by broadvoice?
I think *66 might be an example. With Broadvoice it seems just to try the last number dialed again.
With the SPA, I think it does a true daemon dialer function?

Are there other examples like that?

[mberlant]

There is no "better" or "worse" in the world of VSACs. It's just that there are two possible places to perform the transform - in the client or in the switch - and, since the switch is the 400 lb. gorilla, the client must follow the what the switch dictates.

BV dictates that if you want a VSAC to work you must send the star code to them just like any dialed number. If you let your client transform the star code into a SIP request packet, that request will be politely ignored by the switch. Most other carriers prefer to offload this bit of preprocessing to the client base, so they do not implement star code transformations in their switches. BV prefers to take on this extra workload, believing that their verbal confirmation messages represent better customer service. Both attitudes have merit.

Now, the *66 code you mention is one that has a "better" version, and I agree with you that Sipura's is better. The reason it works at all when left to the Sipura is that the SPA does not transform *66 into a request for the switch. Rather, it performs repeated individual redials - exactly like the Demon Dialer (I still have one. Do you?)

Now, as far as your comment about "least surprize" (sic), I must disagree with you in this instance. The big reason is that there are several workarounds for dealing with VSACs with BV, but if you strip them out on account of BV there is no workaround that can "put them back" for any other service provider you program into Line 2.

[bob-teatow]

MB, Point taken on the Line2 or PSTN (for SPA3K) account thing. I guess this is a deficiency ( bug!) in the Sipura design.
There should be a way to specify which lines get which VSACs. Of course SPA already have soooo many options....

I think the real benefit for BV handling all the feature codes is that its easier and surer for BV to implement and support them at their switch.
That way every customer gets the same experience and support, no matter which model or brand of ATA.(Except wise guys who reconfigure their own SPAs).