deploying sip trunks with cube - amazon web...

Deploying SIP Trunks with Cisco Unified Border Element (CUBE/vCUBE) EnterpriseHussain Ali, CCIE# 38068 (Voice, Collaboration)Technical Marketing Engineer

Dilip Singh, CCIE# 16545 (Collaboration)Technical Leader

BRKCOL-2125

• SIP Trunking and CUBE Overview

• CUBE Architecture (Physical & Virtual)

• Transitioning to SIP Trunking using CUBE

• Advanced features on CUBE (Call Recording, Multi-Tenancy, HA)

• CUBE Serviceability

• Futures & Key Takeaways

Agenda

CUBE Overview

© 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public

CUBE (Enterprise) Product Portfolio

2900 Series ISR-G2 (2901, 2911, 2921, 2951)

ASR 1004/6 RP2

Active Concurrent Voice Calls Capacity

CP

S

<5

8-12

50-150

14-16K<50 500-600 900-1000

3900 Series ISR-G2 (3925, 3945)

17

3900E Series ISR-G2 (3925E, 3945E)

2000-2500

20-35

4

800 ISR

7000-10,000

50-100

12K-14K

ASR 1002-X

4500-6000

ISR 4451-X

ASR 1001-X

4000

ISR 4431

ISR-4K (4321, 4331)

ISR 4351

Introducing CUBE on

CSR

vCUBE [Performance

dependent on vCPU and

memory]

Note: SM-X-PVDM module

supported on XE3.16 or

later for ISR 4K platforms

BRKCOL-2125 4


CUBE Session Capacity Summary

Platform CUBE SIP-SIP Sessions (Audio)

NanoCUBE (8XX and SPIAD Platforms) 15 - 120

2901 – 4321 100

2911 – 2921 200 – 400

4331 500

2951 600

3925 – 3945 800 – 950

4351 1000

3925E – 3945E 2100 – 2500

4431 3000

4451 6000

ASR1001-X 12000

ASR1002-X 14000

ASR1004/1006 RP2 16000

For Your

Reference

BRKCOL-2125 5


Introducing IOS-XE Release 16 • New OS from the platform team with the intent of consolidating OS’ on different

product portfolio

• UX will be the same as IOS-XE, no difference to end user

• IOS-XE Release 16.3.1 support for UC (CUBE, CME, SRST)

Impacts XE based (ASR1K, ISR4K, and vCUBE) platforms

There will be no CUBE 11.5.1 for the XE based platforms [ASR1K, ISR4K, vCUBE]. CUBE 11.5.2 (July 2016 release) will have newer and March 2016 features for the XE based platforms introduced in IOS-XE release 16.3.1

