Cisco Voice Guru

CCIE Voice Study Resources for those who have forsaken free-time and sanity.

CCIE Study Approach

with 6 comments

Approaching a CCIE lab requires intense preparation, accountability, and perseverance.  After passing the lab on August 17th, I decided to crunch some numbers and provide some statistics.  Hopefully, this will help guide you in your journey and provide some sort of baseline to measure yourself against; although, I will be the first to tell you that I am not THE perfect CCIE candidate.

Shot 2010-08-25 at 5.21.35 PM

From the day I passed my CCIE Voice written exam on Nov 25, 2010, until the day I passed the CCIE Voice lab on Aug 17th, 2010, I logged 933 hours of “study.”  To keep myself honest, I had a very rigid definition of studying.  “Study” was classified as the following:

  • Lab time was typically recorded in eight-hour segments.  I used ProctorLabs.com for my CCIE Voice studying needs. In order to get the most “bang for my buck,” I always used the full eight-hour voucher.  This was helped me a lot when the real lab came around.  I was already used to focusing for lengthy periods of times.  This removed the concern about stamina on exam day.
  • Theory time was spent either (a) reviewing IPexpert lab solutions and explanations, (b) listening to Amy Ryan’s amazing Audio on Demand series, or (c) reading every Cisco document that I could get my hands on.  For those of you preparing for the lab, become extremely familiar with the CUCM 7.0(1) SRND, CUCME 7.0(1) Admin Guide, QoS SRND, and anything pertaining to gateways and gatekeepers.  I highly recommend the Troubleshooting IP Telephony book available through Cisco Press.  It’s a bit old, but sure to be a faithful reference beyond passing the exam.
  • Distraction-free was a keyword for studying.  If you’re going to study, don’t leave the TV on in the background.  Don’t listen to music.  Don’t sip margaritas.  You are preparing for a strenuous test unlike any other certification in the IT community.

As you can see from the graphic below, as time progressed, my lab study overtook my theory study.  I don’t think I could have done this any other way.  Before you can really launch out into full eight-hour mock labs, you must have a very solid understanding of call routing, protocols, QoS, features, etc.  The first four months were consumed with SRNDs.  I would wake up at 4:30AM and study theory until 7:00AM.  I’d go to work, come back home, and study another few hours.

As I reached the end of my journey, my theory focused diminished gradually and was replaced by additional lab time.  You should eventually reach a place where you only need to look at documents for clarification.  To make an analogy, you have already built the house, now you’re just applying the finishing touches.

Reader Participation: At this time, I want make myself available to answer strategy questions.  If you have any questions about study methods, lifestyle modifications, etc. pertaining to lab preparation, post them as comments on this blog.  I will compile the questions and answer them as a separate post in the next week.

Written by Matthew Berry

August 25th, 2010 at 4:49 pm

Post-Lab Debriefing: Thanks and Thoughts

with 2 comments

All -

I want to thank IPexpert for their help and support during the last year.  Amy and Vik are incredible instructors.  They really want to form you into a true CCIE, not just someone who can pass the test.  I am greatly indebted to the amount of work they put into the v3 materials that they offer.  Way to go guys!

I also want to say a HUGE thanks to the IPexpert technical support guys: Drew LePla, Ryan Barnum, and Andrew “B” Shipton.  You guys know how many times I  sent after-hours support requests!  Thank you for your help.

A thanks to my buddy, Mike Down aka “Frank” – You sold me a good deal on the end-to-end package and provided plenty of sarcasm and customer service throughout my journey.  Keep yer’ stick on the ice, my friend.

I also want to thank my study partners: Antonio McCarver, Roger Källberg, Jeff Cotter, Warren Heaviside, and the list goes on and on.  I made some great friends on this journey.  You know who you are.  Let’s keep in touch.

I also wanted to shoot out a few thoughts while things were still fresh in my mind.

Tip 1: You begin taking the lab the night before

Make sure that you prepare yourself for the lab the night before.  My wife told me to not have sugar or carbs because they can slow down your mental recall abilities.  Don’t eat heavy food. Try to avoid excess sugar and carbs.

