Trusted Relay Point configuration

The Cisco Unified Communications system can be deployed in a network virtualization environment. Cisco Unified Communications Manager enables the insertion of trusted relay points (TRPs). The insertion of TRPs into the media path constitutes a first step toward VoIP deployment within a virtual network.

The underlying network infrastructure comprises one of the key shared assets in an overall network design. A number of customer use cases require support for network infrastructure virtualization, such as the following examples:

-Guest internet access

-Partner access

-Departmental or divisional separation

-Subsidiaries/mergers and acquisitions

-Application segregation (data/voice)

All these applications include a requirement to maintain traffic separation on the network device as well as between network devices.

Traffic separation translates into concepts such as Virtual Routing and Forwarding (VRF). VRF allows multiple instances of a routing table to co-exist within the same router at the same time. In a virtualized network, these different routing domains, or VRFs, typically cannot communicate directly without transiting through the data center.

This situation challenges applications such as Cisco Unified Communications, where devices in the data VRF domain, such as software endpoints running on PCs, need to communicate directly with hard phones in the voice VRF domain without hairpinning media in the data center and without directly exposing the voice and data VRFs to each other.

Below a sample configuration off TRP.  This sample setup will force softclient RTP streams (voice or video) through the MTP control point in the router. In this router you might want to add additional security settings (FW, ACL, QOS,…). We will focus here on the basic TRP configuration in the  Cisco callmanager and  ISRG2 router.

Basic Principle:

Setup:

As you can see in this setup we make a direct call between a Cisco EX90 and the CUPC client. Both devices are registered to the Callmanager 8.6.

 

Configurations: 

Specifications-Based Hardware Support – VMware considerations

Since a while we support UC virtualization on Cisco, HP and IBM servers apart from the Cisco validated UCS configurations (Tested Reference Configurations or TRCs). This is referred to as “specs-based” hardware support. For these configurations we will not provide sizing guidelines as we do with the TRCs.  The configuration is supported as long as the requirements in term of CPU (vCPU and CPU type), memory and storage capacity and performance are respected. Although this looks very interesting, there are some considerations you should be aware of when going for a specs-based deployment over a Cisco TRC-based installation. In order to be able to support such a deployment that has not been thoroughly tested, TAC will need to be able to use some advanced VMware management tools to debug and analyze the virtual environment. This requires VMware vCenter, which is therefore mandatory for specs-based systems. This has an important influence on the cost of the VMware licenses.  In any doubt about the sizing of the WMware hosts and the number of application they can run, or whenever the pricing of the required VMware licenses is a potential issue, we recommend using the Cisco validated UCS TRCs.  In terms of VMware you are even allowed to use the free edition of vSphere as the hypervisor for them.  For any information on UC on UCS please visit www.cisco.com/go/uc-virtualized.

SIP Trunking for Enterprise IP Communications

More and more SIP trunk services appear in the market. A SIP trunk is a direct connection of your Cisco Unified Callmanager to a Service provider over IP, via SIP. A SIP trunk allows a company to replace the traditional ISDN lines in a centralized manner. This means fewer PSTN circuits and less circuit termination hardware. Moreover it’s easier and quicker to provision for additional capacity, especially if you have multiple sites. From a capacity perspective idle trunk capacity can be re-used by another location. In future video calls and communications can include high-fidelity experiences between two different companies or organizations leading to greater voice, video, and data convergence.

For people not familiar with SIP the following video shows a basic introduction:

A question that immediately pops up, if I connect my enterprise to a public service, is how to protect it? What about connectivity to different providers?

Typically a Session Border Control is placed between your voice infrastructure and the public sip trunk service.
The Cisco Unified Border Element (Enterprise Edition) is Cisco’s enterprise optimized Session Border Controller. The Cisco Unified Border Element (CUBE) interconnects Unified Communications networks securely, flexibly and reliably. CUBE enables end-to-end voice, video, and data between independent unified communications networks. Deploying CUBE is essential for routing voice calls beyond the enterprise boundary to Service Providers. CUBE could be enabled on existing Cisco Integrated Services Router (2800,2900,3800 or 3900 series).

The following video explains the benefits of a Cisco CUBE:

Let’s look at this sample sip trunk communication to give you a better feel on the technical side. In this example a user behind the Cisco Unified CallManager (CUCM) is making a call to the PSTN.

The Cisco CUBE in the middle, between the Cisco CUCM and the SP SIP trunk Service, works as a back-to-back SIP User Agent.
At the start of the flow the CUCM is sending an invite to the Cisco CUBE. In this case an invite with a delayed offer is made. The initial SIP invite contains no Session Description Protocol (SDP) as it is left to the destination to propose the media codec (note:starting from CUCM release 8.5 early offer is available as well). Often the SP’s SIP trunk expects an invite with a SDP included (early offering). Here is a typical example of the role of the Cisco Cube, which adapts the SIP packet/flow.  

