VOIP Tech Chat → [Voip.ms] Outgoing CallerID block using "standard" *67

I just spoke with a Live Chat rep, and to my surprise I found that Voip.ms does not implement this feature - what gives? This was available on landlines for a long time, couldn't believe they don't have it. Also checked with Callcentric and Callwithus and they both have it

Many ATAs have this feature, so that should work. (Obi does, pretty sure Sipura ones do too)

I have CallerID configured in Voip.ms server, I just want to block it on a per-call basis. The ATA cannot over-ride this, and it's exactly what *67 does.

I should have also mentioned I use Voip.ms as an outgoing call provider only (through my OBi110 Voice Gateway feature)

I use voip.ms and an OBi202 and I just tried a call with *67. The callerID shows up as "Private caller" on my Panasonic handsets and is listed in the voip.ms CDR as "Anonymous" .

Quotes from my chat today with Jeff:

"112:44:08 PM [Jeff] *67 is ignored by our service since it is not a valid Star code with us, Can you try 0000000000 as Your CallerID Number
12:44:39 PM [Me] OK, so it's no wonder blocking CallerID doesn't work with your service
12:45:16 PM [Me] Of course I can replace my CallerID with 0000000000, but the point was to block outgoing CallerID on a per-call basis
12:46:11 PM [Jeff] Yes this works on your device only but not through our service unfortunately
...
12:52:52 PM [Me] Sorry, I don't agree with you... *67 is implemented by other VOIP provider as well as Bell CO switches, and NOT at the ATA device level
12:52:55 PM [Me] »www.callcentric.com/faq/4/321
12:55:06 PM [Jeff] That would be Call Centric which is a different more expensive VOIP Service provider, But as stated before you can put Anonymous as your CallerID Name or Put 10 0´s as your CallerID Number through our service. You can also submit a feature request for this to become a star code command for our service if you like"

Perhaps it depends on the server you're making the call through... I am using toronto4

I'm using servers montreal3 and montreal4, but I quite doubt that the choice of server affects features. Again, I think *67 is a feature provided by your device. Considering most devices have these standard features, it seems redundant for the service provider to implement them as well. What shows up as your callerID when you try it?

The fact I am making the calls without registration (using Voip.ms as Voice Gateway account) might also be an issue. I use both Callwithus and Voip.ms as Voice Gateway accounts (configured identically except for the login) and Callwithus works properly. So does Callcentric which I have registered on SP1

How would the ATA implement this feature? Would it translate the *67 DTMF codes into a SIP message?

Obi star codes: »www.obihai.com/docs/OBiF ··· odes.pdf

Also: »www.obihai.com/OBiDevice ··· minGuide (search for *67)

Most ATA's implement the start codes and modify the SIP messages accordingly. Of course, the provider doesn't have to obey, but many will, at least for that one.

On most ATAs, the code is not sent directly to the VoIP provider. It rather triggers a flag in the ATA which will format the next call in a way that tells the VoIP provider to hide the caller ID. So while voip.ms doesn't handle *67 in the dial string, it probably honors the "hide presentation" flag in the SIP call.

Did a few more tests... I am using a OBi110 device, Callcentric is my provider registered on SP1, while Callwithus and Voip.ms are used without registration (Voice Gateways using SIP INVITE).

Callcentric:

1. Dial *67 - wait for a new dial tone - dial the number (CallerID NOT blocked)
2. Dial the number prefixed by *67 (CallerID blocked)

Callwithus:

1. Dial *67 then wait for a new dial tone and dial the number (CallerID blocked)
2. Dial the number prefixed by *67 (CallerID not always blocked)

Voip.ms:
1. Dial *67 - wait for a new dial tone - dial the number (CallerID NOT blocked)
2. Dial the number prefixed by *67 (Error message - The number you dialed was rejected by the Service Provider)

This tells me Callcentric detects and honors the *67 in the dial string, but it does not honor the SIP message coming from the ATA

Callwithus tries to honor both (but not very reliably in case 2)

Voip.ms does not honor either

I will also try another Voip.ms server, as I also had some DTMF issues with toronto4

Your method (1) is not really a valid test. You are applying a POTS method to VoIP.

By waiting for a second dial tone, that's a new call. The system got tired of waiting for you. There is NO "second dial tone" on a CC call.

As far as (2) be sure to dial it as *67-1-xxx-xxx-xxxx, NOT as *67-xxx-xxx-xxxx.

-----

BTW with CallCentric you will have TRUE blocking EVEN TO toll free numbers. That is NOT the case with *67 for POTS, and sometimes not the case with *67 for some VoIP providers.

You can test that by calling the MCI test number 1-800-444-4444 which will read back your CID. However that MAY not work from Canada.

I just tried it with VOIP.ms and a Grandstream HT701 and my AT&T cell came up with all 0's..

*67 - xxx-xxx-xxx straight dial, no waiting... Chicago server.

Interesting... Could this be different for calls made with vs without registration?

What happens if you temporarily take your OBi110 offline and register using a softphone such as Zoiper, and then place a call starting with *67? If that works then you might need to disable the *67 feature code in your OBi110, at least for that provider, so that when you dial *67 + a number it all gets passed directly to the provider, and is not acted upon by the OBi110.

OK, I contacted Callwithus and they also said they do NOT support *67 so I am only left with Callcentric for reliable CallerID blocking. Which is OK since their features (while not very extensive) are extremely reliable

Thanks everyone!

I think that CC features are [quite] extensive. Perhaps you just haven't had the opportunity to explore all of them.

To me your statement was like saying that Wisconsin didn't have cheese or football.

The main things I can think of that they don't have are texting (which only a few have tried and no one has perfected) and IVR (which is coming).

Some of what they do have:

Extensive and flexible call treatments including simulring, hunting, forwarding, telemarketer block [dial 1 or a random number to complete the call]

Call Answer confirmation [press 1 to answer the call] (Voip.MS has been working on that for over 2 years).

Security measures include (among others) the ability to enable/disable outbound calls by country (they were first with that), and the option of IP address whitelist verification for your equipment.

Excellent billing setups with highly configurable recharge options.

Calling cards.

Callcentric Android app.

Free inbound and outbound CNAM.

Inbound and outbound calling options (chosen individually) including both flat-rate and PAYG plans each way. Free unlimited DID's are available for metro NY areas.

Extensive support is provided for free SIP URI calling, iNum, and SipBroker.

Always-free customer support from US-based engineers.

Subaccounts (which they call Extensions) and multiple mailboxes.

-----

I've probably missed some, but CallCentric have lots of features.

Anveo may have the most total but they are quite confusing, and they don't have all the answers either.

For voip.ms, are you using premium or value routing ?
I can confirm that when using value routing, the call with blocked CID gets rejected, while when using premium routing the call goes through and the CID is blocked as expected.
In fact, I think the voip.ms portal mentions somewhere that CID delivery is not guaranteed with the value routing.

Didnt voip.ms recently go to ALL 'premium'?

Premium... But it may also have to do with making the call while not registered. I sort of resigned to use Callcentric in the (rare) case I need to block CallerID

Only for USA