Sep 20

Faxing T.38 Relay MGCP to SIP

Posted on September 20, 2014 by ben

Not so commonly discussed area of the Voice Communication world is the T.38 Fax Relay between multiple signalling protocols. I was tasked to complete a Fax Server install into an existing Cisco UC environment. The Fax Server communicated to the CUCM via the SIP Protocol and the existing UC infrastructure inclusive of VG224 and a 2811 ISR was controlled via the MGCP protocol.

First thing first, gain connectivity between the CUCM and the Fax Server to ensure SIP is correctly working. Make a call to the fax server and you should receive the fax signalling sounds.. done.

Now lets work on the 2811 Voice Gateway. This is an ISDN Gateway controlled via the MGCP Protocol through CUCM. However we don’t need to log into CUCM to allow the T.38 Fax Relay protocol. Enable T.38 Fax Relay Globally under the Voice Services VOIP Menu.

(Config)# voice service voip
(Config-voip)# fax protocol t38 ls-redundancy 2 hs-redundanyc 0 fallback passthru g711alaw

In the above exampled I chose to fallback to Passthru method, as this is the existing method on the Voice Gateway.

Now lets enable the T.38 Fax Relay Protocol under MGCP.

(Config)# mgcp default-package fxr-package
(Config)# no fax t38 inhibit

Now lets restart the MGCP Application. *Depending your MGCP Configuration, this may disrupt existing calls.

(Config)# no mgcp
(Config)# mgcp

Faxing inbound/outbound the UC network should now be working as normal.

The VG224 configuration is exactly the same as the 2811 Voice Gateway. As organisations still have a need to fax internally, the VG224 needs the above configuration mended as well.

Below is the summary of configuration changes made.

(Config)# voice service voip
(Config-voip)# fax protocol t38 ls-redundancy 2 hs-redundanyc 0 fallback passthru g711alaw
(Config)# mgcp default-package fxr-package
(Config)# no fax t38 inhibit
(Config)# no mgcp
(Config)# mgcp

Sep 10

CME Shared Lines – Quick Note

Posted on September 10, 2014 by ben

Shared Lines behave differently between CUCM and CME so much so that I find UC Administrators are getting a little muddled between whats normal and abnormal with Shared Lines configured in CME. Below is a quick note of the configuration and expected behaviour of CME Shared Lines for SCCP Phones.

General requirement of a shared line.

1. When a call comes in, I’d like it to ring both phones
2. If one phone is active, I’d like to have Call Waiting so I can see who is trying to call.
3. We should be able to receive more than two calls at a time
4. I also want the ability to hold, conference or transfer the call to another phone.

Sounds pretty standard right and out of the box CUCM does this by assigning a single DN to multiple phones, with a couple of DN tweaks like Busy Trigger etc. However CME on the other hand, if you were just to configure the a single ephone-dn and assign the ephone-dn to two phones like in the sample configuration below, you would see different results.

ephone-dn 1 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
!
ephone 1
mac-address 00E1.2D14.EEEE
ephone-template 1
max-calls-per-button 4
busy-trigger-per-button 3
button 1c1
!
ephone 8
mac-address 1C1D.8A24.EEEA
ephone-template 1
max-calls-per-button 5
busy-trigger-per-button 3
button 1c1

The above sample represents what seems to be a standard shared line setup, single DN, with the DN being assigned to two phones. The behaviour is as follows. Calls comes in, Both phones will ring, Phone 1 will answer the call. Next call comes in, seeing that Phone 1 has seized the line (currently on an active call) the inbound call will only ring on Phone 1, so Phone 1 will see a call waiting signal because we have configure the button with a ‘c’ however Phone 2 doesn’t ring at all. This is because by default there are two commands placed on each ephone-dn; huntstop and no huntstop channel. These two commands effectively tell the Router to stop hunting if ephone has an available line, which in this case it does, remember dual-line has been configured for the ephone-dn, so ephone-1 can still receive a second call on the second line, hence the call waiting signal being flashed to ephone-1. We need the second call to hunt to another ephone. Below is how we do it.