The invite packet coming from the CUCM will have the following main parts:

INVITE sip:02582XXXX@10.127.127.40:5060 SIP/2.0;…Via: SIP/2.0/TCP 10.127.127.4:5080;
From: <sip:02XXXXX05@10.127.127.4>
( Calling number & CM Ip address  )
To: <sip:02582XXXX@10.127.127.40>
( Called number & CUBE Ip address )
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK,…
CSeq: 101 INVITE …
(Call Sequence 101)
Call-Info: <sip:10.127.127.4:5080> …
Contact: <sip:02XXXXX05@10.127.127.4:5080;transport=tcp>…

To change from early offer to delayed offer the Cube will have a config like:

voice service voip
allow-connections sip to sip
sip
early-offer forced  ← The cube will send a SIP invite with Early-Offer (EO) on the Out-leg.

Furthermore the SIP trunk provider often expects a certain phone number format. Using correct translation rules, profiles on the dial-peers the Cisco CUBE gets the job done:

voice translation-rule 100
rule 1 /^0/ /+32/

voice translation-profile Normalize1
translate calling 100
translate called 100

dial-peer voice 101 voip
description Outbound sip calls to SP Trunk
translation-profile outgoing Normalize1
destination-pattern 0[23456789]…….
session protocol sipv2
voice class codec 1
(refers to codecs supported and will be proposed in SDP)
session target ipv4:10.127.127.200

The outgoing SIP invite from the Cisco Cube in this case will change into:

INVITE sip:+322582XXXX@10.127.127.200:5060 SIP/2.0
(In this case the  config cube ‘normalized the number’ to +32…)
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK,…
From: <sip:+322XXXXX05@10.127.127.40>
To: <sip:+32582XXXX@10.127.127.200>
(SIP Trunk IP address .200)
Contact: <sip:+322XXXXX05@10.127.127.40:5060
CSeq: 101 INVITE
(A Message body  (SDP) is now added by the CUBE:)
IN IP4 10.127.127.40
am=audio 18096 RTP/AVP 8 18 0
(18096=port for RTP stream   8= G.711 Alaw, 18= G.729 0= G.711 Ulaw)
rtpmap:8 PCMA/8000
rtpmap:18 G729/8000
fmtp:18 annexb=no
(format specific parameter in this case to indicate G.729 no vad)
rtpmap:0 PCMU/8000

.
In this more detailed view we have seen one example of the role the Cisco Cube can play in SIP trunk connectivity. The Cisco CUBE is capable of more complex adaptations as a real SBC.
If you want more information on the Cisco CUBE go to:
www.cisco.com/en/US/partner/products/sw/voicesw/ps5640/index.html

People who are interested in all the details of SIP trunking, could also have a look at an excellent Cisco Press book called ‘SIP Trunking‘:
www.ciscopress.com/title/1587059444

The Power of Collaboration Extended to Virtualized Desktops

Cisco Virtualization Experience Infrastructure ( VXI ) is the first solution to combine Cisco Collaboration, Cisco Borderless Networks and Cisco’s Data Center Architectures, creating an unsurpassed offering that eliminates the feature gaps of existing virtualization solutions.

Cisco Virtualization Experience Client endpoints are a critical element of this new solution.

Workers demand access to data, applications, and services anywhere, at any time, and across a
diversity of operating systems, device form factors, networking environments, and work preferences. At the same time, workers expect an uncompromised and unencumbered user experience, with rich media and collaboration services.

Cisco delivers on these requirements with Cisco Virtualization Experience Clients.

Picture 1: Sample of typical CISCO 2100 endpoint in white  integrated to high end IP Phone:

Picture 2: Sample of typical CISCO 2200 endpoint in white :

Picture 3: Sample of typical CISCO CIUS Video  endpoint  :

These endpoints provide workers with secure, real-time access to business applications and content — anytime, anywhere — without compromise of the rich collaborative user experience for which Cisco is known.

CITRIX tm on RDP/ICA as well as VMWARE tm PCoIP are supported on VXC clients.

You can read more on Cius in one of our previous post

More info at http://j.mp/hLAFl9

SAF: Service Advetisement Framework

Service Advetisement Framework (SAF) is a method to transport discovery information that would typically resides locally across Wide Area Networks. A SAF-enabled network will transport encapsulated messages and distribute those as it they were part of an IP routing protocol.

