Cisco Unified Communication Manager History

1994: Multimedia Manager

Started in 1994 by Selsius Systems, was called Multimedia Manager 1.0. It was developed in HP-UX using the SDL-88 programming language but was intended to run on Microsoft Windows NT 3.51. Each Multimedia Manager server served only as a call signaling source and destination. Multimedia Manager 1.0 managed connections by sending commands to network hubs, which contained the matrix for the video connections. Each hub contained 12 hybrid Ethernet/time-division multiplexing (TDM) ports, each one serving either a PC running videoconferencing software or a sub-hub that managed four PRI interfaces for calls across the PSTN. The hubs could be chained using hybrid Ethernet/TDM trunks.

1997: Selsius-CallManager 1.0

In 1997, it was renamed Selsius-CallManager and changed from a video conferencing solution to a system designed to route voice calls over an IP network. It was during this time that support for the Skinny Client Control Protocol (SCCP) and Skinny Gateway Control Protocol (SGCP) were added. Still running under Windows NT, to ensure that the code base could continue to grow, the pure SDL code was ported into a C++ SDL application engine offering same functionality as the previous pure SDL implementation.

1998: Selsius-CallManager 2.0

By 1998 Selsius-CallManager 2.0 had been released. Selsius Systems was later that year acquired by Cisco Systems, Inc..

2000: Cisco CallManager 3.0

CallManager underwent a large design and engineering effort to enable scalability and redundancy to the software. Clustering was introduced at this time and [MGCP] support was added.

2001: Cisco CallManager 3.1

This CallManager release was built off of the 3.0 release. This version supported more gateway devices, IP phone devices and added more enhancements and features. The following features and enhancements were introduced in version 3.1.

• Music on hold (MOH)
• Support for digital interfaces on [MGCP] gateways
• Added support for XML and HTML applications in Cisco IP Phones
• Extension mobility
• Call preservation between IP phones and MGCP gateways
• TAPI (Telephony Application Programming Interface) is introduced

2001: Cisco CallManager 3.2Cisco CallManager version 3.2 provides a scalable, distributable, and highly available enterprise IP telephony call-processing solution. Multiple Cisco CallManager servers are clustered and managed as a single entity. The following features and enhancements were added in version 3.2:

• Client user interface internationalization and localization
• Auto-answer at destination IP phone’s speaker, enabling hands-free intercom service
• Host-based Intrusion Detection System (IDS) certification
• Virus checker certification
• H.323 performance improvement, enabling 1000 H.323 calls per server in a cluster
• Cisco Analog Telephone Adapter, ATA-186 integration
• MGCP protocol extensions, including T1/E1 PRI and T1-CAS (E&M)
• Drop last conference party
• WebAttendant consult transfer
• Message Waiting Indication (MWI) enhancements
• Platform includes: Media Convergence Server (MCS), Integrated Communications Server (ICS-7750), and Selected third-party servers

2002: Cisco CallManager 3.3

Building from the previous release, in [2002] Cisco added even more enhancements to version 3.3. Many bug fixes were introduced as well. Some of the enhancements were.

• QSIG support
• IP Manager/Assistant (IPMA) is introduced
• Scalability to 30,000 phones per cluster
• Improved H.323 features and support
• Support for multiple H.323 gatekeepers
• Configurable call waiting tones
• Many bug fixes

2004: Cisco CallManager 4.0

In 2004 Cisco made a large scale release with CallManager 4.0. Customers were pleased with a large amount of new features. Previously IP phones were restricted to only 2 calls per any given line appearance. This caveat was eliminated and IP phones could now have a user configurable maximum (up to 200) number of calls per line appearance.

Some new features and enhancements added during this release were:

• Hunt group
• Privacy for shared lines
• Call barge
• Improved security with media encryption between phones
• Multi Level Administration (MLA) allowed delegated administration
• Direct transfer allowed a user to select two calls from the same line and connect them together
• Call join allowed users to select several calls from a line and conference them together
• Additional QSIG features added
• Many bug fixes

