Editor’s Note: TS Newsletter readers get a 35% discount on Akhil Behl's book CCIE Collaboration Quick Reference. See discount code at the end of this article.   Cisco Collaboration solutions offer much more than just traditional ways to communicate within and outside of an enterprise network. Complementing the next generation communication solutions such as SIP gateways, SIP endpoints, Jabber, WebEx etc., Cisco Unified Communications Manager (CUCM) has evolved to a degree that it can work and integrate with multiple platforms and can serve multitude endpoints. This article highlights features and benefits of the recent inclusion – SIP Uniform Resource Identifier (URI) based dialing as well as support for Intercluster Lookup Service (ILS) Networking.   SIP URI Dialing In context of Cisco Collaboration, SIP URI can be best compared to an email address such as abc@xyz.com. The URI format is usually general form: sip:user:password@host:port;uri-parameters?headers. This format has been used by SIP dominant networks for years and is now gaining universal popularity because of its globally routable (DNS-based) nature/capability. A SIP URI can be automatically imported from LDAP (provided the cluster is integrated with an LDAP server) such as a mail or the msRTCSIP-primaryuseraddress attribute. Following are salient features of SIP URI: In a SIP URI a user name is optional however, CUCM does not support URIs without a user name URI parameters and headers are optional The user name is case sensitive however host is case insensitive (RFC 3261). This parameter is configurable starting CUCM 9.1 (under Enterprise Parameters – URI lookup policy) A URI can be dialed with or without the domain name, because  calling “abc”, adds “cisco.com” automatically from domain name configured in the Organizational Top Level Domain service parameter in CUCM as shown in figure 1-1. Figure 1-1: CUCM Clusterwide Domain Configuration   SIP URIs help securely extend your entire Collaboration infrastructure’s communications because almost all current SIP phone loads, all Telepresence endpoints, and Jabber 9.6+, support URI dialing. To configure a SIP URI, browse to Device > Phone and select a phone and in-turn a line for which SIP URI is to be configured as shown in figure 1-2. Figure 1-2: SIP URI Configuration   While SIP URI is a native dialing method in SIP-based video environment and allows better integration with other call controls where URI dialing is native dialing habit (e.g. VCS); it does have certain limitations. For example, URIs cannot be used for PSTN calls, therefore they need to be mapped to E.164. URIs also have limited endpoint support (older phones do not support SIP URI). While dialing within the same domain and cluster is not an issue; however, dialing with a flat hierarchy in a domain and multiple clusters does pose a problem. In other words, supporting URI addressing between multiple clusters can be an issue and an administrative overhead. This issue is taken care of via Inter-Cluster Lookup Service (ILS). The next section dives into specifics of ILS Networking.   ILS Networking Inter-Cluster Look-up Service (ILS) is a cluster-wide service in CUCM that when configured on and between CUCM clusters, synchronizes information throughout the “ILS Network”. Before getting to the nuts and bolts of ILS, let’s understand what value it adds to SIP URI dialing between clusters. Without ILS: URI dialing wouldn’t work well in a multi-cluster environment because of mass configuration requirements, routing loops, call setup delays, and so on. It will be necessary to duplicate patterns on each cluster. Manual configuration of Jabber clients to a specific cluster will be a mandate as the Jabber client needs to get directed to the cluster where it will be registered and get its configuration.   With ILS: Support for URI addressing and Home Cluster Discovery becomes much easier. Administrative overhead in a multi-cluster environment is greatly reduced. It allows for adoption of powerful dial plan concepts such as TEHO.   The ILS Network Establishment (which is essentially peering relationships) enables URI and Global Dial Plan replication, for example alternate number advertising. In an ILS network, ILS Node Types can be: Stand-Alone Hub Spoke CUCM clusters participating in ILS network form a hub and spoke topology; each cluster is either a hub or spoke. Hubs must be fully meshed with spokes. Figure 1-3 shows various ILS topologies. Figure 1-3: ILS Network Topologies   Using ILS, each node replicates its URIs to its neighbor’s (or Hubs) and also announces “SIP route string” together with the URIs. CUCM clusters establish ILS Exchange and then URI information is flooded. Then, each cluster creates a table with URIs and associated SIP route string(s). Finally, SIP route strings are routed by SIP route patterns. Note: Before configuring ILS it is important to Set Organization Top Level Domain (OTLD) to match a single corporate domain name and the Cluster Fully Qualified Domain Name (CFQDN) to match the host names of respective clusters/nodes. For example, if cisco.com is the OTLD then the EU cluster can be named as eu.cisco.com and the US cluster can be named as us.cisco.com. This arrangement is illustrated in figure 1-1. Considering that not all endpoints support or need to support SIP URI, the notion of blended addressing comes into perspective, where traditional numeric Directory Numbers (DNs) and (alphanumeric) SIP URIs coexist on endpoint DN. In such case, CUCM will relay an alphanumeric hostname of a caller to the called endpoint as a part of the SIP header information. This enables the called endpoint to return the call using the received or missed call list. In mixed environments where numeric and SIP URIs exist, it’s important to always have FQDNs in SIP requests for all calls. For endpoints registered with CUCM the FQDN in SIP requests will be set to the OTLD configured in the enterprise parameters. The next section briefly discusses blended addressing concept in CUCM.   Blended Addressing In CUCM SIP, URIs are assigned to DNs where DNs are the “primary” identity of the devices. When an environment is configured with both a DN and an SIP URI, you may wonder whether it is the DN or the SIP URI that is the “correct” identity to be presented during calls. Well, the answer is – It mainly depends on the devices involved in the call and if they prefer one over the other. For example, video endpoints use SIP URIs over DNs. “Blended Identity” is the combination of a DN and an SIP URI. CUCM can build missing pieces by looking at the primary URI configured on a DN if the calling party dialed a DN and searched for a DN that has the primary URI when the calling party called using a URI. It is the configuration of trunks on CUCM that defines whether the calling and called party information contains a DN, a URI, or blended addressing. This is shown in figure 1-4. Figure 1-4: SIP Trunk Configuration to Deliver DN and URI   Summary Cisco Collaboration solutions offer a rich feature that is user friendly and allows dialing by URI (username, email address etc.) instead of remembering the phone number(s). This allows enterprise to scale their communication network and administrators to effectively manage the solution. SIP URI dialing has been used for years and is now available at the fingertips of Cisco Collaboration users. In addition, blended addressing helps keep both traditional directory number-based and new name-based dialing together. On the other hand, ILS networking solves the issue of overlapping URI addressing schemes in a multi-cluster environment. Together, SIP URI, ILS Networking, and blended addressing give a powerful, scalable, robust, and highly interoperable collaboration network at disposal of administrators and users alike.     Akhil Behl is a Solutions Architect with Cisco Services, focusing on Cisco Collaboration and Security Architectures. He leads Collaboration and Security projects and service delivery worldwide for Cisco Advanced Services and the Collaborative Professional Services (CPS) portfolio. He's played major role in service conception and creation for various services within Cisco Advanced Services. He has Pre-Sales to Sales to Professional Services to Delivery to Post Sales experience with expertise in Consulting, Advisory, and Guidance services. He has extensive experience in Borderless, Collaboration and Data Center portfolio. Prior to his current role, he spent ten years working in various roles at Linksys as a Technical Support Lead, as an Escalation Engineer at Cisco Technical Assistance Center (TAC), and as a Network Consulting Engineer in Cisco Advanced Services. Akhil has a bachelor of technology degree in electronics and telecommunications from IP University and a master’s degree in business administration from Symbiosis Institute. He is dual Cisco Certified Internetwork Expert CCIE # 19564 in Voice and Security. He also holds many other industry certifications, such as PMP, ITIL, VCP, CCNA, CCSP, CCVP, ISO/IEC 27002, TOGAF and CEH. Over the course of his career, he has presented and contributed at various industry forums such as Interop, Enterprise Connect, Cloud Connect, Cloud Summit, Cisco Networkers, and Cisco SecCon. He also has several research papers published in various national and international journals including IEEE. Akhil is an avid blogger and maintains blogs on Unified Communications Security http://ucsecurity.wordpress.com and CCIE Collaboration http://cciecollaboration.blog.com He is the author of the following Cisco Press books:CCIE Collaboration Quick Reference, and Securing Cisco IP Telephony Networks         CCIE Collaboration Quick Reference By Akhil Behl Series: Quick Reference Published: May 20, 2014 ISBN-10: 0-13-384596-6ISBN-13: 978-0-13-384596-9 Published by Cisco Press.       DISCOUNT: 35% off ciscopress.com for Cisco Technical Newsletter customers; use code CISCOTECH at checkout.   This Chalk Talk is featured in the July 2014 Cisco TS Newsletter. Subscribe now and get Tech Insights, Services Updates, and TAC-inspired Technical documents  delivered to your inbox each month! ... View more