In the sample above we have added the no huntstop and huntstop channel commands to the ephone-dn 1 and also added a second ephone-dn with the same number. Then we have overlayed the second ephone-dn onto the first button. This allows for a second call on the DN 4000 to be routed to the second ephone-dn if a phone is active on a call. Plus this also allows for supplementary features like hold, transfer, conference etc, which requires a second line to complete the transaction.

Only one more problem to solve, one of the requirements was to have each phone be able to handle more that two calls simultaneously. All we have to do is add more ephone-dns to the configuration. The below sample configuration allows for four calls to the 4000 DN.

ephone-dn 1 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
no huntstop
huntstop channel
preference 0
!
ephone-dn 2 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
no huntstop
huntstop channel
preference 1
!
ephone-dn 3 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
no huntstop
huntstop channel
preference2
!
ephone-dn 4 dual-line
number 4000 no-reg primary
label Reception
name Reception
call-forward busy 4999
call-forward noan 4999 timeout 60
preference 3
!
ephone 1
mac-address 00E1.2D14.EEEE
ephone-template 1
max-calls-per-button 4
busy-trigger-per-button 3
button 1c1,2,3,4
!
ephone 8
mac-address 1C1D.8A24.EEEA
ephone-template 1
max-calls-per-button 5
busy-trigger-per-button 3
button 1c1,2,3,4

Now we have all the requirements satisfied. So after reading the above its now worth noting the differences in shared line behaviour between CUCM and CME.

Aug 30

Re-installing VMware ESXi where CUCM, CUC and IMP Publisher Servers Reside.

Posted on August 30, 2014 by ben

Under certain circumstances there may be a required to remove the underlying ESXi Host install and re-install maybe the same ESXi version or an updated version. One use case I can think is if the Server build was not originally built to Cisco Specifications that is incorrect Disk Numbers, Memory, CPU requirements, block size RAID configuration etc. The Cisco TAC Team will not support an independent Server Build unless the exact Server Design Specifications are met.

I will walk through such a case to reinstall an ESXi Server where the Publisher Servers reside, including CUCM, CUC and IMP.

Scenario: Single ESXi Host, Single Local Datastore, ESXi Host maintains the CUCM Publisher, CUC Publisher, IMP Publisher and the ELM Server.

Objective: Install additional Hard Disks, reconfigure RAID according to Cisco Specifications. Reinstall ESXi (same version) onto the first Logical Drive, and then look to reinstate the UC Application Servers.

First we will need to examine the current ESXi Server Build, networking parameters and general system parameters including DNS Servers, NTP, Domain Name, and License ID. Document the configuration parameters, so we can apply the same settings after the install the ESXi Host.

Failover the Publisher Servers to the Subscribers (if you have subscribers). Test UC functionality to ensure the Business can still operate as per normal.

Remove the Publisher Servers from Inventory (not Delete from Disk). In this case, I have access to an NFS Share, so I configured an NFS Datastore. In other cases, there may be iSCSI or FCP available. We basically just need another datastore that will be ‘safe’ for our vmx and vmdk files to be store while we complete the process.

Once the NFS Datastore is attached and the Virtual Machines have been removed from the Inventory we can Browse the Local Datastore, right-click on the first Folder (CUCM Pub) and select Move. Browse to the NFS Datastore and select the appropriate folder to store the CUCM Pub folder and files. This will start to move the CUCM Pub files to the NFS Datastore, this may take up to 2 hours.

Repeat for the CUC Pub and the IMP Pub. I prefer to separate the streams and not move the entire datastore in one move. I find it more efficient to have multiple streams. It’s really just a personal preference.

By now all the Virtual Machines folder/files are being moved to another datastore. Go grab a coffee.

Ok so all files have been moved the NFS Datastore, and you have checked the files are indeed n their correct location. We can no go ahead and shutdown the ESXi Host.

Make the appropriate hardware changes, let it be memory, cpu or Hard Disks and boot the Server up.

Upon boot up we will need to reconfigure the Arrays and Logical Drives. So hit Crtl-H during the Cisco Splash screen. This will direct you to the Array Configuration utility. Delete the existing Logical Drives and start the wizard to configure the Array and Logical Drives.

You must follow the Cisco Server Design Guide exactly. You will need to find what server spec you need to reference. In this case I need to create two logical Drives backed by RAID 5. I have 18 Disks, so 9 Disks per Logical Drive. I go ahead and configure the required arrays and logical drives. Reboot the server when complete.

