Archive for the 'IP Telephony' Category



Call Manager Express CME Deployment Scenarios

Wednesday 11 February 2009 @ 4:51 am

The Cisco Unified CallManager Express (CME) solution not only has the benefit of voice-data integration on a single platform, but offers also flexible deployment options. The Cisco CME on its basic form consists of a router on which the callmanager software is installed, plus several telephony devices. The CME router acts as a gateway between the Public Switched Telephone Network (PSTN) and your local IP telephony network. IP Phones or other legacy telephony devices can be connected on the Call Manager Express router (either directly using FXS ports, or on the local LAN switch). The figure below shows a basic small-office/medium-office CME network topology (figure is from Cisco):

The typical CME deployment above uses a single callmanager router with few legacy telephony devices (normal telephones and a Fax machine) connected directly on the router itself (on FXS ports), plus few IP Phones connected on the local LAN switch. All these phones are controlled by the CME router.

The Cisco CME software uses the following basic building blocks:
 

  • Ephone: This is configured in software (using IOS commands on the router) and represents a physical telephone. The MAC address of each physical phone is configured using the ephone configuration commands.
  • Directory Number: This is again a software concept that represents the line that connects a voice channel to a phone. A directory number represents a virtual voice port in the Cisco Unified CME system.

Call Manager Express Call Handling Modes

Before deploying a Call Manager Express system you must decide how the system will handle calls. There are three call handling models: PBX model, KeySwitch model or Hybrid model.

PBX Model:
This is the simplest and most popular call manager mode of operation. Each internal telephone has its own unique directory number (extension number) as shown in the diagram below.

Incoming PSTN calls are usually routed by the CME router to a central receptionist (or auto-attendant) which then delivers the calls to the appropriate requested extension number. There is also the option of having Direct Inward Dialing (DID) lines towards the PSTN which allows incoming PSTN calls to be directly routed to specific internal extensions. An example of DID is when calls coming to number 555-838-1001 will be routed directly to Extension 1001, calls coming to number 555-838-1002 will be routed to Extension 1002 etc.

It is recommended for this model that you configure directory numbers as dual-lines so that each button that appears on an IP phone can handle two concurrent calls. Dual-line directory numbers enable your configuration to support call waiting, call transfer with consultation, and three-party conferencing (G.711 only).

Keyswitch Model:
In this model there is no central receptionist telephone. Rather, all telephones have an identical configuration in which each phone is able to answer any incoming PSTN call on any line. An example is shown below:

The keyswitch model is configured by creating a set of directory numbers (Extension numbers) that correspond one-to-one with your PSTN lines. Then you configure your PSTN ports to route incoming calls to those directory numbers. When an incoming PSTN call arrives (e.g on Extension 1001), then ALL telephones will ring on line 1001. Any user can then pick-up the ringing line by just pressing the button corresponding to that line.

 Hybrid Model:
In this model, each IP phone can have both PBX and Keyswitch configurations. Each telephone can have unique extension numbers (PBX model) and also shared lines numbers (keyswitch model).

A hybrid model is shown above. Extension numbers 1001, 1002, 1003 are shared lines, and Extensions 1004, 1005, 1006 are unique private numbers for each user.




How To Install Cisco Call Manager Express CME Software

Monday 12 January 2009 @ 7:01 am

The Cisco Call Manager Express (CME) software (its new name is Cisco Unified Communications Manager Express)  provides IP Telephony services that run on Cisco Integrated Services routers (such as 1800, 2800, 3800 family series). I will start a series of posts in this blog about IP Telephony, starting today with the installation of CME on a supported Cisco router.

The CME software can be downloaded from http://www.cisco.com/cgi-bin/tablebuild.pl/ip-iostsp (login required) and you can install it on the router flash. You need to download the CME software (comes as a single .zip compressed file) that is appropriate for the specific router IOS image you are intended to use. The ZIP file contains several individual files and several TAR archives. The individual files can be copied to flash using the regular “copy tftp flash” command and the TAR archives can be copied and extracted to flash using the “archive tar” command (more details later).

The recommended files that you need to install are the following:
 

  •  Basic Files: This is a TAR archive containing the basic files you need to run the Cisco Unified Call Manager express. This archive contains also the phone firmware files required, although additional individual phone firmware files may be needed sometimes. The filename for this tar archive is “cme-basic-x.x.x.tar“.
  • GUI Files: This is again a TAR archive containing only the files of the GUI management tool, which is a mouse-driven interface for provisioning phones and for general CME management after basic installation is complete. The filename for this tar archive is “cme-gui-x.x.x.tar“.
  • Phone Firmware Files: Although the required phone firmware files are included in the Basic tar archive, you may need to add phone firmware files to support individual phone models that are not included in the basic package. Each firmware file is specific for each phone model and for the protocol it uses (i.e SCCP or SIP protocol). By default, new IP phones are shipped with an SCCP firmware image. If the firmware installed on an IP phone is older than the firmware loaded on the Call Manager router flash, the IP phone automatically upgrades its firmware and then registers with the Callmanager. The filename conventions used for phone firmware images are:
    • SCCP firmware: P003xxyyzzww or SCCPxxyyzzww
    • SIP firmware: P0S3-xx-y-zz or SIPxxyyzzww
    • For Java-based IP phones, such as the Cisco Unified IP Phone 7911, 7941, 7941GE, 7961, 796GE, 7970, and 7971, the firmware consists of multiple files including JAR and tone files.

