Can't block CID

[tvBilly]

I've been using an Obi200 for the past few weeks, with great success. I have a Google Voice number and a CallCentric number. The GV number is setup as SIP1 and the CC number is setup as the default outbound line on SIP2. Thanks to massive amounts of reading and the sage advice here, I've managed to configure everything to work the way I want, including different rings for the two services, a different dialtone for the Obi secondary functions, as well as 911, 311, and 411 routing. So thanks to everyone here, who by helping others has also helped me, and made a pleasureable experience of switching from a 35 year old copper pair to VoIP (and saving me $40 a month to boot).

I just had my POTS number ported over to one of my CallCentric DID lines, and that works fine, but I can't seem to get CID blocking to work. I understand that the GV number can't be CID blocked, but I should be able to selectively block outbound CID on the CC line. From what I can tell, prepending *67 to any number I dial should tell CC to block outgoing CID (for one call), and it seems that the Obi uses the same *67 code to do the same thing. But when I prepend *67, though the call goes through just fine, my CID is sent.

Can anyone suggest where I should start looking to figure this out? I wanted to ask here before asking CC support, as I don't know if the problem is in my Obi settings or my CC settings. I don't see how it could be in my CC settings, though I wonder if it might be because I have my cell phone number verified with CC as OK to use as a spoof CID if I want to, and all the tests I've made have involved calling my cell phone from my CC line. Maybe that's something like Obi's trusted circle, and when CC sees I'm calling the cell phone it ignores the block CID request. Or not.

Thanks!

[drgeoff]

Just thinking out loud here, so the following has a high probability of being totally wrong.

1.  The OBi will swallow the *67 so CC will never see it.

2.  Even if the OBi acts on the 'block CID' command, CC still 'knows' your number is originating the call (otherwise you could avoid being billed for all 'CID blocked' calls   ) and can add your CID.

Have you tried pre-pending *67*67?  I'm not entirely convinced that makes sense either!  Maybe better to change OBi to ignore *67 as one of its star codes.  Star codes can be switched off completely by selecting StarCodeProfile None under Phone port.

[tvBilly]

I'll try turning off Obi's *67 code and see if that works.

Edit: nope, neither worked. Interestingly (?), when I turned off the Obi star codes, CC gave me an error message when I entered *67.

[ianobi]

drgeoff was right to suggest switching off OBi Star Codes to stop the OBi swallowing the *67. However, that is only the first half of the answer.

Now you need a digitmap to allow the OBi to dial star codes forward to Callcentric. Others on this forum have come up with this as the best digit map for Callcentric:

(*xx.|*123|**275*x.|[3469]11|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)

This rule *xx. accepts any number of any length that starts with a "*". For example *6712345678912 would be accepted. The problem with any code that ends "x." is that it matches all number formats, so OBi waits for ten seconds to see if you have finished dialling. I would try this:

Service Providers > ITSP Profile B > General > DigitMap:
(*671xxxxxxxxxx|*xx.|*123|**275*x.|[3469]11|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.)

This assumes that when you use *67 the following number is eleven digits starting with "1". Other combinations will be matched by *xx. but will have a ten second delay before going to Callcentric.

Your friend with all these things is Status > Call History. This will show what you dial and what goes to the voip provider. You can only gain access to this via the local OBi web page. Dial ***1 to get the IP address. User name and password should both be "admin".

[tvBilly]

So, progress, but not completely.

Part of my general confusion is where to add/change a command in the Obi settings when there is more than one place that the command will work (e.g. in the ITSP DigitMap versus the Phone Port OutboundCallRoute for 311/411/511/611/911 routing). Anyway, on to the specific of my block CID need.

My settings before trying to make *67 CID block work were as follows:

