This is a repost of a question asked a little while ago. Thought I'd give it one more try in the forum to see if anyone can share their opinions. If not, the spam stops here :)
In lab testing a while back, I noticed a strange quirk that I wanted to throw out here to see if I'm on the right page for Caller ID. It's fairly simple, but I remember in lab tests it was not working the way I had planned.
Basically the scenario is two buildings side by side with 200+ phones in one building deployed, and about 20 more phone deployed in the building next door. The two buildings are connected via MMF, and all the phones from B2 register with CCM over the MMF to the head end. In the head end there are two PRI's off a 3640 for PSTN access.
For 911 purposes the head end building needs to display 555-2700 out to the PSTN. The 2nd building needs to display 555-2800 out to the PSTN so that Emergency responds to the right building.
My plan was to configure the CCM H.323 gateway's Caller ID field with 555XXXX first off. Next the plan was to have all phones in the head end building have an external phone mask or outgoing caller ID pattern programmed in as 555-2700. And in the second building those phones would be programmed with 555-2800.
The theory would be that the Caller ID information from the phone would pass out through the gateway with either 555-2800 or 555-2700 depending which phone made the call. The problem I had a ways back in the lab was that this was not working correctly for some reason, unfortunately without having the gear in front of me at the moment I can't get any more specific on what was happening.
Am I off base on this theory, or can anyone shed some light on the topic? I'd be interested to here any production situation examples.
The usual way to do this with CallManager is to create two sets of route patterns but put them in different partitions. Then set the Calling Party transformation to the correct number on the route pattern page (or the route details if using route groups/lists). Remember that the Route Details page overides the route pattern transformations.
Also, you will need to set the Calling Search spaces up so that the phones in building A get their route pattern/transformation and the phones in building B get theirs.
9.@ Partion-BuildingA - Calling Party Transform 5552700
9.@ Partion-BuildingB - Calling Party Transform 5552800
CSS-BuildingA - includes Partion-BuildingA (but not Partion-BuildingB)
CSS-BuildingB - includes Partion-BuildingB (but not Partiion-BuildingA)
This is no different from setting up normal centralised call processing - just the buildings are a lot closed than normal!
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...