Virtual Number Delivery Changes

Brandon is making a change tonight in the way that virtual numbers are delivered.

On residential accounts, all calls including calls to virtual numbers will be delivered to you using the main number on your account. This means that when someone calls your virtual number, we will send the INVITE to your device with your main number.

If you need to distinguish what DID the number is coming over (like for Asterisk), you'll need to be moved over to our carrier system. It will still distinguish delivery.

This is done primarily to standardize some areas in our system related to virtual numbers. I don't think virtual numbers have been as problem-free as they should be (they are in theory very simple) and this is one of the reasons. The old way is creating an inconsistent environment for them to be delivered which different devices handle in different ways. We see a lot of ATAs responding with 404 on virtual numbers (which causes dead air or an error message) because they are not accepting calls from a number they are not configured for.

I know some of you requested this in order to make using Asterisk easier. We can attempt to reconfigure and tweak to get around this, but at the end of the day, we need to do things like this to make our system more stable overall so we can provide a consistent level of service. The residential service is aimed at residential users and the bulk will be using standard ATAs with no need for this. I'm sure you can agree that we need to structure things in a way that makes the most sense for our service as a whole within the target markets.

For those of you who have a standard setup, this change will NOT affect you. Your virtual numbers will work as they have in the post. You can still setup an independent voicemail box, etc.

For those of you with Asterisk or something similar that need this, the carrier system will absolutely do this for you and anyone who wants to migrate their accounts over to that...please let us know.

Thanks for your cooperation.

I think I saw the tip here--can you avoid this problem by setting (for example in the PAP2) "Answer calls without register" to yes?

This comes back to the early days of using the test account and setting the CID to spoof my home number but incoming calls failing. (Set "username" to the spoof number, but use "Auth ID" with the actual account phone#...)

The point is, this move is sensible for the Residential system. I assume you do not plan on supporting Asterisk for Residential accounts--Asterisk users will have to subscribe to the Carrier service, correct?

Quote:

---

Originally Posted by fisamo

ccount phone#...)
The point is, this move is sensible for the Residential system. I assume you do not plan on supporting Asterisk for Residential accounts--Asterisk users will have to subscribe to the Carrier service, correct?

---

Asterisk on the residential system is not something I anticipate us actively disallowing, but the service won't necessarily be designed for it, no. There ar two many variables and support issues when dealing with inconsistent environments, different versions, configurations, etc.

In most cases, allowing anonymous would fix, yes, but it's still kind of a workaround that is ATA dependent.

We just don't want to be in a position where we have things setup in different ways for different customers to make the service work the same way for both of them.

Quote:

---

Originally Posted by VOIPoTim

Asterisk on the residential system is not something I anticipate us actively disallowing, but the service won't necessarily be designed for it, no. There ar two many variables and support issues when dealing with inconsistent environments, different versions, configurations, etc.

---

I'm assuming that you're talking about the type of accounts registered to codeblue.voipo.com and the number for the user name. If so, I believe you will be much better off simplifying and standardizing that system for the majority 'herd'. I think having only the main number INVITE is pretty standard for that type of account. Avoid complications for the technologically challenged wherever possible. That system is also a feature-rich service that really won't be as attractive to the dedicated * bum like me. It'll also cut down on having to provide technical support on that type of issue for the majority of your residential clients.

Is the carrier system the Express one based on cheetos and cherrios or yet something else? For those numbers I have associated with the cheetos based account, I assume they will belong on your carrier system, if different. But I don't remember seeing any VN availability as such there yet ;-)

Quote:

---

Originally Posted by gbh2o

Is the carrier system the Express one based on cheetos and cherrios or yet something else? For those numbers I have associated with the cheetos based account, I assume they will belong on your carrier system, if different. But I don't remember seeing any VN availability as such there yet ;-)

---

Yeah it is the one using cheetto. In the vPanel for it, you just add DIDs and point them to a registration, IP, etc.

Strange issue - 2 things, actually. On my main number, caller ID comes through with no name. Virtual number, name is good. On my main number, if someone calls and I don't answer, all is good. On the virtual number, if someone hangs up before I answer, it rings, and rings, and rings...you get the idea ;)

I couldn't agree more. On the Residential system, keeping your support issues to a minimum is best for everyone.