Take a 30-45 minute walk the night before.  This will help alleviate stress and provide “feel-good” endorphins that will help as you go to bed.  The morning of the exam, do not have ANY sugar or carbs.  For me, I went to Denny’s and had eggs, bacon, and fruit.  Protein is good for endurance and mental alertness.  After having breakfast, I went for a 30 minute walk.  I was super nervous going into the lab because it was my first attempt.  I felt that the walk in the morning was a great stress reliever.  When I went into the lab, I was riding high on those positive endorphins for the first hour.

Tip 2: Don’t waste your “free” meal at Cisco’s cafeteria

You get something like $13-14 to spend for lunch.  Following my wife’s advice, I avoided sugar and carbs.  I had a big salad with tons of protein (chicken, bacon, eggs) and fruit.  I was tempted by the fresh pizza, burgers, and fries, but managed to avoid them.  When I returned to the lab, I was alert and not groggy in any way.  Other guys picked up sugary drinks, chocolate, cookies, fries, etc.  Don’t make that mistake!  You’ve invested a lot of time into your preparation, don’t handicap yourself by being undisciplined and eating junk food for lunch.

Tip 3: Keep a spreadsheet to track your study progress

The CCIE lab requires a high level of personal dedication and perseverance.  Use a spreadsheet to track your study time.  Every Monday morning, I would determine the number of hours I would study that week, clearly define what IPexpert labs I would focus on, and what Cisco documents/concepts I would study.  I would schedule my week and hold myself to it.

Logging your time can be a great confidence-booster as well.  By the time I went in to the take the test, I had logged 600 hours worth of rack time and another 350 hours worth of reading/reflection since January 1st.  I was able to confidently tell myself, “Matthew, you know this!  You’ve done this many, many times before.”

Tip 4: Get involved in online study lists like the OSL

Gather people around you who will challenge you.  IPexpert’s online study list was a great way to meet other people and be challenged.  If you come across a question, do your research, check the OSL archives, and then send an email out to the group if you’re still stumped.  Make an effort to be a contributor.  Don’t just ask questions, but answer them as well.  I made a commitment early on to answer at least one email once a week.  It was a great way to be stretched.

I will write more on my blog over the next few weeks, but these were just a few tips that really helped me.

You know, there’s no shortcut to getting your CCIE.  In the end, it takes a lot of hard work, sore muscles, awkward schedules, etc.  The reason Voice IEs are so coveted in the marketplace is because there are so few of them.  Not many people are willing to make the sacrifice in order to get the prize.  Commit yourself to the goal, throw yourself into your study plan, and “get ‘er done!”

Written by Matthew Berry

August 18th, 2010 at 8:25 am

I passed – CCIE #26721

with 14 comments

Just found out that I passed! More details to come.

Let me just say that it’s a phenomenal feeling to get that score report. Now I can exhale, lay back, and get back to my real life.

Written by Matthew Berry

August 17th, 2010 at 5:23 pm

Building C – Less than 24 hours away

with 8 comments

This morning I took a trip to Cisco’s campus to figure out where Building C was located.  Actually, I visited the same building the day before.  Even though I knew where it was, I had to do a solo run today for the sake of my nerves.

Tomorrow is D-Day.

BuildingC

Written by Matthew Berry

August 15th, 2010 at 10:41 am

Posted in Random

Practice Lab Reflections 8

with one comment

CUCME

  • When changing MAC addresses on SIP phones in CUCME, make sure that you copy the entire output of the SIP phone.  Otherwise the "no id mac" command will erase the entire configuration under "voice register pool".
  • SIP CUCME phones cannot use "voice class code" to step down codecs to a lower type.
  • "num-exp" commands do not reorder themselves.  You will need to reorder them frm most specific to least specific.

Useful Debugs

debug voip dialpeer
show voice register dial-peer
show sccp connections summary
show sccp connections
show dspfarm dsp active
show call active voice brief
show gatekeeper gw-type prefix
show gatekeeper zone prefix
show gatekeeper endpoint
show gatekeeper call
debug isdn q931

