Contact us
HOME
[BLOG #1] Prefixing on H323
Prefixing and number display on H323 Dial-peers for granular POTS interface selection
Tags: Frink  CISCO  Tech Factors  collaboration  advanced services  PBX  VOIP  CUCM  flexibility  SIP Trunk 
One of the advantages of using MGCP for GW control in UCM is that you can easily do granular routing, e.g. route out of a specific interface for calls. With H323 and SIP the call is send to the Gateway and then the internal call routing logic (i.e. IOS dialpeers) will take over.
Let's compare the two models to make it clear what the "issue" is:
MGCP
• In UCM, a "chassis" is configured to which multiple endpoints are attached.
• an endpoint is generally speaking a single interface (fxs, fxo, pri...)
• every single endpoint is controlled by the UCM with regard to call routing logic
• CDRs will show the specifically selected endpoint
H323/SIP
• GW is a single endpoint, identified by its IP address
• There might be multiple Interfaces hidden behind that IP address
• UCM does not know whether this is a CUBE or a PSTN GW
• Dial-peer call routing logic applies on IOS GWs
• CDRs will only show the IP of the GW
So unless one does really fancy stuff with multiple IPs on the GW UCM do not actually select the POTS interface (or a SIP trunk via CUBE) to be used but rather just speaks to a "chassis"

There are 2 main problem areas with the H323/SIP approach when used in projects
• Granular Call routing
• Billing

So is there some way to get granular call control working at least for the call control part?

The requirements for the solution should be:
1.) It should be transparent to the user, e.g. he should not see which link is being used (e.g. no prefix is visible to the user)
2.) Path selection should be controlled via the UCM configuration and not via Dial-peer routing on the GW
3.) Failover should still work properly, e.g. RouteGroup redundancy inside of the Routelist can be used.
Consider the following situation:
1x normal PRI for standard PSTN Calls
1x PRI Directlink to Mobile Provider
1x SIP Trunk via CUBE

The goal is to enable selection of individual call directions on the UCM (rather than on the gateway itself)
Create and assign the Routegroup
Assign the Routegroup to the Routelist, go into the details of the Routelist/Routegroup connection and set "prefix digits" to either *1, *2 or *3. This way we can now select the individual paths on the Gateway.
If we want to select the Directlink to the mobile provider, we would configure the RL - RG connection as shown on the next picture.
If we now make a test call there is one major caveat. Let's say we decide on sending everything starting with 0676 out the *2 Link.
Now the user will see the following number on the display of his phone:
*200676 XXX XXX

This of course is less than ideal because we might get some helpdesk calls from users because they are complaining about seeing something different then they have dialled.
This happens because the GW will send a display update via H323 during the call which will be displayed on the phone.
To get around this we slightly modify our configuration.
This will match a "*", then any digit, followed by a 0 and finally any number of digits. This will match all of our prefixes. Of course explicitly matching *10, *20 and so on would also be possible (the 0 is part of the match because it is used as the normal PSTN Access Code, e.g. in the US this would likely be *19, *29 and so on)

This rule is bound into the relevant translation-profiles (SIP-OUT and POTS-OUT) which then are applied to the relevant dialpeers.
If we drop the digits this way, the H323 display update will signal the "real" final called number (e.g. 0676 XXX XXXX).
For the user this is ideal because he sees the actual, final called number.
So let's take this in steps:
First we need to decouple the path selection from the actual dialed number. For this we work with, (not very surprising) prefixes.
So for each Link on a GW we decide on a prefix. As an example let's take the following example:
• Primary PSTN Link from Telco: *1
• Directlink from mobile provider: *2
• Alternative Provider via SIP Trunk *3
On the POTS Dialpeers we enabled the command "forward-digits all". This means that digits matched by the destination-pattern will be forwarded rather than dropped.
This means we need now need to take care of the transformation of the called number via translation-rule and a translation-profile.
The rule is quite simple:
Notice two things:
We enabled huntstop on each link (there is actually a small caveat for this which I will explain in a future post)
The POTS Dialpeers will work out of the box (because the matched digits will be dropped), for the SIP dial-peer will not because of the extra *3, we will need a translation rule there.

On the UCM we will need to do the following:
1.) Create a Routegroup for each GW
2.) Create Routelists depending on our routing requirements
back to FRINK Magazine
Editorial Team: Bernhard Albler