I have previously downloaded the correct version of ESXi and is in an ISO format. I remotely connect to the CIMC Console and start-up the KVM. I click to the Media Tab in the KVM and map my ESXi ISO to the server.

I force the Server to boot from the ESXi ISO file and start the ESXi Install.

Using CIMC’s KVM utility login into the ESXi Console and configure the base parameters need to connect to the ESXi Host via the network. Details include selecting the correct VMnic, IP Address, Subnet Mask, Gateway, DNS Servers, Domain Suffix, and Hostname. Save and restart the Management Network.

Using your vSphere Client, connect and log into the ESXi Server. Complete the configuration according to your notes take in the initial information gathering phase.

Attach the NFS Datastore storing the Virtual Machines and proceed to move the Virtual Machine folders/files back to the Local Datastores. Again I prefer to have three data streams one for each Publisher Server. No go grab another well-deserved coffee as the transfer process to a VMDK Disk takes a touch longer than going to NFS storage.

Ok, once all the Virtual Machines have been successfully moved back across to Local Datastores, we can proceed to add the Virtual Machines to the Inventory. We don’t need the OVA files again and the vmx file contains all the original system settings for the Virtual Machines. We will browse to the Local Datastore where the Virtual Machine is now stored. Browse into the Virtual Machine folder, and right-click on the vmx file. (hostname.vmx). Select Add to Inventory. This adds the Virtual Machine back in the Inventory ready for powering on.

Power on the Servers, VMware will more than have you answer a question before permitting the Virtual Machine to be powered on. The question asks “was this Virtual Machine Copied or Moved” Select Moved. The Virtual machine will now power on.

Run all your standard UC Application tests to ensure the system is fully operational.

Last Step. Since we have effectively moved our ELM Server to a new Host, all the UUID information etc has changed. The ELM Server will still show the original licenses, however, they licenses will not be applied to the Publisher Servers. The ELM Server will be running in Demo Mode. 60 Day Grace period. The error complains about the Publishers already being managed by another ELM Server. There are commands on the CLI to clear the ELM Server connection in CUCM Pub and CUC Pub. However in this case, we need to Log a Cisco TAC Case and request to re-host the ELM Server. You will need to supply Cisco with the Original License files and the License Request file. Upon receiving the new License File, upload and sync all Publisher Server to ELM. In some case, you will need to remove the Publisher Server sin ELM first, and then re-connect the Publisher Servers. Log into the CUCM Pub and CUC Pub and ensure the Licenses have sync’d across successfully.

Job done.

Aug 20

SRST Mode Auto-Provision All

Posted on August 20, 2014 by ben

Recently I was caught out with CME-SRST. This issue was ‘awoken’ by an actual failover event for one of the remote sites. When the CUCM solution was initially deployed SRST was tested in full among other services without issues. Phones registered to the SRST Router, tested inbound/outbound calls, voicemail routing to CUC (Head Office), also tested CME features and Media Resources, all these passed with flying colours.

I’m referring to the command “srst mode auto-provision [all , dn, none]” This is what effectively brought undone SRST. Using SRST CME mode is completely fine and I would recommend you configure any SRST Router in this mode, due to the additional features that can be accessed by remote users when in SRST mode. One big gotcha, if you configure the auto-provision mode to be anything other than ‘none’ then this saves the ephone-dn and ephone to the running configuration of the SRST Router.

What does this mean? Exactly what you think it means, the ephone and ephone-dn is now a part of your configuration, and if an ephone-dn is in the running configuration of the router, then the Virtual POTS dial-peer is in an UP state with a host specific dial-pattern [$] beating all others.
So when the remote Site is brought online again, the phones deregister correctly from SRST and register back to CUCM. BUT because the ephone-dn remains in the running configuration…. Yep you guessed it the Virtual POTS dial-peer remains UP. The biggiest issue is when this SRST router is also a local ISDN gateway for the remote site, the inbound calls will match….. the Virtual POTS dial-peer! No calls will ever route to CUCM.

This isn’t so much of an issue if the SRST Router does not terminate calls locally ie ISDN, as the inbound calls will never pass through the SRST router.
You will have to manually delete the ephone-dn’s effectively shutting down the related Virtual POTS dial-peer.

