Dec
13

Just wanted to throw out a quick reminder to all of you involved day-to-day with Cisco Unified Communications in some fashion. Tomorrow I will host a free vSeminar on configuring and utilizing Active Directory as a source of LDAP user synchronization and authentication with the Cisco UC architecture servers.

If you still haven't registered, you can do so right up until the webinar begins. To do so, simply click here and fill in your requested information at the bottom of the page.

In case you missed any previous vSeminars, be sure to check out the recent updates here.

Hope to see you tomorrow!

Nov
18

Hi all, after a lot of studying and dedication i passed the Voice lab yesterday on my second attempt!!!! I want to thank a lot to Mark Snow for coaching me during the 2 week bootcamp. He made me feel very confident that I could pass, while also answering all of my questions and always providing clear explanations of all the topics. I also would like to to say that his Deep Dives videos are the best and were a fundamental part of my study and success in passing. I fully recommend the Deep Dive modules and the 2 week bootcamp. Again, thank you a lot for all Mark!!!!

Eduardo Elizondo, CCIE Voice #27511

Congratulations Eduardo!! Share in Eduardo's Success! Get all 17 current Deep Dive modules for FREE (a $1495 value) when you purchase any upcoming 10-Day CCIE Voice Bootcamp by using discount code 27511 at checkout! Be sure to act on this generous offer fast as it will only be available until November 26!!

Nov
12

Just wanted to update all our CCIE Voice rack renters out there that the new Variphy Remote Phone Control app that I blogged about a few days ago will go live here by the next rack rental session at 3pm PT. Information on how to use it can be found in the first few minutes of this video demonstration of the product.

Nov
10

We are very pleased to announce that we have reached an agreement with a wonderful company called Variphy that will allow us to give all our remote Voice rack renting clients free remote control access over all of the 7961 phones on our CCIE Voice racks! Variphy Insight is the product, and it is one of the most brilliant inventory control, CDR, phone broadcast and remote phone control software that I have seen in quite some time.

Six months back, we added 3 7961 IP Phones to each rack, and offered a discounted remote control software, but I think that you all will agree that "free" is a slightly more affordable and enticing way of getting you closer to passing your CCIE Voice Lab than "discounted" is.

Oh by the way, we are updating our racks again, and this time adding 2 more 7961 phones to each one. This means you will have 2 7961 phones at the CorpHQ site, 1 7961 phone at the Branch1 site, and 2 7961 phones at the Branch2 site, as well as a PSTN phone - of course.

The best thing about this, is not the fact that we are able to give it to our Voice clients at no cost to them (although we are fairly excited about that aspect as well!), but that for the first time it gives everyone a chance to work in their own native OS, and it gives folks that are not located in the US very decent speeds for controlling phones. You see, the remote control aspect of Variphy Insight is done entirely through HTML and AJAX  in your browser. That's right, no client software to install, so it doesn't matter if you are on a Mac (finally!), Linux, or even the ol' standby. And being transported over HTTP and using AJAX means that it is fast. Real fast. With previous remote control software, the further geographically you were from our data centers, the longer you had to wait for the refresh to come back and update your client and thus your screen - and there wasn't much we were able do about the laws of light propagation (though we tried Feynman, we tried!), so you simply had to wait for a good bit. But since we are now updating over HTTP with AJAX - things are lightning fast!

Another great thing about being handled with HTML is the size of the phone on your screen's desktop - it can be whatever size you want it to be! Just use your browser's standard controls to Zoom In or Zoom Out the size of the HTML text, and the phone itself will grow or shrink respectively right along with the text!

Couple of screenshots:

SIP Phone Controlled with Variphy

Larger SIP Phone Controlled with Variphy

We are still getting this software rolled out to all of our racks, but we estimate everything will be completed in a day or two at the most. As always, the always up-to-date Voice Rack Rental Access Guide will contain all of the necessary information to get you rolling and controlling your own phones, and ultimately destiny, of soon becoming a CCIE Voice.

I also have been compiling a list of every one of the features and drawbacks to using each of the different remote phone methods of remotely studying for the Voice exam, including 1) Hardware phones, 2) Variphy remote control, 3) VoIP Integration remote control, 4) IPBlue SCCP Softphone, 5) X-Lite SIP Softphone, and 6) CIPC. I will post an article here in a few days with a detailed comparison to help you make the best choice possible when studying for your exam. If there is some sort of software that any of you would like compared that I seemed to have missed in the above list, please be sure to add it in the comments section, and I will do my best to get it evaluated along with the others.

Nov
02

I took the Voice lab exam last week and passed! I would like to send a BIG thank you to Mark Snow at INE for not only providing excellent training during the two weeks of intense bootcamp, but for taking the time to personally answer all of my questions and provide in-depth explanations in the areas where I was not feeling confident. Mark is an amazing instructor who cares about every student in the class. If you want to make the most of your studies and feel extremely confident before going for your CCIE Voice attempt, I highly recommend attending Internetwork Expert's two week Voice bootcamp classes with Mark Snow!

