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.
- A 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 specific 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 wether 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 does 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 (that's what I generally need):
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 indiviual call directions on the UCM (rather than on the gateway itself)
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
Now we create a dial-peer for each provider:
dial-peer voice 10 pots
description Primary Link to Telco
huntstop
preference 1
destination-pattern *10T
progress_ind setup enable 3
progress_ind alert enable 8
progress_ind progress enable 8
port 0/0/0:15
forward-digits all
!
dial-peer voice 11 pots
description Directlink to Mobile
huntstop
preference 1
destination-pattern *20T
progress_ind setup enable 3
progress_ind alert enable 8
progress_ind progress enable 8
port 0/0/1:15
forward-digits all
dial-peer voice 2000 voip
description Link to SIP Provider
destination-pattern *30T
session protocol sipv2
session target dns:proxy.siprovider.at
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711alaw
huntstop
Notice 2 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.
But we are not finished yet.
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
When we create the RouteList and assign the Routegroup we do the following:
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 following 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 dialed.
This happends because the GW will send a display update via H323 during the call which will be displayed on the phone. Darn!
To get around this we slightly modify our configuration
voice translation-rule 5
rule 1 /\*.0\(.*\)/ /\1/
!
voice translation-profile POTS-OUT
translate called 5
voice translation-profile SIP-OUT
translate called 5
dial-peer voice 10 pots
translation-profile outgoing POTS-OUT
description Primary Link to Telco
huntstop
preference 1
destination-pattern *10T
progress_ind setup enable 3
progress_ind alert enable 8
progress_ind progress enable 8
port 0/0/0:15
forward-digits all
!
dial-peer voice 11 pots
translation-profile outgoing POTS-OUT
description Directlink to Mobile
huntstop
preference 1
destination-pattern *20T
progress_ind setup enable 3
progress_ind alert enable 8
progress_ind progress enable 8
port 0/0/1:15
forward-digits all
dial-peer voice 2000 voip
translation-profile outgoing SIP-OUT
description Link to SIP Provider
destination-pattern *30T
session protocol sipv2
session target dns:proxy.siprovider.at
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
dtmf-relay rtp-nte
codec g711alaw
huntstop
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:
voice translation-rule 5
rule 1 /\*.0\(.*\)/ /\1/
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.
Pretty easy, huh?
