Always get busy signal when doing *67

[LouisWilen]

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?)

[tritch]

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.

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.