Mark Holloway, CCIE Voice #27384

Congratulations Mark, CCIE Voice #27384!!

Share in Mark's Success! Save 20% on the upcoming CCIE Voice 10-Day Bootcamp Nov. 29 - Dec. 10 2010 in London, UK when you use discount code 27384! You can also share in his success with 30% off all self-paced material for any track, just use discount code NOV30 at checkout!

Oct
05

INE is happy to announce that we now have all 21 Modules of our new CCIE Voice Deep Dive completed --115 hours of recorded class-on-demand style video (no breaks or dead-air in the recordings - that's 115 hours of actual learning!)-- completed and ready for your consumption!

As we mentioned in a previous post, The author and poet Maya Angelou said “Words mean more than what is set down on paper. It takes the human voice to infuse them with deeper meaning.”. Well that is certainly what we have attempted to do with the CCIE Voice Deep Dive self-paced Class on Demand series – that is to bring the human instructional voice element to infuse deeper meaning to what is already fantastic Cisco Documentation. Anyone that has set out and determined to undertake the task of studying for and ultimately passing any CCIE Lab exam, knows that at some point during your studies, the words on paper (Cisco Docs, RFCs, books) – while a absolute phenomenal source of information – can at times seem to loose their impact. Perhaps you have been studying too long, read one too many docs, have the time pressure of your family and friends waiting for you to return to be a part of their life, or perhaps you are just starting out on your adventure and don’t know where to begin. Whatever stage you are at or whatever the case may be, it is certainly helpful to have a tutor and mentor there beside you at times, assisting you in understanding what each complex technology’s documentation is trying to teach you, in possibly a deeper and more insightful way than you can manage on your own.

For each complex topic we have held (or will soon hold) an online class where we dive down deep and explore all the concepts, practical application, and troubleshooting associated with each technology topic. The general format for each Class-on-Demand Deep Dive module spends between 4-7 hours on the given topic for that day, and during that time follows this outlined training methodology:

  • Collectively discuss and teach all concepts involved in the technology
  • Whiteboard concepts to further deepen every participant’s understanding
  • Define a specific set of tasks to be accomplished
  • Demonstrate how the tasks and concepts are implemented and properly configured
  • Test the configuration thoroughly
  • Vary the configuration to understand how different permutations effect the outcome
  • Debug and trace the working configuration to understand what should be seen
  • Break the configuration and troubleshoot with debugs and traces to contrast from the working set

Before we go on with the 21 module outline, here are a few demos of this Deep Dive series:

Demo 1: Module 10 :: Dial Plan :: Globalization Prezi - Theory and Reasons :: Runtime 1 hr

Demo 2: Module 10 :: Dial Plan :: Inbound Calling Party Localization :: Runtime 30 mins

Demo 3: Module 12 :: CUBE :: Conforming to ITSP Reqs: SIP Header Conversions :: Runtime 51 mins

Demo 4: Module 13 :: Unified Mobility :: Mobile Connect Access Lists and Exclusivity :: Runtime 20 mins

Here is the outline for the complete Deep Dive series:

Network Infrastructure

Module 1 :: Network Infrastructure, RSVP CAC, and LAN & WAN Quality of Service :: Runtime 10.5hrs

  • NTP
  • VLANs
  • TFTP
  • DHCP
  • Multicast (Infrastructure)
  • LAN QoS - including:
  • Catalyst 3560/3750 Classification and Marking
  • Catalyst 3560/3750 Conditional Trust
  • Catalyst 3560/3750 Ingress Interface Mapping
  • Catalyst 3560/3750 Ingress Interface Queuing
  • Catalyst 3560/3750 Ingress Interface Expedite Queue
  • Catalyst 3560/3750 L2 CoS to L3 DSCP Mapping
  • Catalyst 3560/3750 Egress Interface Mapping
  • Catalyst 3560/3750 Egress Interface Queuing
  • Catalyst 3560/3750 Interface Queue Memory Allocation
  • Catalyst 3560/3750 Egress Queue-Set Templates
  • Catalyst 3560/3750 Weighted Tail Drop (WTD) Buffer Allocation
  • Catalyst 3560/3750 Egress Interface Expedite Queue
  • Catalyst 3560/3750 Egress Interface Sharing
  • Catalyst 3560/3750 Egress Interface Shaping
  • Catalyst 3560/3750 Scavenger Traffic Policing
  • CUCM RSVP-Based Locations for Call Admission Control
  • WAN QoS Classification
  • WAN QoS Low Latency Queuing (CBWFQ-PQ)
  • WAN QoS Traffic Shaping
  • WAN QoS Frame-Relay Fragmentation

Unified Communications Manager

Module 02 :: CUOS GUI and CLI Admin :: Runtime 3.6 hrs

  • CUCM WebUI: Service Activation and Stop/Start/Reset
  • CUCM WebUI: Bulk Administration Tool (Import/Export, Phone Reports, etc)
  • CUCM WebUI: DB Replication Status
  • CUCM WebUI: Trace Files
  • CUOS CLU: TFTP Files Management
  • CUOS CLU: Status and Hostname
  • CUOS CLU: DB Replication Assurance
  • CUOS CLU: DB Replication Repair and Cluster Reset
  • CUOS CLU: Trace Files
  • CUOS CLU: RIS DB Search
  • CUOS CLU: Performance Monitor (PerfMon)
  • RTMT: Trace Files
  • RTMT: Performance Monitor (PerfMon)

Module 03 :: CUCM System and Phone - SCCP and SIP Fundamentals :: Runtime 4.4 hrs

  • CUCM Services
  • UC Servers and Groups
  • Date/Time with NTP Reference
  • Regions and Codecs
  • Location-Based Call Admission Control
  • SRST References
  • Device Pools
  • System Parameters
  • Enterprise Parameters
  • Phone Button Templates
  • Softkey Templates
  • SCCP Phone Basics
  • SIP Phone Basics

Module 04 :: Users, Credentials, Multi-Level Roles and LDAP Internetworking :: Runtime 3.6 hrs

  • CUCM User Credentials and Policies
  • LDAP Synchronization for CUCM and Unity Connection
  • LDAP Authentication for CUCM and Unity Connection
  • CUCM End Users
  • CUCM User Roles
  • CUCM Multi-Level Administration
  • CUCM Device/Phone/Line User Association
  • UCCX and CUP Basic Users

Module 05 :: Call Features - In-Depth :: Runtime 5.3 hrs

  • SCCP and SIP Phone Display
  • Phone Firmware
  • Phone Logging
  • Ring Settings
  • Basic and Advanced Call Forwarding Display
  • Auto-Answer Options
  • CallBack (Camp-On)
  • Intercom
  • Advanced Call Hold Options
  • Call Park
  • Directed Call Park
  • Advanced Call Park Settings
  • Call Pickup
  • Group Call Pickup
  • Other Call Pickup
  • Directed Call Pickup
  • Call Pickup Attributes
  • Shared Line
  • Barge and cBarge (Conference Barge)
  • Privacy
  • Built-In IP Phone Bridge

Module 06 :: Media Resources - MTPs, Conf Bridges, Annunciator and Music on Hold :: Runtime 5.6 hrs

  • IOS Software MTP
  • IOS Conference Bridge
  • IOS Transcoding
  • Media Preference and Redundancy
  • Meet-Me Conferencing
  • Ad-Hoc Conferencing
  • Annunciator
  • Unicast Music on Hold
  • Traditional Multicast Music on Hold
  • Alternate Multicast Music on Hold

Module 07 :: Expert Gateways & Trunks :: Runtime 5.9 hrs

  • ISDN Switch Types and Advanced CNAM options
  • ISDN Information Elements
  • SIP Trunks - Fundamental and Advanced Options
  • H.323 Gateways - Fundamental and Advanced Options
  • MGCP Gateways - Fundamental and Advanced Options

Module 08 :: Expert H.323 Gatekeeper :: Runtime 7.1 hrs

  • Provisioning IOS H.323 Gatekeeper
  • Registering CUCM with H.323 Gatekeeper
  • Registering CUCME with H.323 Gatekeeper
  • Routing Calls from CUCME to CUCM via Gatekeeper in Multiple Zones with Dynamic E.164 Aliases
  • Routing Calls from CUCM to CUCME via Gatekeeper in Multiple Zones with Multiple Tech Prefixes
  • Routing Calls from CUCME to CUCM via Gatekeeper in Multiple Zones with Multiple Tech Prefixes
  • Routing Calls from CUCME to CUCM via Gatekeeper in Multiple Zones with Static E.164 Aliases
  • Routing Calls from CUCM to CUCME and Back via Gatekeeper in One Zone with One Tech Prefix
  • Gatekeeper Call Admission Control
  • Routing Calls from CUCM to CUCME and Back via Alternate Gatekeeper Clustering in Multiple Zones with Multiple Tech Prefixes using GUP

Module 09 :: Dial Plan - Line Device Approach and the Not-So-Basic Fundamentals :: Runtime 7 hrs

  • Class of Service: Calling Search Spaces and Partitions
  • Gateways, Route Groups, Local Route Groups/Device Pools
  • Route Lists and Standard Local Route Groups
  • Route Patterns and Translation Patterns
  • Digit Manipulation: Calling & Called Party Transformations and IOS Dial Peers
  • Private Line Automatic Ringdown (PLAR)

Module 10 :: Dial Plan - Globalization & Localization of both the Calling and the Called Numbers, and with Mapping the Global Number to the Local Variant :: Runtime 6.3 hrs

  • Inbound PSTN Calls (Ingress from PSTN, Egress to Phones): Calling Party Globalization :: GW Incoming Calling Party Settings
  • Inbound PSTN Calls (Ingress from PSTN, Egress to Phones): Calling Party Localization :: Phone Calling Party Transformations
  • Outbound PSTN Calls (Ingress from Phones, Egress to PSTN): Called Party Globalization :: PSTN Patterns - a.k.a. "Translation Patterns are the *New* Route Patterns"
  • Outbound PSTN Calls (Ingress from Phones, Egress to PSTN): Called Party Localization :: Digit Manipulation: Calling & Called Party Transformations and IOS Voice Translation Rules & Dial Peers
  • Mapping the Global Number to the Local Variant :: + Dialing and One-Button Missed Call DialBack

Module 11 :: Dial Plan - Unlocking the Full Potential of Globalization & Localization :: Runtime 4.2 hrs

  • System & User Speed Dials and Corporate Directory
  • Call Forward on Unregister
  • Automated Alternate Routing Made So Simple
  • Multiple Backup Gateways for Every Site using only Standard Local Route Group
  • National and International Tail End Hop Off (TEHO) Made Easy
  • Globalized Call Routing using H.323 ICTs

Module 12 :: Dial Plan - Cisco Unified Border Element (CUBE) with SIP Normalization :: Runtime 6.5 hrs

  • SIP Trunk to SIP ITSP for PSTN Call Routing
  • Conforming to ITSP Reqs: Various SIP-Attributes
  • Conforming to ITSP Reqs: SIP Header Conversions
  • Advanced Call Admission Control Mechanisms with CUBE
  • Skype SIP Trunk for Branch2 Site
  • Testing Supplementary Features

Module 13 :: Unified Mobility - Getting the Most out of Single Number Reach and Direct Inward System Access :: Runtime 6.8 hrs

  • Mobile Connect Basics
  • Mobile Connect Ring Schedule
  • Mobile Connect Localization
  • Mobile Connect Access Lists and Exclusivity
  • Mobile Connect Interaction with Local Route Group
  • Mobile Voice Access - Inbound Call Recognition and Display
  • Mobile Voice Access and Direct Inward System Access (DISA)
  • Mobile Connect Mid-Call Features - Supplementary Services

Module 14 :: Device Mobility & Extension Mobility - What They Have in Common and When To Use Each :: Runtime 4 hrs

  • Device Mobility - Between Sites but Within a Country
  • Device Mobility - Between Sites and Between Countries
  • Extension Mobility
  • Device and Extension Mobility and TEHO Interactions

Unified Communications Manager Express

Module 15 :: CUCME System and Phone Basics - SCCP and SIP :: Runtime 5 hrs

  • IOS DHCP
  • IOS Clock and Network Time
  • IOS TFTP Server
  • SIP CME Server Setup
  • SIP CME Phone and DN Setup
  • SCCP CME Server Setup
  • SCCP CME Phone and DN Setup
  • CME Directory Services
  • SCCP CME Server Redundancy
  • Endpoint Registration with External SIP Proxy Server
  • CME Templates for SCCP and SIP Phones and DNs
  • CME Phone Customization

Module 16 :: CUCME Dialplans, Class of Restrictions (COR) & Media Resources :: Runtime 5.6 hrs

  • PSTN Dialing from CME
  • IOS Voice Translation Rules in CME
  • Load Balancing Calls in CME
  • Class of Restrictions for CME
  • Multicast Music on Hold for CME
  • IOS Transcoding for CME
  • IOS Hardware Conference Bridge for CME
  • Multicast Broadcast-Paging in CME
  • MTP and DSP Resources in CME
  • Speed Dials in CME

Module 17 :: CUCME Advanced Call Features :: Runtime 4.2 hrs

  • Shared Lines and Feature Ring with SCCP Phones
  • Shared Lines with Barge and Privacy for SCCP Phones
  • Intercom for SIP and SCCP Phones
  • Night Service Bell for SCCP Phones
  • Call Park for SIP and SCCP Phones
  • Call Blocking for SIP and SCCP Phones
  • CallerID Blocking for SIP and SCCP Phones
  • Call Transfer and Forwarding for SIP and SCCP Phones

Module 18 :: CUCME Call Coverage and Survivable Remote Site Telephony :: Runtime 3.5 hrs

  • CME as SRST Fallback Mode (SIP, SCCP and MGCP Fallback)
  • Traditional SRST Fallback Mode (SIP, SCCP and MGCP Fallback)
  • 4-Digit Reachability from CUCM & SRST While in Fallback Mode
  • Call-Coverage - Call Pickup Groups
  • Call-Coverage - Basic-Automatic Call Distribution (B-ACD)
  • Call-Coverage - SIP and SCCP Hunt Groups and IOS Hunting

Unified Contact Center Express

Module 19 :: Unified Contact Center Express – Integration, CSQ Provisioning and Custom Scripting :: Runtime 5.1 hrs

  • UCCX Setup and Integration and Troubleshooting Being "Locked-Out"
  • CSQ Setup with Preferential Agent Choice
  • Basic Custom Scripting – Examination of UCCX Editor and “Simple Queuing.aef” Default Script
  • Basic Custom Scripting – Day of Week & Time of Day
  • Basic Custom Scripting – Reroute to Voicemail or Proceed to Queue
  • Basic Custom Scripting – MoH in Queue
  • Basic Custom Scripting – How Many Times Through Queue with Option to Go to Voicemail
  • Basic Custom Scripting – Nested Queues for More Available Agents
  • Basic Custom Scripting – Agent-Based Routing
  • Basic Custom Scripting – Testing and Debugging

Unified Messaging

Module 20 :: Messaging - Unity Connection & Unity Express :: Runtime 2.4 hrs

  • Unity Connection
  • Unity Express

Unified Presence

Module 21 :: CUCM Presence and Cisco Unified Presence Server - Integration and Client Usage :: Runtime 4 hrs

  • CUCM-Only Presence with Subscribe CSS
  • CUCM-Only Presence with Presence Groups
  • CUPS & CUCM Integration and CUPC Personal Communicator Provisioning
  • CUPS and IP Phone Messenger (IPPM)

And for those that couldn't get enough of this trailer for this series the first time, here it is again:

Sep
10

A while back, Cisco began consolidating all of the CCIE lab equipment used by candidates when sitting to write their practical lab exam. Most of the lab hardware now resides in San Jose, California US, with only the Storage and Wireless awaiting movement. While most of the CCIE tracks' practical lab examinations are able to be completely self-contained inside a single rack, the pesky Voice exam remains an abnormality with the need for hardware IP phones at the testing site where the candidate may sit for the exam.

Having the IP phones in a completely separate location -- and therefore seemingly an entirely different L3 IP subnet -- would seem to present a major challenge for candidates attempting to test certain configuration tasks such as Multicast Music on Hold, many QoS mechanisms, SRST, and even smaller things such as CDP discovery and DHCP. So how is Cisco able to get away with having phones at a remote location (5000 miles or more in some instances), and yet still allow candidates to configure and then properly test what they critically need to?

Layer 2 Tunneling - that's how. It's the only way to make phones "look" via CDP like they are connected to the same switch that they students are configuring on their rack - even if this couldn't be further from the truth (pun intended). This also allows everything else to function and work as perfectly as if the phone actually were on the same physical L2 wire, but alas, they most certainly are not.

Now to do this, it requires a good investment in a good number of additional routers and switches to make it all work, since after all there are a number of physical L2 LANs per candidate rack, and many more than simply one rack, not only in San Jose, but also at each remote testing site.

INE is very happy to announce that -- in both a strong desire to provide the exact same environment as the real lab, and also our response to listening to student requests from bootcamps this year -- we have put forth the necessary investment in both capital and man-hours to setup the necessary infrastructure to allow every Voice class that we run to be identical to taking a seat in the actual CCIE Voice lab exam. When you take a seat in any one of INE's Voice classes, that your 2 CorpHQ 7961 IP phones, your 1 Branch1 7961 IP phone, and your 2 Branch2 7961 IP phones will both appear to their respective site L2 switches, and function, just as if they were directly connected to your rack. It's as if we are now transporting each Voice rack of equipment with us no matter where we travel. Oh - did I mention that? This will be the standard no matter where you sit an INE Voice class - London, Seattle, Chicago, RTP, and anywhere else that we may have an on-site class requested and put together (some possibilities at the moment are Dubai, Bangalore, and Sydney).

On that note, we also just released our new training schedule with dates and expanded locations for 2011. Only dates through March are posted on the site at the moment, but the rest should be posted up either today or Monday (13 Sept).

So just to recap what you get when you train with INE for your CCIE Voice exam:

  • 5  7961 Hardware IP Phones on your desk in front of you, plus 1  7960 PSTN phone
  • Every 7961 IP phone functions exactly as it would as if it were physically and directly connected to its site's layer 2 switch (and just as it actually is in the real CCIE lab exam)
  • An instructor who has helped hundreds of people become CCIEs and who has been developing training materials and teaching the technologies needed to pass the CCIE Voice exam for over 5 years now

It is also worth updating everyone that we have released a few more CCIE Voice Deep Dive modules (scroll to bottom of linked page for each module details), and next week we will be completing two additional modules (both on different forms of Mobility) to round out our complete section relating to the CUCM server. So currently we are up to modules 1-12 and we have over 70 hours of class-on-demand style training with extremely detailed walk-throughs of every configuration and debug/trace in CUCM. Once we finish up the last two modules on CUCM, we will be moving onto CME, and you can expect the same level of detail on absolutely every aspect of that platform as well!

Happy Studies!

-Mark Snow

Aug
20

Many businesses globally - large and small alike - have been converting calls from routing over traditional PSTN carrier trunks - such as E1 & T1 PRI or CAS - to much lower cost, yet still high performance, SIP ITSP (Internet Telephony Service Provider) trunks for years now. INE is no different than your business with regard to this - we have been using SIP trunks in lieu some traditional PSTN calling for years now as well. In fact, in response to a US Federal Communications Commission sub-commitee's exploration on "PSTN Evolution" in December 2009, a representative from the US carrier AT&T described the traditional circuit-switched PSTN as "relics of a by-gone era", and said that "Due to technological advances, changes in consumer preference, and market forces, the question is when, not if, POTS service and the PSTN over which it is provided will become obsolete" - source: Reuters [emphasis mine].

The challenge however, becomes that every SIP ITSP carrier has a slightly different way of implementing these sorts of trunks, and each has different provider network equipment that you, the customer, must connect to, and interoperate (properly) with. If you are a large national or multinational business, you may for instance sometimes even connect to two or three different types of provider network equipment, between possibly having multiple contracts with multiple carriers, and even sometimes having to deal with different provider equipment within a single carrier's network.

Now while you both speak the same agreed upon language (namely SIP), it seems more often than not that you don't always seem to speak exactly the same dialect of that language. This presents a major challenge in that calls and supplementary services (such as Hold, Resume, Blind Transfer, Semi-Attended Transfer, Fully-Attended Transfer, Forwarding, Faxing, etc) don't behave as expected, or worse, that some functions don't work at all.

It is not that SIP isn't fully mature yet (it will turn 15 years old next year and has been widely used for over 10 years now), or that it is fully standardized and therefore governed by those IETF standards and working groups, it is simply that - as every one of us in the field for any respectable amount of time now knows - not every equipment vendor chooses to implement every single extension and option defined in every IETF RFC for SIP. I mean, have you ever actually looked at how many RFCs there are that deal with not just the core functions, but describe every option and extension to the SIP protocol? There are well over 100 RFCs! Therein lies the problem.

So what are we to do? Cisco Unified Border Element to the rescue! Today we will cover just a few of CUBE's ability to perform SIP Normalization to allow optimum interoperability with many various SIP ITSPs.

At its base, CUBE consists of allowing both inbound and outbound call legs to be of the type VoIP. Here we first explore a very basic configuration where we have 2 Inbound/Outbound Dial-Peers (depending on which direction the call originates from) To/From the CUCMs in the cluster, and 2 Inbound/Outbound Dial-Peers To/From a fictional AT&T SIP ITSP trunk. We are allowing a codec negotiation and also possibly a DTMF relay internetworking between CUBE  and the CUCMs on Dial-Peer's 101 & 102 (we needed both of these for another utility on this router using the SIP stack), while allowing for the codec of G.729 Annex B on the AT&T carrier side in Dial-Peers 1001 & 1002. We are also load balancing calls between both of the CUCM Subscriber servers and also between both of the SBCs on AT&T's side that they have given us to peer with. We see this here:

!
ip domain retry 0
ip domain timeout 2
ip domain name ine.com
ip name-server 177.1.100.110
!
voice service voip
address-hiding
allow-connections sip to sip
redirect ip2ip
sip
bind control source-interface Loopback0
bind media source-interface Loopback0
header-passing error-passthru
midcall-signaling passthru
g729 annexb-all
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
!
dial-peer voice 101 voip
description ** TO/FROM CUCM SUBSCRIBER 1 **
destination-pattern 2065011...$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.20
incoming called-number .
dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 102 voip
description ** TO/FROM CUCM SUBSCRIBER 2 **
destination-pattern 2065011...$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.25
dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 1001 voip
description ** TO/FROM SIP ITSP - AT&T SBC 1 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip1.att.com
incoming called-number 2065011...$
dtmf-relay rtp-nte
codec g729br8
!
dial-peer voice 1002 voip
description ** TO/FROM SIP ITSP - AT&T SBC 2 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip2.att.com
incoming called-number 2065011...$
dtmf-relay rtp-nte
codec g729br8
!
dial-peer hunt 1
!
!
voice service voip
allow-connections sip to sip
sip
bind control source-interface Loopback0
bind media source-interface Loopback0
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
!
dial-peer voice 101 voip
description ** TO/FROM CUCM SUBSCRIBER **
destination-pattern 2065011...$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.20
incoming called-number .
dtmf-relay frtp-nte
!
dial-peer voice 102 voip
description ** TO/FROM CUCM PUBLISHER **
preference 1
destination-pattern 2065011...$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.10
dtmf-relay rtp-nte
!
dial-peer voice 1001 voip
description ** TO/FROM SIP ITSP - AT&T SBC 1 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip1.att.com
incoming called-number 2065011...$
dtmf-relay rtp-nte
!
dial-peer voice 1002 voip
description ** TO/FROM SIP ITSP - AT&T SBC 1 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip2.att.com
incoming called-number 2065011...$
dtmf-relay rtp-nte
!
dial-peer hunt 1

Now what if we have a carrier who wants to see our specific domain name (ine.com) after the @ in the Contact header of a SIP INVITE request message (so 2065011001@ine.com   vs.   2065011001@177.1.254.1), possibly for something like compliance with SIP Asserted-Identity? Let's look at what the SIP INVITE might look like prior to any modification to the above configuration:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@177.1.254.1:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20

So what can CUBE do about this? CUBE can alter the contents of any header in any SIP or SDL header of any request or response (SDL or "Session Description Language" is where things like media, DTMF relay, etc are negotiated - you see a SDL sub-component of the above SIP INVITE  message - which is known as a "SIP Early Offer"). So let's tell CUBE to alter that Contact header of that particular INVITE message, but only out to AT&T. As a preface to our configuration example, it is worth noting that SIP Profiles allow for pattern matching and replacement in a similar (but not exact) method to that of Voice Translation Rules, and like them, are based (loosely) on the GNU SED stream editor. We will use this to match and replace a few possible dynamic values of the string. Like Voice Translation Rules, reference "sets" of matched information in the replacement string with \1 which calls Set 1 from the matched pattern to the replacement pattern. Also like Voice Translation Rules, any part of the string (beginning or end) that we don't match, passes through to the replacement pattern, unaltered.
!
voice class sip-profiles 1
request INVITE sip-header Contact modify "<sip:(.*)@(.*):5060>" "<sip:\1@ine.com:5060>"
!
dial-peer voice 1001 voip
voice-class sip profiles 1
!
dial-peer voice 1002 voip
voice-class sip profiles 1
!

Now let's take a look at what that did to the contents of our Contact header in a new call, and thus a new SIP INVITE message that we send out to AT&T:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@ine.com:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20

Excellent! It did exactly what we asked it to!

There are many other things that the Cisco's UBE can do for us, and we have only covered one small one here in this article. For a lot more great information on this product check out INE's Class-on-Demand CCIE Voice Deep Dive for CUBE. By the way, Cisco's implementation of what others in the industry might label a "SBC" (Session Border Controller), goes far beyond what other industry SBCs are able to offer in terms of both features and scalability (CUBE hardware support ranges from ISRs for SMBs, up through ISR-G2s and ASRs for Enterprises, up to the 12000 series routers for SPs). I will cover many more of the offered features of the CUBE in follow-up postings, so stay tuned!

I will leave you with a great Cisco article describing some basic functionality of CUBE and SIP Normalization, and also a lot of great Cisco configuration examples from live SIP ITSP trunks that Cisco has installed and tested with in their RTP labs, as well as live PBX integrations that they have performed, and subsequently written up these "recommended practice" documents.

Apr
28

IPMA is yet another well-known CCM application that you may encounter on your CCIE Voice lab exam. While IPMA Proxy mode is clearly a legacy approach to configure this application its still a topic you could see in the lab. Before we discuss the configuration steps, let’s take a quick overview of a simplified model for IPMA Proxy mode operations. Refer to the diagram for IP Phone extension numbers.

IPMA Proxy Mode

The whole purpose of IPMA proxy is to intercept calls going directly to manager’s IP Phone primary line (“1001”), and proceed them using IPMA configurable call routing logic – usually divert calls to the assistant’s so-called Proxy line (“1112”). In other words, calls placed to manager phone, gets re-routed to assistant’s “proxy” line. Of course, manager has some control of the call-routing logic from it’s IP Phone, using special set of softkeys (plus a Web-interface for advanced configurations).

Now the whole idea of Proxy mode is to put the IPMA application in the call routing path between a caller and the manager’s primary extension. To accomplish this goal, manager’s primary line should be isolated into a separate partition – let’s call it PT_MANAGER. No other IP Phone in the system should have direct access to this partition – their respective CSSes should not contain this partition. Let’s name the CSS used by all IP Phones in the system as CSS_DEFAULT.

Now recall that IPMA is a Java application running in Cisco Tomcat server. IPMA uses CTI interface to control various call-routing components in the CallManager. Specifically, a CTI Route Point should be created in the CallManager system, and IPMA application should take control of it. Next, a “wildcard” extension “100X” should be associated with the CTI RP line and placed in partition PT_INTERNAL - the default partition used for all IP Phone lines within the system (Well, the DocCD recommends using a separate partition for the CTI RP – and indeed, this is a more flexible approach. However, for the sake of the configuration speed, it makes sense to use the minimum set of partitions). The “wildcard” extension number is actually used in configurations where many managers with the primary extension numbers in range “100X” should be covered with the IPMA application. If you are providing call coverage for just one manager’s phone, you can use “1001” here. Also, you may want to set the CFNA number to “100X” or “1001” – this will provide call routing backup in a case when IPMA application would happen to fail.

With the above configuration, when any phone in the system calls “1001” – the manager’s primary line, the call gets routed to “100X/PT_INTERNAL”, and eventually hits the IPMA application. At this point, the IPMA application may want to direct the call to the manager’s real line – “1001/PT_MANAGER” – and this is why the CTI RP should have a special CSS assigned, which has access to PT_MANAGER partition. Let’s name this CSS as CSS_IPMA. As a minimum, CSS_IPMA should contain PT_MANAGER and PT_INTERNAL – since the IPMA may need to redirect call to some other internal extension. (Note that “1001/PT_MANAGER” precedes “100X/PT_INTERNAL” when using CSS_IPMA. This order resolves the ambiguity, even in case when one assigns number “1001” to CTI RP).

To complete the picture, recall the proxy line on assistant’s phone. This is where IPMA application direct calls to by default. Since the assistant may need to direct the call back to manager’s phone, this proxy line should be configured to use CSS_IPMA as the Line CSS. With this setup, the proxy number “1112” is placed in PT_INTERNAL partition (so the CTI RP can reach it) and is allowed to call the manager’s primary line directly. Of course, the primary line of assistant’s phone (“1002”) has no special Line CSS configured, and will therefore hit the IPMA application when calling “1001”.

Per the recommended design, you should also create two intercom lines on both manager’s and assistant’s IP Phones. An intercom is simple a line, which has auto-answer with speakerphone turned on. On the opposite side, you just add a speed dial to reach the intercom number. Thus, you need to intercom lines plus two speed dials to accomplish the intercom configuration.

Now let’s move to the actual configuration. While CallManager has a special built-in IPMA Wizard, personally I’d prefer not to mess with it - unless you’re absolutely sure about what you are doing – the wizard will modify your partitions and CSSes, and may do that in the way you don’t expect. Configuring IPMA proxy mode manually takes a little more time, but once you understand it completely, it won’t take that much. Plus, you get full control of your configuration. So it’s a good idea to create your own IPMA configuration checklist, and use it during your practice. Here is how a checklist may look like.

[Call Intercept]

1) Create Partitions & CSSes: PT_MANAGER & CSS_IPMA
2) Create CTI RP, assign extension number “100X/PT_INTERNAL” to it, set CSS_IPMA as the device CSS. You may also use “1001” extension to cover just one manger
2.1) Set CFNA to “100X” or to “1001” if you provide call coverage for just one manager. This will provide call backup if the IPMA application fails.

