Use your widget sidebars in the admin Design tab to change this little blurb here. Add the text widget to the Blurb Sidebar!
Posted: February 22nd, 2013 | Author: Matthew Berry | Filed under: Blog, Featured | Tags: Blacklist, Call Blocking, CUCM | No Comments »
Earlier this week, one of my customers asked for a way to blacklist numbers in CUCM. In CUCM 7.x and earlier releases this wasn’t possible. The best option an engineer could offer was to push the blacklisting to the PSTN. Even then, the gateway had to use SIP/H.323 (no MGCP) and the scalability was an issue (limit 15 rules).
In CUCM 8.x, Cisco released an option in translation patterns called “Route Next Hop by Calling Party Number.” Leveraging this capability, translation patterns can be transformed into blacklist entries.
While the procedure below closely follows a whitepaper posted in the Cisco Support Community, I have modified the process to route these blacklisted calls to a Unity Connection call handler. The benefit of this design is that the blacklisted callers, naughty as they may be, are informed of their “fall from grace” before being disconnected. Without this announcement, the blocked caller might assume that there is a telco problem and try again later.
Call Flow Diagram
This diagram illustrates the call flow through CUCM and UCXN.
Read the rest of this entry »
Posted: February 17th, 2011 | Author: Matthew Berry | Filed under: Blog | Tags: Bogen, CUCM, Integration, Paging, TAMB2 | 1 Comment »
How to integrate a Bogen TAMB2 with CUCM using the H.323 protocol
A quick Google search showed revealed that there was lacking a step-by-step guide on Bogen TAMB2 setup and integration. Since there’s a deficiency, I’ll make my contribution to the technical ghetto today.
Step One: CUCM to Gateway
For starters, you will need a way to activate the paging unit when a page is initiated. Because H.323 is far more granular than MGCP, I’ll be using H.323 in this example.
Create a route pattern in CUCM (e.g. *7222) that points to the local gateway’s route list. This route list includes a route group, “Patagonia Local” (for example), that contains the H.323 gateway with the loopback’s IP address of 10.254.254.50.
Assuming all calling search spaces and partitions are setup correctly, when a user calls *7222 they will sent to the gateway.
Step Two: H.323 Gateway Configuration
For the purposes of this example, I will be including a base H.323 configuration. This basic configuration that will satisfy the needs of this example:
voice call send-alert
voice rtp send-recv
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
signaling forward unconditional
fax protocol pass-through g711ulaw
no ip address trusted authenticate
## This is a new command to the IOS 15 train. You must modify this to address the new toll-fraud prevention app.
## Make sure to hit enter after this command. If you cut/paste it won’t take. You must confirm.
h225 display-ie ccm-compatible
call preserve limit-media-detection
modem passthrough nse codec g711ulaw
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
voice class h323 1
h225 timeout tcp establish 3
## Bind H.323 to a particular interface on the router
interface Loopback 0
ip address 10.254.254.50 255.255.255.255
h323-gateway voip interface
h323-gateway voip bind srcaddr 10.254.254.50
## Not used in this example, but you ALWAYS created an inbound POTS dial-peer – ALWAYS
dial-peer voice 1 pots
incoming called-number .
## To address setup parameters for outbound paging call coming from CUCM
dial-peer voice 2 voip
incoming called-number .
voice-class codec 1
voice-class h323 1
dtmf-relay rtp-nte h245-signal h245-alphanumeric
## Defines this port for outbound paging and adjusts attenuation
output attenuation -3
description Bogen TAMB2 Overhead Paging
## Provides dial-peer matching from CUCM and sends it out the paging port
dial-peer voice 10 pots
description Bogen TAMB2 Overhead Paging
Step Three: Connect Bogen Unit
Depending on whether you’re using an VIC3-4FXO card or an EVM module, you’ll be exiting the router on either a silver satin with RJ-11 ends or an amphenol to 66 block. Either way, you’ll need to send a twisted pair to the Bogen unit and connect them on the STATION/TRUNK posts aptly named T and R (tip and ring).
After connecting to the Bogen, you’re on your own. Depending on the intercom system, you might need to run the Bogen output through an impedance-matching transformer that increases the voltage in the amp’s input. Otherwise, you’ll be paging successfully, but users will only hear a faint sound coming from the paging speakers.
Bogen has a great wiring diagram for their TAMB2 unit on their website. For ease of use, I’m going to link to it below.
Bogen TAMB2 Manual (PDF – Right click, “Save as”)
That’s it! It’s pretty straight-forward without too many tricks. Just make sure you order the right parts, have an AC power unit, and include the necessary transformer if required.
Posted: February 7th, 2011 | Author: Matthew Berry | Filed under: Blog, Cisco Reference | Tags: Cisco, CUCM, IP Phone, Phone | 3 Comments »
This month, I have been building a lab in my downstairs office. I purchased the essentials: router, switch, and a few phones. Today, I received a used 7970 IP Phone in the mail.
It felt like Christmas. That is, if I celebrated Christmas (that’s another story). Anyway, I opened the box, pulled out my like-new phone, and plugged her into my 3550 POE switch.
As the phone was powering up, my heart sank (well, it was a bit less dramatic than that). The screen was very dim. So I went into Settings > User Preferences > Brightness to make some adjustments. To my shock, I couldn’t make the screen any brighter that about 20%.
Then I came across this interesting tidbit thanks to Big Brother Google:
The Cisco Unified IP Phones 7970G and 7971G-GE have `low power’ modes, in which the phones operate at reduced screen brightness.
A Cisco IEEE+CDP powered device, such as a Cisco IP phone 7970G, comes up in low power mode (6.3W) and transmits a Cisco Discovery Protocol (CDP) message with an inline power (ILP) type length value (TLV) that informs the Power Source Equipment (PSE) of the actual power required by the device. If the power is less than the default 15.4W, the PSE acknowledges the request with its available power and modifies the PSEs power budget. If the requesting powered device exceeds the power budget for the line card or switch, the port is either powered down, or the port remains in low power mode (7W).
This management scheme is implemented in order to provide backward compatibility and investment protection to the installed base of Cisco Catalyst pre-standard Power over Ethernet capable line cards and switches. Cisco IP phones are power efficient and require 6.3W maximum power as reflected within the pre-standard Power over Ethernet implementation. - SOURCE
Fortunately, I had an extra power supply that I could use. So basically, this model of phone can use POE, only with a reduced set of features. If you want to use the full capability of this phone type for a lab environment, you’ll need to purchase a CP-PWR-CUBE-3.
Posted: January 27th, 2011 | Author: Matthew Berry | Filed under: Blog, Cisco Reference | Tags: CUCM, interesting, Reference, security, trust | No Comments »
For users who upgrade CUCM from 4.x to 7.x or 8.x, you’ll notice a new indicator below registered devices:
For H.323 gateways, you’ll see a similar (but different) message:
These indicators denote whether the device can support Cisco criteria for secure signaling and media. The CUCM 7.1(3) Release Notes explain what these messages mean. In order to be classified as “trusted”, a device must meet the following criteria:
- Are all devices that are on the call trusted?
- Is the signaling secure (authenticated and encrypted)?
- Is the media secure?
For calls that involve a device that is not trusted, regardless of signaling and media security, the overall status of the call will stay unsecure, and the phone will not display the Lock icon. For example, if you include an untrusted device in a conference, the system considers its call leg, as well as the conference itself, to be unsecure.
A Trusted Device represents a Cisco device or a third-party device that has passed Cisco security criteria for trusted connections. This includes, but is not limited to, signaling/media encryption, platform hardening, and assurance. If a device is trusted, a Security icon displays, and a secure tone plays on supported devices. Also, the device may provide other features or indicators that are related to secure calls. – CUCM 7.1(3) Release Notes
Posted: January 26th, 2011 | Author: Matthew Berry | Filed under: Blog, Cisco Reference | Tags: Cisco, CUCM, Networking, Reference, SRND, UC, UCS | No Comments »
Having finished the CCIE Voice v3 lab, I’ve turned to the CUCM 8.x SRND to look for the latest updates. Here are just a few notes I gathered while on the plane. More to come!
- Limit the number of devices per VLAN to 512, roughly equivalent to two Class C subnets (e.g. 10.4.100.0/23)
- Enable root guard or BPDU guard on all access ports to prevent a rouge switch from taking the Spanning Tree root position. Such an action causes STP re-convergence events and could affect network traffic flows.
- Best practice remains to leave the Layer 2/3 demarcation on the access switches. This is a best practice move from the old standard that placed the demarcation on the distribution switches. With this configuration, Hot Standby Router Protocol (HSRP) or Gateway Load Balancing Protocol (GLBP) virtual gateway addresses are no longer necessary.
- The most apparent advantages to the Layer 3 Access model are: (1) improved convergence, (2) simplified multicast configuration, (3) dynamic traffic load balancing, (4) single control plane, (5) and a single set of troubleshooting tools (for example, ping and traceroute).
- It’s a good idea to use the passive-interface command on all interfaces facing the access layer in order to prevent routing adjacencies to be advertised out through these interfaces. This constitutes a small, but present and unnecessary, CPU drain on the access switches.
- Voice marking for QoS remains at CoS 5 (IP Precedence 5, PHB EF, or DSCP 46).
- Videoconferencing marking for QoS remains at CoS 4 (IP Precedence 4, PHB AF41, or DSCP 34).
- Call signaling for voice and videoconferencing is now classified as CoS 3 (IP Precedence 3, PHB CS3, or DSCP 24) but was previously classified as PHB AF31 or DSCP 26.
Virtual Unified Communications with Cisco UCS
- With the emergence of UC on UCS, there are three virtual switching platforms available for UC applications running on top of VMware: (1) Local VMware vSwitch, (2) Distributed VMware vSwitch, (3) and the Nexus 1000V switch. The Nexus 1000V requires the Enterprise Plus Edition of the VMware ESXi 4.0.
- The virtual machines send traffic to the software switch (options listed above) and then on to the physical UCS Fabric Interconnect Switch (UCS 6100 Series) through its blade server’s Network Adapter and Fabric Extender.
- The UCS 6100 carries both the IP and fibre channel SAN traffic via Fibre Channel over Ethernet (FCoE) on a single wire. IP traffic is sent onward to an IP switch (Catalyst/Nexus) and SAN traffic is sent to a Fibre Channel SAN switch (e.g. Cisco MDS)
- By default, the UCS 6100 creates a fibre-channel priority QoS class for traffic destined for the SAN Switch. This FC QoS class has no drop and marks traffic as CoS 3.
- VMware local/distributed vSwitches and the UCS 6100 cannot map L3 DSCP values to L2 CoS values. Traffic can only be prioritized or de-prioritized within the UCS 6100 based on L2 CoS only.
- UC applications mark L3 DSCP values only. In order to make sure UC on UCS traffic is classified appropriately, you must configure all traffic originating from a blade server Network Adapter to be marked with a single L2 CoS value.
- Nexus 1000V software switch has the ability to map L3 DSCP values to L2 CoS values, and vice versa, like traditional Cisco physical switches such as the Catalyst Series Switches.