Current Cisco implementation leverage EIGRP as a transport medium, independent of the actual routing protocol; could be a BGP, OSPF or IS-IS routed network.

The first application I want to spend a bit more time on is Call-Control Discovery.

Problematic with a large number Call-agent is to have them inter-working and in particular adjusting dial-plan amongst and between them. Previous to SAF, two options were offered as depicted below:

Fully meshed network of h.323 or SIP trunks

Centralized SIP proxy or h.323 gatekeeper

You’ll note that in both case the operational overhead and technical complexity can ramp up pretty quickly as the number of call-agents to inter-work is growing.

Cisco Unified Communications is using a new service, CCD, that leverages SAF to exchange call routing information, automatically, between multiple SAF-enabled call control systems (like CUCM, CUCME, CUBE). This permits those systems to update their call routing table dynamically.

SAF enabled network

The call-control, being a SAF-client, is sending CCD information to the first connected SAF-forwarder, a router in this case. CCD is contained in a SAF Advertisement, itself having a header and ‘service data’ payload.

Terminology:

SAF Client: any application wishing to advertise a service to the network or request a service from the network or both
SAF Forwarder: router feature – provides relationship between client and framework, stores service information and propagates it to other forwarders
Service: any information that a SAF client wishes to advertise and “consume” (e.g., dial plans for CCD)
SAF Advertisement: carries service information, consists of SAF Header and Service Data
Non-SAF Node: any router that does not run the SAF protocols

How does it work ?

In the following example, you have the San Jose site updating, via the SAF-enabled  network, the New-York office with its call routing information.

Then New-York office is also sending its CCD to the SAF-enabled network, and by which San Jose call-control also gets updated call routing information.

Now a third call-control, London, is added to the scheme, the CCD does not need to be re-send by the call-control as it’s the SAF-agent that will update the new call-control, without other intervention. In the meantime, London’s CCD will be propagated across the SAF-enabled network.

If for any reason the IP path becomes unavailable to a specific call agent, the network will update itself the call routing information, alerting the other call-control to use the PSTN path to reach those location.

And the beauty of this, it all happened without any administrative actions with regards to the call-routing…. great isn’t it  🙂

Stay tuned to an upcoming post on how to configure CUCM to use SAF.

Borderless Collaboration #3: Cisco VPN Phone

Hello,

In this third article about Borderless Collaboration, we will discuss about the Cisco VPN Phone solution, one of the new feature of the Cisco UC Manager 8.0 release.

Cisco VPN Phone is a cost-effective solution for extending the reach of your UC environment outside the perimeter of your Firewall. It permits to establish a Secure connection from any location to your Intranet. It adds an other option for the teleworkers or small branches office communications needs and complements the existing teleworkers offering  like CVO, AnyConnect or  OfficeExtend.

Cisco VPN Phone is a fully enabled VPN connection between remote locations and HQ. It is, unlike its predecessor Phone Proxy, encapsulating all the traffic from the phone. Permitting the use of phone xml apps (like Extension Mobility)  ontop of secure signaling and VoIP.

How it helps your business ?

Cisco VPN Client for IP Phones is easy to install, to use and to manage. No more headaches when providing Unified Communications to teleworkers, remoter contact center agents, small branches, temporary deployment, sales events or disaster recovery plants.

You will be able to implement remote connectivity without extra hardware then an IP Phone !

Let’s take the example of road winter maintenance keeping role; a group of people have to wait for the GO from HQ before staring spreading salt on the road. now if those people can wait, truck loaded, at home instead of staying in a regional dispatch station…

What do you get ?

Happier employees, diverse location for quicker and more efficient actions and lower costs from keeping the employees at home !

How to implement it ?