[IP Phones]

1) Create a new Button Template, say “3+3 7960” to allow more than two lines on an IP Phone. You will need this template for assistant’s phone, to accommodate three lines: primary, proxy and intercom.

2) Configure the Manager’s Phone
2.1) Set Softkey template to “Standard IPMA Manager”
2.2) Configure the primary line in “PT_MANAGER”
2.3) Add an intercom line, “*1001” and a speed-dial to “*1002” to reach the assistant
2.4) Create IPMA IP Phone service & subscribe the IP Phone to it (URL could be found on DocCD)

3) Configure the Assistant’s Phone
3.1) Set Softkey template to “Standard IPMA Assisant”
3.2) Set Button Template to “3+3 7960” (assistant needs extra lines)
3.2) Add a proxy line “1112/PT_INTERNAL” and set the Line CSS to “CSS_IPMA” for this line
3.3) Add an intercom line, “*1002” and a speed-dial to “*1001” to reach the assistant

[Users]

1) Create a new user named “manager”
1.1) Allow it the use of CTI Application & CTI Super Provider
1.2) Associate this user with manager’s IP Phone

2) Create a new user named “assistant”
2.1) Allow it the use of CTI Application & CTI Super Provider
2.2) Associate this user with assistant’s IP Phone

3) Get back to “manager” user
3.1) Start the Cisco IPMA configuration dialog and disable automatic configuration
3.2) Configure the settings per your setup
3.3) Add a new assistant to the manager
3.4) Configure the assistant, matching proper primary manager’s line against the assistant’s proxy line

