Always get busy signal when doing *67

When using *67 with my BYOD, I always get a busy signal after dialing the destination number. For example, *67 XXX-XXX-XXXX <get busy signal>. Just to be clear -- it's not a reorder signal, it's a busy signal.

Also, if I enable "Block caller ID for all calls" with *30, then dial XXX-XXX-XXXX, I get a busy signal on all calls. If I disable "Block caller ID for all calls" with *31, calls complete normally.

My ATA is an SPA-2102, if that makes any difference.

I don't think that it's a dial plan issue because the problem occurs even when I enable caller ID blocking with *30.

Any ideas on what would be causing this problem?

Do the calls show up in your call history online?

In order for *67 to work on a BYOD device - you will want to configure the actual device to send us a request-uri in the format of *679495551234 as an example.

Look forward to hearing back from you.

Brandon is the man.....I'm sure he can get to the bottom of your issue.


BTW, I'm using the SPA2102 with this dial plan I created below. I always use 10 digit dialing like my cell phone, so I never created any 11 digit plans.

(0[3-9][0-9]S0|[49]11S0|[2-9]xx[2-9]xxxxxxS0|123S0|*xx[2-9]xx[2-9]xxxxxxS0|011[2-9]x.S3)

Just make sure you have *xx[2-9]xx[2-9]xxxxxxS0 or *xx1[2-9]xx[2-9]xxxxxxS0 somewhere in your dial plan. Only having *xx or *xxS0 may cause the ATA to send the code before sending the rest of the numbers following *67 code.

I did some experimenting with my dial plan using your 3 examples above:

1) If I dial *67 followed by a 10 digit phone number, the call works and blocks CID as expected.

2) If I dial *30, the phone acts dead for about 3 seconds and I get a busy signal, however it does activate the "Block caller ID for all calls" feature. I confirmed this by testing a call and looking to see if it turned this feature on in vPanel (Go to the Features option in vPanel and see if the option shows "Caller ID Blocked: Do not send any caller ID info" to verify it worked)

3) If I dial *31, the phone acts dead for about 3 seconds and I get a short automated response that says "Thank you" and hangs up. Again, I confirmed the option re-enabled caller ID as expected by doing a test call and checking vPanel which now shows "Caller ID Blocked: Send my caller ID info" enabled.

Thanks for the very helpful replies.

This is the dial plan that I was using that did NOT allow *67 to work:

(123S0 | 011[2-9]x.S5 | 1[2-9]xx[2-9]xxxxxxS0 | [2-9]xx[2-9]xxxxxxS0 | [2-9]11S0 | *xx )


Based on your suggestions, I modified my dial plan to be as follows:

(123S0 | 011[2-9]x.S5 | 1[2-9]xx[2-9]xxxxxxS0 | [2-9]xx[2-9]xxxxxxS0 | *xx1[2-9]xx[2-9]xxxxxxS0 | *xx[2-9]xx[2-9]xxxxxxS0 | [2-9]11S0 | *xx )

With this dial plan, *67 works correctly. However, there are a few quirks, as follows:

1. If I dial *67 followed by a 10 digit phone number, the call works and blocks CID as expected. However, I have to dial the 10 digit number right after dialing the *67 -- that is, before hearing the second dial tone. If I wait until the second dial tone appears, then dial the 10 digit number, I get a busy signal. I guess this is because of the *xx at the end of my dial plan. Note that I need the *xx at the end of the dial plan to allow "standalone" commands like *30 and *56 to be entered (right?)

2. If I dial *30, then wait for the second dial tone, then hang up, then go off hook again and dial a 10 digit number, I get a busy signal. If I dial *31 to reverse the *30, I can make calls again with no problem. This isn't a big issue, but I don't see why the *30 appears to break things.

Any additional comments will be appreciated.

Let me toss in another piece of information that might be related. I've set the Vertical Service Activation Codes as follows. What I don't understand is how they relate to what is actually sent in the request-uri. Can you give me a bit of explanation?

(Click on the image below to see the screen shot)
Attachment 210

Hello,

Drop the vertical service codes - we handle our codes server-side. This is why when you dial *67 and the code is triggered client-side on the device problems are occurring. Let me know if this makes sense / how this works out for you, thanks!

Brandon is exactly right!!

I had some free time today and did some experimenting. The Vertical Service Codes simply don't work at all. I was able to duplicate all of your symptoms with your setup.

Here's what you need to do get things working right:

Step 1)
Modify your dial plan back to the way you had it before:
(123S0 | 011[2-9]x.S5 | 1[2-9]xx[2-9]xxxxxxS0 | [2-9]xx[2-9]xxxxxxS0 | [2-9]11S0 | *xx )

Step 2)
See the attached pdf picture - modify your Vertical Services Code fields as highlighted in picture by erasing these 3 fields and placing *67 in the "Features Dial Services Codes" field.