Mobility

Physical Location

  • Is mobility enabled on the device?
  • Check the phone’s subnet.  Is it connected by Device Mobility Information to a Device Pool?
  • Compare the Physical Location of the home Device Pool to the roaming Device Pool.
  • If the same, use the home Device Pool.
  • If different, use the roaming Device Pool paying additional attentions to the "Roaming Sensitive Settings."

Device Mobility Group

  • Check the Device Mobility Group on the Device Pool
  • If the same, the ROAMING device pool CSS overrides the device CSS.  This is the one case where Device Pool overrides device CSS.
  • If different, the device CSS takes precendence.
  • Note: Think of DMGs are dialing vernacular for a region.  This would allow a caller in France to roam to the US and dial a local Minnesota number as he is familiar with, as an international number.
  • CIPC is not a supported UM client.
  • The "Mobile Phone" checkbox allows use of the "Transfer to my mobile" service.

Written by Matthew Berry

August 9th, 2010 at 1:06 pm

Posted in Practice Lab Notes

Practice Lab Reflections 7

without comments

Gatekeeper

  • Make sure gatekeepers setup to route according to the full E.164 number.
  • You must have more than a zone match in order route the call.
  • # is good for gatekeeper routing because there is no chance of overlap.
  • The advantage of the default technology is that you don’t need to prepend the Tech-Prefix in the Called #.  The gatekeeper routes the call to the destination zone as defined by the matching zone prefix.  The gatekeeper will randomly choose a gateway in the destination zone that has registered with the default tech-prefix: gw-type-prefix 1#* default-technology

Gateway

  • H.323 gateways view the + character as an invalid character.  You must do a number translation on the IOS gateway itself to re-add the + to the outbound calling party (ANI) number.
  • Useful command for voice translation rules: "test voice translation-rule [rule#] [test#]"
    If you add a voice translation to the voice-port instead of the dial-peer, this will change all PSTN calls coming in/out of the T1/E1.
  • When configuring a gateway and gatekeeper in CUCM that coincidentally happens to be the same device, remember that you cannot use the same IP address.  Either use a different physical interface or create a loopback address to use for the second logical device in CUCM.
  • The following command is useful when configuring redundant dial peers to external H.323 endpoints.  It allows for timeouts and resulting failover capabilities:
    voice class h323 1
    h225 timeout tcp establish 3
  • The following command is used to change the H.225 listen port:
    h323
    h225 listen-port 1820
  • As a best practice, strip the 9 at the IOS gateway level to accommodate SRST capabilities.
  • In order to strip the caller ID name information on an IOS gateway, use the "clid strip name" in dial-peer config mode.
  • dsp-farm profiles are in a "shutdown" state by default.  Remember to "no shutdown" them.
  • With H.323 gateways and SRST, it is always best to take the incoming calling number and manipulate it for call processing while the call is still within the IOS gateway.

