How to channelise PRI circuits with MGCP

MGCP doesn't properly support channelised E1 or T1 circuits, in that you can only specify circuits that have the full 30 or 23 channels respectively, rather than an E1 that only has 8 channels from the TELCO.

You can use the following guide from Cisco to get channelised PRI to work in CallManager, simply by creating a full T1 or E1 with the full amount of channels, and then use the guide to busy out the channels that aren't required/available from the TELCO. You can also use the same feature to disable individual channels when troubleshooting:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a008076f8d2.shtml

Beware users of UK Numbering Plan 27.0 !

If you're using UKNP 27.0 with CallManager 4.X then beware that this may give strange behaviour...

This Dial Plan was released primarily to add 075xx mobile numbers to the list of supported E.164 numbers of the dial plan; but has unfortunately exhibited strange issues with dialling out.

If you experience issues with ISDN Q.931 messages being returned on the gateway with either "No bearer channel available" or "Number not obtainable" then you may find that the dial plan is causing the gateway to send out incorrectly formatted Plan and Type fields. This can be remedied in two ways:

1) Change the "Called Party IE Number Type", "Calling Party IE Number Type" and both Plans under the Outbound Calls settings section of Gateway configuration page of CallManager to "Unknown" instead of "Cisco CallManager".

2) Add the following line to the serial0/0/0:15 interface:

isdn map .* plan unknown type unknown

As far as i'm aware, this patch has now been recalled and Cisco are working on a replacement.

Been a jettin'

Howdo folks,

Not many posts as of recent as i’ve been so so busy with customer projects. Managed to get everything installed up in Scotland (300 user phone system) and also off to Nottingham to Demonstrate integration between a DPNSS Siemens/Octel PBX system with a Westell converter and Cisco CallManager. Which was nice…

Other than that hoorah the sun is shining, it’s almost the weekend, and we won at football (15-14, close match!). Oh and there’s talk of a company car soon again which’d be rather nice.
Off to Northampton again tomorrow, then a nice relaxing weekend doing some studying.

The tale of the mysterious DN numbers...

Today i’m having to deal with a bizzarre problem for a customer. They want Outlook Dialling using TAPI. Dead easy!
Or not.

This person who wants Outlook Dialling is finding that 37 CtiParkDevices are appearing in their list of Cisco Lines to Dial from, with DN numbers that don’t exist in CallManager (and never have done!). The icing on the cake is that the SEP line that they’re looking for to do the dialling is not in the list.
If I run Phone.exe (from www.julmar.com/samples) the SEP line appears in the list and therefore demonstrates that: 1) TAPI is installed correctly, 2) All passwords and whatnot are configured correctly, and 3) The customer is not going mad.

WTF. If I fix it i’ll stick it up here.

When the CallManager went Pete Tong...

ARGH.

Well i’m on a customer site and the most bizarre things are happening. Essentially three different engineers have looked at the problem, and spent hours on it, to find that it’s still broken. We found that the Callmanager service was only running on the Subscriber so we kick started this off - but to no avail. Finally after a Publisher restart did the problem go away. However the other site that we added before this one in London is exhibiting the same problem, and wasn’t fixed by the reboot. Very strange…

Essentially it’s a dialling problem to do with picking the right route pattern. Whoever installed the original design in this centralised Callmanager cluster is just an idiot - where logged off phones have the Unrestricted Call search space on them so you can call anywhere from any logged off phone (Toll fraud anyone?), whereas when you log on, that’s where the restrictions come on…

Basically it’s a failed attempt to get the route pattern design correct so that employees can move sites and use the local gateway instead of their own gateway back at ‘home base’ ergo getting cheaper local calls. It’s all a very woolly subject that needs a darn good article writing about it. Watch this space.

Oh and i’m tired of travelling - in London at mo, Scotland Friday. Eurgh.