This is a problem that has me a bit stumped, I have come up with one working solution, unfortunately it does not quite meet my requirement.
The problem is this, Using CME, how does one send a string of DTMF tones inband via a PRI connection to the PSTN. Why would we want to do this? There are many occasions when interaction is required across the PSTN using just DTMF tones e.g. Logging in to vmail, logging into a providers call center, setting call diverts etc.
In the case that I was looking at I have been asked to provide a quickdial solution that would call a PSTN number, then when the call was connected, log into the service, and enter mobile phone number. This would in effect set the destination for the companies 1800 number.
The sequence of numbers and information sent to me was as follows (numbers etc changed for obvious reasons):
dial pstn number 555-5678
when asked enter pin "12345" then *
after listening to the instructions enter the destination number that the 1800 number will be diverted to 555-8888, then #
Wait for the digits to be read back, then enter 1 to accept.
The plan was that depending who was on call each week would have the 1800 number diverted to their phone. The client wanted users to be able to dial 150, 151, 152... etc to move the on call number between phones without having to manually doing the process.
At first look it seems like a pretty straight forward request, and something that I would imagine is pretty common. I am sure it would be very easy using IPCC, or CUE AA. Unfortunately the client is running straight CME, without CUE.
My next thought was TCL, so I had a quick search, hmmm, not much luck there. Then after having a discussion with a close friend we came up with a fiendish plan to use num-exp.
So here is what I did.
Firstly I wrote the DTMF sequence as it would be entered by the end user, using commas for pauses:
95555678,,,12345*,,,5558888#,,,,,1
The real trick of this solution comes from using "forward-digits extra inband" in the dial-peer configuration. What this does is uses the number that appears in the destination-pattern in the ISDN call setup, then forwards any extra digits "inband" (ie as DTMF tones).
Using these two things we can then configure a working solution:
! First Diversion
num-exp 150 5555678,,,12345*,,,5558888#,,1
! Second Diversion
num-exp 151 5555678,,,12345*,,,5558889#,,1
! Third Diversion
num-exp 152 5555678,,,12345*,,,5558890#,,1
dial-peer voice 10 pots
destination-pattern 5555678
forward-digits extra inband
port 0/2/0:23
That's it. Simple!
Now the problem is. It appears that dial-peers can only forward 32 digits, so though this does work for the solution above, it will not work if we even wanted to add one more comma/pause. It appears to me (unless someone has a better idea) that the only way to send DTMF tones will be to create a TCL script.
Time to learn a bit about TCL I guess. Look out for part 2 sometime in there near future where I do just that.
Friday, August 15, 2008
Monday, August 4, 2008
Redundant CME Configuration
Recently I was required to configure a redundant CME solution.
The scenario is as follows:
Two routers each with a PRI connected, the Telco had
no restrictions as to which PRI could be used for voice calls into the site. Outbound calls would prefer the active CME router, with overflow being sent to the non-active CME router. I have tried to show the requirements in the following diagram.
If we break the configuration down, between the Telephony service, and H323 routing components, the configuration to meet the requirements is pretty straight forward.
Telephony service.
Pre version 4.0 CME redundancy was achieved by using HSRP between the two CME routers, however we can now configure the standby router address directly, this will then assign two "callmanager" addresses to the IP phones (this is similar to a CallManager group if we were using CUCM). In the device menu on the phone the addresses will be listed, with an indication showing which address is the current active address.
To do this the following command is entered on the router that will be the primary CME (as per the address listed as DHCP option 150 :
ip source 192.168.1.1 port 2000 secondary 192.168.1.2
on the secondary router, you can get by with listing only one address:
ip source 192.168.1.2 port 2000
At this point both routers will now be running the Telephony Service, and will accept phone registrations. The rest of the Telephony service will now be identical between the two routers. All call routing will be done via the Dial-peer configurations.
Outbound calls:
For simplification only one dial-peer will be configured.
The following dial-peer will send all traffic destined for 9T (using 9 as the PSTN access number) to the local PSTN voice-port. This dial-peer will be configured exactly the same on on both routers
dial-peer voice 9 pots
destination-pattern 9.T
port 0/0/0:23
If this port is unavailable for some reason due to either a fault, or no available channels, all outbound traffic should be sent to the standby router. Being a VOIP dial-peer all matched digits will be forwarded. The call will then match the PSTN dial-peer that has been configured on the standby router, as mentioned above.
dial-peer voice 91 voip
destination-pattern 9.T
preference 2
session target ipv4:192.168.1.2
Inbound Calls:
Inbound calls require a slightly trickier configuration, as we have to make sure that calls that are received on the standby router are forwarded to the active router, even though the standby router has the same ephone-dn's configured on it as the active router.
There a several ways this can be achieved, the first is to create a dial-peer for each DN and give this dial-peer as better preference than that of the ephone-dn's. Though this will work, it involves quite a bit of extra configuration should new ephones be added.
The method I decided on was to create two dial-peers that matched the digits received from the telco, the most preferred dial-peer will forward the call to the active router, without any translation. The second less preferred dial-peer will match the digits received from the telco, translate the received digits to those of the ephones, and then have itself configured as the dial-peer. This way inbound calls will only be received by the standby router destined for the ephone-dn's them selves if the active router is unavailable.
Hopefully the following configuration will "clarify" things.
First as this solution means that we cannot use the dial-plan configuration command, an inbound translation rule will need to be defined. For our example, the full e164 number is 450-2300 - 450-2399 mapping to extns 1300-1399
voice translation-rule 1
rule 1 /\^45023\(..$\)/ /1\1/
voice translation-profile pstnIN
translate called 1
This translation will need to be configured on both routers.
On the active router, the translation profile is applied to the default inbound pots dial-peer, and the default inbound voip dial-peer (this is required as the standby router is going to forward all digits)
dial-peer voice 1 pots
direct-inward-dial
incoming called-number .
translation-profile incoming pstnIN
port 0/0/0:23
dial-peer voice 1 voip
incoming called-number .
translation-profile incoming pstnIN
codec g711ulaw
no vad
On the standby router, similar dial-peers are configures, however this time the translation profile is not applied to the default pots dial-peer. Tow additional dial-peers are added to forward the inbound PSTN traffic to the active router as first preference, then back to itself as second preference, the number is then translated at this point to match the numbers that have been assigned to the ephones.
dial-peer voice 1 pots
direct-inward-dial
incoming called-number .
port 0/0/0:23
dial-peer voice 1 voip
incoming called-number .
translation-profile incoming pstnIN
codec g711ulaw
no vad
dial-peer voice 91 voip
destination-pattern 45023..
session target ipv4:192.168.1.1
dial-peer voice 91 voip
destination-pattern 45023...
preference 2
translation-profile outgoing pstnIN
session target ipv4:192.168.1.2
That is pretty much it.
Subscribe to:
Posts (Atom)
Posts