Physical Interfaces>PHONE 1>
StarCodeProfile is set to "A"
OutboundCallRoute is set to:
{911:sp2},{933:sp2},{(<311:12126399675>):sp1},{(<511:18884651169>):sp1},{([1-9]x?*(Mpli)):pp},{(<##:>):li},{(<**70:>(Mli)):li},{(<**82:>(Mbt2)):bt2},{(<**81:>(Mbt)):bt},{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**9:>(Mpp)):pp},{(Mpli):pli}


Service Providers>ITSP Profile B>General>DigitMap is set to:
(*xx|*123|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*]@@.)

So there are a couple of differences between what you suggested and how I set things up. I don't remember why I chose the method I did, though it was from reading suggestions here. My "311/511/911/933" stuff is set in the PHONE1 OutboundCallRoute rather than the ITSP DigitMap. Not sure this makes any difference, though I suspect one passes the number through another DigitMap before sending it out, and the other doesn't. Everything works fine the way I have it set, so I don't plan on changing it unless there is a good reason.

In my original ITSP DigitMap, there are some mistakes. The leading "*xx" is wrong, and it what was causing all the trouble, because it sends *67 out to CC without waiting for the rest of the digits. I "fixed" this by adding a trailing period (making it *xx.). This works as expected, although as you point out there is a 10 second delay. Prepending *671xxxxxxxxxx| takes care of the delay when I want to use *67. Note that in your message's suggested change, there are only nine x's instead of ten x's, which I assume was a typo on your part. With only nine x's one still gets the 10 second delay. At the end of my original ITSP DigitMap I have [^*]@@. and your suggestion is [^*#]@@. which has an additional #. I don't have my ObiDeviceAdminGuide handy here, so I can't look up what the added # does; if I get home before you answer, I'll look it up and save you the trouble of answering this.

Once I fixed the missing trailing period in the *xx at the beginning of the original ITSP DigitMap, things started to work the way they should. As did they when I also prepended the *671xxxxxxxxxx| getting rid of the ten second delay. HOWEVER, there are a couple of things that aren't working as expected. It doesn't appear to make any difference if I change the Physical Interfaces>PHONE 1>StarCodeProfile to "None" or leave it set to "A". It works the same in either case, and I don't know why. Not really a problem, just curiosity on my part; I left it set to "A". But more significantly, CC still sends out a CID number even with the *67 stuff "working". It doesn't send out MY number though, it sends out a generic CC number (224-567-5814). Calling this number gets a CC "this number is not in service" message. Googling that number also reveals that some less than scrupulous telemarketers (is that an oxymoron?) must vector through CC, with their CID blocked, because that number shows up in a (thankfully) few "nasty telemarketer" reports.

So the (224-567-5814) number seems to be a CC thing, not an Obi thing. I'd really like CC to send out a "blocked" or "anonymous" CID when I prepend *67, not a generic bogus CC number. Any thoughts about this, or should I just open a ticket on CC and ask them.

Thanks for all the help!!!

Edit: OK, I read through the CallCentric FAQs, and they send the 224-567-5814 out whenever "block outbound CID" is set. Some nonsense about "This is required for compliance with US laws and regulations." Funny how it's allowed for POTS carriers but not VoIP carriers. In any case, the Obi is doing what it's supposed to, and my bitch is with CC not Obi.

More Edit: Oh, and I'm still not home with my ObiDeviceAdminGuide, but I was thinking about the meaning of [^*#]@@. versus the one I have which is missing the #. Since I have an Obi200, I can't see ever starting a dial string with a # since I don't have a POTS line hooked up. And I can't remember what the ^ character represents. but wouldn't *@@. be superfluous since there's a *xx. already at the beginning of the map? (If I'm remembering correctly that @ represents any digit while x represents any character).

Even More Edit: OK, I looked up ^, and I think I get it. [^*#]@@. matches any string that doesn't begin with * or #. And I had "x" and "@" mixed up.

[ianobi]

Note that in your message's suggested change, there are only nine x's instead of ten x's, which I assume was a typo on your part.

Yes, I think the "x" key on my keyboard may be getting worn after so many digitmaps! Every little "x" is important, so I will go back and add that one to my original post in case anyone copies it.

My "311/511/911/933" stuff is set in the PHONE1 OutboundCallRoute rather than the ITSP DigitMap.

This is fine so long as the same numbers also appear in the Phone Port DigitMap. 911 is there by default. If you put them in ITSP Profile B, then they will appear in Msp2, which is in the Phone Port DigitMap and OutboundCallRoute, so the numbers are there "by reference". If say 311 is not in the Phone Port DigitMap, then it may get processed by the "xx." rule in your PrimaryLine DigitMap (in your case also Msp2), which will work, but will add a ten second delay.


My original suggestion dropped these from the DigitMap: xx.|(Mipd)|[^*#]@@.
xx. matches any digit followed by any number of digits, the "catch all" rule. It adds two seconds to number processing and if all possible numbers are matched anyhow in the digitmap, then it has no purpose. Although see paragraph above.
Mipd allows you to dial IP addresses - I don't think you will do that using CC.
[^*#]@@. allows you to use sip uri calling. It allows any alphanumeric character followed by any number of alphanumeric characters, but not starting with "*" or "#". Again I don't think you will be using this for CC. This rule also acts as "xx." as far as digits are concerned.

Anyhow, it seems to me you have a good grasp on "How to Configure Your OBI". The problem is it is so configurable that there is often more that one way to achieve the same result.

[tvBilly]

My "311/511/911/933" stuff is set in the PHONE1 OutboundCallRoute rather than the ITSP DigitMap.

This is fine so long as the same numbers also appear in the Phone Port DigitMap. 911 is there by default.

And indeed my Phone Port Digimap has: [359]11

Mipd allows you to dial IP addresses - I don't think you will do that using CC.
[^*#]@@. allows you to use sip uri calling. It allows any alphanumeric character followed by any number of alphanumeric characters, but not starting with "*" or "#". Again I don't think you will be using this for CC. This rule also acts as "xx." as far as digits are concerned.

Thanks for the help, and the continuing education. I have another question, but it has nothing to do with this, so I'll start another thread.

This is a nice place to hang out.

[ipse]

Guys, I have the same problem, but in my case it's with POTS....no funny business here, the phone connected straight to POTS works just fine blocking CID, once I send it through OBI110 it's understood but ineffective.
Do I really need to start playing around with the digits map for something as simple as this?
TIA

[tvBilly]

Silly question 1: Are you sure the Obi is dialing out on your POTS line rather than one of your VoIP lines?

Without seeing your settings, the only think I can think of to suggest is to dial your outbound call that you want sent from your POTS line with CID blocked by prepending a # before the rest of the dial string. If I remember my reading here, the leading # tells the Obi to just connect your phone immediately to the POTS line, and whatever else you push on the touch tone pad will just go out your POTS line unmolested.

So if you wanted to call 12125551212 out your POTS line with your CID blocked, you would enter #*6712125551212.

Since you didn't go into a lot of detail, and I don't understand what you mean by "it's understood but ineffective", I can only suggest you try the above, and if it's not sufficient for what you want (or it just doesn't work either), then a little more info about what you want to do and what your settings are will help.

ps I don't know squat compared to a lot of others here...