Editor’s Note: TS Newsletter readers get a 35% discount on Akhil Behl's book CCIE Collaboration Quick Reference. See discount code at the end of this article.   Cisco Collaboration (aka Cisco Unified Communications) solutions have come a long way since the conception of IP Telephony. With advancements in technology and the need to reduce economic and environmental impact, virtualization is well on way to become the core of all major technologies including Unified Communications. Cisco Collaboration solutions are now fully supported on Cisco UCS, with backend Nexus, storage, and Fibre Channel over Ethernet (FCoE) based systems complementing the next gen solutions. However, with inclusion and dependency on virtualized environments the issue of Quality of Service (QoS) remains to be understood as it is no longer physical switches, NICs, or application instances that are deployed; it is virtual switches (for example Nexus 1000V), virtual NICs, and virtual machines that are deployed as Cisco Collaboration solutions are increasingly virtualized.   QoS with UC on UCS In today’s converged environments, every application and/or device may be marking the traffic originating from it. From UC applications to virtual switches to Cisco Unified Computing Server (UCS) to Fabric Interconnects (61XX, 62XX) every application/device is capable of marking traffic, however, it makes more sense to mark it closest to the source of the traffic and then carry those trust markings as such in the network. In general, the rule of thumb applied to bare metal servers and physical infrastructure still applies in case of virtualized environments: Voice marking for QoS is classified as CoS 5 or DSCP 46 (EF). Videoconferencing marking for QoS is classified as CoS 4 or DSCP 34 (AF41, CS4). Call signaling for voice and videoconferencing is classified as CoS 3 or DSCP 24 (CS3).   At a high level, table 1-1 defines the traffic classification that can be defined for a virtualized Cisco Collaboration setup. Table 1-1: Traffic Classification for Virtualized Cisco Collaboration Network   A virtual machine running as a base for a UC application can connect to following virtual switches: Cisco Nexus 1000V Switch: Requires the Enterprise Plus Edition of VMware ESXi and is a distributed virtual switch. Nexus 1000V offers policy-based virtual machine connectivity and enhanced QoS. Local VMware vSwitch: This vSwitch is available with all editions of VMware ESXi hypervisor and is limited to the local physical blade server on which the virtual machine is running. Distributed VMware vSwitch: This vSwitch is available only with the Enterprise Plus Edition of VMware ESXi hypervisor and can span multiple physical blade servers. In this article, we will cover Nexus 1000V as this is the most commonly used and viable solution in a multiple server/application Cisco Collaboration network where juggling CoS to DSCP and vice-versa is required. Moreover, we will emphasize Cisco UCS’s capabilities to support QoS.   Nexus 1000V – Where and Why Do I Need It? The Nexus 1000V is the edge switch on the virtual access layer and therefore provides a full quality of service (QoS) solution that includes: Traffic classification and marking Traffic policing (rate-limiting) Class-Based Weighted Fair Queuing for congestion management. UCS Fabric Interconnects (FIs) create fibre-channel priority QoS class for traffic destined for the SAN Switch, which is set to FC QoS class that has no drop and marks traffic as CoS 3. With UC applications marking traffic (media and signaling) as L3 DSCP values only, it becomes challenging to prioritize or de-prioritize the traffic when UCS FIs as well as VMware (local or distributed) vSwitches are not designed to map L3 DSCP values to L2 CoS values. This issue is resolved with the help of the Nexus 1000V software switch which  has the ability to map L2 CoS values to L3 DSCP values and vice versa. Example 1-1 illustrates the configuration of Nexus 1000V to map DSCP to CoS (L3 to L2) markings. Example 1-1: Nexus 1000V MQC to Prioritize L3 Traffic Transiting to FI and SAN class-map type qos match-all media-audio   match dscp EF class-map type qos match-any media-video   match dscp CS4   match dscp AF41 class-map type qos match-all signaling   match dscp CS3 ! policy-map type qos voice-qos   class media-audio     set cos 5   class media-video     set cos 4   class signaling     set cos 3 ! port-profile type vethernet  VM_INTERFACES   service-policy type qos input voice-qos   Figure 1-1 depicts the association of Nexus 1000V with vEthernet interface for a VM on VCenter.   So, as you can see, Nexus 1000V makes it very convenient to mark multiple traffic types and, at the same time, preserve the classification while the traffic transits form applications to FI/SAN or vice-versa. However, in case Nexus 1000V is not part of a solution in a UC network, you could create multiple virtual switches and assign a different CoS value for the uplink ports of each of those switches. In other words, each virtual switch would have uplink ports configured with a different CoS value (for example, vSwitch 1 with a CoS value of 5, vSwitch 2 with a CoS value of 4, and so on). In such case, each VM would be assigned to a virtual switch, however, that will limit the traffic to a certain class. This is not a workable solution for Cisco UC on UCS as applications mark different traffic in different classes. Hence, a leading practice recommendation is to leverage Nexus 1000V for end-to-end QoS in a Cisco Collaboration solution.   QoS on Cisco UCS – How Can I Go About It? Cisco UCS also offers the ability to mark traffic in various CoS values. Traffic classification in UCS is done on per vNIC basis. If you want a certain type of traffic to be treated a certain way, it needs its own vNIC(s).With the vNIC or vNIC template, you can configure the QoS policy you wish to put into effect on it. As discussed earlier, Nexus 1000V offers mapping CoS to DSCP and DSCP to CoS when the traffic is ingress and egress respectively to/from UC applications. QOS for the entire UCS Fabric is configured from the UCS Manager. By default 50 percent of the bandwidth is allocated for COS3 traffic. This includes the FCOE traffic (which is marked as COS3) and any other traffic that is marked COS3 value. This queue has a no-drop policy. The remaining 50 percent is best effort for all other traffic. Table 1-2 gives an overview of the different configurable classes in UCS.   Table 1-2: UCS Fabric QoS Classes Figure 1-2 shows the UCS based QoS classes that can be configured to keep CoS consistent across the virtual network. Figure 1-2: Cisco UCS-based QoS Classes   Because leading practice recommends avoiding overlap with voice/video signaling traffic marked as CoS 3, FCoE traffic should be marked at a different CoS value. QoS policies can be created and properties for each policy can be set such that when a policy is applied to a vNIC the traffic is treated per the policy. Figure 1-3 shows the definition of Platinum policy.   Figure 1-3: Cisco UCS-based QoS Policy The challenge with marking traffic in UCS is that multiple traffic classes cannot be linked to VM’s unless each VM is tagged to a specific vNIC. Moreover, the traffic markings are L2 CoS markings only, which still need Nexus 1000V to resolve the markings to L3 DSCP markings and vice-versa.   Summary While virtualization of Cisco Collaboration solutions bring a rich feature set, and data center optimization (power, rack space, management), it also introduces certain key challenges that must be addressed, QoS is one of the major roadblocks if not properly planned and managed. QoS has its own twist and flavor with virtualized UC networks and requires diligent planning and deployment to ensure that the end-users do not feel anything out of place when it comes to voice media and signaling QoS requirements. This article focused on deployment of QoS in virtualized Cisco Collaboration solution; explicitly on Cisco Nexus 1000V and Cisco UCS. Nexus 1000V is an important component of any virtualized UC solution and must be strongly considered for inclusion in design and deployment. Cisco UCS offers QoS however, it is limited in QoS capabilities without support of Nexus 1000V, that enables L2 CoS to L3 DSCP conversion which the FI is unable to perform. Nexus 1000V and UCS together build a strong foundation for enabling QoS in virtualized Cisco Collaboration environments.   Akhil Behl is a Solutions Architect with Cisco Services, focusing on Cisco Collaboration and Security Architectures. He leads collaboration and security projects and service delivery worldwide for Cisco Services and the Collaborative Professional Services (CPS) portfolio. He's played major role in service conception and creation for various services within Cisco Advanced Services. He has Pre-Sales to Sales to Professional Services to Delivery to Post Sales experience with expertise in Consulting, Advisory, and Guidance services. He has extensive experience in Borderless, Collaboration and Data Center portfolio. Prior to his current role, he spent ten years working in various roles at Linksys as a Technical Support Lead, as an Escalation Engineer at Cisco Technical Assistance Center (TAC), and as a Network Consulting Engineer in Cisco Advanced Services. Akhil has a bachelor of technology degree in electronics and telecommunications from IP University and a master’s degree in business administration from Symbiosis Institute. He is dual Cisco Certified Internetwork Expert CCIE # 19564 in Voice and Security. He also holds many other industry certifications, such as PMP, ITIL, VCP, CCNA, CCSP, CCVP, ISO/IEC 27002, TOGAF and CEH. Over the course of his career, he has presented and contributed at various industry forums such as Interop, Enterprise Connect, Cloud Connect, Cloud Summit, Cisco Networkers, and Cisco SecCon. He also has several research papers published in various national and international journals including IEEE. He is the author of Cisco Press books: CCIE Collaboration Quick Reference, and Securing Cisco IP Telephony Networks. He is an avid blogger and maintains blogs @ http://cciecollaboration.blog.com/ and http://ucsecurity.wordpress.com     CCIE Collaboration Quick Reference By Akhil Behl Series: Quick Reference Published: May 20, 2014 ISBN-10: 0-13-384596-6 ISBN-13: 978-0-13-384596-9 Published by Cisco Press.   DISCOUNT: 35% off ciscopress.com for Cisco Technical Newsletter customers; use code CISCOTECH at checkout.   This article is featured in the May 2014 issue of the Cisco TS Newsletter. Are you subscribed?   ... View more

  Introduction     Akhil Behl is a solutions architect with Cisco Services, focusing on Cisco Collaboration and Security architectures. He leads collaboration and security projects and service delivery worldwide for Cisco Services and the Collaborative Professional Services (CPS) portfolio. He has played a major role in service conception and creation for various services within Cisco Advanced Services. He has presales to sales to Professional Services to delivery to post sales experience with expertise in consulting, advisory, and guidance services. He has extensive experience in borderless, collaboration, and data center portfolios. Prior to his current role, he spent 10 years working in various roles at Linksys as a technical support lead, as an escalation engineer at the Cisco Technical Assistance Center (TAC), and as a network consulting engineer in Cisco Advanced Services.   Akhil has a bachelor of technology degree in electronics and telecommunications from IP University and a master's degree in business administration from Symbiosis Institute. He is dual Cisco Certified Internetwork Expert CCIE 19564 in voice and security. He also holds many other industry certifications, such as PMP, ITIL, VCP, ISM, CCNA, CCSP, CCVP, ISO/IEC 27002, TOGAF, and CEH.   Over the course of his career, Akhil has presented and contributed at various industry forums such as Enterprise Connect, Cloud Connect, Cloud Summit, Interop, Cisco Networkers, and SecCon. He has several research papers published in various national and international journals, including IEEE. He is an avid blogger and maintains a blog about unified communications security at http://ucsecurity.wordpress.com.   Akhil is the author of the Cisco Press title “Securing Cisco IP Telephony Networks” (ISBN 1-58714-295-3) http://click.linksynergy.com/fs-bin/click?id=aV8WWcTd0Yc&offerid=145238.10000326&type=3&subid=0   Expert Aashish Jolly was helping Akhil Behl to answer few of the questions asked during the session.   You can download the slides of the presentation in PDF format here. The related Ask The Expert sessions is available here. The complete recording of this live Webcast can be accessed here.     Cisco Unified Communications Manager (CUCM) Certificates & Cisco Unity Connection (UC) Security   Q. What is the function of CAPF? A. Certificate Authority Proxy Function (CAPF) is the core of CUCM security and enables secure signaling with Transport Layer Security (TLS) and secure media with Secure Real-Time Transport Protocol (SRTP) on the CUCM cluster. CAPF enables the endpoints in order to establish secure signaling with the CUCM cluster and SRTP between themselves. CAPF is also the root for the Locally Significant Certificate (LSC).   Q: Does SRTP use symmetric key cryptography? A: SRTP uses asymmetric keys. TLS also uses   Q: What is the difference between the Identity certificate and the Certificate Authority (CA) certificate? A: The CA Certificate is a self-signed certificate generated by a trusted third party (CA). It is used to sign the Certificate Signing Request (CSR) and installed on the client before the signed certificate can be installed. The Identity certificate is a certificate that results from CA signing the CSR, and it is installed on the server. Q: Can you describe the phone downloading certificate process? A: Refer to the IP Phone Security and CTL (Certificate Trust List) document for that information.   Q: When is the Phone-Site Administrator Security Token (SAST)-Trust certificate used? A: The CTL client signs the CTL file with the private key (SAST) from the security token (USB token). As a result the CTL file is created with the CTL client and signed by the Cisco Site Administrator Security Token (SAST) Q: Hostname=FQDN. Does this mean that, when you create servers, you have to use a Fully Qualified Domain Name ( FQDN) instead of IP addresses in order to create a  CUCM cluster? A: When you create a cluster, you enter the IP address if you do not use a Domain Name Server (DNS). If you want to use an external CA in order to sign the certificate of your CUCM node, you need to use the FQDN or the hostname. This further implies that CUCM may not use an FQDN with DNS suffix however, DNS server records be created to resolve CUCM hostname to IP address therefore, avoiding any need for DNS client on CUCM.   Q: If CA can create certificates with IP addresses instead of FQDN, can you keep the IP addresses in CUCM? A: Yes, the Subject Name can be the IP Address. In most cases, subject name is kept at FQDN or hostname and Alt Subject name can be added (if requried) as FQDN/hostname or IP address.   Q: Are certificate chains upload supported by CUCM? A: Certificate chains can be uploaded to CUCM. Refer to the Uploading a Certificate or Certificate Chain section of the Security document.   Q: Do you need to restart the CUCM service after you install Call Manager certificates for secure conferencing? A: Yes, you need to restart the CUCM service. Q: How is the VPN phone certificate affected when a CUCM upgrade is performed? A: I deally the VPN certificate should not expire if a VPN phone works remotely, is connected to the CUCM, and is upgraded. However, if the certificate expires, the phone must be brought back to the enterprise premises, and you can download the new certificate over the trust-established connection. The CUCM upgrade does not impact the VPN phones remotely because the upgrade does not replace any certificates.   Q: Will CUCM support Simple Certificate Enrollment Protocol (SCEP)? A: SCEP is not supported yet and SCEP support isn't on the roadmap.   Q: Online Certificate Status Protocol (OCSP) certificate verification happens only during the certificate upload process. Why does it not occur during the certificate lifetime like all other products that use OCSP, such as the Cisco Identity Services Engine (ISE)? Will this be changed in a future UCM release? A: This is not committed yet. Q: Will CUCM, Cisco Unified Presence Server (CUPS), or Jabber support the Network Device Enrollment Service (NDES) (Microsoft)? Do CUPS, CUCM, or another Cisco application support SCEP? A: These are not supported as of today and not on the Roadmap.   Q: What about SCEP in UC? A: SCEP is not used commonly with Cisco devices/applications and is not currently supported on any UC applications. Q: Is it expected to use SCEP in any UC product? A: There is no SCEP support on any UC application at this time.     Related Information Slides of the Live Webcast Webcast Recording Ask the Expert event Cisco Support Voice community CUCM Administration Guide - Security Release 8.6(1) ... View more

