Issue: Video conference fails when TPC conductor media resource is used for conference.
This solution works fine when a media resource is used from the gateway.
From the traces we see that the cdcc is not sending request to split the call as a result the conference fail.
We could see that only once call is being split, however the other calls are not getting split.
After this when we verify the call to the TPC conductor
The CUCM is sending INVITE to the conductor however we do not see a 200 OK coming to the CUCM as a result this is failing.
From the Packet capture of the TPC conductor we see that it is sending 200 OK and we do not send ACT to it.
Verified the Packet capture on the CUCM side and observed that Packets are seen on the .pcap file but not on the CUCM call manager traces.
That particular packet size for SDP is over 5000 Bytes; we can see this in packet capture.
In CUCM traces we see the below after receiving this particular packet.
42520304.002 |11:43:59.619 |AppInfo |SIPTcp - Ignoring large message from 10.61.25.98:. Only allow up to 5000 bytes. Resetting connection.
CUCM is dropping the packet as it is exceeding the limit.
In CUCM 8.6 and earlier the maximum size allowed for the SDP is 5000 bytes.
However in CUCM 9.x and later we have an option to increase this to 11000 bytes to allow the large SDP packets.
Path to modify this parameter:
On the Cisco UCM administration interface, choose System > Service Parameters.
Choose the active server from the Server drop-down list.
Choose Cisco CallManager (Active) from the Service drop-down list.
Click Advanced in the toolbar, since the message size is not shown in the Condensed (default) view.
Scroll until you find the Clusterwide Parameters (Device - SIP) section.
Locate the SIP Max Incoming Message Size parameter.
This parameter would require to be changed on all the servers, where call processing will be done and a reset is required when saved.
Once we modify this parameter the issue is resolved and conference works fine.
... View more
When Encryption is enabled in CUCM then the VG224 analog ports are not getting registered. The registration is shown as rejected in cucm. The issue is noticed only on some gateways, however there are working Gateways which are registered properly with similar configuration. The configuration is through SCCP and is configured correctly. When a secured Analog profile is selected for the Analog phones then the phones will not get registered. On Some Gateways the phones are registered when we select the encryption option in the phone security profile without any issue. The VG224's on working and non-working are on the same release. In CUCM traces we could see that the registration is rejected as invalid certificate name or configuration issue. Reason code 11 and reason code 3 which is certificate name invalid/ DatabaseConfigurationError. May 12 09:01:55 POZVLNX001 local7 3 : 38266: POZVLNX001: May 12 2014 10:01:55.489 UTC : %UC_CALLMANAGER-3-DeviceTransientConnection: %[ConnectingPort=2000][DeviceName=ANF70D02F618400][IPAddress=10.32.252.85][DeviceType=30027][Reason=11][Protocol=SCCP][IPAddrAttributes=2][UNKNOWN_PARAMNAME:LastSignalReceived=StationRegister][UNKNOWN_PARAMNAME:StationState=wait_register][AppID=Cisco CallManager][ClusterID=EURO-CUCM][NodeID=POZVLNX001]: A device attempted to register but did not complete registration 3 indicates DatabaseConfigurationError - The device is not configured in the Unified CM Administration database and auto-registration is either not supported for the device type or is not enabled. To correct this problem, configure this device in Unified CM Administration. 11 indicates InvalidX509NameInCertificate - Configured "X.509 Subject Name" doesn't match the information in the certificate from the device. Check the Security profile of the indicated device and verify that the Device Security Mode is set to either Authenticated or Encrypted. Verify that the X.509 Subject Name field has the appropriate content; it should match the Subject Name in the certificate from the peer. We could see the same from the call manager traces. Line 15394: 09:03:59.210 |DeviceTransientConnection - A device attempted to register but did not complete registration Connecting Port:2000 Device Name:ANF70D02F618401 Device IP Address:10.32.252.85 Device type:30027 Reason Code:11 Protocol:SCCP IPAddressAttributes:2 UNKNOWN_PARAMNAME:LastSignalReceived:StationRegister UNKNOWN_PARAMNAME:StationState:wait_register App ID:Cisco CallManager Cluster ID:EURO-CUCM Node ID:POZVLNX001|AlarmANF70D02F618401^*^ANF70D02F618401 Line 15401: 09:03:59.210 |StationD: (0036154) registrationError sent StationOutputRegisterReject|0,0,0,0.0^10.32.252.85^ANF70D02F618401 Line 15402: 09:03:59.210 |StationD: (0036154) RegisterReject text='Security Error'.|0,0,0,0.0^10.32.252.85^ANF70D02F618401 We have done the following: 1. Stop “Cisco Certificate Change Notification Service” on all the nodes and regenerate the certificate and upload it to the call manager. 2. Restart the call manager service/Node and check the issue. This did not have any impact. The issue is with the subject name. So under crypto pki trustpoint” configuration of gateway we changed the change the “subject-name CN= F7:0D:02:F6:18” from xx.xx.xx.xx.xx format to xx:xx:xx:xx:xx After which the gateway is registered. However we need to make sure the following point which is important. The device pool under the VG224 and the analog port should be same if not the ports may register or may not register; even though the ports are registered the calls would fail. Other point which is important to be noted when configuring a PLAR when VG224 is registered to CUCM then it is recommended to use PLAR configuration on the gateway side rather than the CUCM side. The impact of this is, when the called party disconnects the call then the status of the analog phone still remains off –hook which causes the gateway to send the off-hook status to CUCM and thus resulting the call again.
... View more
EMCC Configuration. This document guides you the minimum requirements and configuration steps required to enable EMCC functionality between two clusters. For enabling the EMCC we need 4 services to be running on both the clusters. TFTP Extension Mobility Bulk Provisioning Cisco Call manager You could verify this from the serviceability on both the clusters. On the phone configuration page we need to enable Extension mobility. The EMCC checkbox has to be enabled for the end user and we need to associate device profile. Configure the phone service for EMCC. Non secure EMCC service URL is: http://<IP address if the CUCM>:8080/emapp/EMAppServlet?device=#DEVICENAME#&EMCC=#EMCC# You can enable enterprise subscription as needed. Exporting certificates We need a ftp serve where we can export and import certificates. Add the FTP server details and save the configuration, it will be validated if server is reachable. Click on Export and select all and export the certificates. Repeat the same process on the cluster B as well After this you will see an option to consolidate the certificates. Select the option all and click on consolidate; this can be done only once. Next step is to import the certificates to the home and remote cluster. After importing the certificates, you need to add a new common device configuration. Add a new EMCC template from Bulk AdministrationàEMCCà EMCC template configuration and select the created common device configuration. Update the EMCC configuration from Bulk AdministrationàEMCCà Insert/Update EMCC Select Insert EMCC Devices (select the number of EMCC devices) select run immediately and submit Select the update EMCC device and select the configured template, reset option and run immediately and submit the option. This process has to be repeated on cluster B as well. The Cluster ID should be unique on both the cluster. You can verify this option under system-> Enterprise parameters Add a new Geo location filter by adding appropriate parameters. Repeat the same process in cluster B as well. Go to Advance Features à EMCC feature configuration Select default TFTP Server for EMCC Login Device Select EMCC Geolocation Filter Select the default Server For Remote Cluster Update This should also be repeated on Cluster B. Create new SIP trunk for EMCC by selecting the Geolocation that is configured for EMCC and SIP trunk type as EMCC. Repeat the process on Cluster B as well. EMCC Inter cluster service profile. Add new and select the service and click on save. Repeat the same process in cluster B as well with the Cluster id of A. Go to InterCluster Service Profile and select EMCC and PSTN access and click on save and validate. After validation you should see the success message as below. Then you will be able to login to the remote cluster by selecting the EMCC service on the phone.
... View more
The purpose of this document is to provide the procedure to deploy the UC with the help of answer files. Answer file contains the information of the platform related configuration of the server which will be used during installation. The information includes the following: Server IP address (publisher and subscribers), subnet mask default gateway. Administrator username and password. Certificate related details, etc… This will be helpful for the voice administrator to install the server without his intervention. There are two stages when an answer file can be used. Pre-deployed server to get installed. To modify the existing platform related configuration. Procedure to install a pre-deployed server: Created a new VM and mounted the bootable iso image in the cd driver. Started the installation and skipped the disk check. After skipping the disk check the system prompted to continue the server installation. In the next step the system would prompt for platform configuration, we even get an option to skip the process of configuring the platform configuration. Here it is mandatory to skip the platform configuration. After skipping this option, the system would automatically continue the installation and at the end again it would prompt for an option to continue the platform configuration or cancel and halt the installation. We need to cancel the platform configuration and the system would halt. --------------------------------------------------------------------------------- At this stage we have to power off the Virtual machine and export the OVF template. We have to use this template at the customer system and import the template. Now depending on the customer network setup we need to configure the platform related configuration and create a virtual floppy image for the platformconfig.xml file. Platform configuration can be created with the help of below link. http://www.cisco.com/web/cuc_afg/index.html --------------------------------------------------------------------------------- The procedure to create virtual floppy image is as follows: .Download and install Winimage . In Winimage, select File > New. Select 1.44 MB from Standard format and click OK. Import the platformConfig.xml file onto the Winimage window. Click Yes when prompted to inject the file into Winimage. Select File à Save As. Select Virtual floppy image from the Save as type dropdown list. Enter a file name and click Save. Once the virtual floppy image is being build and OVF template is imported we could mount and turn on the VM so that the installation will go on without user intervention. Limitations: We need to install the publisher first and wait till it gets installed completely. There should be network reachability for the subscribers to get installed successfully
... View more