CUCM

  • Significant digits are always the right-most digits.
  • H.323 Fast Start sends H.225 call control and H.245 call capabilities information over the same TCP 1720 port at the same time.  This allows for faster call establishment.
  • Calling/Called Party Transformation Patterns should be completely separated from the call routing partitions.
    pt-ani-gw-hq
    css-ani-gw-hq
  • SIP devices do not support the annunciator in CUCM.
  • It is the destination device (from CUCM’s perspective) that determined the called/calling party transformations used.
    Local:         \+1212.XXXXXXX
    Long Distance:     \+1.!
    International:     \+.!
  • With SIP dial rules in CUCM, the following commands are useful:
    >#    Used at the end of a string to bypass the interdigit timeout
    \*     Used at the beginning of a string to denote a number beginning with *
  • Inbound globalization takes place after the call has been passed from the IOS gateway to CUCM.
  • SIP does not offer an indication of the numbering type. Therefore, SIP gateways will not be able to receive an indication of the called or calling party number type set by CUCM
  • When you uncheck "Use Device Pool Calling/Called Party Transformation CSS" on an MGCP gateway, you must bounce MGCP on the IOS itself.
  • TIP: Whenever something fails, immediately restart the gateway or trunk in CUCM.  You never know.
  • Remember to set "Stop Routing on Unallocated Number Flag" to FALSE.  This is required to allow failover across trunks in CUCM.
  • No MTP check box is required when setting up interoperability between Cisco devices.  The devices use proprietary communication channels to enable MTP as necessary.
  • Translation patterns preempt route patterns.
  • The # is stripped by default when sending the call out of CUCM.  There is a service parameter to modify the way it behaves.
  • When deploying site codes in a variable-length on-net dial plan, configure a translation pattern per site to translate 1XXX into 8-408-1XXX to be routed on via the PT-INTERNAL partition.
  • When using the line device approach, remember the priority order is reversed for CTI devices.  For these devices, partitions in the device calling search space are given priority over those before the line casing search space.
  • When using the line/device approach, make sure that the globalized version of the numbers are also blocked.  This is a gotcha.
  • When using the line/device approach for extension mobility, the users must adapt their dialing behavior to that of the local site.
  • The Call Forward All CSS under the line configuration is not concatenated with any other calling search space.  In order to function properly, they must be manually set.

Written by Matthew Berry

August 9th, 2010 at 1:00 pm

Posted in Practice Lab Notes

CUE MWI Notification Methods

with 3 comments

When considering MWI notification methods for a CUCME-CUE integration, there are three options: (1) Outcalling, (2) Subscribe Notify, and (3) Unsolicited Notifiy.  While the two SIP notify methods can be used together, you cannot configure Outcalling and Unsolicited notify at the same time.

The following will briefly explain the commands required to configure each method.  For the purpose of this posting, the CUCME IP address is 10.10.202.1 and the CUE IP address is 10.10.202.2.  Anyone familiar with ProctorLabs’ IP schema will recognize that I use ProctorLabs.com for all my remote vRack studying needs.

Look at the three methods and tell me which one you would rather configure.  Based on the number of commands alone, SIP Unsolicited Notify is the prime choice.  A study partner of mine actually commented that unsolicited is Cisco’s best practice for MWI delivery in a CUCME-CUE integration.  Don’t call that gospel, I haven’t found the documentation for myself, by I can see why it would be a best practice.

Outcalling

CUCME:

dial-peer voice 3600 voip
destination-pattern 3600
session protocol sipv2
session target ipv4:10.10.202.2
incoming called-number 399[89]….
dtmf-relay sip-notify
codec g711ulaw
no vad
!
ephone-dn  11
number 3998…. no-reg primary
mwi off
!
ephone-dn  12
number 3999…. no-reg primary
mwi on

CUE:

ccn application ciscomwiapplication aa
parameter "strMWI_OFF_DN" "3998"
parameter "strMWI_ON_DN" "3999"
end application

SIP Subscribe Notify

CUCME:

sip-ua
mwi-server 10.10.202.2
!
ephone-dn 1
description BR2 Phone 1
number 3001 no-reg
mwi sip

CUE:

ccn subsystem sip
gateway address "10.10.202.1"
mwi envelope-info
mwi sip outcall sub-notify
end subsystem

SIP Unsolicited Notify

CUCME:

sip-ua
mwi-server 10.10.202.2 unsolicited

CUE:

ccn subsystem sip
gateway address "10.10.202.1"
sip unsolicited
end subsystem

Written by Matthew Berry

August 8th, 2010 at 10:31 pm

Practice Lab Reflections #6