So my recommendation is too always configure SRST with auto-provision none. This ensure the ephone-dns and ephones do not write to the running configuration.

Like I’m mentioned in the beginning of this article, my initial failover tests worked like a charm, but was bitten by this little command.

Aug 10

Cisco Prime Collaboration Manager v10

Posted on August 10, 2014 by ben

Cisco have release the Video Data sheet for Cisco the Prime Collaboration Manager 10. This product is shipped with all v10 deployments and includes Cisco Prime Collaboration Assurance and Provisioning Manager. Also includes Analytics for an additional cost. The Collaboration Manager allows Voice Administrators to effectively monitor the health of their UC Environment and provides troubleshooting tools to resolve voice related issues quickly. One other big plus for me is the inclusion of being able to audit changes in Call Manager. Now Voice Administrators can delegate voice MACDs to helpdesk staff and review actual changes made to ensure changes are completed correctly.

I’ll write up configuration snippet in future blogs.

Jul 30

Photo Retrieval Using UDS Directory Service in Jabber

Posted on July 30, 2014 by ben

Configuring Photo retrieval in Jabber clients to work with UDS Directory Services is slightly different to the EDI methods.

The only photo retrieval method UDS supports is HTTP Based. So you’ll need to create a web server to save your photos too.

Ensure that you can browse and open the photos from a PC or laptop using the HTTP path.

UDS uses a URL Template to dynamically build the photo retrieval path. The variable used by UDS is %%uid%%, this is the username field in CUCM EndUser.

Therefore the only line of code we need in the Jabber-config.xml file is the following

<UdsPhotoUriWithToken>http://webserver.domain/photos/%%uid%%.jpg</UdsPhotoUriWithToken>

Example Jabber-conf.xml file layout.

<Directory>
<DirectoryServerType>UDS</DirectoryServerType>
<UdsPhotoUriWithToken>http://webserver.domain/photos/%%uid%%.jpg</UdsPhotoUriWithToken>
</Directory>

Note: If you had tried other methods of photo retrieval, you may need to remove the CSF folder under %profile%\AppData\Local\Cisco\Unified Communications\Jabber. then sign back into Jabber.

Photos should be 128px x 128px. However the Jabber Client will resize if the image is larger.

To verify the photoUrlTemplate is correct review the Jabber Log file under %profile%\AppData\Local\Cisco\Unified Communications\Jabber\CSF\Logs\ and search for the line ‘photoUrlTemplate=’

This should reflect the value of the field in the jabber-config.xml file.

Jul 20

Configuring IM&P Server with PostgreSQL Database for Persistent Chat

Posted on July 20, 2014 by ben

Installing and Configuring Cisco IM&P 10.0 with PostgreSQL 9.3 on Windows 2008 R2 Server.

Download the PostgreSQL Database Appliation from PostgreSQL Website

Run the downloaded executable and complete the wizard.

Connecting to the PostgreSQL Database

Open the Administration console for PostgreSQL (pgAdmin III), then start and connect to the database service from the sub-menu.

Create a new Login Role. The Role Name is the username, ensure to assign a password to this login role as the Cisco IM&P Service requires this. Under Role Privileges, check the ‘superuser’ box.

Creating a Database

Click on the ‘Databases’ object to Create a New Database. Give the database a name (lower-case) and assign the above created user as the Owner.

Allowing Client Connections

In PostgreSQL v9.3 the database listens on all available IP Addresses configured on the Host Server. In order to restrict listening IP Addresses, modify the postgreqls.conf file located under the install directory \data\postgresql.conf

For host IP 192.168.1.1 , modify the following line

listen_address = ‘*’ to listen_address = ‘192.168.1.1’

PostgreSQL Database version 9.3 by default only accepts database connections from the localhost. In order to allow remote connections into the database we need to modify the hba.conf file located under the installation directory \data\hba.conf

Add the following line to the hba.conf file

HOST ALL ALL 192.168.1.0/24 md5

Cisco IM&P Server Configuration

Within the IM&P server we need to create an external database relationship and then assign the external database to a service like Persistent Chat.

