CallCentric digit map
tome:
Quote from: RonR on August 31, 2011, 09:37:28 am
Quote from: tome on August 31, 2011, 06:16:25 am
Quote from: RonR on August 30, 2011, 08:55:45 pm
*xx. -> Star Codes (this will disable the OBi's Star Codes)
Why would they want the * codes disabled and should I?
Just about everyone, including the OBi, supports Star Code features to block CallerID (*67), return the last call (*69), etc. The way the OBi is set up, it handles Star Codes unless DigitMap rules turn them over to someone else. This can be done selectively (*67|*69|...) or collectively (*xx|...). Unless you need a particular (or all) Star Code(s) to be handled outside the OBi, I recommend you don't change anything in this area.
RonR,
I was just re-reading this and realized I am not sure if you mean I should have *xx. in my Digit Map for CallCentric (which means, I think, that CallCentric will handle them), or if I should not have it in the Digit Map (which means the Obi handles them)...?
Tom
RonR:
tome,
I just ran some tests to make sure I give you accurate information and discovered things have changed at some point. Here's the way things currently work:
1. If Star Codes are explicitly matched (i.e. *67, *69, etc.) in a DigitMap rule, they are sent to the provider.
2. A rule matching all Star Codes (i.e. *xx, *xx., etc.) is ignored and the Star Code is handled by the OBi if the match occurred on the PrimaryLine (no **n was used). If the match occurred using a trunk specifier (i.e. **1, **2, etc.), the Star Code is sent to the provider.
Not exactly consistent, is it?
tome:
Quote from: RonR on September 03, 2011, 09:03:46 pm
tome,
I just ran some tests to make sure I give you accurate information and discovered things have changed at some point. Here's the way things currently work:
1. If Star Codes are explicitly matched (i.e. *67, *69, etc.) in a DigitMap rule, they are sent to the provider.
2. A rule matching all Star Codes (i.e. *xx, *xx., etc.) is ignored and the Star Code is handled by the OBi if the match occurred on the PrimaryLine (no **n was used). If the match occurred using a trunk specifier (i.e. **1, **2, etc.), the Star Code is sent to the provider.
Not exactly consistent, is it?
Wow, that is obtuse. In my case, the digit map is on Sp2 so if I send a star code it will be forwarded to Callcentric. But generally the Obi can handle the star codes itself, so I should probably just remove that part of the digit map?
-Tom
RonR:
Quote from: tome on September 04, 2011, 07:45:26 am
Wow, that is obtuse. In my case, the digit map is on Sp2 so if I send a star code it will be forwarded to Callcentric. But generally the Obi can handle the star codes itself, so I should probably just remove that part of the digit map?
You'll have to see if there are any Callcecentric Star Codes that are interesting to you. If there's only one or two, you may want to explicitly include them in your ITSP Profile B DigitMap instead of the *xx. rule.
Randrage:
Sorry to necro this thread. RonR's comments here have been very helpful, however I've run into an issue that hasn't been addressed.
I've been explicitly adding star codes to the digitmap that I want CallCentric to handle as discussed above. For the most part it's working fine. However, star codes that require you to enter a phone number immediately after don't work properly.
For example, *67 is supposed to block my caller ID per call, and it expects a phone number immediately after. But if I just add *67 to the digitmap by itself, the OBi sends it immediately and doesn't allow for the subsequent phone #, resulting in a CallCentric message saying "The number you have dialed is invalid" etc.
I'm assuming I'd have to add it to the following portion of the digitmap, but I'm not exactly sure how:
Quote
|1xxxxxxxxxx|<1505>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|
The reason I want CallCentric to handle this is because if I use the OBi's *67, it calls the number fine but the CallerID still goes thru for some reason (Edit: It seems that even manually blocking CallerID via the CC web portal doesn't work for me, probably because I had them 'force' a CallerID # that they don't own. Might also explain why using OBi's *67 doesn't work)
Navigation
[0] Message Index
[#] Next page
[*] Previous page