For multiple Service Providers offering TelePresence services, one of the key features is Conference Control Protocol. The Cisco TelePresence Multipoint Switch (CTMS) uses the Conference Control Protocol (CCP) to provide Video endpoints with access to in-meeting functions, such as the participant list; room or speaker switching policies; and the lock meeting feature. CCP is delivered over HTTP or HTTPS. The VPN security solution for CCP allows you to specify a default route (via an outbound http proxy) for CCP traffic, so that the traffic between the CTS endpoint and a remote CTMS can be routed hop-by-hop across one or more HTTP proxies. This HTTP proxy can be Cisco ACE module, Apache web server or any other HTTP proxy server. In the CCP VPN model (fixed path) solution, the administrator configures the enterprise by adding a static (fixed path) configuration file to the Cisco Unified Communications Manager. When the video endpoint joins a meeting on the Cisco TelePresence Multipoint Switch, the endpoint attempts to route CCP traffic based on this configuration file. Typically, you set up the file so that all CCP HTTP traffic first attempts to go to a local CTMS. If no local CTMS matches, packet traffic is routed to the HTTP proxy. Please refer to Cisco TelePresence Exchange system documentation: "Configuring the Conference Control Protocol (CCP) VPN Security Solution" section. This document describe how to configure the ACE as HTTP proxy to be able to offer CCP. *Disclaimer: This configuration is a sample config but it should be deployed in such a way that doesn't expose any other resource or internal network, nor should it generate a lot of extra support. Please perform a network analysis based on the security requirements of the deployment. ACE configuration Using the ACE to Request a Certificate From a CA The ACE can be used to generate an RSA key, as well as a certificate request. After submitting the certificate request to a CA, the CA will supply a certificate to be imported into the ACE. The first step in this process is to generate an RSA key on the ACE. ACE# crypto generate key 1024 CTMSVIP-KEY.pem sh crypto files Filename File File Expor Key/ Size Type table Cert ----------------------------------------------------------------------- CTMSVIP-KEY.pem 1679 PEM Yes KEY Next use the ACE to create a Certificate Signing Request (CSR) from the key generated in the previous step. On the ACE this is a two step process. First a CSR parameter map must be created, and then a CSR is generated from the key and the CSR parameter map. For more information on the various parameters, there is a good reference in the following URL. http://cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A2/configuration/ssl/guide/certkeys.html#wp1021811 crypto csr-params CTMSVIP country US state CA organization-name Cisco organization-unit TIBU common-name tibu-ctms.cisco.com ACE# crypto generate csr CTMSVIP CTMSVIP-KEY.pem
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST----- The VIP and server farm in this example allow the Cisco ACE to accept connections to the VIP on port 9501 and forward them to a real server on port 9501. Note that if the port is not provided, the VIP port will be preserved. Most SSL termination configurations begin by importing the certificate and key onto the Cisco ACE. The easiest way to accomplish this is by placing the two files onto a secure FTP (SFTP) or FTP server so they can be transferred to the ACE. ACE#crypto import ftp 22.214.171.124 cisco CTMSVIP-cert.pem CTMSVIP-cert.pem Note: If the files are in privacy enhanced mail (PEM) format, you can cut and paste to import the SSL file using the terminal parameter. ACE SSL configuration The SSL termination configuration begins like the basic Layer 4 load-balancing configuration, by defining a VIP and corresponding server farm and rservers. Although the VIP can be configured with a port of “any,” the ACE will do a TCP reset on any non-SSL connections. To prevent this, it is recommended that you bind the VIP to a port. In this example, the IP address 10.10.10.10 and port 9501 will be used access-list permit any line 8 extended permit ip any any probe https https-443 interval 5 passdetect interval 15 passdetect count 5 expect status 200 200 parameter-map type ssl param_ssl cipher RSA_WITH_RC4_128_MD5 cipher RSA_WITH_RC4_128_SHA cipher RSA_WITH_DES_CBC_SHA cipher RSA_WITH_3DES_EDE_CBC_SHA cipher RSA_WITH_AES_128_CBC_SHA cipher RSA_WITH_AES_256_CBC_SHA cipher RSA_EXPORT_WITH_RC4_40_MD5 cipher RSA_EXPORT1024_WITH_RC4_56_MD5 cipher RSA_EXPORT_WITH_DES40_CBC_SHA cipher RSA_EXPORT1024_WITH_DES_CBC_SHA cipher RSA_EXPORT1024_WITH_RC4_56_SHA rehandshake enabled rserver host CTMS1 ip address 10.10.10.11 probe https-443 inservice rserver host CTMS2 ip address 10.10.10.12 probe https-443 inservice ssl-proxy service SSL-Client-CTMS ssl advanced-options param_ssl ssl-proxy service SSL-Server-CTMS key CTMSVIP-KEY.pem cert CTMSVIP-cert.pem ssl advanced-options param_ssl serverfarm host ServerFarm-CTMS1 rserver CTMS1 inservice serverfarm host ServerFarm-CTMS2 rserver CTMS2 inservice class-map type http loadbalance match-any CTMS1 2 match http url /cisco/sj/ctms1/.* class-map type http loadbalance match-any CTMS2 2 match http url /cisco/sj/ctms2/.* class-map match-any CTMS-HTTPS-VIP 2 match virtual-address 10.10.10.10 tcp eq 9501 class-map type management match-any MGMT 2 match protocol icmp any 3 match protocol telnet any 4 match protocol ssh any 5 match protocol http any policy-map type management first-match MGMT class MGMT permit policy-map type loadbalance first-match CTMS-LB class CTMS1 serverfarm ServerFarm-CTMS1 ssl-proxy client SSL-Client-CTMS class CTMS2 serverfarm ServerFarm-CTMS2 ssl-proxy client SSL-Client-CTMS policy-map multi-match CTMS-Policy class CTMS-HTTPS-VIP loadbalance vip inservice loadbalance policy CTMS-LB loadbalance vip icmp-reply active nat dynamic 10 vlan 10 ssl-proxy server SSL-Server-CTMS interface vlan 10 ip address 10.10.10.2 255.255.255.128 access-group input permitany nat-pool 10 10.10.10.3 10.10.10.2 netmask 255.255.255.128 pat service-policy input MGMT service-policy input CTMS-Policy no shutdown ip route 0.0.0.0 0.0.0.0 10.10.10.1 CTMS configuration In CTMS1 in the External URL field, enter the routable service location https://10.10.10.10:9501/cisco/sj/ctms1 Please refer to Cisco TelePresence Exchange system documentation for more information. "Configuring the Conference Control Protocol (CCP) VPN Security Solution" section. References: http://docwiki.cisco.com/wiki/SSL_Termination_on_the_Cisco_Application_Control_Engine_Without_an_Existing_Chained_Certificate_and_Key_in_Routed_Mode_Configuration_Example
... View more
The Cisco TelePresence Exchange System is an integrated video service-creation platform that enables service providers and strategic partners to offer secure cloud-based managed and hosted Cisco TelePresence and business video services. As part of the Cisco TelePresence Exchange solution, the Cisco TelePresence Exchange System exposes a set of standards-based APIs to provide integration across business and operational support systems. The Cisco TelePresence Exchange System provides the following APIs. • Scheduling The Cisco TelePresence Exchange System provides the Scheduling Application Programming Interface (API) to facilitate the development of scheduling portals and other software applications. The Scheduling API provides web services to control scheduling of services such as Meet-Me and two-party scheduled meetings on the Cisco TelePresence Exchange System. By using the Scheduling API, you can schedule, modify, or cancel meetings and retrieve information about organizations and rooms. You can access the WSDL file for the Scheduling API at http://<DNS name or IP address for your admin server>:8080/ctxapi/api/sched?wsdl Example: http://10.22.132.41:8080/ctxapi/api/sched?wsdl • Call Detail Record (CDR) The CDR API provides web services to retrieve and manage call detail records for services provided by the Cisco TelePresence Exchange System. The CDR API provides services to accomplish the following tasks: • Retrieve call detail records from the Cisco TelePresence Exchange System. The API provides web services to retrieve CDR records. • Perform tasks that are related to the API. The API provides services that are related to managing the CDR API. You can access the WSDL file for the Scheduling API at http://<DNS name or IP address for your admin server>:8080/ctxapi/api/cdr?wsdl Example: http://10.22.132.41:8080/ctxapi/api/cdr?wsdl For more details about the API please use: http://www.cisco.com/en/US/docs/telepresence/tx/exchange_system/1_0/api_guide/sched.html In this document we will learn how to create a meeting using SOAP UI and CTX Scheduling API WSDL. You will need the following: - SOAP UI SoapUI is an open source web service testing tool for service-oriented architectures (SOA). Its functionality covers web service inspection, invoking, development, simulation and mocking, functional testing, load and compliance testing Download SOAP UI from here: http://www.soapui.org/ - CTX wsdl - CTX version 1.x (This was tested using FCS 1.0.3) 1. Obtain SOAP UI 2. Get WSDL 3. Create new project: 4. Make sure WSDL is loaded. 5. Create CTX API user in CTX Admin 6. Create new request 7. Populate information to create new request. In this case we will create a meeting with 1 hosted endpoint and 1 guest dial out endpoint. You need to configure authentication for API user and populate XML request. Please check documentation to verify each field is populated correctly. 8. Click "Play button" and request will be sent to CTX Admin server. 9. In case request fail, you can verify: Right XML information is populated in request and SOAP UI authentication is configured. IP connectivity and DNS resolution from SOAP UI client to CTX Admin servers CTX API logs located under: /var/log/active/ctc/jboss_admin/log/cisco Packet capture in CTX and SOAP UI or scheduling portal (CHASM) Scheduling portal logs. 10. If you want to create multiple meetings you can create test cases to automate this process. Please review SOAP UI documentation for this.
... View more
CTS Diagnostics 0.1(1002) Disclaimer The tools out here are not TAC nor BU supported.When a tool is not supported by TAC, it is a "use at your own risk" tool. You can get help with these tools using the public forum (link below), but TAC will not assist you. Introduction This document explains how to install, configure and use CTS Diagnostics tool. CTS Diagnostics tool was created to access basic information stored in TelePresence Log files. This information will provide TAC or Cisco Partners valuable details for the CTS systems. This reduce the time extracting manually information and reading log files. This initial version permits users to obtain: - Network information - System version - System Errors - Serial Numbers - Obtain Serial numbers and access latest Field Notices for possible match. - Email reporting This initial draft will permit collect more information about user needs base on customer feedback. Please email me directly for feature requests or bug fixes. Next version will include: - Improve menu selection CLI - SIP Call analysis - Audio and video statistics report - TIP/MUX call analysis - Defect analysis and possible solution. This feature will search keywords and look against database to match possible defects if any errors are present. Example: Abnormal call disconnect Install Your Software Installation notes (CLI) CTS Diagnostics 1.0(1002) CLI version System Requirements: MAC OSX 10.6, CentOS, RedHat, or any Linux Based Operating system Perl 5.0 or above We use the following CPAN modules: use Archive::Extract; use File::Spec; use File::Basename; use HTTP::Request::Common; use LWP::UserAgent; use Net::SMTP; use Net::DNS Compile Perl script from command line to confirm system contains all modules needed perl -c <script name> Depending the errors, install required platforms or software. (Example:) cpan -i Archive:Extract Configure your software: - Download Script - Download menufile.txt - Modify GLOBAL Variables: $MENULOCATION Menu file location (menufile.txt) $userAgent->proxy (HTTP Proxy) $host (SMTP server) - Compile script perl -c <script name> - Change permissions to be executable chmod 755 <script name> - Run script $ ./ctsdebug_cli_0.01002.pl Installation notes (Web) CTS Diagnostics 1.0(1002) CGI version System Requirements: MAC OSX 10.6, CentOS, RedHat, or any Linux Based Operating system Perl 5.0 or above Apache - Install CentOS http://www.unix-tutorials.com/go.php?id=4470 - Install Apache Web Server Select WebServer during installation or use yum install command - Enable CGI scripts in Apache Check httpd.conf ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" - Download CGI script and HTML files ( webfiles.zip and ctsdebug.cgi ) - Upload CGI script and HTML files - Place ctsdebug.cgi to /var/www/cgi-bin/ - Place html files under /var/www/html Create directory /var/www/html/ctsrepository/logs Apply apache permissions for ctsrepository and logs subfolder chown -R apache:apache ctsrepository/ - Change permissions to ctsdebug.cgi chmod 755 ctsdebug.cgi ls -l ctsdebug.cgi -rwxr-xr-x 1 lies www 217 Sep 11 23:42 ctsdebug.cgi - Install Perl yum groupinstall 'Development Tools' - Download Perl CPAN modules We use the following CPAN modules: use Archive::Extract; use CGI; use CGI::Carp use File::Spec; use File::Basename; use HTTP::Request::Common; use LWP::UserAgent; use Net::SMTP; use Net::DNS Compile CGI script from command line to confirm system contains all modules needed perl -c ctsdebug.cgi Depending the errors, install required platforms or software. (Example:) cpan -i Archive:Extract - Start Apache service httpd start - Verify Apache is working by typing your Server IP address go to main.html and verify your CTS Analyzer is running - If using HTTP proxy edit ctsdebug.cgi $userAgent->proxy variable - Edit your mail server hostname ctsdebug.cgi $host = ""; #Enter a Mailbox hostname Default login is admin/cisco - If using HTTP proxy edit ctsdebug.cgi $userAgent->proxy variable - Edit your mail server hostname ctsdebug.cgi $host = ""; #Enter a Mailbox hostname Click View Report Please find more details and newer versions here: http://code.google.com/p/cts-diagnostics/
... View more
we have been doing some intial testing with CTS 1.7.4, we used CUCM 8.5 -- VCS - VCS-E, but we found some issues in the audio and video, caused by signalling interowrking. Works really good using a TPS 8710 in the middle. CTS -- CUCM -- VCS -TPS - VCS- E - BJN. We haven't tested with newer CUCM, VCS versions, when we do it will update thread or you can contact BJN solutions team.
... View more
Hi Tom, It is the first time we get this request, but unfortunately theres no way to change the hostname in CTS. I think your tool needs to be improved, talking to some folks that monitor CTS endpoints with propietary applications they parse the description field from CUCM in order to have a human readable format stored and they just associate it with the real MAC or SEPhostname inside the app and when displaying results display both. Example: Table CTSDEVICES DEVICENAME DESCRIPTION SEPAABBCCDDEEFF SAN JOSE 21-3 CONF1 As a reference in the future you can take a look Collaboration Manager http://www.cisco.com/en/US/products/ps11480/index.html
... View more
What about Location & Region settings in CUCM? Make sure you increase BW to allow Video between phones. We see this a normal configuration problem in our TelePresence initial deployments. HTH
... View more
H.264 Profiles are discussed in depth in the web, but I will focus in the profile-level-id as we can get information for resolution which is the most common request for most of the users. http://en.wikipedia.org/wiki/H.264#Levels Profile level ID string is divided into 3 substrings, each 2 characters long: [PROFILE IDC][PROFILE IOP][LEVEL IDC] Each substring represents one byte in base16! So, if Profile IDC is 28, that means it is actually 40 in base10. Later you will use base10 values to construct AVC Decoder Configuration Record RFC 3984 defines this (page 38). http://tools.ietf.org/html/rfc3984 "If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the profile that the codec supports and the highest level supported for the signaled profile. The profile-iop byte indicates whether the codec has additional limitations whereby only the common subset of the algorithmic features and limitations of the profiles signaled with the profile-iop byte and of the profile indicated by profile_idc is supported by the codec. Profile-iop byte is composed of the values of constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit-significance order, starting from the most significant bit. A level to which the bitstream conforms shall be indicated by the syntax elements level_idc and constraint_set3_flag as follows: – If level_idc is equal to 11 and constraint_set3_flag is equal to 1, the indicated level is level 1b. – Otherwise (level_idc is not equal to 11 or constraint_set3_flag is not equal to 1), level_idc shall be set equal to a value of ten times the level number specified in Table A-1 and constraint_set3_flag shall be set equal to 0. For example, if a codec supports only the common subset of the coding tools of the Baseline profile and the Main profile at level 2.1 and below, the profile-level-id becomes 42E015, in which 42 stands for the Baseline profile, E0 indicates that only the common subset for all profiles is supported, and 15 indicates level 2.1." How does the 15 convert to level 2.1? Page 298 of the ITU spec for H.264 documents how to convert this hex value into a level. This means to covert the last byte you convert the hex to decimal and divide it by 10. 0x15 = decimal 21 = level 2.1 Level limits for each are documented at table A-1 of the H.264 ITU spec linked below. http://www.itu.int/rec/T-REC-H.264/en Real life example: In our Cisco CTS system 1.7.4 we support interoperability with other Cisco endpoints or devices. Please check URL below for further information about which devices are tested. http://www.cisco.com/en/US/docs/telepresence/interop/interop_1_7_4.html#wp108777 In this example we are experiencing a problem calling from Cisco CTS system to a third party Video solution. In this case there is no Video display in Cisco CTS system. We collected packet captures and SIP logs from Cisco CTS and this is what we found: From packet capture: Call from Cisco CTS 1.7.4 to BJN Call flow: Cisco CTS --> CUCM -- SIP --> VCS -- H323 --> VCS-E --H323 --> BJN Problem: No Video in CTS From CTS to Remote end: By analyzing SIP SDP message: Media Attribute (a): fmtp:97 profile-level-id=42001F;packetization-mode=0;max-mbps=108000;max-fs=3600;max-br=4000 Media Attribute (a): imageattr:97 send [x=1280,y=720,q=0.6] [x=640,y=368] [x=352,y=288] recv [x=1280,y=720,q=0.6] [x=768,y=488] [x=640,y=368] [x=352,y=288] [x=352,y=240] From Remote end to CTS: Media Attribute (a): fmtp:96 profile-level-id=428016;max-mbps=108500;max-fs=3840;max-smbps=108500 From CTS: profile-level-id=42 00 1F From BJN: profile-level-id=42 80 16 [PROFILE IDC] CTS: 42 = 66 BJN: 42 = 66 Each substring represents one byte in base16! So, if Profile IDC is 42, that means it is actually 66 in base10. (66=baseline, 77=main, 100=high) [PROFILE IOP] CTS: 0000 0000 = 00 BJN: 1000 0000 = 80 If bit 7 (the most significant bit), bit 6, or bit 5 of profile-iop is equal to 1, all constraints of the Baseline profile, the Main profile, or the Extended profile, respectively, are obeyed in the NAL unit stream. [LEVEL IDC] CTS: 1F = 31 = 3.1 = 720×firstname.lastname@example.org (13) 720×email@example.com (11) 1280×firstname.lastname@example.org (5) BJN: 16 = 22 = 2.2 = 352×email@example.com(10) 352×firstname.lastname@example.org (7) 720×email@example.com (6) 720×firstname.lastname@example.org (5) As seen before, resolution coming from remote end does not match what CTS is expecting, no video displayed.
... View more
CUCM SIP Trunk does not send REGISTER request. But it does support MD5
authentication. The recommended deployment is with the CUBE that can solve some
of the interop problems or just a direct SIP Trunk no auth.
... View more
You can take a look at the SNMP MIBs and configure SNMP monitoring via SNMP walk or SNMP traps. http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml For configuration check: https://supportforums.cisco.com/docs/DOC-13584
... View more
Hi Michael, Let me clarify 2 main differences here: 1. We support SIP OPTIONS in 8.5 and above, which act as a Keepalive and this link describe the parameters needed to tweak the default values. http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/8_5_1/delta/delta.html#wp1820323 2. Without SIP OPTIONS, we dont declare SIP Trunk or Down, nor we monitor the SIP trunk, CUCM has two Steps to check the connectivity with the remote sip party through tcp: Step 1: checking the TCP sync "sip tcp timer" - if failed: meaning the timer expired before getting tcp ACK then this session will be torn down and cm will select the secondary device in the corresponding route group if exist. - if the tcp passed: meaning we got tcp ACK before this timer expires then cm will send Invite message and starts step 2 Step 2: checking "the sip invte expires timer" - as soon as cm sends Invite message this timer will start and if expired before receiving ACK on the invite message, cm will retry the same according to the configured count number of "Retry INVITE" HTH
... View more
The Cisco TelePresence Exchange System is an integrated video service-creation platform that enables service providers and strategic partners to offer secure cloud-based managed and hosted Cisco TelePresence and business video services. The Cisco TelePresence Exchange System is a software environment that provides the following benefits: • Simplifies end-to-end subscriber service provisioning • Optimizes intelligent call routing for endpoints and network bandwidth • Manages the call processing and allocation of media resources for conferencing • Consolidates a centralized control point for management, billing, and administration • Presents an open application programming interface (API) for application integration such as scheduling and directory services Based on proven technology and powered by a fully redundant and horizontally scalable architecture, it delivers an open, scalable, and robust multi-tenant solution that can grow in scale and functions based on service needs. As a result, it accelerates time to market by simplifying the process of new services production and promotes service innovation through APIs that support service customizing. In this document we will describe CTX SIP engine architecture and how interacts with other components in the TelePresence Exchange. After reading this document you will be able to understand how SIP messages are processed by CTX engine, and how CTX interacts with SIP resources and other Media resources. At the end of this document you will find a perl script which will help you analyzing the logs for CTX engine. This script was designed to reduce the time system administrators and technical support team spend during troubleshooting and analysis of the calls. The analysis of Cisco CTX logs requires basic SIP protocol knowledge as well as XML and HTTP protocols basic understanding. Cisco CTX SIP engine The Cisco TelePresence Exchange System manages the media resources and the call processing that inter-company telepresence services require. The Cisco TelePresence Exchange System fulfills the following network-level responsibilities: Controls the reservation and allocation of media resources. Manages the resource usage for organizations. Provides connectivity between service provider networks. The Cisco TelePresence Exchange System server cluster includes the following components: Administration Server Database Server Engine Server CTX SIP Engine Server provides SIP call control for the services that are offered by the Cisco TelePresence Exchange System. In high availability mode deployments, we can find 2 SIP engine servers in our CTX cluster. These 2 SIP servers will run in Active/Active mode. Cisco CTX Engine interacts with multiple Cisco components to provide services: Cisco Session Border Controller (SBC) Cisco Application Control Engine (ACE) appliance Cisco Router with Integrated Voice Response (IVR) Cisco TelePresence Multipoint Switch Cisco TelePresence Manager Cisco Unified Communications Manager (Unified CM) Cisco TelePresence Media Services Engine (MSE) 8000 Series products Cisco Catalyst Switch Cisco TelePresence Video Communication Server In some cases we interact using SIP Protocol directly, in other we use XML API to control call establishment. Please review Deployment guide for more information http://www.cisco.com/en/US/docs/telepresence/tx/exchange_system/1_0/install_admin/overview.html#wp1073719 Collecting CTX engine logs Collecting logs from CTX is documented in the following document: http://www.cisco.com/en/US/docs/telepresence/tx/exchange_system/1_0/install_admin/logs_cli.html In this case we will collect ctc-engine logs which display main SIP information about SIP Proxy calls. admin:file list activelog /ctc/log/cisco/ctc-engine.log* detail 14 Jun,2011 21:24:26 66,881,911 ctc-engine.log 12 Jun,2011 07:17:27 104,857,611 ctc-engine.log.1 08 Jun,2011 05:54:06 104,857,649 ctc-engine.log.2 dir count = 0, file count = 3 admin:file get activelog /ctc/log/cisco/ctc-engine.log* recurs Please wait while the system is gathering files info ...done. Sub-directories were traversed. Number of files affected: 3 Total size in Bytes: 276623235 Total size in Kbytes: 270139.88 Would you like to proceed [y/n]? y SFTP server IP: 126.96.36.199 SFTP server port : User ID: gogasca Password: ******************* Download directory: / The authenticity of host '188.8.131.52 (184.108.40.206)' can't be established. RSA key fingerprint is a3:8c:1d:e1:a8:a7:c2:60:a9:fa:19:a9:de:df:ce:09. Are you sure you want to continue connecting (yes/no)? yes Transfer completed Reviewing CTX engine logs Once you have captured the engine logs, the next step is to identify the following: 1. Understand which SIP resources are involved in the call. 2. Obtain conference ID and use Meeting Diagnostics to obtain more details about the call. http://www.cisco.com/en/US/docs/telepresence/tx/exchange_system/1_0/release_notes/rn_102.html#wp1031458 3. Collect information about the devices involved: Calling number Called number Timestamp In this example we will analyze a call from a TelePresence endpoint dialing directly into CTX Exchange and landing in a CTMS server. Calling number: 14082323488 Called number: 14082323400**22556607 Timestamp: Around 17:00 hrs PST We downloaded ctc-engine logs from CTX engine server Using CTX Diagnostics tool we can find which server handle that call, using procedure described above. Once you obtain ctc-engine logs, those will contain plain SIP messages which will help you track all information related to the call routing and handling of calls via CTX SIP engine server. A very useful tool is the ctx log parser and sip viewer which can help you visualizing call flow in seconds. The above diagram show all SIP resources involved: 1. SBC 10.35.195.50 2. CTMS 10.35.194.151 3. SIP Engine 10.35.194.201 We can see 2 different SIP Call IDs, in order to identify SIP dialogs, CTX engine will use Cisco-GUID, in this case our GUID is: Cisco-Guid: 92F53F3EA44-3AA9BDC100D-9BA344A0C71-29661072130 Once the call is recieved by SBC, CTX engine application will attach Cisco-GUID in case there is no field containing it already, this will be used for tracking the call when is sent to multiple resources. For example in case call is handled to IVR then to a TPS server we will insert Cisco-GUID in both SIP INVITEs. By using CTX engine logs, CTX log parser, Cisco Guid and CTX Diagnostics we have powerful and fast tools to obtain information about calls in our system. For this call we can conclude in seconds we can see the SIP BYE message is coming from SBC, so now we have good information in order to analyze logs deeper. (Logs attached) CTX engine logs parser When reading SIP Calls for multiple Cisco products you face the challenge to go through multiple files parsing information manually. The more complex the call flow is, the most difficult to track problems at SIP signaling level. When analysis of call drops is critical this tool can give you a good overview of the calls. Not Cisco supported This Perl program goal is a module parser to feed sip viewer. Which is in charge of drawing call information: Features Parse Cisco CTX engine logs ctc-engine.log files http://www.cisco.com/en/US/products/ps11276/index.html Look for Calling number Look for SIP URI Look for SIP Call-ID Support for calls coming from SBC Support for calls coming from Broadworks This first version provides support for new Cisco TelePresence Exchange Next version will support: Cisco TelePresence Multipoint Switch CTMS Cisco TelePresence CTS Multiple file reading (fixed) Requirements MAC OS 10.6.X and up or Linux based system Perl 5.x and up Java 1.6 and up Download location http://code.google.com/p/ctx-log-parser/downloads/list Installation notes Download shell script ciscoparser (Latest version) Download Perl script ctxparser.pl (Latest version) Download Perl script mail.pl Download sip-viewer from: http://code.google.com/p/sip-viewer/ Create dependencies folder (i.e. mkdir dependencies) In dependencies folder place perl files and sip-viewer-XXX.jar Edit following from shell script if necessary: PARSER=dependencies/ctxparser.pl SIPVIEWER=dependencies/sip-viewer-1.5.0-jar-with-dependencies.jar Usage ./ciscoparser filename -sip ./ciscoparser ctc-engine.log ./ciscoparser -d foldername -sip ./ciscoparser -d ../logs ./ciscoparser filename -c callingnumber -sip ./ciscoparser ctc-engine.log -c 14082323488 ./ciscoparser filename -u sipuri -sip ./ciscoparser ctc-engine.log -u email@example.com ./ciscoparser filename -i sipcallid -sip ./ciscoparser ctc-engine.log -i BW1228250320305111714537240@10.1.2.100 ./ciscoparser filename -sip <Display detailed SIP Messages> ./ciscoparser ctc-engine.log -sip ./ciscoparser -d foldername -sip -c | -u | -i | -sip ./ciscoparser -d ../logs -i sipcallid [-sip]
... View more
You'll need to use an HDMI splitter to get two or more external displays. The AV
expansion box has this capability, but in the 1300 HDMI ports are used for the
left and right camera. You'll need to order another AV expansion box or just use a supported 3rd party HDMI splitter
... View more