Creating an External Database
Navigate to Messaging -> External Server Setup -> External Databases. Add new Database and complete the required details. The Database Name is to be lower case, Database Type Postgres, User Name (Role Login), IP Address for the Hostname and keep the default Port Number.

After saving the configuration, there will be errors in the External Database Section. This is because this database is not yet linked to a service.

Linking the External Database to the Persistent Chat Service.

Navigate to Messaging -> Group Chat and Persistent Chat. Enable Persistent Chat, then scroll down to the Persistent Chat Database assignment section and drop the menu down and select the above created external database. Save the Configuration.

Check Database Connectivity

Navigate to Diagnostic -> System Troubleshooter. Then scroll down to the External Database Troubleshooter and check the system health.

Jul 10

Cisco IM&P Server Install Fails – Connectivity Check to CUCM Publisher Fails

Posted on July 10, 2014 by ben

A slight change to the way IM&P is added to the CUCM Infrastructure in version 10. The IM&P Server is now thought of like a Subscriber in the CUCM Environment as it so tightly integrated in CUCM. So before you install IM&P Server, you will need to add the server to CUCM first, just as you would a CUCM Subscriber.

CUCM -> System -> Server -> Add New

Server Type will be CUCM IM and Presence, then enter the required details for IP Address and Presence Domain.

Now you can go ahead and install the IM&P Server.

Jun 30

Unified Collaboration 10 Licensing Brief

Posted on June 30, 2014 by ben

Licensing is always a hot topic when any new version of a product such as Unified Collaboration, especially when changing Licensing Management Server. However Licensing between UC 9.0 and 10 are much the same. The big jump is between Pre 9.0 releases to UC9.0+.

UC 10 Licensing is now managed from the Prime Licensing Manager Server (Prime LM). The Prime LM is much the same as the ELM in 9.0 and 9.1 with just a few interface differences. The licensing structure remains the same, no change in pricing for license types (CUWL or UCL). Cisco Prime LM is designed to simplify licensing procurement with Cisco and align Businesses to strategic Collaboration trends.

Cisco separates licensing into 3 Levels. UCL Enhanced / Plus , CUWL Standard and CUWL Professional.

UCL Enhanced and Enhanced Plus

• Supports Cisco’s entire portfolio of personal endpoints, such as 8900 series, 7900 series, Jabber CSF devices etc.
• Enhanced provides support for one Device
• Enhanced Plus provides support for two Devices. Example. Joe Citizen can operate two devices, his 8945 IP Phone and his Jabber Client on his iPad. Joe will only consume a single UCL Enhanced Plus License in this scenario.

New to UC 10

• UCL will include Firewall Traversal for IM&P, voice and Video within an organisation. This relates to the new Collaboration Edge solution for Remote and Mobile Workers.
• Cisco Prime Collaboration Standard.

CUWL Standard

• CUWL Standard provides for all the features included with the UCL Enhanced / Plus license level.
• CUWL Standard provide support for more than two devices. I believe 10 devices remains the maximum keeping in line with UC9.0 CUWL Standard Licensing parameters.
• CUWL Standard provides support for Cisco Unified Messaging. Ie User will be licensed for a Voice mailbox.

CUWL Professional

• This is the most comprehensive licensing level for the UC 10 solution.
• CUWL Professional provides for all the features of CUWL Standard and UCL Enhanced / Plus.

New in UC 10

• CUWL Professional includes ONE Named User license for Webex onPremise AND a 1yr subscription to the Webex Cloud Servicee
• CUWL Professional includes ONE Named User license for Personal Multiparty to host up to 4 party video conference.

Jun 20

Finding and Changing the Default Directory URI Partition

Posted on June 20, 2014 by ben

By default Cisco CUCM 10 includes a system partition called “Directory URI”. All SIP URIs are placed into this partition automatically.

As this is a system partition, it cannot be removed from the system, however you can specify another partition where all SIP URIs can be automatically placed into.

System -> Enterprise Parameters -> Directory URI Alias Partition. Drop the menu down and select a partition you would like the SIP URIs to be placed into.

As you can see I have selected the partition called INTERNAL_PT for my SIP URIs.

Page 13 of 17« First ‹ Previous 10 11 121314 15 16 Next ›Last »

Cisco UC

Collaborate Anywhere

Category Archives: Cisco UC