with one comment

  • Great list of troubleshooting documents under the support web page: Technology > Voice > Gateway Protocols > All gateway Protocols > Config Examples and Technotes
  • If you have DHCP issues, disable CSA using “utils csa disable”
  • To configure LLDP-MED, go to SWITCHES > CISCO CATALYST 3750 SERIES SWITCHES > CONFIGURE > Configuration Examples and TechNotes > Configuration Guides > Catalyst 3750 Switch Software Configuration Guide, 12.2(50)SE > Configuring LLDP, LLDP-MED, and Wired Location Service
  • To configure VATS over Frame Relay, go to IOS > 12.4 T > CONFIGURE > Configuration Guides > WAN >

    Cisco IOS Wide-Area Networking Configuration Guide, Release 12.4T > Expand Part 1: Frame Relay > Adaptive Frame Relay Traffic Shaping for Interface Congestion

  • To capture the first several digits in a string variable in UCCX, use the following example: “set sFirstDigits = sAllDigits.substring(0,2)”.  This will capture the first two digits in a string.
  • It is a good idea to mark all “emergency” route patterns in CUCM with Urgent Priority in order to avoid any T.302 inter-digit timeouts.
  • Press voicemail button in SRST mode. On hunt pilot, check calling party mask to XXXX and it should work.
  • Access list for signaling traffic

ip access-list extended Signaling-ACL
permit tcp any any range 1718 1721
permit tcp any any range 2000 2002
permit tcp any any range 2427 2428
permit udp any any range 11000 11999

  • CCIE Voice techtorial from Cisco Live! this year had the following sample configuration for dspfarm profiles:

sccp ccm 10.1.1.1 identifier 1 priority 1 version 6.0+
sccp ccm 10.1.1.2 identifier 2 priority 2 version 6.0+
sccp ccm 10.1.1.3 identifier 3 priority 3 version 6.0+
!
sccp ccn group 1
associate ccm 1 priority 1
associate ccm 2 priority 2
associate ccm 3 priority 3
associate profile 10 register SB-CONF
 keepalive retries 5
switchover method immediate
switchback method immediate
switchback interval 15

  • It is possible to verify queuing using the command “show policy interface”.
  • A great place for best practices is in the CUCM SRND under CALL PROCESSING > INTEROPERABILITY OF UNIFIED CM AND UNIFIED CM EXPRESS.
  • Remember to add the TERMINATE step at the end of a script, right before the END step.
  • Placing an outbound H.323 call triggers an H.225 call setup conversation between devices.  As soon as the recipient picks up the receiver, an H.245 call control TCP handshake takes place between the endpoints.  During this interaction, TerminalCapabilitySet is negotiated.

103086

UCCX Configuration Checklist

  1. CUCM – CTI Manager Service Activation
  2. UCCX – Define AXL Service Provider Address, Username, Password
  3. UCCX – Define Cisco Unified CM Telephony Provider (CTI Manager), User Prefix (Jtapi user), Password
  4. UCCX – RMCM Provider, User ID (Rm user), Password
  5. UCCX – NTP Server
  6. UCCX – Add new Application, associate with ICD script
  7. UCCX – Cisco Media Termination Dialog Group Configuration
  8. UCCX – Cisco Unified CM Telephony Subsystems Configuration
    • Define Cisco Unified CM Telephony Provider
    • Define Cisco Unified CM Telephony Call Control Group (Add CTI ports)
    • Define Cisco Unified CM Telephony Call Control Triggers
  9. UCCX – Define RMCM Proivder
  10. UCCX – Define Resource Group, and then Resources (or skills)
  11. UCCX – Define Contact Service Queue (CSQ)

Written by Matthew Berry

August 5th, 2010 at 8:01 pm

Posted in Practice Lab Notes

10 Days and Counting

with 2 comments

My first attempt at the CCIE Voice lab in San Jose, CA is ten days away.  I have the lesser part of a week to study in isolation.  My wife took the two boys out of town to visit family.  From now until Wednesday night, I will be labbing 12-16 hour days in preparation for my first attempt.

When I talk to people about my upcoming lab they all ask me how I feel.  That’s a difficult question to answer.  My personality is such that I am very hard on myself.  If I feel 90%, I cut it down to 50% to be safe.  It’s just part of my personality.  I never plan on anything.  I always assume the worst.  Not good, I know, but it at least keeps me driving towards my goal.

My biggest struggle now is what to focus on in the next ten days.  I don’t want to get tunnel vision and only focus on two or three concepts.  I need to keep the entire blueprint in view.  However, there are definite areas that I am weak in.