IOS-XE 16 requires a minimum of ASR1001-X, 1002-X, 1004/1006 RP2, ESP20 (Embedded Service Processor, SIP40 (SPA Interface processor)

It will include all features up to and including IOS-XE 3.17 as well

• Due to new hardware requirements, customers will have the following migrations options as IOS-XE 3.17 rebuilds will stop by June 2017

Replace unsupported ASR1K hardware and upgrade to IOS-XE 16.3.1 or later and continue to enjoy new feature set/support for any issues

Drop using new feature set and move back to IOS-XE3.16 long maintenance release for longer support

BRKCOL-2125 6


ISR G2 ASR 1K / ISR-4K/vCUBE (CSR)

CUBE Vers. 2900/ 3900 FCS CUBE Vers. IOS XE Release FCS

11.1.0 15.5(3)M July 2015 11.1.0 3.16 15.5(3)S July 2015

11.5.0 15.6(1)T Nov 2015 11.5.0 3.17 15.6(1)S Nov 2015

CUBE Vers.

2900/ 3900 FCSCUBE Vers.

IOS XE Release 16 2 FCS

11.5.14 15.6(2)T14 Mar 2016 N/A 3 16.2.13 Mar 2016

11.5.2 15.6(3)M1 Dec 2016 11.5.23 16.3.2/16.4.13 Nov 2016

EOL EOL EOL 11.6.0 16.5.1 Mar 2017

7

CUBE Software Release Mapping

2 IOS-XE 16 requires a minimum of ASR1001-X, 1002-X, 1004/1006 RP2, ESP20 (Embedded Service Processor, SIP40 (SPA Interface

processor)

3 IOS-XE release 16.2.1 does not support CUBE functionality on the platforms. There is no CUBE version 11.5.1 for the XE based

platforms. All CUBE features from 11.5.0 (IOS-XE 3.17) and earlier versions along with CUBE 11.5.1 (March 2016 release) on ISR G2

are included in CUBE release 11.5.2 for the IOS-XE based platforms, IOS-XE release 16.3.1 [July 2016 release]

4 IOS 15.6(2)T will show CUBE Release version to be 12.0.0 but due to DDTS# CSCuz43735, rebuilds for this release train will align

to CUBE release 11.5.1, that is 15.6(2)T1/T2/T3/T4 and so on will be CUBE version 11.5.1


ISR G2 CUBE EntASR Parity

with ISR

ASR 1K Series

CUBE Vers. 2900/ 3900 FCS CUBE Vers. IOS XE Release FCS

8.5 15.1(2)T July 2010 <50% 1.4 3.2 15.1(1)S Nov 2010

8.6 15.1(3)T Nov 2010 <50% 1.4.1 3.3 15.1(2)S March 2011

8.7 15.1(4)M April 2011 ~50% 1.4.2 3.4 15.1(3)S July 2011

8.8 15.2(1)T July 2011 ~70% 1.4.3 3.5 15.2(1)S Nov 2011

8.9 15.2(2)T Nov 2011 >80% 1.4.4 3.6 15.2(2)S Mar 2012

9.015.2(3)T/

15.2(4)MMar 2012 >85% 9.0 3.7 15.2(4)S July 2012

9.0.1 15.3(1)T Oct 2012 >95% 9.0.1 3.8 15.3(1)S Oct 2012

9.0.2 15.3(2)T Mar 2013 >95% 9.0.2 3.9 15.3(2)S Mar 2013

9.5.1 15.3(3)M1 Oct 2013 >95% 9.5.1 3.10.1 15.3(3)S1 Oct 2013

10.0.0 15.4(1)T Nov 2013 >95% 10.0.0 3.11 15.4(1)S Nov 2013

10.0.1 15.4(2)T Mar 2014 >95% 10.0.1 3.12 15.4(2)S Mar 2014

CUBE Software Release Mapping – Earlier Releases

8


ISR G2 CUBE EntASR Parity

with ISR

ASR 1K / ISR-4K Series

CUBE Vers.

2900/ 3900 FCSCUBE Vers.

IOS XE Release FCS

10.0.2 15.4(3)M July 2014 >95% 10.0.2 3.13 15.4(3)S July 2014

10.5.0 15.5(1)T Nov 2014 >95% 10.5.0 3.14 15.5(1)S Nov 2014

11.0.0 15.5(2)T Mar 2015 >95% 11.0.0 3.15 15.5(2)S Mar 2015

CUBE Software Release Mapping – Earlier Releases

9


Proven Interoperability and Interworking with

Service Providers Worldwide

Cisco Interoperability Portal:

www.cisco.com/go/interoperability

• Validated with Service

Providers World-Wide

• Independently Tested

with 3-Party PBXs in

tekVizion Labs

• Standards basedVerified by

CUBE Interoperability

BRKCOL-2125 10

http://www.cisco.com/go/interoperability







Agenda

CUBE Call Flow


CUBE Call Processing

Actively involved in the call treatment, signaling and media streams

SIP B2B User Agent

Signaling is terminated, interpreted and re-originated

Provides full inspection of signaling, and protection against malformed and malicious packets

Media is handled in two different modes: Media Flow-Through

Media Flow-Around

Digital Signal Processors (DSPs) are only required for transcoding (calls with dissimilar codecs)

IP

CUBE

CUBE

IP

Media Flow-Around

Only Signaling is terminated on CUBE

Media bypasses the Cisco Unified Border Element

Media Flow-Through

Signaling and media terminated by the Cisco Unified Border Element

Transcoding and complete IP address hiding require this model

BRKCOL-2125 13


Cisco Unified Border Element Basic Call Flow

1. Incoming VoIP setup message from originating endpoint

2. This matches inbound VoIP dial peer 1 for characteristics such as codec, VAD, DTMF method, protocol, etc.

3. Match the called number to outbound VoIP dial peer 2

4. Outgoing VoIP setup message

Incoming VoIP Call Outgoing VoIP Call

dial-peer voice 1 voipdestination-pattern 1000session protocol sipv2 session target ipv4:1.1.1.1codec g711ulaw

dial-peer voice 2 voipdestination-pattern 2000session protocol sipv2session target ipv4:2.2.2.2codec g711ulaw

Originating Endpoint -

1000

TerminatingEndpoint –

2000

CUBE

voice service voip

mode border-element

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

BRKCOL-2125 14


CUBE

10001.1.1.1

20002.2.2.2

Incoming VoIP Call LegMatches an Incoming Dial-peer

Outgoing VoIP Call LegMatches an Outbound Dial-peer

INVITE /w SDP INVITE /w SDP

100 TRYING100 TRYING

VRF1 – 10.10.10.10 20.20.20.20 – VRF2

c= 1.1.1.1m=audio abc RTP/AVP 0

c= 20.20.20.20m=audio xxx RTP/AVP 0

180 RINGING180 RINGING

200 OK200 OK c= 2.2.2.2

m=audio uvw RTP/AVP 0c= 10.10.10.10m=audio xyz RTP/AVP 0

RTP (Audio)

ACKACK

1.1.1.1 10.10.10.10 20.20.20.20 2.2.2.2

Understanding the Call flow

BYE BYE

200 OK200 OK

BRKCOL-2125 15

CUBE ArchitectureISR G2 vs ASR1K vs ISR 4K vs vCUBE (CUBE on CSR)


ASR/ISR-4K & ISR-G2 Architecture Comparison

ISR: Pkt fwd’ing and signaling are handled by the same CPU

ASR: Pkt fwd’ing and signaling are handled by different CPUs

‒ ESP must be programmed or instructed by the control plane to do specific media functions

‒ Performed by Forwarding Plane Interface (FPI)

I/O ESP I/O

Kernel

IOS-XEIOS-XE

Msg I/f

Control Plane

Data (Forwarding) Plane

ASR/ISR-4K (IOS-XE) Architecture

RPIOS

CPU

I/O I/O

Control

Plane

Data Plane

ISR G2 Architecture

Sig

nalin

g

Sig

nalin

g

MediaBRKCOL-2125 17


Introducing vCUBE (CUBE on CSR 1000v)Architecture

• CSR (Cloud Services Router) 1000v runs on a Hypervisor – IOS XE without the router

Console Mgmt ENET Ethernet NICsFlash / DiskMemoryVirtual CPU

RP (control plane)

Chassis Mgr.

Forwarding Mgr.IOS-XE

Kernel (incl. utilities)

ESP (data plane)

Chassis Mgr.

Forwarding Mgr.

QFP Client / Driver

FFP code

Hypervisor

Hardware

vSwitch NIC

GE GE…X86 Multi-Core CPU Memory Banks

ESXi Container

CUBE signaling CUBE media processing

CSR 1000v (virtual IOS-XE)

BRKCOL-2125 18


Introducing vCUBE (CUBE on CSR 1000v) –Cont’d

• CSR1000v is a virtual machine, running on x86 server (no specialized hardware) with physical resources are managed by hypervisor and shared among VMs

• Requires APPX (No TLS/SRTP) or AX (All vCUBE features) CSR licensing package to access voice CLI and increase throughput from 100 kbps default. CUBE Licensing follows ASR1K SKUs and still trust based

• No DSP based features (transcoding/inband-RFC2833 DTMF/ASP/NR) available

• Specs based hardware supported but performance benchmarked for Cisco UCS B and C series only

• vCUBE Tested Reference Configurations [UCS base-M2-C460, C220-M3S, ESXi 5.1.0 & 5.5.0]. ESXi 6.0 supported with IOS-XE 16.3.1 or later







Agenda


SIP Trunk Pointing to CUBE

Step 1: Configure CUCM to route calls to the edge SBC

Standby

IP PSTNA

TDM PBX

SRST

CME

MPLS

Enterprise Branch Offices

Enterprise

CampusCUBE with High

Availability

Active

CUBE

CUBE

PSTN is now used only for emergency calls over FXO lines

• Configure CUCM to route all PSTN calls (central and branch) to CUBE via a SIP trunk

• Make sure all different patterns of calls – local, long distance, international, emergency, informational etc.. are pointing to CUBE

BRKCOL-2125 21


Step 2: Get details from SIP Trunk provider

Item SIP Trunk service provider requirementSample

Response

1 SIP Trunk IP Address (Destination IP Address for INVITES) 20.1.1.2 or DNS

2 SIP Trunk Port number (Destination port number for INVITES) 5060

3 SIP Trunk Transport Layer (UDP or TCP) UDP

4 Codecs supported G711, G729

5 Fax protocol support T.38

6 DTMF signaling mechanism RFC2833

7 Does the provider require SDP information in initial INVITE (Early offer required) Yes

8 SBC’s external IP address that is required for the SP to accept/authenticate calls

(Source IP Address for INVITES)

20.1.1.1

9 Does SP require SIP Trunk registration for each DID? If yes, what is the

username & password

No

10 Does SP require Digest Authentication? If yes, what is the username & password No


Step 3: Enable CUBE Application on Cisco routers

voice service voip

mode border-element license capacity 20 License count entered here not enforced though this CLI is

required to see “show cube” CLI output

allow-connections sip to sip By default IOS/IOS-XE voice devices do not allow an incoming

VoIP leg to go out as VoIP

2. Configure any other global settings to meet SP’s requirements

voice service voipmedia bulk-stats To increment Rx/Tx counters on IOS-XE based platforms. W/O this CLI, it will show 0/0

sipearly-offer forced

header-passing error-passthru

3. Create a trusted list of IP addresses to prevent toll-fraud

voice service voipip address trusted list Applications initiating signaling towards CUBE, e.g. CUCM, CVP,

ipv4 66.77.37.2 ! ITSP SIP Trunk Service Provider’s SBC. IP Addresses from dial-peers with “session target

ipv4 10.10.1.20/28 ! CUCM ip” or Server Group are trusted by default and need not be populated here

sipsilent-discard untrusted Default configuration starting XE 3.10.1 /15.3(3)M1 to mitigate TDoS Attack

1. Enable CUBE Application


Step 4: Configure Call routing on CUBE

IP PSTNA

TDM PBX

SRST

CME

MPLS

Enterprise Branch Offices

Enterprise Campus

CUBE with High

Availability

Active

Standby

CUBE

CUBE

PSTN is now used only for emergency calls over FXO lines

WAN Dial-PeersLAN Dial-Peers

BRKCOL-2125 24

• Dial-Peer – “static routing” table mapping phone numbers to interfaces or IP addresses

• LAN Dial-Peers – Dial-peers that are facing towards the IP PBX for sending and

receiving calls to & from the PBX

• WAN Dial-Peers – Dial-peers that are facing towards the SIP Trunk provider for

sending & receiving calls to & from the provider


WAN Dial-Peer Configuration

dial-peer voice 100 voip

description *** Inbound WAN side dial-peer ***

incoming called-number 408527….$

session protocol sipv2

voice-class sip bind control source gig0/1

voice-class sip bind media source gig0/1

codec g711ulaw

dtmf-relay rtp-nte

no vad

Outbound Dial-Peer for call legs from CUBE to SP


description *** Outbound WAN side dial-peer ***

translation-profile outgoing Digitstrip

destination-pattern 91[2-9]..[2-9]......$




session target ipv4:<SIP_Trunk_IP_Address>

codec g711ulaw

dtmf-relay rtp-nte

no vad

Specific to your DID range

assigned by the SP

Dial-peer for making long distance

calls to SP, based on NANP (North

American Numbering Plan)

Note: Separate outgoing DP to be created for Local, International,

Emergency, Informational calls etc.

Inbound Dial-Peer for call legs from SP to CUBE

Apply bind to all dial-peers when

CUBE has multiple interfaces.

Gig0/1 faces SP.

Translation rule/profile to strip the

access code (9) before delivering

the call to the SP

BRKCOL-2125 25


LAN Dial-Peer Configuration


description *** Inbound LAN side dial-peer ***

incoming called-number 9T




codec g711ulaw

dtmf-relay rtp-nte

no vad

Outbound Dial-Peer for call legs from CUBE to CUCM


description *** Outbound LAN side dial-peer ***

destination-pattern 408527….$




session target ipv4:<CUCM_IP_Address>

codec g711ulaw

dtmf-relay rtp-nte

no vad

CUCM sending 9 (access code) + All

digits dialed

SP will be sending 10 digits (NANP)

based on your DID that is being

delivered to CUCM

Inbound Dial-Peer for call legs from CUCM to CUBE

Apply bind to all dial-peers when

CUBE has multiple interfaces. Gig0/0

faces CUCM.

Default codec is G729 if none is

specified

Note: If more than 1 CUCM cluster exists, you will have to create multiple such LAN dial-peers with “preference CLI” for CUCM redundancy/load balancing as the

traditional way to accommodate multiple trunks


Step 5: SIP Normalization

SIP incompatibilities arise due to:

• A device rejecting an unknown header (value or parameter) instead of ignoring it

• A device expecting an optional header value/parameter or can be implemented in multiple ways

• A device sending a value/parameter that must be changed or suppressed (“normalized”) before it leaves/enters the enterprise to comply with policies

• Variations in the SIP standards of how to achieve certain functions

• With CUBE 10.0.1 SIP Profiles can be applied to inbound SIP messages as well

More information at http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/118825-technote-sip-00.html

Incoming Outgoing

INVITE

sip:[email protected]:5060

user=phone SIP/2.0

INVITE


SIP/2.0

voice class sip-profiles 100

request INVITE sip-header SIP-Req-URI modify "; SIP/2.0" ";user=phone SIP/2.0"

request REINVITE sip-header SIP-Req-URI modify "; SIP/2.0" ";user=phone SIP/2.0"

Add user=phone for INVITEs

Modify a “sip:” URI to a “tel:” URI in INVITEs

Incoming Outgoing

INVITE

tel:2222000020

SIP/2.0

INVITE


SIP/2.0


request INVITE sip-header SIP-Req-URI modify "sip:(.*)@[^ ]+" "tel:\1"

request INVITE sip-header From modify "<sip:(.*)@.*>" "<tel:\1>"

request INVITE sip-header To modify "<sip:(.*)@.*>" "<tel:\1>"

CUBE

CUBE

SIP profiles is a mechanism to normalize or customize SIP at the network border to provide interop between incompatible devices

BRKCOL-2125 27

http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/118825-technote-sip-00.html

https://cway.cisco.com/tools/SipProfileTest


Normalize Inbound SIP Message (Example 2)


request INVITE sip-header Diversion modify “sip:” sip:1234@


description Incoming/outgoing SP

voice-class sip profiles 700 inbound

Received:

INVITE sip:[email protected]:5060 SIP/2.0

………

User-Agent: SP-SBC

………

Diversion: <sip:9.44.44.4>;privacy=off;

reason=unconditional;screen=yes

……...

m=audio 6001 RTP/AVP 0 8 18 101

a=rtpmap:0 PCMU/8000

……...

Configure Inbound

SIP Profile to add a

dummy user part

Apply to incoming

Dial-peer

Received:

INVITE sip:[email protected]:5060 SIP/2.0

……….

User-Agent: SP-SBC

……….

Diversion: <sip:[email protected]>;

privacy=off;reason=unconditional;screen=yes

……….

m=audio 32278 RTP/AVP 18 8 101

a=rtpmap:0 PCMU/8000

………..

CUBE

RequirementSIP Diversion header must include a user portion

SIP INVITE received by CUBE SIP INVITE CUBE expects

Enable Inbound

SIP Profile feature

voice service voip

sip

sip-profiles inbound

For Your

Reference

SIP Profile Rule Tagging


SIP Profile – Feature Overview Existing Implementation

1. Insertion

New rules are always inserted at the end, there was no way to insert a rule at the beginning or in between existing rules.

Only way to achieve this is by removing the complete profile and configuring it again in the desired order.

2. Deletion

While deleting a rule User has to give complete no form of that rule.

If there are duplicate rules, always 1st one is deleted.

3. Modification

There is no direct way to modify an existing rule. User has to delete and reconfigure the profile.

4. Duplication

If the same profile/rules applied more than once, then the rules are be duplicated

BRKCOL-2125 30


SIP Profile Tagging EnhancementNew rule tagging mechanism is being introduced

1. Insertion :

New rules can be inserted at any position i.e at the beginning, at the end or in between existing rules by specifying rule tag number.

2. Deletion :

Rules can be deleted by giving no form of the rule with just the tag number.

3. Modification :

Any of the existing rules can be modified by specifying the rule tag number.

4. Duplication :

When a rule with an existing tag number is applied again, the rule will be over-written, without creating any duplicate rules.

BRKCOL-2125 31


A mechanism to automatically upgrade the legacy SIP Profile configurations to the new rule format has been provided. The following exec CLI is being provided to upgrade existing implementation

voice sip sip-profiles upgrade

A mechanism to automatically downgrade the SIP Profile configurations with the rule tags to non-rule format has been provided. The following exe CLI has been provided for this purpose

voice sip sip-profiles downgrade

Note: When SIP Profiles are configured in “rule <tag>” format and the IOS version is migrated to a version which does not have this capability, then all the SIP Profile configurations will be lost. Hence, it is advisable to execute voice sip sip-profiles downgrade before IOS version migration.

SIP Profile Tagging Enhancement – Cont’d

BRKCOL-2125 32


• For tagging the rules, an additional option of “rule <tag>” has been provided

SIP Profile Tagging – Configuration

CUBE(config)#voice class sip-profiles 1

CUBE(config-class)#?

VOICECLASS configuration commands:

exit Exit from voice class configuration mode

help Description of the interactive help system

no Negate a command or set its defaults

request sip request

response sip response

rule Specify the rule

CUBE(config-class)#rule ?

<1-1073741823> Specify the rule tag

before The rule to be inserted before

CUBE(config-class)#rule 1 ?

request sip request


The new

keyword “rule”

“tag” to be

provided with

rule keyword


• For inserting a rule between two rules, “before” option has been provided

SIP Profile Tagging – Configuration Cont’d


CUBE(config-class)#rule before ?

<1-1073741823> Specify the rule tag

CUBE(config-class)#rule before 3 ?

request sip request


• If rule <tag> option is used to configure a SIP Profile rule, then this rule can be deleted by specifying just the tag number instead of specifying the entire rule configuration.


CUBE(config-class)#no rule before <tag>

For inserting a rule

between two rules, the new before keyword

is being introduced

BRKCOL-2125 34


Configuration Example

• For tagging the rules:


rule 1 request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”

rule 2 request INVITE sip-header Supported Add “Supported: ”

• For inserting a rule between two rules using “before” option:

rule before 2 request INVITE sip-header To Modify “(.*)” “\1;temp=abc”



rule 2 request INVITE sip-header To Modify “(.*)” “\1;temp=abc”


before

option

The new rule has

been inserted

between #1 and

#3

BRKCOL-2125 35


• Auto-Upgrade : Exec command - “voice sip sip-profiles upgrade”

• Suppose we have the following rules configured:

request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”

request INVITE sip-header Supported Add “Supported: ”

request REGISTER sip-header Contact Modify “(.*)” “\1;temp=abc”

• After auto upgrade, the rules will be automatically upgraded as follows:



rule 3 request REGISTER sip-header Contact Modify “(.*)” “\1;temp=abc”

Configuration Example continued….

BRKCOL-2125 36


• Auto-Downgrade : Exec command - “voice sip sip-profiles downgrade”

• Suppose we have the following rules configured:



rule 3 request REGISTER sip-header Contact Modify “(.*)” “\1;temp=abc”

• After auto downgrade, the rules will be automatically downgraded as follows:

request INVITE sip-header Contact Modify “(.*)” “\1;temp=xyz”

request INVITE sip-header Supported Add “Supported: ”

request REGISTER sip-header Contact Modify “(.*)” “\1;temp=abc”

Configuration Example continued….

BRKCOL-2125 37

SIP Profile Support for Non-Standard Headers


SIP Profile support for Non-Standard Headers Introducing support for adding/copying/removing/modifying non-

standard SIP headers using SIP profiles

A new 'WORD' option has been added to the SIP Profiles CLI chain to allow the user to configure any non-standard SIP HeaderCUBE(config)#voice class sip-profiles 1

CUBE(config-class)#request INVITE sip-header ?

Accept-Contact SIP header Accept-Contact

…….

Via SIP header Via

WORD Any other SIP header name

WWW-Authenticate SIP header WWW-Authenticate

CUBE(config-class)#request INVITE sip-header WORD ?

ADD addition of the header

COPY Copy a header

MODIFY Modification of a header

REMOVE Removal of a header

CUBE(config-class)#request INVITE sip-header WORD ADD “MyCustomHeader : Hussain Ali”

The new “WORD”

option for specifying

unsupported headers







Agenda

CUBE Dial-PeersCall Routing


Understanding Dial-Peer matching Techniques:LAN & WAN Dial-Peers

• LAN Dial-Peers – Dial-peers that are facing towards the IP PBX for sending and receiving calls to & from the PBX

• WAN Dial-Peers – Dial-peers that are facing towards the SIP Trunk provider for sending & receiving calls to & from the provider

CUCM SIP Trunk ITSP SIP Trunk

CUBE

A

Outbound Calls Outbound WAN Dial-PeerInbound LAN Dial-Peer

IP PSTN

Inbound WAN Dial-PeerOutbound LAN Dial-PeerInbound Calls

BRKCOL-2125 42


Understanding Inbound Dial-Peer Matching Techniques

CUCM SIP Trunk SP SIP Trunk

CUBE

A

Inbound LAN Dial-Peer

IP

PSTN

Inbound WAN Dial-PeerInbound Calls

Outbound Calls

Match based on

Called Number

Match based on

Calling number

1Match Based on URI

of an incoming

INVITE message

Default Dial-Peer = 0

Exact Pattern

match

Host Name/IP

Address

User portion of

URI

Phone-number of

tel-uri

Received:

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-

tag="cid:[email protected]";;branch=z9hG4bK-23955-1-0

From: "555" <sip:[email protected]:5060>;tag=1

To: ABC <sip:[email protected]:5060>

Call-ID: [email protected]

CSeq: 1 INVITE

Contact: sip:[email protected]:5060

Supported: timer

Max-Forwards: 70

Subject: BRKUCC-2934 Session

Content-Type: application/sdp

Content-Length: 226

........

2

3

4

Priority

BRKCOL-2125 43


Understanding Outbound Dial-Peer Matching Techniques

Match based on

Called Number &

carrier-id target

Match Based on URI

of incoming INVITE

message & carrier-id

target

Received:







CSeq: 1 INVITE


Supported: timer

Max-Forwards: 70



Content-Length: 226

........

Match based on URI

of an incoming

INVITE message

Match based on

Called number


CUBE

A

Outbound LAN Dial-Peer

IP

PSTN

Outbound WAN Dial-Peer

Inbound Calls

Outbound Calls

Exact Pattern

match

Host Name/IP

Address

User portion of

URI

Phone-number of

tel-uri

1

2

3

4

Exact Pattern

match

Host Name/IP

Address

User portion of

URI

Phone-number of

tel-uri

Priority

CSCua14749 – Carrier-id CLI not working on XE based

platforms


Destination Server Group• Supports multiple destinations (session targets) be defined in a group and applied to

a single outbound dial-peer

• Once an outbound dial-peer is selected to route an outgoing call, multiple destinations within a server group will be sorted in either round robin or preference [default] order

• This reduces the need to configure multiple dial-peers with the same capabilities but different destinations. E.g. Multiple subscribers in a cluster

voice class server-group 1

hunt-scheme {preference | round-robin}

ipv4 1.1.1.1 preference 5

ipv4 2.2.2.2

ipv4 3.3.3.3 port 3333 preference 3

ipv6 2010:AB8:0:2::1 port 2323 preference 3

ipv6 2010:AB8:0:2::2 port 2222

* DNS target not supported in server group


description Outbound DP

destination-pattern 1234


codec g711ulaw

dtmf-relay rtp-nte

session server-group 1

BRKCOL-2125 45


Multiple Incoming Patterns Under Same Incoming/Outgoing Dial-peer

SIP Trunk SP SIP Trunk

CUBE

IP PSTNA

(408)100-1010

(510)100-1010

(919)200-2010

(919)200-2000

(510)100-1000

(408)100-1000

voice class e164-pattern-map 300

e164 919200200.

e164 510100100.

e164 408100100.


description Inbound DP via Calling

incoming calling e164-pattern-map 300

codec g729r8

voice class e164-pattern-map 400

url flash:e164-pattern-map.cfg


description Outbound DP via Called

destination e164-pattern-map 400

codec g711ulaw

! This is an example of the contents of E164 patterns text file stored in flash:e164-pattern-map.cfg

919200201051010010104081001010

Site A

Site B

Site C

Site A

Site B

Site C

G729 Sites

G711 Sites

Provides the ability to combine multiple

incoming called OR calling numbers

on a single inbound voip dial-peer,

reducing the total number of inbound

voip dial-peers required with the same

routing capability

Up to 5000 entries in a text file

BRKCOL-2125 46


Destination Dial-peer Group

• Allows grouping of outbound dial-peers based on an incoming dial-peer, reducing existing outbound dial-peer provisioning requirements

• Eliminates the need to configure extra outbound dial-peers that are sometimes needed as workarounds to achieve desired call routing outcome

• Multiple outbound dial-peers are saved under a new “voice class dpg <tag>”. The new “destination dpg <tag>” command line of an inbound voip dial-peer

can be used to reference the new dpg (dial-peer group)

• Once an incoming voip call is handled by an inbound voip dial-peer with an active dpg, dial-peers of a dpg will then be used as outbound dial-peers for an incoming call

• The order of outgoing call setups will be the sorted list of dial-peers from a dpg, i.e, the destination-patterns of the outgoing dial-peers is not relevant for selection

BRKCOL-2125 47


Destination Dial-peer Group Configuration

voice class dpg 10000

description Voice Class DPG for SJ

dial-peer 1001 preference 1

dial-peer 1002 preference 2

dial-peer 1003

!


description Inbound DP

incoming called-number 1341

destination dpg 10000




session target ipv4:10.1.1.1

!





!




session target ipv4:10.1.1.31. Incoming Dial-peer is first

matched 2. Now the DPG associated with

the INBOUND DP is selected

BRKCOL-2125 48

External/PSTN Call Recording


External/PSTN Call Recording Options• CUBE Controlled (Dial-peer based ORA)

• Based on Open Recording Architecture, metadata sent in Cisco Proprietary format from CUBE to Recorder

• Dial-peer controlled, IP-PBX independent

• Source of recorded media (RTP only) is always CUBE (External calls only). For SRTP-RTP calls, apply media forking CLI on the RTP leg only.

• Records both audio and video calls and supported with CUBE HA (Inbox or box-2-box)

• CUBE Controlled (Dial-peer based SIPREC)

• Based on SIPREC (RFC 6341, 7245, Metadata-draft-17, Protocol-draft-15), CUBE sends metadata in XML format

• Dial-peer controlled, IP-PBX independent

• Source of recorded media (RTP only) is always CUBE (External calls only). For SRTP-RTP calls, apply media forking CLI on the RTP leg only.

• Records both audio and video calls and supported with CUBE HA (Inbox or box-2-box)

• CUCM NBR (Network Based Recording)

• CUCM Controlled, requires CUCM 10+ and UC Services API be enabled on CUBE

• Recording triggered by CUCM and this mode records only Audio calls

• Source of Recorded Media can be CUBE or Endpoint (BiB), CUBE as source desired for PSTN calls

BRKCOL-2125 50


CUBE Controlled Recording Option – Media Forking

• Call agent independent

• Configured on a per Dial-peer level to fork RTP

Cisco MediaSense

(authentication disabled w/o UCM)

Cisco Search/Play demo app or Partner

Application

media class 9

recorder parameter

media-recording 950


description dial-peer that needs to be forked


media-class 9


description dial-peer pointing to MediaSense

destination-pattern 9999 ! Dummy


session transport tcp

session target ipv4:<Mediasense_IP>

! Bind on this DP mandatory

• CUBE sets up a stateful SIP session

with MediaSense server

• After SIP dialog established, CUBE

forks the RTP and sends it for

MediaSense to record

• With XE 3.10.1, Video calls supported

and CUBE HA for audio calls

SIPSIP

SIP

A

SP SIP

CUBERTP RTP

MediaSense

Needs to

match

Dial-peer based – Open Recording Architecture (ORA)

Cisco Proprietary Metadata


Audio only Media Forking for an Audio/Video Call

media profile recorder 100

media-type audiomedia-recording 950




media-class 1

• MediaSense 10+ or any recording server can decline the video stream and choose to have only the audio

stream recorded by setting the video port as 0 in the SDP answer

• CUBE can be configured to offer only audio streams to be recorded even if the call that is being recorded

is an audio/video call

SIPSIPA

SP SIP

CUBERTP RTP

MediaSense

CUBE Controlled Recording – Dial-peer based

media-class 1

recorder profile 100

• Support for forwarding any 3rd

party IP PBX GUID to the

recording server by use of SIP

ProfilesSIP

Cisco Proprietary Metadata









CUBE Controlled Recording Option - SIPREC

• SIP Profiles can additionally be used to forward 3rd party IP PBX Call Identifier to the Recorder for Correlation

SIPREC Compliant Recorder

• SIP is used as a protocol between CUBE and the recording server, where CUBE acts as the recording

client and any third party recorder acts as the recording server

• Along with SDP, metadata information is passed by CUBE to the recording server in XML format

SIPSIPA

SP SIP

CUBERTP RTP

Recorder

Dial-peer based – SIPREC Standard

XML Metadata

• Metadata includes the

communication session details of

audio or video calls and also

identifies the participants of the call

media class 9

recorder parameter siprec

media-recording 950




media-class 9








Needs to

match


CUCM (10.X or later) Controlled Recording

1. Enable HTTP on IOSip http server

http client persistent

2. Enable the API on IOSuc wsapi

source-address [IP_Address_of_CUBE]

3. Enable XMF service within the APIprovider xmf

remote-url 1 http://CUCM:8090/ucm_xmf

no shutdown

Gateway/CUBE Recording

Enabled

1. 2.

3.

4.

5.

[1] – [3]: An external call is answered by user with IP phone

[4] – [5]: CUCM sends forking request over HTTP to CUBE, which

sends two media streams towards the Recording Server

UC Services API – Network Based Recording

• Recording not preserved on failover in CUBE HA• Selective Recording, Mobile/SNR/MVA Calls• Recording Call Preservation

Now Supports Inbound CVP (Survivability.tcl) Call Recording [IOS 15.6(1)T, IOS-XE 3.17]

BRKCOL-2125 54

http://cucm:8090/ucm_xmf

Multiple Non-Authenticated SIP Trunks on a CUBE


Non-Authenticated SIP Trunking to more than one Service Provider

A

TDM PBX

SRST

CME

MPLS

Enterprise

Branch Offices

Enterprise

Campus

Active

CUBE

SIP SP-1(10.10.10.2)

SIP SP-2(20.20.20.2)

Large enterprises are deploying more

than one SIP Trunk provider for:

• Alternate call routing

• Load balancing


description “Secondary path to SIP SP-2”

destination-pattern 91[2-9]..[2-9]......



preference 2

voice-class sip options-keepalivevoice-class sip bind control source-interface loopback2

voice-class sip bind media source-interface loopback2

interface loopback1

ip address 10.10.10.1 255.255.255.0

interface loopback2

ip address 20.20.20.1 255.255.255.0


description “Primary path to SIP SP-1”

destination-pattern 91[2-9]..[2-9]......



voice-class sip options-keepalivevoice-class sip bind control source-interface loopback1

voice-class sip bind media source-interface loopback1

SIP SP-1’s

network

SIP SP-2’s

network

NOTE: Dual SPs can be used for outbound calls, but to be utilized for inbound calls, arrangements between SPs required

BRKCOL-2125 56

Multiple Authenticated/Registered SIP Trunks on a CUBE


Multiple Instances of SIP-UA on a CUBE

Existing Implementation, prior to IOS 15.6(2)T and IOS-XE 16.3.1

• CUBE Configuration generally consists of • Global – Everything under voice service voip

• Call Routing – Dial-peers (Any configuration under dial-peers always overrides Global config)

• SIP User Agent Config – Everything under sip-ua, applicable globally on the platform

• No provision to configure specific bind/credentials/outbound proxy for different registrar

• No provision to configure specific configs (e.g. timers, retry) for different tenants

• Unable to handle authentication challenge for more than one trunk that have the same SIP realm

BRKCOL-2125 58


Introducing Tenants on CUBE

• Every Registrar/User Agent/ITSP connected to CUBE can be considered a Tenant to CUBE

• Allows specific global configurations (CLI under sip-ua) for multiple tenants such as specific SIP Bind for REGISTER messages

• Allows differentiated services for different tenantsBRKCOL-2125 59


“Voice class Tenant” Overview

Prior to Multi Tenancysip-uaregistrar 1 ipv4:60.60.60.60:9051 expires 3600registrar 2 ipv4:70.70.70.70:9052 expires 3600credentials username aaaa password 7 06070E204D realm aaaa.comcredentials username bbbb password 7 110B1B0715 realm bbbb.com

voice service voip outbound-proxy ipv4:10.64.86.35:9057bind control source-interface GigabitEthernet0/1

With Voice Class Tenant (Multi-Tenancy)voice class tenant 1registrar 1 ipv4:60.60.60.60:9051 expires 3600credentials username aaaa password 7 06070E204D realm aaaa.comoutbound-proxy ipv4:10.64.86.35:9057bind control source-interface GigabitEthernet0/0

voice class tenant 2registrar 1 ipv4:70.70.70.70:9052 expires 3600credentials username bbbb password 7 110B1B0715 realm bbbb.comoutbound-proxy ipv4:10.64.86.40:9040bind control source-interface GigabitEthernet0/1

E164 - aaaa

E164 - bbbb

Registrar - 1

Registrar - 2

E164 - aaaa

E164 - bbbb

Registrar - 1

Registrar - 1

OB Proxy 1 & Bind-1

OB Proxy 2 & Bind-2

• Most configs under “sip-ua” and “voice service voip” added in “voice class tenant <tag>”, e.g. Registrar and Credentials CLI under tenant using different bind and outbound proxy

Global OB Proxy and Bind

BRKCOL-2125 60


Authenticating Multiple trunks with same Realm

With Voice Class Tenant (Multi-Tenancy)voice class tenant 1registrar 1 dns:cisco.com expires 3600credentials number +1234 username aaaa@cisco password 0 AAAA realm cisco.comauthentication username aaaa@cisco password 7 AAAA realm cisco.com

voice class tenant 2registrar 1 dns:cisco.com expires 3600credentials number +6789 username bbbb@cisco password 0 BBBB realm cisco.comauthentication username bbbb@cisco password 7 BBBB realm cisco.com

• Requirement : To register two different authenticated numbers/usernames to different registrars, but with the same realm

• Prior to IOS 15.6(2)T / IOS-XE 16.3.1, CUBE could register multiple trunks only with different realms as the “authentication” command only accepted different realms. If the realms were the same, it just overwrote the username and password

• Now each credential/authentication pair can be defined under its own voice class tenant so that the same realm can be used for authentication

BRKCOL-2125 61


Configuring Voice Class Tenant• Configure voice class tenantvoice class tenant 1

registrar 1 ipv4:10.64.86.35:9052 expires 3600

credentials username aaaa password 7 06070E204D realm aaaa.com

credentials number bbbb username bbbb password 7 110B1B0715 realm bbbb.com

bind control source-interface GigabitEthernet0/0

bind media source-interface GigabitEthernet0/0

copy-list 1

outbound-proxy ipv4:10.64.86.35:9055

early-offer forced

• Apply tenant to the desired dial-peer




session target ipv4:10.64.86.35:9051

session transport udp

voice-class sip tenant 1 Apply Tenant to a Dial-peer

Add new voice class tenant

BRKCOL-2125 62

Multi-VRF Aware CUBE


Introduction to Multi-VRF

ATT

VZN

SPT

• Virtual Routing and Forwarding (VRF) is an IP technology that allows for multiple instances of a routing table to coexist on the same router at the same time as opposed to a single global route table, allowing for multiple virtual networks within a single network entity to isolate between media and data virtual networks

• Multi-VRF allows for the use of only one router to accomplish the tasks that multiple routers usually perform

• Prior to IOS 15.6(2)T / IOS-XE 16.3.1, CUBE only supports a single VRF for Voice [voice vrf vrfname]

BRKCOL-2125 64


Multi-VRF and CUBE Enterprise

BRKCOL-2125 65


Multi-VRF Aware Call Routing on CUBE

• CUBE allows intra and inter VRF routing of voice and video calls without the need of Route Leaks improving security at the network level

• Overlapped IP addressing and Dial Plan with Multi VRF feature provides seamless integration of networks

• Show command outputs enhanced to display the VRF ID’s for active voice and video calls

• Provision to configure RTP port ranges for each VRF and allocation of Local RTP ports based upon VRF. Listen sockets on UDP, TCP and TLS transports based on the VRF

BRKCOL-2125 66


Multi-VRF Design Considerations

• It is strongly recommended to deploy CUBE 11.5.2 or later [IOS 15.6(3)M, IOS-XE 16.3.1] for Multi-VRF aware call routing as inbound dial-peers are filtered based on the incoming VRF FIRST and then followed by the regular inbound dial-peer matching. This ensures no potential routing issues will exist for incoming INVITES or any out-of-dialog messages such as REGISTER, OPTIONS, NOTIFY, etc

• Dial-peer bind statements are mandatory as the VRF association to a dial-peer is based upon the interface sip bind and both Control and Media on a dial-peer has to bind with the same VRF

• Whenever global sip bind interface associated with a VRF is added/modified/removed, user should restart the sip services under “voice service voip sip call service stop/no call service stop”

• Default incoming dial-peer (dial-peer 0) match is not supported with VRF

BRKCOL-2125 67


Understanding Inbound Dial-Peer Matching Techniques


CUBE

A

Inbound LAN Dial-Peer

IP

PSTN

Inbound WAN Dial-PeerInbound Calls

Outbound Calls

Match based on

Called Number

Match based on

Calling number

1Match Based on URI

of an incoming

INVITE message

Default Dial-Peer = 0

Exact Pattern

match

Host Name/IP

Address

User portion of

URI

Phone-number of

tel-uri

Received:







CSeq: 1 INVITE


Supported: timer

Max-Forwards: 70



Content-Length: 226

........

2

3

4

Priority

0

Filter dial-peers based

on incoming VRF if

configured and then 1

to 3 below

BRKCOL-2125 68


Multi-VRF Design Considerations – Cont’d

• Whenever destination server group is used with VRF, ensure that the server group should have the candidates (i.e. session targets) belonging to the same network as that of sip bind on the dial-peer where the server-group is configured. Sample Configuration in notes section below

• Dial-peer group feature or COR (Class of Restriction) lists can be used to restrict call routing to the same or group of VRFs (e.g. Overlapping Dial plans)

• The DSP resources are a global pool and not reserved on a per VRF basis. It is used on a first come first serve basis

BRKCOL-2125 69


Multi-VRF Feature Restrictions

• CUBE + CME co-located with VRF and TDM-SIP gateway are not supported

• IPV6 with VRF is not supported on CUBE. Only IPv4 is supported with VRF

• Multi-VRF calls across CUBE are supported in SIP-SIP flow-through mode only and not supported in flow-around mode.

• Media Anti-trombone is not supported with VRF

• Legacy global voice vrf and Multi VRF doesn’t co-exist. Customers using global voice vrf have to remove the CLI in order to use Multi VRF feature

• UC Services API (CUCM NBR Recording) is not VRF aware. Works globally for all call recordings and will not separate the call notification on a per VRF basis

• With Single/Multi VRF configured, DNS request will be at global (i.e. no vrf is associated with the DNS request)

For Your

Reference

BRKCOL-2125 70


CUBE Multi VRF - Basic Configuration

CUBE

VRF 1 VRF 2

ip vrf vrf1rd 1:1

interface GigabitEthernet0/0/0ip address 7.44.44.13 255.255.0.0 ip vrf forwarding vrf1

dial-peer voice 100 voipvoice-class sip bind all interface GigE0/0/0

ip vrf vrf2rd 2:2


dial-peer voice 200 voipvoice-class sip bind all interface GigE0/0/1

1. Configure VRF

2. Apply VRF under the interface/sub-interface

3. Bind the VRF associated interface to the dial-peer (VRF association by dial-peer bind CLI)

• Up to 54 different VRFs supported in 15.6(3)M and IOS-XE 16.3.1 or later releases

Gig0/0/0 Gig0/0/1

BRKCOL-2125 71


CUBE Multi VRF – Inbound dial-peer match

ip vrf vrf1rd 1:1

!


!

dial-peer voice 100 voipvoice-class sip bind all interface GigE0/0/0incoming called-number 2000

ip vrf vrf2rd 2:2

!


!


Inbound match based on VRF where SIP INVITE received

For VRF 1, dial-peer 100 is matched

For VRF 2, dial-peer 200 is matched

CUBE

VRF 1 VRF 2INVITE

sip:[email protected]

INVITE


BRKCOL-2125 72


CUBE Multi VRF – Inter/Intra VRF Routing

ip vrf vrf1rd 1:1



dial-peer voice 100 voipvoice-class sip bind all interface GigE0/0/0destination-pattern 2000session-target ipv4: 10.1.1.1


ip vrf vrf2rd 2:2



dial-peer voice 200 voipvoice-class sip bind all interface GigE0/0/1destination-pattern 3000session-target ipv4:10.2.2.2

dial-peer voice 2000 voipvoice-class sip bind all interface GigE0/0/1incoming called-number 3000Intra VRF

Routing

Inter VRF

Routing

CUBE

VRF 1 VRF 2

VR

F1

INVITE sip:[email protected] INVITE sip:[email protected]

VR

F1

INVITE sip:[email protected] INVITE sip:[email protected]

VR

F2

VR

F2

VR

F1 V

RF

2


CUBE Multi VRF – Routing w/ Overlapped Dial Plan

Route Inter or

Intra VRF calls

based on

outbound

dial-peer groups

ip vrf vrf1


voice class dpg 100dial-peer 11 preference 1

dial-peer voice 1 voipvoice-class sip bind all interface GigE0/0/0incoming called-number 2000destination dpg 100


ip vrf vrf2





INVITE


INVITE


INVITE


INVITE


VRF1 VRF2


CUBE Multi VRF – Call Routing w/ Overlapped IP

ip vrf vrf1





ip vrf vrf2





INVITE


INVITE


INVITE


INVITE


VRF1 VRF2

Overlapped

local IP

Overlapped

Remote IP


CUBE Multi Tenant Configuration Example

ip vrf vrf1 rd 1:1


voice class tenant 1registrar ipv4:10.1.1.5 expires 3600credentials username vrf1 password 7 104F081804 realm vrf1.commax-forwards 57retry invite 7timers trying 100bind all source-interface GigabitEthernet0/0/0

dial-peer voice 1 voipvoice-class sip bind all interface GigabitEthernet0/0/0incoming called-number 2000 voice class sip tenant 1

dial-peer voice 11 voipvoice-class sip bind all interface GigabitEthernet0/0/0destination-pattern 2000session-target ipv4: 10.1.1.1voice-class sip tenant 1

ip vrf vrf2rd 2:2


voice class tenant 2registrar ipv4:10.2.2.5 expires 3600credentials username vrf1 password 7 104F081804 realm vrf2.commax-forwards 58retry invite 5timers trying 200bind all source-interface GigabitEthernet0/0/1

dial-peer voice 2 voipvoice-class sip bind all interface GigabitEthernet0/0/1incoming called-number 3000 voice class sip tenant 2

dial-peer voice 22 voipvoice-class sip bind all interface GigabitEthernet0/0/1destination-pattern 3000session-target ipv4: 10.2.2.2voice-class sip tenant 2

CUBE

VRF 1 VRF 2

BRKCOL-2125 76

High Availability


CUBE High Availability Options

CUSP CUSP

• L2 Box-to-Box redundancy• ISR G2/4K (Stateful failover)

• ASR 1001-X/2-X/4/6 (Stateful failover)

• Local redundancy (Both routers must be physically located on the same Ethernet LAN)

• Not supported across data centers

• Only 1 RP and 1 ESP in ASR1006

• Preserves both signaling and media

• Clustering with load balancing• All platforms

• Load balancing by

• SP call agent

• Cisco Unified SIP Proxy

• Local and geographical redundancy

• Inbox redundancy• ASR 1006, preserves signaling & media• Stateful failover

• Local redundancyASR(config)#redundancy

ASR-RP2(config-red)#mode sso

ASR-RP2(config-red)#end

Active

Virtual IP

CUBE

CUBE

Virtual IP

Standby

SIP SP

SIP SP

BRKCOL-2125 78


CUBE HA Design Considerations on ISR-G2 for Box-to-Box Redundancy

• Anytime a platform is reloaded in a CUBE-HA relationship, it always boots up as Standby

• All signaling/media is sourced from/to the Virtual IP Address

• Multiple Traffic (SIP/RTP) interfaces (Gig0/0, Gig0/1) require preemption and interface tracking

• HSRP Group number should be unique to a pair/interface combination on the same L2

• All interfaces of the same group have to be configured with the same priority

• No media-flow around or UC Services API (CUCM NBR) support for CUBE HA

BRKCOL-2125 79


• Lower IP Address for ALL the interfaces (Gig0/0, Gig0/1, Gig0/2) should be on the same platform, which is used as a tie breaker for the HSRP Active state

• Multiple HSRP Groups/Interfaces/sub-interfaces can be used on either LAN or WAN side

• Upto 6 multimedia lines in the SDP are checkpointed for CUBE HA

• SDP Passthru (upto 2 m-lines) calls are also checkpointed starting IOS 15.6(1)T

• TDM or SRST or VXML GW cannot be collocated with CUBE HA

• Both platforms must be connected via a physical Switch across all likewise interfaces for CUBE HA to work, i.e. Gig0/0 of CUBE-1 and CUBE-2 must terminate on the same switch and so on

CUBE HA Design Considerations on ISR-G2 for Box-to-Box Redundancy – Cont’d

BRKCOL-2125 80


• Cannot have WAN terminated on CUBEs directly or Data HSRP on either side. Both Active/Standby must be in the same Data Center

• Both the CUBEs must be running on the same type of platform and IOS version and identical configuration. Loopback interfaces cannot be used for bind as they are always up. Sub-interfaces are supported for all interfaces. Port Channels are supported for all interfaces from IOS 15.6(3)M

• CUBE HA only checkpoints SIP/RTP Traffic. Support for Survivability.tcl preservation was added in 15.6(2)T for CVP deployments


BRKCOL-2125 81


• CCB (courtesy callback) feature is not supported if a callback was registered with CVP and then a switchover was done on CUBE. The CCB will not work in these scenarios.

• Recommended to configure TCP session transport for the SIP trunk between CVP and CUBE

• LTI based transcoding called flows including SRTP/RTP interworking preserved starting 15.5(2)T. Requires same PVDM3 chip capacity on both active and standby in the same slot/subslot. CPA calls (prior to being transferred to the agent), SCCP based media resources, Noise Reduction, ASP, transrating calls are not checkpointed

• SRTP - RTP, SRTP - SRTP and SRTP passthru supported on ISR-G2


BRKCOL-2125 82


• CUBE HA with HSRP is supported with VRFs configured

• Traffic interfaces (SIP/RTP) can have VRFs configured but HSRP interface [ipc zone default config –Gig0/2 above] cannot have any VRF associated with it. This means for every CUBE HA deployment where VRFs are being utilized for SIP/RTP interfaces, at least three interfaces are required. Otherwise, any of the LAN interfaces (Gig0/0 above) can be used as an HSRP interface

• VRF ID’s will be check pointed for the calls before and after switchover. VRF Configurations in both active and standby routers have to be identical. This includes VRF based rtp port range as well

• Upon failover, the previously ACTIVE CUBE goes through a reload by design, preserving signaling/media. Thus, running config should always be saved to avoid losing it due to the reload


BRKCOL-2125 83


CUBE Configuration on ISR-G2 Box-to-Box Redundancy

CUBE-1> enable CUBE-1# configure terminal CUBE-1(config)# ip vrf LAN-VRF CUBE-1(config)# rd 1:1 CUBE-1(config)# ip vrf WAN-VRFCUBE-1(config)# rd 2:2

CUBE-2> enable

CUBE-2# configure terminal

CUBE-2(config)# ip vrf LAN-VRF

CUBE-2(config)# rd 1:1

CUBE-2(config)# ip vrf WAN-VRF

CUBE-2(config)# rd 2:2

Configure VRFs

on the platform

(if applicable)

CUBE 1 CUBE 2

BRKCOL-2125 84



interface GigabitEthernet0/0description “Enterprise LAN”ip vrf forwarding LAN-VRFip address 10.10.1.12 255.255.255.0standby version 2standby 1 ip 10.10.1.13standby delay minimum 30 reload 60standby 1 preemptstandby 1 track 2 decrement 10standby 1 track 3 decrement 10standby 1 priority 50

Inside interfaces :

HSRP group 1

VRF ID : LAN-VRF

(if applicable)

Interface can be

utilized as an HSRP

interface if no VRFs

are required or

configured

CUBE 1 CUBE 2

interface GigabitEthernet0/0description “Enterprise LAN”ip vrf forwarding LAN-VRFip address 10.10.1.11 255.255.255.0standby version 2standby 1 ip 10.10.1.13standby delay minimum 30 reload 60standby 1 preemptstandby 1 track 2 decrement 10standby 1 track 3 decrement 10standby 1 priority 50

BRKCOL-2125 85



interface GigabitEthernet0/1description “Enterprise WAN”ip vrf forwarding WAN-VRFip address 128.107.66.77 255.255.255.0standby version 2standby 10 ip 128.107.66.79standby delay minimum 30 reload 60 standby 10 preemptstandby 10 track 1 decrement 10standby 10 track 3 decrement 10standby 10 priority 50

interface GigabitEthernet0/1

description “Enterprise WAN”

ip vrf forwarding WAN-VRF

ip address 128.107.66.78 255.255.255.0standby version 2standby 10 ip 128.107.66.79standby delay minimum 30 reload 60 standby 10 preemptstandby 10 track 1 decrement 10standby 10 track 3 decrement 10standby 10 priority 50

Outside

interfaces :

HSRP group 10

VRF ID : WAN-

VRF (if

applicable)

CUBE 1 CUBE 2

BRKCOL-2125 86



interface GigabitEthernet0/2description “HSRP Interface”ip address 1.1.1.1 255.255.255.0standby version 2standby 100 ip 1.1.1.3standby delay minimum 30 reload 60 standby 100 preemptstandby 100 name CUBEHAstandby 100 track 1 decrement 10standby 100 track 2 decrement 10standby 100 priority 50

!track 1 interface Gig0/0 line-protocol track 2 interface Gig0/1 line-protocoltrack 3 interface Gig0/2 line-protocol

interface GigabitEthernet0/2

description “HSRP Interface”

ip address 1.1.1.2 255.255.255.0standby version 2standby 100 ip 1.1.1.3standby delay minimum 30 reload 60 standby 100 preemptstandby 100 name CUBEHAstandby 100 track 1 decrement 10standby 100 track 2 decrement 10

standby 100 priority 50

!track 1 interface Gig0/0 line-protocol track 2 interface Gig0/1 line-protocoltrack 3 interface Gig0/2 line-protocol

Configure Interface

Tracking (for line protocol

on corresponding

interfaces of the platform

HSRP interfaces :

HSRP group 100

CANNOT HAVE VRFs

associated

CUBE 2CUBE 1

BRKCOL-2125 87



redundancy inter-devicescheme standby CUBEHA

voice service voipmode border-elementallow-connections sip to sipredundancy

ipc zone defaultassociation 1no shutdownprotocol sctp

local-port 5000local-ip 1.1.1.1

remote-port 5000remote-ip 1.1.1.2

redundancy inter-devicescheme standby CUBEHA

voice service voipmode border-elementallow-connections sip to sipredundancy

ipc zone defaultassociation 1no shutdownprotocol sctp

local-port 5000local-ip 1.1.1.2

remote-port 5000remote-ip 1.1.1.1

Define Redundancy scheme: Creates

interdependency b/w CUBE

redundancy & HSRP

Turn on CUBE Redundancy

HSRP Interface - IPC configuration :

Allows the ACTIVE CUBE to tell the

STANDBY about the state of the calls.

CONFIG SHOULD BE APPLIED on the

LAN SIDE (to avoid SPLIT BRAIN) and a

NON-VRF associated interface

CANNOT HAVE VRFs

associated with this interface

CUBE 1 CUBE 2

BRKCOL-2125 88




description TO SERVICE PROVIDER

destination-pattern 9T


session target ipv4:y.y.y.y

voice-class sip bind control source-interface GigabitEthernet0/1

voice-class sip bind media source-interface GigabitEthernet0/1

!


description TO CUCM

destination-pattern 555….



voice-class sip bind control source-interface GigabitEthernet0/0

voice-class sip bind media source-interface GigabitEthernet0/0

!

ip rtcp report interval 3000

!

gateway

media-inactivity-criteria all

timer receive-rtcp 5

timer receive-rtp 86400

Bind traffic destined to the outside (SP SIP trunk)

to the outside Physical interface.

This ensures that all RTP and SIP packets are

created with the virtual IP associated with the

respective physical interface.

CUBE HA does not work with loopback interfaces

as they are always up

Configuration on Active and Standby

Bind traffic destined to the inside (CUCM or IP

PBX) to the inside Physical interface.

This ensures that all RTP and SIP packets are

created with the virtual IP associated with the

respective physical interface.

Configure media inactivity feature to clean up any

calls that may not disconnect after a failover

BRKCOL-2125 89


CUBE HA Design Considerations on ASR1K/ISR-4K/vCUBE for Box-to-Box Redundancy

• Uses Redundancy Group (RG) Infrastructure Protocol

• GE0/0/0 and GE0/0/1 are referred to as traffic (SIP/RTP) interfaces and GE0/0/2 is RG (Redundancy Group) Control/data interface

• Starting IOS-XE 16.3.1, Port channel is supported for both RG Control/data and traffic interfaces

• When configuration is applied and saved, the platform must go through a reload cycle

• RG Control/Data Interfaces (GE0/0/2) must be connected through a Switch and not a Crossover Cable

BRKCOL-2125 90


Additional Supported options for CUBE HA

• The RG control data interfaces can be a sub interface that is part of the same port channel used for voice traffic. This will go to switch D and E

thereby eliminating the need for additional switches for RG control/data. This is provided there is sufficient bandwidth for voice + RG

data/control on the port channel (for example when using 10G)

• Multiple ITSPs or multiple trunks from the same ITSP can be terminated on the same CUBE ENT HA (ISR G2, ISR 4K, ASR 1K, vCUBE) pair

• Port Channel(s) can be used on the WAN/ITSP side as well as shown for the LAN side in the above diagram with L2 and CE router redundancy

CUBE-1

CUBE-2

CUCM

WAN Edge

PortChannel34

Gig0/0/3

PortChannel34

Gig0/0/4

Gig0/0/3

Switch A Switch B

CUBE

CUBE

Gig0/0/2.100 – ITSP 1

Gig0/0/2.100

Gig0/0/0

Gig0/0/0

Gig0/0/4

red

un

dan

cy rii 3

red

un

dan

cy rii 2 Switch C

Gig0/0/2.200

Gig0/0/2.200 – ITSP 2

Gig0/0/1

Gig0/0/1

Po

rtC

han

ne

l2P

ort

Ch

ann

el2

Switch D Switch E

red

un

dan

cy

rii 1

ITSP 1

ITSP 2

vPC

vPC

Video Suppression


Video Suppression

• When CUBE receives video capabilities as part of SDP, it passes them across by default

• This feature adds a mechanism on CUBE to allow only audio and image (for T.38 fax) media capabilities and drop all other media capabilities like video, application m-lines etc. while routing calls to service providers

»Only supported for SIP-SIP calls not in SDP Passthru mode

A SP SIP

INVITE w/ audio, video, application

CUBE(config)#voice service voip

CUBE(conf-voi-serv)#sip

CUBE(conf-serv-sip)#audio forced

CUBE(conf-serv-sip)#dial-peer voice 100 voip

CUBE(conf-serv-sip)#description “Outgoing Dial-peer”

CUBE(config-dial-peer)#voice-class sip audio forced

SBCCUBE

INVITE w/ audio only

Video Endpoints

BRKCOL-2125 93







Agenda

Serviceability


Cisco Unified Border Element Basic Call Flow

1. Incoming VoIP setup message from originating endpoint

2. This matches inbound VoIP dial peer 1 for characteristics such as codec, VAD, DTMF method, protocol, etc.

3. Match the called number to outbound VoIP dial peer 2

4. Outgoing VoIP setup message

Incoming VoIP Call Outgoing VoIP Call

dial-peer voice 1 voipdestination-pattern 1000session protocol sipv2 session target ipv4:1.1.1.1codec g711ulaw

dial-peer voice 2 voipdestination-pattern 2000session protocol sipv2session target ipv4:2.2.2.2codec g711ulaw

Originating Endpoint -

1000

TerminatingEndpoint –

2000

CUBE

voice service voip

mode border-element

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

BRKCOL-2125 96


CUBE

10001.1.1.1

20002.2.2.2

Incoming VoIP Call LegMatches an Incoming Dial-peer

Outgoing VoIP Call LegMatches an Outbound Dial-peer

INVITE /w SDP INVITE /w SDP

100 TRYING100 TRYING

VRF1 – 10.10.10.10 20.20.20.20 – VRF2

c= 1.1.1.1m=audio abc RTP/AVP 0

c= 20.20.20.20m=audio xxx RTP/AVP 0

180 RINGING180 RINGING

200 OK200 OK c= 2.2.2.2

m=audio uvw RTP/AVP 0c= 10.10.10.10m=audio xyz RTP/AVP 0

RTP (Audio)

ACKACK

1.1.1.1 10.10.10.10 20.20.20.20 2.2.2.2

Understanding the Call flow

BYE BYE

200 OK200 OK

BRKCOL-2125 97


Basic Show commands for Active CallsCUBE# show call active voice brief

121A : 17 13:02:24.215 IST Mon Jun 27 2011.1 +2040 pid:1 Answer 1000 activedur 00:00:14 tx:0/0 rx:0/0IP 1.1.1.1:6000 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: offmedia inactive detected:n media contrl rcvd:n/a timestamp:n/along duration call detected:n long duration call duration:n/a timestamp:n/a VRF:VRF1

121A : 18 13:02:24.225 IST Mon Jun 27 2011.1 +2020 pid:2 Originate 2000 activedur 00:00:14 tx:0/0 rx:0/0IP 2.2.2.2:6001 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: offmedia inactive detected:n media contrl rcvd:n/a timestamp:n/along duration call detected:n long duration call duration:n/a timestamp:n/a VRF:VRF2

Telephony call-legs: 0SIP call-legs: 2H323 call-legs: 0Call agent controlled call-legs: 0SCCP call-legs: 0Multicast call-legs: 0Total call-legs: 2

CUBE# show voip rtp connections

VoIP RTP active connections :No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF 1 17 18 17474 6000 10.10.10.10 1.1.1.1 NO VRF1 2 18 17 17476 6001 20.20.20.20 2.2.2.2 NO VRF2

Found 2 active RTP connections

BRKCOL-2125 98









BRKCOL-2125 99









BRKCOL-2125 100









BRKCOL-2125 101









BRKCOL-2125 102









BRKCOL-2125 103









BRKCOL-2125 104



121A : 17 13:02:24.215 IST Mon Jun 27 2011.1 +2040 pid:1 Answer 1000 active

dur 00:00:14 tx:0/0 rx:0/0IP 1.1.1.1:6000 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: offmedia inactive detected:n media contrl rcvd:n/a timestamp:n/along duration call detected:n long duration call duration:n/a timestamp:n/a VRF:VRF1

121A : 18 13:02:24.225 IST Mon Jun 27 2011.1 +2020 pid:2 Originate 2000 active






BRKCOL-2125 105











BRKCOL-2125 106











BRKCOL-2125 107



121A : 17 13:02:24.215 IST Mon Jun 27 2011.1 +2040 pid:1 Answer 1000 activedur 00:00:14 tx:0/0 rx:0/0

IP 1.1.1.1:6000 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: offmedia inactive detected:n media contrl rcvd:n/a timestamp:n/along duration call detected:n long duration call duration:n/a timestamp:n/a VRF:VRF1

121A : 18 13:02:24.225 IST Mon Jun 27 2011.1 +2020 pid:2 Originate 2000 activedur 00:00:14 tx:0/0 rx:0/0






BRKCOL-2125 108











BRKCOL-2125 109











BRKCOL-2125 110







VoIP RTP active connections :No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF

1 17 18 17474 6000 10.10.10.10 1.1.1.1 NO VRF1 2 18 17 17476 6001 20.20.20.20 2.2.2.2 NO VRF2


BRKCOL-2125 111


Total Number of Active Concurrent Calls

Router# show call active total-calls

Total Number of Active Calls : 10

Total Number of Active Calls

A single call can have multiple call-legs. To determine the total number of active calls from call-legs is challenging

CLI added to display the value of current number of active (connected) calls on CUBE

The table defines the relation between call-legs and number of active calls

Call Flow Call-legsConnected

call

Basic call (audio/video) 2 1

Transferred call (Refer

handling)

3 2

Transcoded call (SCCP) 4 1

Calls after rotary/hunt 2 + x 1

Forwarded calls (CUBE

handling)

3 1

Forked call (media forking) 3 2

Forked call (signaling forking) 2 1

BRKCOL-2125 112


Avoiding Non-call-context Debug Logs

• Many times SIP debugs contain unrelated debugs that are not useful in debugging issues related to call failures

• Starting CUBE 10.0.1, non-call-context debugs will not be printed when debug ccsip is issued

• This applies to messages originating from CUBE. Non-call context INBOUND messages towards CUBE will still be printed when debug ccsip is issued.

• If a message is not part of any call, that debug will not be printed

• Affected messages: OPTIONS, REGISTER, SUBSCRIBE/NOTIFY

• To see the above OUTBOUND messages in debugs, issue the following command

debug ccsip non-call

BRKCOL-2125 113


Debugging Made Easier

Router# debug ccsip feature < audio | cac |

config | control | dtmf | fax | line | misc |

misc-features | parse | registration | sdp-

negotiation | sdp-passthrough | sip-profiles

| sip-transport | srtp | supplementary-

services | transcoder | video >

Categorize Debugs based on Functionality

Categorization based on Functionality

1. Audio/video/sdp/control

2. Configuration /sip-transport

3. CAC

4. DTMF/FAX/Line-side

5. Registration

6. Sdp - passthrough

7. Sip-profile/SRTP/transcoder

Example: enabling DTMF and audio debugs only with default log level is considered.

CUBE#sh debugging

CCSIP SPI: SIP info debug tracing is enabled (filter is OFF)

CCSIP SPI: audio debugging for ccsip info is enabled (active)

CCSIP SPI: dtmf debugging for ccsip info is enabled (active)

May 21 17:54:53.377: //444/5FE632EB8479/SIP/Info/verbose/32/sipSPI_ipip_store_channel_info: dtmf negotiation done, storing

negotiated dtmf = 0,

May 21 17:54:53.377: //444/5FE632EB8479/SIP/Info/info/2/sipSPIUpdateCallEntry:

Call 444 set InfoType to SPEECH

DTMF(32) debug code

Audio(2) debug code

BRKCOL-2125 114


Debugging Made Easier

CUBE# show cube debug category codes

Categorize Debugs based on Functionality

This CLI is used to collect the predefined debug features category codes , which helps in analysis of debugs manually.

|-----------------------------------------------

| show cube debug category codes values.

|-----------------------------------------------

| Indx | Debug Name | Value

|-----------------------------------------------

| 01 | SDP Debugs | 1

| 02 | Audio Debugs | 2

| 03 | Video Debugs | 4

| 04 | Fax Debugs | 8

| 05 | SRTP Debugs | 16

| 06 | DTMF Debugs | 32

| 07 | SIP Profiles Debugs | 64

| 08 | SDP Passthrough Deb | 128

| 09 | Transcoder Debugs | 256

| 10 | SIP Transport Debugs | 512

| 11 | Parse Debugs | 1024

| 12 | Config Debugs | 2048

| 13 | Control Debugs | 4096

| 14 | Mischellaneous Debugs| 8192

| 15 | Supp Service Debugs | 16384

| 16 | Misc Features Debugs| 32768

| 17 | SIP Line-side Debugs | 65536

| 18 | CAC Debugs | 131072

| 19 | Registration Debugs | 262144

|-----------------------------------------------

BRKCOL-2125 115


Diagnostic Signature Lookup Tool (DSLT)On-demand Troubleshooting Automation





• CUBE Management & Troubleshooting


Agenda

Introducing Cisco Business Edition 4000 (BE4K)


BE4K – Simple, cloud-managed office communications

BRKCOL-2125 119

Features

Packaged Collaboration Offer - Voice and Voicemail solution for SMBs (200 users)

Based on ISR4321 router running CUCME and virtualized CUE.

Support for the latest IP Phones (78xx, 88xx, Jabber, ATA-190)

Rapid Installation – Preconfigured before shipment

Smart licensing

ISR 4321


BE4K – Contd.

BRKCOL-2125 120

Voice & Voicemail

Cisco OEM Cloud Management.

Cloud Deployed - configuration, administration and management.

Rich Feature Set – Auto-attendant, Flexible call routing, Park, Hold, Transfer, Hunt groups, Conferencing, Voicemail.

Single or multiple sites.

Fixed configuration SKU for ease of ordering.

Migration options include BE6000 / BE7000, Cisco Spark. No throw-away capex.

Add-on Spark and WebEx for messaging and meetings.


Key Takeaways• It is a manageable transition from existing TDM based networks to SIP

networks using these network design techniques

• Enterprise SBC (Cisco Unified Border Element - CUBE) is an essential component of a UC solution providing;

• Security, Session Management, Interworking, Demarcation

• Over 18,000 Enterprise customers all over the Globe

• Proven interoperability with 3rd party PBX vendors and different service providers around the world (more than 165 countries)

• Now is the time to deploy SIP Trunking in either a Centralized or a Distributed solution to save money, simplify your topology and setup your infrastructure for future services

• Complete feature Presentations, Lab Guide, Free Hands-on Lab access & Application Notes :

»https://cisco.box.com/cubeBRKCOL-2125 121

https://cisco.app.box.com/cube


Complete Your Online Session Evaluation

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

• Please complete your Online Session Evaluations after each session

• Complete 4 Session Evaluations & the Overall Conference Evaluation (available from Thursday) to receive your Cisco Live T-shirt

• All surveys can be completed via the Cisco Live Mobile App or the Communication Stations

122BRKCOL-2125

CiscoLive.com/Online

http://ciscolive.com/Online


Cisco Spark Ask Questions, Get Answers, Continue the Experience

Use Cisco Spark to communicate with the Speaker and fellow participants after the session

Download the Cisco Spark app from iTunes or Google Play

1. Go to the Cisco Live Berlin 2017 Mobile app

2. Find this session

3. Click the Spark button under Speakers in the session description

4. Enter the room, room name = BRKCOL-2125

5. Join the conversation!

The Spark Room will be open for 2 weeks after Cisco Live

123Presentation ID


Continue Your Education

• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Lunch & Learn

• Meet the Engineer 1:1 meetings

• Related sessions

BRKCOL-2125 124

Thank You

deploying sip trunks with cube - amazon web...

Documents