Installation of CME software

After you download the .zip CME software file from Cisco, uncompress the file on a local TFTP server. You will get several individual files and several TAR archives. We assume the TFTP server is at 192.168.10.1 and has access to the CallManager router.

 For individual files:

Use the regular copy command to transfer the file from TFTP to the router’s flash:

Example:

Router# copy tftp://192.168.10.1/P00307020300.sbn flash:

For TAR archive files:

Use the archive command to transfer the files and extract them at the same time to the router’s flash:

Example:

To transfer the Basic Files tar archive (cme-basic-3.0.3.tar) to callmanager router:

Router# archive tar /xtract tftp://192.168.10.1/cme-basic-3.0.3.tar flash:

After all required files are installed, use the “show flash” command to list the files installed on flash memory.




Hardware Conferencing with PVDM Module on 2801 Call Manager Express

Friday 2 January 2009 @ 10:04 am

A PVDM (Packet Voice DSP Module) is a router hardware module that looks like a computer memory chip and is used to provide Digital Signal Processing voice services to routers working as voice gateways or as Call Manager Express devices. The high-density PVDM2 module enables Integrated services routers (such as 2800, 3800 models) to provide high-density voice services such as transcoding, hardware conferencing and voice encoding in IP communications solutions.

The following configuration example is about a cisco 2801 router working as Call Manager Express version 4.1 with both local IP phones and IP Phones located in remote branches over IPSEC VPN. The remote phones work with G729 codec and the local phones use normal G711 voice encoding. The requirement is to enable hardware ad-hoc conferencing between remote G729 and local G711 phones.

Here is the configuration snapshot (only commands related to hardware conferencing are shown):

voice-card 0
dsp services dspfarm
!
voice class custom-cptone leavetone
dualtone conference
frequency 400 800
cadence 400 50 200 50 200 50
!
voice class custom-cptone jointone
dualtone conference
frequency 600 900
cadence 300 150 300 100 300 50
!
interface FastEthernet0/0
ip address 192.168.10.1 255.255.255.0

sccp local FastEthernet0/0
sccp ccm 192.168.10.1 identifier 100 priority 1 version 4.1
sccp
!
sccp ccm group 2
bind interface FastEthernet0/0
associate ccm 100 priority 1
associate profile 2 register DSPprofile2
keepalive retries 5
!
dspfarm profile 2 conference
! Configure codecs allowed to participate in conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
maximum sessions 2
conference-join custom-cptone jointone
conference-leave custom-cptone leavetone
associate application SCCP

telephony-service
sdspfarm units 2
sdspfarm tag 2 DSPprofile2
conference hardware
max-ephones 24
max-dn 48
ip source-address 192.168.10.1 port 2000 strict-match
max-conferences 4 gain -6

!
ephone-dn  43  dual-line
number A000
description Ad-Hoc Conference
conference ad-hoc
no huntstop
!
!
ephone-dn  44  dual-line
number A000
description Ad-Hoc Conference
conference ad-hoc
preference 1
no huntstop
!
!
ephone-dn  45  dual-line
number A000
description Ad-Hoc Conference
conference ad-hoc
preference 2
!
!
ephone-dn  46  dual-line
number A000
description Ad-Hoc Conference
conference ad-hoc
preference 3

Notice on the configuration above that we have to create some dummy phone directory numbers (ephone-dn 43 to 46) to facilitate the ad-hoc conference operation. An Ad-hoc conference is an unscheduled conference. It occurs when a third party is added into any conversation by the participants. The ad-hoc initiators can add/delete/drop participants to/from the conference.

CME hardware conferencing supports a maximum of 8 participants in an ad-hoc conference.
Each DSP can support a maximum of 64 G.711 participants only (single-mode), this translates to:

  • 8 conferences of 8 participants each.

Each DSP can support a maximum of 16 G.711/G.729A/G.729 participants (mixed-mode), so this translates to:

  • 2 conferences of 8 participants each.

Verify DSP registration

If your DSPfarm is not registered to CME, you will not be able to use the DSP resources to initiate a conference call. To check if the dspfarm is registered, perform the following command – “show dspfarm all

Example: Registered – good example

Router#show dspfarm all

<output omitted>

Profile Operation State : ACTIVE

Application : SCCP Status : ASSOCIATED

<output omitted>

Example: Unregistered – bad example

<output omitted>

Profile Operation State : ACTIVE IN PROGRESS

Application : SCCP Status : ASSOCIATION IN PROGRESS

<output omitted>




Next Posts »»
cisco asa firewall ebook

Configuration Tutorial For Cisco ASA 5500 Firewalls
With FREE ASA 5505 Configuration Tutorial Bonus

CLICK HERE TO DOWNLOAD EBOOKS


Sponsored Links