[IPMA Application]

1) Choose Service Parameters for Cisco IPMA Application
2) Configure CTI Manager IP Addresses (primary/backup). In simplest case just use your Publisher IP
3) Configure IPMA Application IP Addresses (primary/backup). In simplest case just use your Publisher IP
4) Set the CTI RP name for the IPMA application
5) Restart the Cisco Tomcat Windows Service or go to Tomcat manager interface at http://[IPMA server IP Address]/manager/list and restart the service there

[Verification]

1) Check that manager’s phone has IPMA softkey set on it’s screen
2) Install the Cisco IPMA Console Application and log in there as “assistant”
3) Place a call to manager’s primary line, ensure it get’s routed to the assistant phone, and pick it up from the IPMA console. Forward the call back to manager’s primary line
4) Configure from the manager’s phone to accept all calls and place a call to manager’s primary line once again

Making checklists for complex tasks is a must when preparing to CCIE Voice lab. The above list suggests a simplified manual approach to configure all IPMA application settings, in the order specifically optimized for speed. However, if you are pretty much comfortable with the IPMA Wizard, you can use it for your setup. Just make sure you performed a thorough verification after that.

The final note is about interaction of IPMA proxy mode with the voicemail system. Since we isolate the manager’s primary line in separate partition, we need to make sure MWI CSS is able to access it, in order to light the MWI lamp. Make sure you wont forget about it, since this may cost you some precious points.

Further reading:

Cisco IP Manager Assistant With Proxy Line Support

Subscribe to INE Blog Updates