With only a few simple configuration steps you will activate the VPN client on IP Phones (and #1 being already covered for you data VPN needs)

Step 1: Configure Anyconnect VPN access on ASA to provide network access. This can be achieve using CLI or ASDM GUI

Step 2: Upload VPN certificates to UC Manager: from OS admin page, choose Security > Certificate Management.

Step 3: Configure the VPN gatway in UC Manager: in CUCM admin page, under Advanced Features > VPN > VPN Gateway.

Step 4: Create a VPN group in Advanced Features > VPN > VPN Group.

Step5: Configure the (optional) VPN Profile under Advanced Features > VPN > VPN Profile.

Step 6: Assign VPN group and profile into common phone profile. this is done under Device > Device Settings > Common Phone Profile

Then apply the configuration on your IP Phone

You can use your Cisco IP Phone to establish a VPN connection.

VPN client is supported on 7942G, 7945G, 7962G, 7965G, 7975G and 99xx/89xx IP Phones. Require UC Manager 8.0.1 and Phone firmware equal or above 9.0(2)SR1S.

More information can be found at:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/security/8_0_2/secugd/secuvpn.html

https://supportforums.cisco.com/docs/DOC-9124

Borderless Collaboration #2: Cisco UCM Session Manager Edition

Hello,

In this second post about Borderless Collaboration I wanted to discuss with you the Cisco Unified Communications Manager Session Management Edition (UCM-SME); what it is and what additional benefits it brings to large corporate network.

SME is an aggregation solution for IP Trunking and UC applications. It will help simplify large design, save cost on infrastructure and make your company ready for extending UC to business partners and customers.

SME is before all an evolution of the existing concept of session management; like were class4 switching for TDM, gatekeeper for h.323 comm’s, SIP proxy to IP Tel, …

SME will help create service blocks for UC services like Unified Messaging, Call Recording, Presence and Enterprise Instant Messaging (EIM), as well as integration of legacy TDM Pbx durign migration phase and interoperability with standard-based IP-Pbx vendor (SIP,  h.323, Q.Sig, …)

So for a company having a large number of branches, a multi-vendor IP Pbx environment, a migration plan from TDM to IP based telephony, a migration plan from TDN to IP trunking to SP, the integration of Web2.0 tools into the Communication process and vice-et-versa or just a desire for simplifying dial-plan, SME is the right choice.

SME will act as a proxy for communications between disparate systems. IP trunk have to be established between those system, that will further interrogate SME for call routing decision.

Learn more:

Product page: http://www.cisco.com/en/US/products/ps10661/index.html

CUCM 8.0 SRND: https://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/models.html#wp1089795

UCM Session Manager in action

Borderless Collaboration #1: Inter-company Media Engine [IME]

Hello,

This is the first chapter of a series of articles that will discuss the different solutions to answer the growing need of extended the reach of Collaboration outside of your Enterprise perimeter.  We will look at a set of solutions that Cisco offer or will be offering soon, including IME, SAF, UCM Session Manager, RSVP CAC, VPN phone, and so on.

In this first article, I’d like to introduce you with Cisco Intercompany Media Engine or Cisco IME.

IME provides an innovate way of connecting VoIP networks between different companies. The solutions relies on Cisco Unified Communications Manager (UCM) and Adaptive Security Appliance (ASA).

With IME, we remove the barrier of current “Islands of VoIP” interconnected by PSTN, and provide a richer and better experience with completely end-to-end over IP communications.

The goal is to permit one to make a end-to-end IP phone call over Internet in a secure, automatic and dynamic way; the number of the different company are learned automatically by the systems and subsequent call are placed over the IP Network, here a secure VPN tunnel over the Internet.
In case the IP connectivity would be lost, the call will be rolled-back to use the PSTN.  Call Admission Control (CAC) is also used to monitor the number of call permitted over the IP network and is able to re-route call to an alternate path (PSTN or other) ensuring all calls maintain a good quality.

The IME solution is based on the UCM 8.0.1 release interworking with ASA 8.3.1. The ASA provides the P2P component, allowing to connect to external companies. Between companies, both VoIP signaling (SIP trunk in TLS) and VoIP payload are encrypted (sRTP).

Cisco has develop the ViPR Access Protocol (VAP) in a client/server mode. The UCL running VAP client and ASA the VAP server. The ViPR server is effectively an automated provisioning service. It will self-learn new VoIP routes to particular phone numbers, and push those routes into UCM. The ViPR server is there to form a worldwide P2P network. (P2P protocol: RELOAD)

Enterprises willing to join the IME global network will first configure Cisco IME and Enroll DID patterns to IME Servers from CUCM using VAP.  Then the IME server will cache the DID patterns and publish those patterns onto P2P network. Once the first Call to a Number over PSTN is done, the IME Server on the Orig side performs call validation with Term side using the validation capability of P2P Protocol. Upon successful validation, Orig side IME Server securely pushes learned route to CUCM via VAP. Next call placed to that DN is a Secure Business to Business call over the IME SIP Trunk instead of PSTN

Furthermore, Cisco is helping its customers to benefit the best of this innovative solution by providing a number of bootstrap server (~SIP proxy here) in order to facilitate interconnection between companies.

Now only a discovery to one of Cisco’s bootstrap server is required to access all of the existing known VoIP network, making the ROI faster after the adoption of Cisco’ IME.

Learn more:

Product page: http://www.cisco.com/en/US/products/ps10669/index.html

and http://docwiki.cisco.com/wiki/Cisco_Intercompany_Media_Engine_–_Cisco_Unified_Communications_Manager_Not_Using_Cisco_IME_Routes

IME in action: