News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

CallCentric digit map

Started by tome, August 30, 2011, 07:07:31 PM

Previous topic - Next topic

tome

I signed up with Callcentric for 911 services.  I have set it up on SP2 (and modified my outboundroutemap to add the 911 stuff RonR has posted in other threads.  I tested a 911 call, an outbound to a mobile number and an inbound call from Callcentric's test stuff.  Everything seems to be working fine.  I have a question on their setup information:

In the setup information on the Callcentric web site they say:
Service Providers > ITSP Profile > General
Digit Map:   (*xx.|**275*x.|[3469]11|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)

What does this digit map do?

Tom

RonR

*xx.  ->  Star Codes  (this will disable the OBi's Star Codes)
**275*x.  ->  Sip Broker support
[3469]11  ->  311/411/611/911  (911 is already handled in the PHONE Port DigitMap/OutboundCallRoute)
1xxxxxxxxxx  ->  11-digit dialing
<1>[2-9]xxxxxxxxx  ->  10-digit dialing
011xx.  ->  International dialing
xx.  ->  let anything through
(Mipd)  ->  IP dialing
[^*]@@.  ->  SIP URI dialing  (bad rule : matches way too much)

tome

Quote from: RonR on August 30, 2011, 08:55:45 PM
*xx.  ->  Star Codes  (this will disable the OBi's Star Codes)
**275*x.  ->  Sip Broker support

Thanks Ron, some questions...

Why would they want the * codes disabled and should I?  And is the Sip Broker support required to use Callcentric?  What is it exactly?

Quote from: RonR on August 30, 2011, 08:55:45 PM
[^*]@@.  ->  SIP URI dialing  (bad rule : matches way too much)

Should I remove it or change it?

Tom

RonR

#3
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.

Quote from: tome on August 31, 2011, 06:16:25 AM
Quote from: RonR on August 30, 2011, 08:55:45 PM
**275*x.  ->  Sip Broker support
And is the Sip Broker support required to use Callcentric?  What is it exactly?

Sip Broker might allow you to call users on other networks:  Sip Broker

Unless/until you need Sip Broker support, I wouldn't worry about it.

Quote from: tome on August 31, 2011, 06:16:25 AM
Quote from: RonR on August 30, 2011, 08:55:45 PM
[^*]@@.  ->  SIP URI dialing  (bad rule : matches way too much)
Should I remove it or change it?

There are some DigitMap rule situations where [^*]@@. matches way too much and prevents the intended result (this rule matches ANYTHING that doesn't start with an *).  Since the purpose of this rule is to match SIP URI's, I recommend using @@.'@'@@. (anything@anything) instead of [^*]@@.  There is currently a bug on the OBi firmware, necessitating that this rule be written as [^*]@@.'@'@@. to prevent it from interfering with *60, *62, *72, and *74, which should not be occurring.  If/when this bug is corrected, the [^*] can be removed.

tome

Quote from: RonR on August 31, 2011, 09:37:28 AM
There are some DigitMap rule situations where [^*]@@. matches way too much and prevents the intended result (this rule matches ANYTHING that doesn't start with an *).  Since the purpose of this rule is to match SIP URI's, I recommend using @@.'@'@@. (anything@anything) instead of [^*]@@.  There is currently a bug on the OBi firmware, necessitating that this rule be written as [^*]@@.'@'@@. to prevent it from interfering with *60, *62, *72, and *74, which should not be occurring.  If/when this bug is corrected, the [^*] can be removed.

Ok, I will change it to:  [^*]@@.'@'@@.
By the way, it was written as [^*#]@@.  (with the #) on the CallCentric config page.

Thanks,
Tom

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

#8
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

#9
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)

RonR

Randrage,

Here's what you'd probably need to do to keep 7-. 10-. and 11-digit dialing working along with *67:


(*671xxxxxxxxxx|*67<1>[2-9]xxxxxxxxx|*67<1505>[2-9]xxxxxx|
1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1505>[2-9]xxxxxx|011xx.|(Mipd)|[^*]@@.'@'@@.)