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: 

Continue reading

IPv6 Unified Communications

Hello,

In this post I want to update you with what is available today when implementing Unified Communications on an IPv6 network.

What you need to retain from this post, is that IPv6 is available today when deploying Cisco Unified Communications, and it can be enable in a few easy steps. (Let’s agree that this would be first done in a lab though 😉

Configuring the UC server

The Ethernet interfaces of the UC server can be configured both in CLI and GUI [fig. 1]. This configuration is at OS level. An important note here is that Cisco UC-OS is a Common Application Run-time for most existing Cisco UC products, meaning that once a feature is available in it, it can be exposed and used by any UC applications.

with CLI, enable IPv6 :

set network ipv6 service enable

set a static IPv6 server address :

set network ipv6 static_address <addr> <mask>

review IPv6 address settings :

show network ipv6 settings

Or using the UCOS GUI, as showed below. This is done in OS administration; under Settings > IP > Ethernet IPv6

ucv6_srv_cfg

Configuring the CUCM, at the application level for phone and intra-cluster communications

The IPv6 address can be used for both phone to UC server and between server communications [fig. 2]. This is required configuration for every server in the cluster where you wish to use IPv6.

Either a AAAA record or IPv6 address can be used for the IPv6 name. In case of AAAA, your DNS (v4 and v6) will need to provide resolution for it.

under System > server

ucv6_ucm_cfg

Enabling IPv6 for IP Phones to Server communications

You will first need to enable IPv6 cluster-wide, and then have the option of setting your signaling and media preference parameters either cluster-wide [fig. 3] or per group of phone [fig. 4]

under System > Enterprise Parameters

ucv6_ent_param_cfg

under Device > Device Settings > Common Phone Profile

ucv6_common_device_profile


SIP trunking

SIP trunk can be configured directly on CUCM or on an IOS VoIP gateway or SBC (like CUBE). More details on SIP trunks are covered in this previous post.

SIP trunking is fully supported in both IPv6 only and dual-stack depending of your needs. Both SIP Early Offer or Delayed Offer with ANAT or without ANAT are supported.

Today the recommended addressing mode would be dual-stack leaving the option to select one or the other thru ANAT.

IPv6 destination address and SRV records can be used in configuration.

A few work on ANAT:  Alternative Network Address Types (RFC 4091)

ANAT is an application layer mechanism that permit the offer of both IPv4 and IPv6 address in the SIP invite (mid:1 and mid:2) as well as indicating a preference (group:ANAT 2 1) where here mid:2 is the preferred choice.

SIP INVITE with SDP ( Early Offer)

a=group:ANAT 2 1
m=audio 18356 RTP/AVP 0
c=IN IP4 192.0.2.1
a=mid:1
m=audio 16462 RTP/AVP 0
c=IN IP6 2001:db8:aaaa::987:65ff:fe01:234b
a=mid:2

Then in the SIP answer  200 (OK) with SDP, shown below, the remote end replied saying, ok I can do IPv6, as group:ANAT 2 indicate. And to further indicate this, the UDP port number for IPv4 is set to zero.

a=group:ANAT 2
m=audio 0 RTP/AVP 0
c=IN IP4 192.168.1.1
a=mid:1
m=audio 16462 RTP/AVP 0
c=IN IP6 2001:db8:bbbb::123:45ff:fe32:191d
a=mid:2

So ANAT gives us an application aware, very flexible way to inter-connect multiple call-agents (could be both in your enterprise or between you and a service provider or another enterprise)

In conclusion

UCv6 is available today, and despite full feature set are not fully available yet, you can already start testing and validating this deployment. IPv6 only IP phones can be deployed today and be a starting point to help you save your IPv4 addresses.

Cisco has about 10 customers using it in production environment today. And we expect to provide a full featured UCv6 solution within the next 2 years.

Jerome

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

%d bloggers like this: