Globalized DialPlan Collab11

johnhsnow · ‎01-22-2016

I am trying to understand the logic in the srnd from call control perspective. It appears that there are no access codes for PSTN calls anymore and they are used to force on-net dialing?

If I create a global CSS for class of service for example International the srnd shows 2 translation patterns - 1. for abbreviated dialing, that globalizes to the +E.164 and matches the DN because it does not use originating CSS to match anything on the PSTN.

2. for local dialing (7 digit in this case), once again it gets globalized to the +E.164 and matches the DN, and does not use the originating CSS to match anything on the PSTN.

In both cases, if originating CSS was enabled, the international CSS would match route pattern in PSTN International PT and egress GW to PSTN.

so if i am dialing 9.XXXXXXX or 9.XXXXXXXXXX (and they get globalized) and it is matching these translation patterns and forcing on-net calls to the DN, the only logic is that the call logic in CM knows that if it DOESNT match a DN, it will match based on the PSTN patterns, \+1XXXXXXXXXX for national calls, or \+[^1]! for international calls or the local \+1<siteNSX>XXXXXXX and there is no need for 9.[2-9]XX[2-9]XXXXXX and 9.1[2-9]XX[2-9]XXXXXX

Is this correct?

I have attached the screen shot from srnd - hope someone can verify this.

Thanks guys

Vivek Batra · ‎01-22-2016

Hi,

Very important note in this example, all DN's are assigned E164 number, not 1XXX and partitions are listed in following order;

DN

SJCtoE164

UStoE164

PSTNNational

USPSTNNational

SJCPSTNLocal

So if you are dialing 9+7 digit (9.XXXXXXX), so it could be intra-site call or off to PSTN. Say you dial 9.5551234 (1234 is internal), this will get translated to globalized format and hence becomes +14085551234. Now under translation pattern, we are again using the original device CSS and the translated number will match with the DN partition since it is on the top in CSS, this shall result in routing the call to 1234.

Now say you dial 9.5552222 (off to PSTN), this will again get translated using the same logic and becomes +14085552222. Now under translation pattern, we are using original device CSS however this number will only match with the partition SJCPSTNLocal and hence will go to gateway. At gateway, we will again localize the number and will remove +1408 and actual dialed number to PSTN will be 5552222.

Coming back to your question again, user can either dial from call logs or manually hence there is a need of 9.1[2-9]XX[2-9]XXXXXX pattern. If you don't configure this translation pattern, how user will make national long distance call while dialing the number manually. Now if user dials this pattern manually and since first translation pattern (SJCtoE164) only globalizing 4 digit DN's and 7 digit local number, hence this pattern is kept in UStoE164 partition so that if caller is dialing the number manually, it can be first globalized and again check all partitions to find out whether this number is internal DN or off to PSTN. Had user been dialed the internal DN (say 1234) using this format, first partition DN will be matched, else depends on area code one of the route pattern will be matched (either USPSTNNational or SJCPSTNLocal as the case may be).

- Vivek

johnhsnow · ‎01-25-2016

HI Vivek:

I appreciate that input and the logical breakdown. It was very helpful.

As simple as it was i did neglect to factor in the top down order of partitions. I just want to point out one other thing regarding your comment "we are using original device CSS".

My understanding is the line(or device) CSS/CoS is the recommended design now as depicted in figure 14-28 and 14-29 in this document("The single calling search space creating the requested class of service can be used as a line or device calling search space.")?

and I read because somehow line/device approach breaks +dialing but i'm not sure.

Vivek Batra · ‎01-26-2016

Hi,

1. Regarding first point 'we are using original device CSS'

As you might be aware that there are three choices how to take call further from translation pattern.

First obvious choice is CSS configured under TP itself.

Second is on the basis of calling party number (along with TP CSS).

Third is newly introduced in V10 to route the call further using 'Originator Calling Search Space'. So TP will use the originator CSS to find the next hop instead of TP CSS. This was missing point since globalization and localization concept was introduced in V7 and it took three major releases to introduce this parameter.

So with this parameter being used to find the next hop, not only originator device CSS will be used, it will use the same approach as it used to be of line/device CSS.

2. I believe that the respective example has not considered any CoR hence had only one CSS. But in SRND it is also mentioned that if the deployment is using mobility features like EM and DM, line CSS has to be used to preserve users CoR when roaming.

Anyway, I don't see even using line CSS as well for CoR won't break the E164 approach.

For example, if you want to restrict specific pattern local to SJ viz 2222222 and as all patterns are globalized before being out dialed, you would like to apply this restriction using E164 hence you would create RP of +14082222222 (SJCPSTNLocal) and restrict this pattern.

If you would like to block specific area code altogether say 202, you would create RP +1202! (USPSTNNational) and block this pattern.

If you would like to restrict international call to specific country say India (91), you would create RP +91! (PSTNInternational) and block this pattern.

- Vivek