Agenda   An overview of Cisco Unified Communications PKI Insights into Cisco Unified Communications Manager certificates Understanding Cisco Unified Communications Manager certificates & their functions Managing Cisco Unified Communications Manager certificates   Webcast related links: Ask the Expert Event FAQ from the live webcast Slides from the live webcast ... View more

In today’s world, organizations are striving to stay connected with their employees. With businesses going 24X7, no organization can afford to have employees disconnected from the enterprise network and not able to access corporate voice or data resources. Understanding that modern day organizations need secure connectivity for their remote employees as well as telecommuters, Cisco has come out with the concept of VPN client on physical Cisco Unified IP Phone. Yes, you read it right, it’s an SSL client installed on a Cisco IP Phone that enables remote workforce and on-the-go employees to get access to corporate UC resources. Cisco VPN Phone Overview This new feature is called Cisco VPN Phone, and it leverages Cisco AnyConnect SSL client built into an IP phone’s firmware to connect to enterprise edge firewall (Cisco ASA). Cisco VPN Phone feature has numerous benefits,such as: No additional hardware is required by the end-user except for the IP Phone itself. Cisco Unified IP Phone with Cisco VPN client can get online from wherever Internet access is available. Cisco VPN Phone feature is supported with both Cisco ASA and Cisco IOS routers. Cisco VPN Phone can secure voice and video media along with IP Phone service traffic. This gives additional flexibility to go from a voice-only call to a video call. VPN tunnel applies only to voice, video, and IP phone services. The PC connected to PC port is responsible for authenticating and establishing its own tunnel with VPN client software (Split Tunneling) All settings are configured via CUCM administration, thereby providing ease of administration. Figure 1 gives an overview of Cisco VPN Phone solution: Figure 1: Cisco VPN Phone Overview The Cisco Unified IP Phone creates an AnyConnect-based SSL tunnel to Cisco ASA, where all voice pertinent data is sent into the tunnel, whereas all regular data (non-voice traffic) is sent directly to the internet (split-tunnel) for the PC connected behind the IP Phone. When the SSL-tunneled data reaches Cisco ASA, matching the tunnel group, it decrypts the traffic and sends unencrypted traffic to CUCM (signaling as SCCP) and to the IP Phone within enterprise (media as RTP). Cisco VPN Phone Configuration Prerequisites There are certain pre-requisites that must be met before Cisco VPN Phone can be configured on a Cisco ASA and subsequently on a CUCM cluster. Cisco VPN Phone client is supported on 7942G, 7945G, 7962G, 7965G, 7975G, and 99xx and 89xx series IP phones. For a list of phones supported with your CUCM version, you can check Feature: Virtual Private Network Client from CUCM Administration GUI > Cisco Unified Reporting > System Reports > Unified CM Phone Feature List > Generate a new report option. The minimum requirements for support Cisco VPN Phone are as following: CUCM version 8.0.1 or above are supported. IP Phone SCCP firmware version 9.0(2) SR1S or later Cisco ASA IOS 8.0.4 or later Anyconnect VPN Pkg 2.4.1012 or later Two licenses,  i.e. a premium AnyConnect license and AnyConnect for Cisco VPN Phone license is required for Cisco ASA. The part number for AnyConnect for Cisco VPN Phone is L-ASA-AC-PH-55XX (55XX is firewall model number such as 5505, 5510, 5580 and so on). Detailed Steps to Configure Cisco VPN Phone Step 1.  Ensure that ASA Security Appliance Software version is 8.0(2) or greater UCASA# show version Cisco Adaptive Security Appliance Software Version 8.2(2)99 Device Manager Version 6.3(1) Step 2. Confirm ASA is licensed for Cisco AnyConnect VPN Phone and AnyConnect Software 2.0 or greater is installed in flash. UCASA#show disk0: <output ommited> 140 2154944 Mar 18 2013 03:38:06 anyconnect- win-3.1.00495-k9.pkg Step 3. Generate self signed certificate on cisco ASA. UCASA (config)# crypto key generate rsa label vpnphone UCASA (config)# crypto ca trustpoint asatrust UCASA (config)# encrollment self UCASA (config)# fqdn sslphone.cisco.com UCASA (config)# subject-name CN=sslphone.cisco.com UCASA (config)# keypair vpnphone UCASA (config)# crypto ca enroll asatrust noconfirm UCASA (config)# ssl trust-point asatrust outside Step 4. Enable AnyConnect access on the interface that will terminate SSL VPN Connections. UCASA (config)# webvpn UCASA(config-webvpn)# enable outside UCASA(config-webvpn)# svc enable Step 5. Create a VPN Pool for assigning the VPN Phones unique IP addresses. UCASA(config)# ip local pool SSLPool 192.168.250.1 - 192.168.250.254 mask 255.255.255.0 Step 6. Create a Group Policy, which specifies the configuration parameters that will be applied to the clients when they connect to Cisco ASA. UCASA(config)# group-policy SSLVPNPhone internal UCASA(config)# group-policy SSLVPNPhone attributes UCASA(config-group-policy)# dns-server value 10.60.70.80 UCASA(config-group-policy)# vpn-tunnel-protocol svc UCASA(config-group-policy)# default-domain value cisco.com UCASA(config-group-policy)# address-pools value SSLPool Step 7. Create a Connection Profile and Tunnel Group for the AnyConnect Client Connections, and assign an alias. UCASA(config)# tunnel-group SSLPhone type remote-access UCASA(config)# tunnel-group SSLPhone general-attributes UCASA(config-tunnel-general)# default-group-policy SSLVPNPhone UCASA(config-tunnel-general)# tunnel-group SSLPhone webvpn-attributes UCASA(config-tunnel-webvpn)# group-alias SSLPhoneClient enable UCASA(config-tunnel-webvpn)# group-url https://10.81.80.200/VPNPhone enable Step 8. Enable alias/tunnel group selection for SSL VPN Connections. UCASA(config-tunnel-webvpn)# webvpn UCASA(config-webvpn)# tunnel-group-list enable Step 9. Add user(s) to ASA local DB or use the  TACACS+/RADIUS backend (if available). UCASA(config)# username vpnclient password C1sc0123 UCASA(config)# username vpnclient attributes UCASA(config-username)# service-type remote-access Step 10. Export the ASA crypto certificate and save it as a .pem file on your laptop/PC. UCASA(config)# crypto ca export vpnphone identity-certificate The PEM encoded identity certificate follows: -----BEGIN CERTIFICATE----- MIIB8zCCAVygAwIBAgIEAoMjTTANBgkqhkiG9w0BAQUFADA+MRowGAYDVQQDExFl <output omitted> -----END CERTIFICATE----- Step 11. Upload the ASA Certificate on CUCM. Go to Cisco Unified OS Administration > Security/Certificate Management Select "Upload Certificate" Upload the ASA certificate to "Phone-VPN-Trust" Figure 2: Cisco ASA to CUCM Certificate Upload Step 12. Go to CUCM Administration > Advanced Features > VPN > VPN Gateway. Select the certificate that was uploaded earlier from ASA to CUCM, and ensure it’s listed under VPN gateway certificates. Figure 3: CUCM VPN Gateway Configuration Step 13. Go to CUCM Administration > Advanced Features > VPN > VPN Group. Under VPN Gateway Information, add the VPN Gateway created earlier. Figure 4: CUCM VPN Group Configuration Step 14. Go to CUCM Administration > Advanced Features > VPN > VPN Profile. Ensure that the client authentication method is set to ‘user and password’ (similar to what was configured in Cisco ASA). Figure 5: CUCM VPN Profile Configuration Step 15. Go to CUCM Administration > Device > Device Settings > Common Phone Profile. Assign ‘Common Phone Profile’ to VPN phone. Cisco VPN Phone configuration is now complete. After connecting the phone from within the enterprise environment, the IP Phone can be handed over to the user. The end user has multiple options to connect to VPN on Cisco Unified IP Phone: The user can select between VPN client (mode) enabled or disabled in the phone menu. With disabled mode on the VPN client; the phone makes no attempt to create a VPN connection and proceeds with the standard startup sequence. With enabled mode on the VPN client (and auto-network detection) the phone tries to detect the type of network and attempts to initiate a VPN connection only if the phone is outside of the enterprise network i.e. on a public network. With enabled mode on the VPN client and auto-network detection disabled the phone attempts to initiate a VPN connection. This allows the VPN connection to be established within the secure enterprise network. The following figure gives an overview of user end configuration to initiate a VPN connection from IP Phone: Figure 6: End USer VPN Phone -- VPN Connection Initiation Summary Cisco VPN Phone is a promising feature that is easy to deploy and maintain. It gives end users the flexibility to connect to the enterprise network and leverage voice resources from anywhere; wherever there is Internet connectivity. Moreover, it’s a solution that replaces older Phone Proxy and the need to have a VPN client side hardware, thereby reducing complexity of deploying a remote worker solution and helping lower costs. Author's Biography Akhil Behl is a Solutions Architect with Cisco Services, focusing on Cisco  Collaboration and Security Architectures. He leads collaboration and  security projects and service delivery worldwide for Cisco Services and  the Collaborative Professional Services (CPS) portfolio. He's played  major role in service conception and creation for various services  within Cisco Advanced Services. He has Pre-Sales to Sales to  Professional Services to Delivery to Post Sales experience with  expertise in Consulting, Advisory, and Guidance services. He has  extensive experience in Borderless, Collaboration and Data Center  portfolio. Prior to his current role, he spent ten years working in  various roles at Linksys as a Technical Support Lead, as an Escalation  Engineer at Cisco Technical Assistance Center (TAC), and as a Network  Consulting Engineer in Cisco Advanced Services. Akhil  has a bachelor of technology degree in electronics and  telecommunications from IP University and a master’s degree in business  administration from Symbiosis Institute. He is dual Cisco Certified  Internetwork Expert CCIE # 19564 in Voice and Security. He also holds  many other industry certifications, such as PMP, ITIL, VCP, ISM, CCNA,  CCSP, CCVP, ISO/IEC 27002, TOGAF and CEH. Over the  course of his career, he has presented and contributed at various  industry forums such as Enterprise Connect, Cloud Connect, Cloud Summit,  Interop, Cisco Networkers, and SecCon. He has several research papers  published in various national and international journals including IEEE. He is an avid blogger and maintains a blog on Unified Communications Security - http://ucsecurity.wordpress.com Securing Cisco IP Telephony Networks Series: Networking Technology: IP Communications Published: Aug 31, 2012 Copyright 2012 ISBN-10: 1-58714-295-3 ISBN-13: 978-1-58714-295-6 Published by Cisco Press This article is featured in the December 2013 issue of the Cisco TS Newsletter. Are you subscribed? ... View more