Does anyone have any suggestions on last-mile preparation?

This is a rough plan that I might follow:

Saturday – Aug 7th

  • Before 8:00 AM – Review recent notes, determine key issues to test during the day
  • 8:00 AM to 4:30 PM – Full lab with 30 minute lunch in between
  • 4:30 PM to 6:00 PM – Break. Dinner. Relax.
  • 6:00 PM to 12:00 AM – Grade my lab. Isolate specific issues.

Sunday – Aug 8th

  • 7:00 AM to 8:00 AM – Quiet time of reflection
  • 8:00 AM to 9:00 AM – Review recent notes, determine key issues to test during the day
  • 9:00 AM to 5:30 PM – Full lab with 30 minute lunch in between
  • 5:30 PM to 8:00 PM – Break. Dinner. Relax.  Call wife.
  • 8:00 PM to 12:00 AM – Grade my lab. Isolate specific issues.

Monday – Aug 9th

  • Repeat previous day

Tuesday – Aug 10th

  • Repeat previous day

Wednesday – Aug 11th

  • 7:00 AM to 8:00 AM – Quiet time of reflection
  • 8:00 AM to 4:30 PM – Full lab with 30 minute lunch in between
  • 4:30 PM to 7:00 PM – Pick up wife and kids from airport. Dinner.
  • 7:00 PM to 12:00 AM – Grade my lab. Isolate specific issues.

Thursday – Aug 12th

  • 7:00 AM to 8:00 AM – Quiet time of reflection
  • 8:00 AM to 9:00 AM – Review recent notes, determine key issues to test during the day
  • 9:00 AM to 5:30 PM – Full lab with 30 minute lunch in between
  • 5:30 PM to 7:00 PM – Dinner with family.
  • 7:00 PM to 12:00 AM – Grade my lab. Isolate specific issues.

Friday – Aug 13th

  • 6:00 AM to 7:00 AM – Quiet time of reflection
  • 7:00 AM to 2:45 PM – Full lab with no lunch in between
  • Rest of day – Spend time with family, date with wife, pack for trip

Saturday – Aug 14th

  • 7:30 AM – Arrive at airport
  • Airport/Plane – Read notes, mentally prepare
  • 1:00 PM to 3:00 PM – Check into hotel and take a nap
  • 3:00 PM to 5:00 PM – Read notes, mentally prepare
  • 5:00 PM to 7:00 PM – Dinner with fellow CCIE study partner
  • 7:00 PM to 8:00 AM – Call wife
  • 8:00 PM to 10:00 PM – Scour Cisco’s documentation website

Sunday – Aug 15th

  • 7:00 PM to 8:00 AM – Quiet time of reflection
  • 9:00 AM to 11:00 AM – Read notes, mentally prepare
  • 11:00 PM to 12:00 PM – Drive to Cisco’s Building C
  • 12:00 PM to 6:00 PM – Find something to do in San Jose
  • 6:00 PM to 7:00 PM – Scour Cisco’s documentation website
  • 7:00 PM to 8:00 PM – Read notes, mentally prepare
  • Rest of evening – Close my books, shut down the computer, take walk, listen to music.

Monday – Aug 16th

  • 6:00 AM to 7:00 AM – Quiet time of reflection
  • 7:00 AM to 8:00 AM – Get ready. Drive to Cisco.
  • 8:15 AM to 5:10 PM – CCIE Voice Lab – Attempt #1
  • 6:00 PM to 8:00 PM – Dinner with friend

Tuesday – Aug 17th

  • Fly back home

Written by Matthew Berry

August 5th, 2010 at 3:14 pm

Posted in 00 General

MeetMe Password Protection

without comments

Several months ago, I came across a great script that combines UCCX/IP-IVR with MeetMe functionality.  This allows you to front-end MeetMe calls with a conference number and pin.  Call it a “poor man’s” version of Meeting Place.

Read the rest of this entry »

Written by Matthew Berry

July 28th, 2010 at 7:38 am

Posted in Random