You want your MGCP controlled E1/T1 to present a single outbound CLI for a group of DN’s that is different from their individual DID’s. You also want all other DN’s to present as normal.
- You could hardset the Caller ID DN field on the E1 under “Call Routing Information – Outbound Calls” – This will overwrite all DN’s not just the ones you want
- You could adjust the “External Phone Number Mask” on the DN. – This works but it will also change the phone display and can have AAR Implications
- You could duplicate your dialplan in a seperate partition with new CSS’s and Route lists. Overwrite the CLI at the Route List – This is just yuck and doesn’t scale
Transformation Patterns to the Rescue! A Transformation Pattern will allow you to adjust the Calling Party number when it hits the gateway conditionally based on the original internal calling party number.
- Create a Partition called CLIRewrite
- Create a CSS called CLIRewrite that looks at Partition CLIRewrite
- Configure your MGCP Gateway:
- Device > Gateway
- Select your Gateway
- Select your E1/T1 Interface
- Under “Call Routing Information – Outbound Calls Uncheck “Use Device Pool Calling Party Transformation CSS”
- Choose “CLIRewrite” in Calling Party Transformation CSS Combo Box
- Create your Transformation Mask:
- Call Routing > Transformation Pattern > Calling Party Transformation Pattern
- Click Add New
- Under Pattern enter the internal DN you wish to rewrite (Pattern matches like 28XX also work for matching multiple DN’s)
- Under Calling Party Transformation Mask enter the full number you wish to present out your E1
- Reset your MGCP gateway under Devices>Gateways
- I also had to do a “no mgcp” and then “mgcp” on the gateway itself
- Make a test call to your mobile phone to see the re-written number
Use the Following config to configure your 827 into Bridge Mode :
no service single-slot-reload-enable
no service pad
service timestamps debug uptime
service timestamps log uptime
logging rate-limit console 10 except errors
no ip finger
no ip dhcp-client network-discovery
no ip address
no ip address
no ip mroute-cache
no atm ilmi-keepalive
protocol ip inarp
dsl operating-mode itu-dmt
no ip http server
bridge 1 protocol ieee
line con 0
transport input none
line vty 0 4
scheduler max-task-time 5000
So you want to access the CLI huh?
Well it can be accessed through the web interface by appending /exec to the URL.
When authenticating l2tp-ipsec users against the local database on an ASA, you must use the mschap keyword when creating the user accounts:
username l2tp password secret mschap
I was working on a CUWN deployment in a healthcare environment with the following Charcteristics :
- 7921 Phone Handsets
- A Cisco 4404 Wireless Lan Controller running controller code 126.96.36.199
- 1252 Light weight Access-points powered by 15.4W POE ports on a Catalyst 3750
- Internal DHCP Server was being used.
The Site also had existing 1242 AP’s connected to the controller, however these where geographically seperate from the new deployment.
Everything was installed, configured and appeared to be running correctly, until after several days the 7921’s were having issues connecting. The following Symptoms were displayed:
- The 7921 would display “DHCP TIMEOUT” on the screen and go into a loop
- Not all of the AP’s would display the problem at the same time.
- If you connected when associated with a functional AP and then roamed to a non-funtional AP network connectivity was extremly flaky.
- The 1242 AP’s at the other end of the site were unaffected.
Once a 1252 was affected the only way to rectify the issue was to perform one of the following:
- Perform a factory reset from the WCS by selecting “Clear AP Config”
- Disabling and Re-enabling the WLAN.
It should be noted that merly rebooting the AP would not fix the issue.
OK, time to call TAC.
With TAC’s assistance I took the following action:
- Moved to an external DHCP server – This rectified the DHCP TIMEOUT Issue, however the poor connectivity continued
- I was using dot1x authentication with PEAP on the phones. – I moved to WPA/WPA2 with a Pre-shared Key for the voice WLAN. Didn’t fix the issue, however I was impressed with how much quicker association and Authentication took place.
- I upgraded the 4404 controller code to 188.8.131.52 – This Appears to have Fixed the Issue.
I always found it odd that I couldn’t negate terminal commands in IOS like other commands.
Eg; no Terminal Monitor
I just assumed it wasn’t there, until I saw another engineer execute to disable term mon.
Router# terminal no monitor
It seems in IOS the terminal commands are special in that they require the terminal key word before the no keyword to negate sub-commands.
I have been involved with a CUWN deployment using 1252 AP’s in a healthcare environment. Several of the Access-points were making buzzing noises whilst operating but for all intents and purposes were functioning ok.
I knew these units probably needed to be replaced but I hadn’t had the time to report the issue to TAC and get a replacement.
Well apparently I’m not alone. Jeremy at ciscoblog.com has mentioned the same issue showing up in a TAC Field notice. There is even a web tool for checking your serial numbers if they are affected.
The Field notice mentions issues with radio communication whilst buzzing, however I haven’t experienced these issues.