Webinar on Design & Implementation of SIP Trunking using Cisco’s SBC – CUBE

A recording of last week’s webinar on designing and implementing SIP trunking using Cisco’s SBC- CUBE solution is now available.

Many enterprises are looking at SIP trunk implementation because of cost savings, network efficiency, rich business to business collaboration and end-to-end Unified Communications deployment. Due to the challenges around security, interoperability, session management and performance, it is becoming a best practice to deploy a session border controller (SBC) to ensure these challenges are addressed.

This session will provide an in-depth understanding of how to design and implement Cisco’s Enterprise SBC – Cisco Unified Border Element (CUBE). It will include an in-depth procedural approach on how to connect to SIP trunks in five easy steps using CUBE. The session will also identify some of the monitoring and troubleshooting tools and how to utilize them to quickly isolate most commonly seen problems.

Register and watch a playback of this great session on the link below:

http://tools.cisco.com/gems/cust/customerSite.do?METHOD=E&LANGUAGE_ID=E&PRIORITY_CODE=4&SEMINAR_CODE=S15366

Advertisements

Cisco 880 and 892F ISR platforms support CUBE SIP trunking

The Cisco 800 ISR support SIP trunk connectivity, including demarcation and interworking, based on Cisco Unified Border Element (CUBE), Cisco’s Session Border Controller. The CUBE feature license on the Cisco 880 and 892F ISR is available as a bundled offer to simplify ordering and network capacity planning. The CUBE IP-IP Voice gateway functionality for connecting to SIP trunking services may be used as a replacement for PRI or FXO voice connectivity to the Service Provider.

The 880 series support upto 15 Sip-to-Sip sessions, the 892F up to 25 Sip-to-Sip sessions.

More info on supported features of CUBE on the 880 router can be found here

 
 

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

%d bloggers like this: