CUCM 7.X – Rewrite Outbound CLI Presentation with Calling Party Transformation Masks

Posted on by
24

Problem :

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

Solution:
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:
  1. Device > Gateway
  2. Select your Gateway
  3. Select your E1/T1 Interface
  4. Under “Call Routing Information – Outbound Calls Uncheck “Use Device Pool Calling Party Transformation CSS”
  5. Choose “CLIRewrite” in Calling Party Transformation CSS Combo Box
  • Create your Transformation Mask:
  1. Call Routing > Transformation Pattern > Calling Party Transformation Pattern
  2. Click Add New
  3. Under Pattern enter the internal DN you wish to rewrite (Pattern matches like 28XX also work for matching multiple DN’s)
  4. 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
Advertisements

Cisco 827 – Configuring Bridge Mode

Posted on by
Reply

Use the Following config to configure your 827 into Bridge Mode :

!
version 12.1
no service single-slot-reload-enable
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname Bridge
!
logging rate-limit console 10 except errors
!
ip subnet-zero
no ip finger
!
no ip dhcp-client network-discovery
bridge crb
!
!
!
interface Ethernet0
no shutdown
no ip address
bridge-group 1
!
interface ATM0
no ip address
no shutdown
no ip mroute-cache
no atm ilmi-keepalive
pvc 8/35
encapsulation aal5snap
protocol ip inarp
!
dsl operating-mode itu-dmt
bridge-group 1
!
ip classless
no ip http server
!
bridge 1 protocol ieee
!
line con 0
transport input none
stopbits 1
line vty 0 4
scheduler max-task-time 5000
end
!

Cisco 7921 / WLC 4.2.130.0 / Cisco 1252 LWAPPS – Intermittent Wireless Voice Connectivity

Posted on by
Reply

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 4.2.130.0
  • 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:

  1. Moved to an external DHCP server – This rectified the DHCP TIMEOUT Issue, however the poor connectivity continued
  2. 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.
  3. I upgraded the 4404 controller code to 4.2.176.0 – This Appears to have Fixed the Issue.

Cisco IOS – Negating Terminal Commands

Posted on by
1

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.

1252 LWAPP – Buzzing Access Point

Posted on by
Reply

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.

Thanks Jeremy!