Tag Archive - CUCM

Bogen TAMB2 Overheard Paging CUCM Integration

February 17, 2011 in Blog with Comments Off

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.
h323
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 .
direct-inward-dial
## 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
no vad
## Defines this port for outbound paging and adjusts attenuation
voice-port 1/0/8
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
destination-pattern *7222
port 1/0/8

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”)

Finis

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.

Low Power Mode and 7970 Phones

February 7, 2011 in Blog, Cisco Reference with 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.

Device is not Trusted

January 27, 2011 in Blog, Cisco Reference with Comments Off

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:

  1. Are all devices that are on the call trusted?
  2. Is the signaling secure (authenticated and encrypted)?
  3. 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

CUCM 8.X SRND – UC Networking

January 26, 2011 in Blog, Cisco Reference with Comments Off

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!

    Network Infrastructure

  • 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.

CUCM 7.0 Port List Reference

February 9, 2010 in Blog with Comments Off

Attached to this post if the CUCM 7.0 port list reference sheet.  If you ever wanted to know what port is used for attendant console (1103-1129 TCP), you can now find this and plenty of other port numbers.  Enjoy!  Yah, right.

CUCM 7.0 Port List (PDF – Right click, “Save As”)