This will allow you to dial *67 with or without a dial tone prompt followed by a 10 or 11 digit phone number, whichever you prefer. Your busy signal should be completely gone with this setting. If you want more information on how to add more feature codes other than *67 or use different prompt tones in the "Features Dial Services Codes", please refer to page 148 in the SPA2102 admin guide here:
http://www.cisco.com/en/US/docs/voic..._v3_NC-WEB.pdf

The *30 and *31 should work as well now that the fields have been erased in your Vertical Services Codes page.

This is what I now experience using *30 and *31 codes:

Dialed *30, I get almost an immediate busy signal, but it does activate the "Block all CID" feature. I once heard a quick "thank you", but only once. It works, but Voipo should fix the "thank you" response time.

Dialed *31, I get "thank you" after about 1 second, then a busy signal. The feature works as expected and disables the "Block all CID" feature.

As Brandon stated above, you can drop/erase any of those other star codes in the Vertical Services Codes page that might conflict with Voipo's handling of the same star codes.

Hope this helps.......

Thanks! Great replies! *67, *30, and *31 are working fine now. And most of the time, I get "Thank you" after entering *30 or *31.

Remaining question: tritch wrote: "As Brandon stated above, you can drop/erase any of those other star codes in the Vertical Services Codes page that might conflict with Voipo's handling of the same star codes."

How can I determine which star codes are handled by Voipo? (In other words, which star codes are handled by the server?)

By the way, I finally noticed in the SPA-2102 manual that "Vertical Service Activation Codes are automatically appended to the dial-plan."

Therefore, I was able to remove the *nn from my dial plan. My dial plan is now set to:

(123S0 | 011[2-9]x.S5 | 1[2-9]xx[2-9]xxxxxxS0 | [2-9]xx[2-9]xxxxxxS0 | [2-9]11S0)

What isn't clear to me is if specifying VSACs has any other effect. Are they just a convenient method of adding values to the dial plan, or do they actually cause something additional to happen in the ATA? For example, if a star code is set in the VSAC list and the star code is entered at a phone, does the ATA process the star code internally in some way?

Quote:

---

Originally Posted by LouisWilen

How can I determine which star codes are handled by Voipo? (In other words, which star codes are handled by the server?)

---

Brandon can correct me if I'm wrong, but these are the only star codes that Voipo has publicly stated they support:
http://forums.voipo.com/showthread.p...Star-Code-List

If you plan on using any of the other Voipo star codes and see them in the VSAC, I would erase them so as not to cause future problems.

I'm surprised that you are still able to use *30 and *31 after removing *xx from your dial plan. Once they were erased from the VSAC, these codes were no longer automatically appended to the dial plan per the admin manual. I'm almost positive these codes stopped working when I removed *xx in the dial plan.....you might want to double check again.

Quote:

---

Originally Posted by LouisWilen

What isn't clear to me is if specifying VSACs has any other effect. Are they just a convenient method of adding values to the dial plan, or do they actually cause something additional to happen in the ATA? For example, if a star code is set in the VSAC list and the star code is entered at a phone, does the ATA process the star code internally in some way?

---

Brandon is the expert here and will have to answer the technical aspects. It seemed to me the ATA was trying process the star code itself in some way or sending unsupported commands to Voipo's SIP server. Either way the VSAC star codes were causing weird problems or making things not work at all. That *30 in the VSAC was sure a strange one.....it caused all outbound calls to go straight to busy. The only way to recover was to enter *31.

BTW, I'm sure glad you brought this issue up because it helped me learn a whole lot more about the ATA's dial plan and how the VSAC interacts (or secretly interacts) with the dial plan.

Oops, I just checked and I'm not able to use *30 and *31 now that *xx is gone from my dial plan. I forgot to test those codes after removing *xx.

So *xx is going back into the dial plan. [...] Okay, *30 and *31 are working again now.

Onward now to removing lots of other entries from the VSAC and adding entries to the Feature Dial Services Codes list (each separated by a vertical bar).

Thanks again for all the help. I'll check back here soon for any further comments.

Okay, this is very interesting. To enable call return, I had to specify *69 in the VSAC Call Return field and not specify it in the Feature Dial Services Codes. Note that Call Return is listed as a supported feature here: http://www.voipo.com/voip-features.php.

I'm thinking that when a voipo provisioned ATA is used, some of the features are handled in the client (in the ATA) and some in the server. It would be nice for us BYOD users to know exactly which star codes are handled in the server and which need to be handled in the ATA.

Also found that I can enable lots of features that are controlled entirely by the ATA. For example, I can do *07 to redial the last number that I called. This is going to be fun!

Louis,

All feature access codes (VOIPo offers) are handled server-side.

I would be careful with the use of the client-side feature codes, many times end users have enabled client-side feature codes resulting in adverse / ambiguous affects to their service and induces additional troubleshooting delays.

Thanks for the follow-up tip.