This version (as well as all Windows 2000-based versions of CallManager (4.0, 4.1 and 4.2) are End of Life (announcement will be made November 15, 2007, with an End of Sale date of May, 2008).

2004: Cisco CallManager 4.1

In a short time after the release of version 4.0, Cisco released a minor upgrade to 4.1. This version focused on improved stability and support for even more features. Several utility tools were added as well. Additionally, some of the new features of CCM 4.0 include greatly enhanced conference calling features, enhanced Client Matter Code (CMC) and Forced Account Code (FAC), Multilevel Precedence and Preemption (MLPP) and Malicious Call Identification (MCID). CallManager 4.1 also enhances the encryption capabilities first introduced in CallManager 4.0. When using Cisco Phones 7940/7960/7970 or 7971 it is now possible to encrypt signaling as well as voice traffic itself.

• More QSIG enhancements
• Dialed number analyzer (DNA) is a tool used to analyze how dialed strings route
• Forced authorization codes (FAC)
• Time of day routing
• Client matter codes (CMC)
• Malicious Call Identification (MCID)
• Increased security through addition support for encryption

2006: Cisco Unified CallManager 4.2

CallManager 4.2 was released in parallel with CallManager 5.0 on Monday the 6th of March [2006]. At the same time Cisco re branded the product “Cisco Unified CallManager”; they also added the Unified tag to all of their Voice and Video offerings (i.e. Cisco Unified Contact Center, Cisco Unified MeetingPlace).

Cisco Unified CallManager 4.2 runs on Windows 2000 and includes new PABX features over 4.1(3) (namely logging into hunt groups and call-forward on no coverage (so, if you forward a line to a hunt group, and the hunt group is unavailable or busy, you can forward calls somewhere else); Also introduced was Call Forward Unregistered, so that if you called a remote site, but the WAN link was down, you could automatically forward that call to the PSTN. This version does not include SIP end-point support.

2007: Cisco Unified CallManager 4.3

CallManager 4.3 runs on Windows 2003.

2006: Cisco Unified CallManager 5.0

CallManager 5.0 was released in parallel with CallManager 4.2 on Monday 6 March 2006. Cisco Unified CallManager 5.0 is Linux based and for the first time can use Session Initiation Protocol (SIP) to IP end-points; apart from the addition of SIP it is feature compatible with CallManager 4.1(3). CallManager 5.0 servers are being sold as pre-installed appliances. Cisco Unified CallManager 5.0 can also be installed on compatible MCS servers and Cisco approved HP and IBM servers. Users of CallManager 4.x can upgrade to Unified CallManager 5.0 and keep their current Databases by having another server on the LAN with a shared drive available during the upgrade process. Unified CallManager 5.0 comes with an introduction of a new licensing structure that is based on device-weights. A license file must be acquired and installed before any services can be activated.

2007: Cisco Unified CallManager 5.1

This version is essentially bug fixes for Communications Manager 5.0.

2007: Cisco Unified Communications Manager 6.0

Cisco renamed the product to Unified Communications Manager. Version 6 was supposed to merge all features of the Linux appliance (SIP support and licensing requirements) between the Linux platform and Windows version. The released version of Unified Communications Manager will not support the Windows platform.

This version added an intercom feature between endpoints (station-to-station only), and integrated Mobility Manager (single number reach to multiple destinations, IP Phone, Cell Phone, etc.).

This version utilizes a slightly different licensing model from that found in 5.X. First off, CUCM 6.0 requires service licenses (for Communications Manager, etc.) and comes with a ’starter’ license for a single node and 50 device weights (about 10 phones), and will install natively on VMWare for lab purposes; in addition it requires a ‘feature license’ to activate the CallManager feature.

NOTE: Upgrades to Communications Manager 6.X from Communications Manager 5.X require the acquisition of a new license; proceeding with the upgrade without acquiring this license will result in a non-functional system.

Also released was Cisco Unified Communications Manager Business Edition (CUCMBE, aka Cucumber), which places Cisco Unified Communications Manager 6.0 and Cisco Unity Connections 2.0 (Voicemail) on the same server (an MCS 7828 with dual 250GB hard drives and 6GB of RAM).

Version 6.1 was released in January 2008 and contained bug fixes.

2007: Cisco Unified Communications Manager 6.1

The 6.1 release of Cisco Unified Communications Manager offers the following performance improvements on the infrastructure side, enabling a more a robust platform. See more information reference below.

2008: Cisco Unified Communications Manager 7.0

Released in September 2008, this version was originally slated to be available in both Windows and Appliance models. However Cisco have since stated that OS Independence will not be a feature of any version of CallManager after 4.3. Cisco refers to their entire suite of products to be released in 2008 as “System 7″; major updates are expected to Presence Server and Client at the same time as Communications Manager 7.0 is released.

The database will be standardized using IBM Informix (Microsoft SQL will not appear in any version after 4.3).

References:

» Cisco IPT

» Cisco Unified Communications Manager (CallManager)

» CUCM Wikipedia

» Cisco CallManager 3.1

» Cisco CallManager 3.2

» Cisco CallManager 3.3

» Cisco CallManager 4.0

» Cisco CallManager 4.1

» Cisco Unified CallManager 4.2

» Cisco Unified CallManager 4.3

» Cisco Unified CallManager 5.0

» Cisco Unified CallManager 5.1

» Cisco Unified Communications Manager 6.0

» Cisco Unified Communications Manager 6.1

» Cisco Unified Communications Manager 7.0

Filed under: Uncategorized

Updated CCSP Track

Here’s the new and updated track for the CCSP

Reference:

» What’s New to CCSP

Filed under: » Exam, » Tech Life

TCP/IP and TCPdump Quick Reference Guide from SANS

This is a quick reference guide of the TCP/IP headers created by SANS. Helps when decoding packets captured by tcpdump.

Reference:

» TCP/IP and TCPdump Quick Reference Guide (pdf)

Filed under: » Networking

Troubleshooting for 10/100/1000 Mbps NICs Autonegotiation

Just a quick note:

Reference:

Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues

PDF copy from Cisco

Filed under: Uncategorized

Cisco and Juniper DSU Compatibility Mode

Cisco DS3(T3) DSu Compatibility Mode Option

• Mode 0 : Digital Link DSU (DL3100) [default]
• Mode 1 : Kentrox DSU
• Mode 2 : Larscom DSU
• Mode 3 : Adtran T2SU 300
• Mode 4 : HDM 2182

Juniper DS3(T3) DSU Compatibility Mode Option

• None
• Larscom (Mode 2)
• Kentrox
• Digital-Link (Mode 0)

Juniper References:
» Interfaces Monitoring and Troubleshooting (T1/E1, T3(DS3)/E3, FE, GE, MLPPP)
» Monitoring T3 and E3 Interfaces
» Configuring T3 and E3 Interfaces
» Juniper Show Interface Commands

Cisco References:
» Cisco 3700 DS3 DSU mode option
» Configuring the 6E3 Line Card

Filed under: » WAN

Ethernet Protocol Overhead Notes

Found this Ethernet info, another note to remember:

Ethernet frame format:

• 6 byte dest addr
• 6 byte src addr
• [4 byte optional 802.1q VLAN Tag]
• 2 byte length/type
• 46-1500 byte data (payload)
• 4 byte CRC

Ethernet overhead bytes:
12 gap + 8 preamble + 14 header + 4 trailer = 38 bytes/packet w/o 802.1q
12 gap + 8 preamble + 18 header + 4 trailer = 42 bytes/packet with 802.1q

Ethernet Payload data rates are thus:
1500/(38+1500) = 97.5293 % w/o 802.1q tags
1500/(42+1500) = 97.2763 % with 802.1q tags

TCP over Ethernet:
Assuming no header compression (e.g. not PPP)
Add 20 IPv4 header or 40 IPv6 header (no options)
Add 20 TCP header
Add 12 bytes optional TCP timestamps
Max TCP Payload data rates over ethernet are thus:
(1500-40)/(38+1500) = 94.9285 % IPv4, minimal headers
(1500-52)/(38+1500) = 94.1482 % IPv4, TCP timestamps
(1500-52)/(42+1500) = 93.9040 % 802.1q, IPv4, TCP timestamps
(1500-60)/(38+1500) = 93.6281 % IPv6, minimal headers
(1500-72)/(38+1500) = 92.8479 % IPv6, TCP timestamps
(1500-72)/(42+1500) = 92.6070 % 802.1q, IPv6, ICP timestamps

UDP over Ethernet:
Add 20 IPv4 header or 40 IPv6 header (no options)
Add 8 UDP header
Max UDP Payload data rates over ethernet are thus:
(1500-28)/(38+1500) = 95.7087 % IPv4
(1500-28)/(42+1500) = 95.4604 % 802.1q, IPv4
(1500-48)/(38+1500) = 94.4083 % IPv6
(1500-48)/(42+1500) = 94.1634 % 802.1q, IPv6

Notes:

1. 48-bit (6 byte) ethernet address have a 24-bit “Organizationally Unique Identifier” (OUI) assigned by IEEE + a 24-bit number assigned by the vendor.
2. The minimum ethernet payload (data field) is 46 bytes which makes a 64 byte ethernet packet including header and CRC.
3. The maximum ethernet payload (data field) is 1500 bytes which makes a 1518 byte ethernet packet including header and CRC. When 802.1q added an optional 4-byte VLAN Tag Header, they extended the allowed maximum frame size to 1522 bytes (22 byte header+CRC).
4. The bit speed of 100 Mbps ethernet on the wire/fiber is actually 125 Mbps due to 4B/5B encoding. Every four data bits gets mapped to one of 16 5-bit symbols. This leaves 16 non-data symbols. This encoding came from FDDI.
5. The original Ethernet II spec had a two byte type field which 802.3 changed to a length field, and later a length/type field depending on use: values 1536 and over are types, under 1536 lengths.

Reference:

» Protocol Overhead

Filed under: » Networking

How to install the MS Loopback adapter in Windows XP

A quick note on how to install a MS loopback adapter.

The Microsoft Loopback adapter is a testing tool for a virtual network environment where network access is not available. Also, you must use the Loopback adapter if there are conflicts with a network adapter or with a network adapter driver. You can bind network clients, protocols, and other network configuration items to the Loopback adapter, and you can install the network adapter driver or network adapter later while retaining the network configuration information. You can also install the Loopback adapter during the unattended installation process.

To manually install the Microsoft Loopback adapter in Windows XP, follow these steps:

1.	Click Start, and then click Control Panel.
2.	If you are in Classic view, click Switch to Category View under Control Panel in the left pane.
3.	Double-click Printers and Other Hardware, and then click Next.
4.	Under See Also in the left pane, click Add Hardware,and then click Next.
5.	Click Yes, I have already connected the hardware, and then click Next.
6.	At the bottom of the list, click Add a new hardware device, and then click Next.
7.	Click Install the hardware that I manually select from a list, and then click Next.
8.	Click Network adapters, and then click Next.
9.	In the Manufacturer box, click Microsoft.
10.	In the Network Adapter box, click Microsoft Loopback Adapter, and then click Next.
11.	Click Finish.

After the adapter is installed successfully, you can manually configure its options, as with any other adapter. If the TCP/IP properties are configured to use DHCP, the adapter will eventually use an autonet address (169.254.x.x/16) because the adapter is not actually connected to any physical media.

Note By default, TCP/IP properties are configured to use DHCP.

Reference:
» How to install the MS Loopback adapter in Windows XP

Filed under: » Microsoft

IP Telephony Endpoints

Major IP Telephony Endpoints (my quick notes)

» Analog Gateways
» Cisco Unified IP Phones
» Software-Based Endpoints
» Wireless Endpoints
» Cisco IP Conference Station
» Video Endpoints

Reference:

» IP Telephony Endpoints

Filed under: » Gatekeeper, » Gateway, » Voice

Notes: H.225 RAS Messages

Added on my notes, here is the list of H.225 RAS (Registration, Admission, and Status) signal messages which are initiated by a gateway and gatekeeper.

• Gateway-to-gatekeeper signaling is H.225 RAS signaling. This signaling is User Data Protocol (UDP) based. Signaling messages between gateways are H.225 call control, setup, or signaling messages.
• H.225 call control signaling is used to set up connections between H.323 endpoints. The ITU H.225 recommendation specifies the use and support of Q.931 signaling messages.
• If no gatekeeper is present, H.225 messages are exchanged directly between the endpoints.
• After call signaling is set up between the gateways, H.245 is negotiated. H.245, a control signaling protocol in the H.323 multimedia communication architecture, is for the exchange of end-to-end H.245 messages between communicating H.323 endpoints or terminals. The H.245 control messages are carried over H.245 control channels. The H.245 control channel is the logical channel 0 and is permanently open, unlike the media channels. The messages carried include messages to exchange capabilities of terminals and to open and close logical channels.
• After a connection has been set up via the call signaling procedure, the H.245 call control protocol is used to resolve the call media type and establish the media flow, before the call can be established. It also manages the call after it has been established.

H.225 RAS Messages

Gateway Discovery Messages (See the graphics illustration)

• GRQ-Gatekeeper Request: Message that a gateway sends during the gatekeeper discovery process.
• GCF-Gatekeeper Confirm: Reply from the gatekeeper to the gateway, which indicates the transport address (port) of the gatekeeper RAS channel.
• GRJ-Gatekeeper Reject: Reply from the gatekeeper to gateway that rejects the gateway request for registration. Usually due to gateway or gatekeeper configuration error.

Gateway Registration Messages

• RRQ-Registration Request: Message sent from a gateway to the gatekeeper.
• RCF-Registration Confirm: Message acknowledging that the gatekeeper has allowed gateway registration.
• RRJ-Registration Reject: Message acknowledging that the gatekeeper has not allowed the gateway to register.

Gateway Unregistration Messages

• URQ-Unregister Request: Message sent from a gateway or gatekeeper requesting cancellation of the registration.
• UCF-Unregister Confirm: Message sent from a gateway or the gatekeeper to confirm unregistration.
• URJ-Unregister Reject: Response to a URQ when the gateway was not registered.

Admission Control Messages

• ARQ-Admission Request: Message that a gateway sends to initiate a call.
• ACF-Admission Confirm: Reply from the gatekeeper to the gateway admitting the call. This message also contains the IP address of the destination gateway so that the originating gateway can begin call control signaling.
• ARJ-Admission Reject: Reply from the gatekeeper denying the call request. This can be for many reasons, including a number that could not be resolved to an IP address, insufficient available bandwidth, and so on.

Location Request Messages

• LRQ-Location Request: Message sent between gatekeepers to find a gateway in a different zone.
• LCF-Location Confirm: Message sent between gatekeepers to provide the IP address of the requested gateway.
• LRJ-Location Reject: Message sent between gatekeepers in response to an LRQ when the requested gateway is unknown or not registered.

Status Information Messages

• IRQ-Information Request: Message sent from the gatekeeper to a gateway.
• ICF-Information Confirm: Sent from gateway to gatekeeper to confirm the status.
• IRR-Information Response: Message sent from the gateway to tell the gatekeeper about active calls.
• IACK-Information Request Acknowledgement: Response from the gatekeeper to a successfully handled IRR.
• INACK-Information Request Negative Acknowledgement: Response from the gatekeeper for an unsuccessful IRR.
• RIP-Request in Progress: Message sent from a gatekeeper to a gateway when the gatekeeper must use an LRQ to resolve an ACF in a different zone.

Bandwidth Control Messages

• BRQ-Bandwidth Request: A request for an increase/decrease in call bandwidth that the gateway sends to the gatekeeper.
• BCF-Bandwidth Confirm: Message that the gatekeeper sends to confirm the acceptance of the bandwidth change request.
• BRJ-Bandwidth Reject: Message that the gatekeeper sends to reject the bandwidth change request.

Resource Availability Messages

• RAI-Resource Availability Indication: Message that gateways use to inform the gatekeeper whether resources are available in the gateway to take on additional calls.
• RAC-Resource Availability Confirm: Response from the gatekeeper to the gateway that acknowledges the reception of the RAI message.

Reference:

» Implementing Gatekeepers and IP-to-IP Gateways

» Understanding H.323 Gatekeepers

Filed under: » CCVP, » Review Notes, » Voice

Notes: Configuring T3 Interface in Juniper Routers

Here is my quick reference note for configuring a T3 interface on Juniper routers. Not part of my GWGK materials but as reminder again.

T3 is the physical layer protocol used by the Digital Signal level 3 (DS-3) multiplexing method in North America. A T3 interface operates at a bit rate of 44.736 Mbps. The JUNOS software supports payload scrambling and subrate operation on each physical T3 interface. One encapsulation format, PPP, Frame Relay, or HDLC, must be configured for the interface.

Important Links from Juniper:

• Configure T3 Interfaces
• Configure T3 BERT Properties
• Disable T3 C-Bit Parity Mode
• Configure the T3 CSU Compatibility Mode
• Configure the T3 Frame Checksum
• Configure the T3 FEAC Response
• Configure the T3 Idle Cycle Flag
• Configure the T3 Line Buildout
• Configure the Channelized T3 Loop Timing
• Configure T3 Loopback Capability
• Configure T3 HDLC Payload Scrambling
• Configure the T3 Start End Flags
• t3-options 

Filed under: » Juniper, » Notes