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

Advertisements

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.

%d bloggers like this: