Blog Move

I've decided to move to hosting my blog myself. So from here on out head over to TrippleHelix.net for new posts.

Exchange 2010 Blind Transfer

Scenario

Edward executive admin answers the phone for Edna executive. This is setup in CUCM so that Edward
has two line appearances. His x1000, and then Edna’s on his second line button x1001. When someone
calls Edna both her and Edward’s phones ring. Occasionally Edward would answer Edna’s line and the
caller would ask to be transferred to her voicemail. Under the Unity voicemail system this was not a
problem Edward would press transfer on his phone dial *1001 and then transfer again to connect the
caller to Edna’s voicemail greeting, the caller would leave a message and all was well with the world.

Problem

With Exchange UM this was not the case. When Edward would dial *1001 from Edna’s line he would be
greeted with the user PIN prompt as if he was trying to check Edna’s voicemail. As we know Exchange
UM relies on the SIP diversion header information to know who the call is from. In this case the call
appeared to be from Edna meaning Exchange UM assumes that Edna is trying to check voicemail so play
the login greeting.

Solution

The root cause of the problem is the default settings on the SIP trunk going from CUCM to Exchange
UM. On the Outbound Calls section, Calling Party Selection this is defaulted to Originator. Meaning the
directory number sent in the diversion header to Exchange is going to be the first call leg in the transfer,
in the above example this would be Edna’s directory number.
Changing this setting to Last Redirect Number results in the last device to be connected to the call leg
having its caller ID used in the diversion header. In this example that would be the caller that is currently
being transferred to Edna’s voicemail. This results in the desired behavior of the caller being prompted
to leave a voice message for Edna.


HOWEVER this then means that during a normal call no answer scenario the last device connected in the
call leg is Edna’s phone which brings us back to where we started. The user would be greeted with the
login prompt for voicemail and not the option to leave one. This is resolvable however by creating a
special trunk used only for blind forwarding. The blind forwarding trunk will have its Calling Party
selection set to Last Redirect Number. While the normal voicemail trunks will be set to Originator
solving both use case needs. This also requires the creation of a separate voicemail pilot number to be
created so it can be pointed at this specific blind forward trunk.

Summary

Normal Voicemail Trunk

Blind Forward Trunk

CUCM SQL Magic (well really just queries) - Part 2

So last time we figured out how to read from the CUCM DB directly using SQL statements. This time we're going to start changing things. So like last time I recommend you take a backup and don't do anything you think could end in creating a fissure in the space time continuum.

Last time we learned that DN 1234 had a voice mail profile of 16c584ea-6a81-4138-9ea1-af452de8f75a. But maybe we want to change this, to say no voice mail. We learned that this had a PKID of NoVoiceMail 00000000-1111-0000-0000-000000000000. So we just need to update the DN to reflect this. With an easy SQL statement.


run sql update numplan set fkvoicemessagingprofile = '00000000-1111-0000-0000-000000000000' where dnorpattern = '1234'

What we've said above is update the numplan table and set the fkvoicemessagingprofile field to the value 00000000-1111-0000-0000-000000000000 where the DN is 1234. If all is well you should get the following output:

Rows: 1

Meaning that 1 row in the table was updated. If you go and check in the GUI your new voice mail profile change is reflected. Now it would be easy to break this into a nice long excel document output that in plane text and you're a copy paste away from easy DB updates that you otherwise couldn't do in the GUI.

CUCM SQL Magic (well really just queries) - Part 1

Have you ever been trying to do a mass edit of some sort in CUCM and realized that the field or way you wanted to do it wasn't available to you via the Bulk Administration menu. Or more aptly like me today "Are you @#$@ing kidding me Cisco you are epic fail!". Well then you're in luck my suffering is your gain.

The Resources
The Data Dictionary
In order to work with the CUCM DB one must know thy enemy. That's where the data dictionaries come in. If you go to Cisco.com and do a search for "Data Dictionary" you'll come up with a list of hits select the data dictionary that applies closest to your version of CUCM. Each version of CUCM does not come with data dictionary only when the Devs decide to make schema changes do you get a new one. The horribly created PDF lists each table in the CUCM DB and each column in it. With descriptions of what, who, blah blah.

SQL Cheat Sheet
If you're also like me knowing SQL is near the bottom of things I'd like to know. I'm not a programmer I'm a hack programmer. I can take something rip it apart and hope for the best. That being the case I can't remember SQL syntax from Expect syntax to PHP to HTML, so on so forth and god only knows how many other things are floating around in my brain.

So why know when I can cheat. After all it's not about knowing the answers it's about knowing where to find them. The following site is a nice condensed command reference for SQL which we'll need as CUCM uses a SQL to Informix interrupter.
http://www.sql-tutorial.net/SQL-Cheat-Sheet.pdf

The Task
Look don't touch
Now I highly recommend before you go mucking about in your CUCM DB you 1) take a backup. You might BREAK THE WORLD. 2) Why not look around before we go hacking off limbs willy nilly. So with that in mind lets use the following example.

Find a users voicemail profile based on assigned DN. Example DN = 1234

1.  Login to the CUCM publisher via SSH. (if you don't know what I'm talking about this whole blog post isn't for you probably)
2. Build our query - the syntax in the CLI is as follows: run sql
3. So in our case we want to find the voicemail profile on lines that have DN 1234 assigned. So our statement would be:
   run sql select fkvoicemessagingprofile from numplan where dnorpattern = '1234'

admin:run sql select fkvoicemessagingprofile from numplan where dnorpattern = '1234'
fkvoicemessagingprofile            
====================================
16c584ea-6a81-4138-9ea1-af452de8f75a 

What we've said above is show me (select) the field fkvoicemessagingprofile from the numplan table, where the DN (dnorpattern) is equal to 1234.

This returned the system unique identifier for the lines voicemail profile. But that's not too helpful unless you happened to remember each ID in the system. But we can look this up with another query. Instead of just looking up one lets get a list of all of them in the system. The statement would be:
run sql select name,pkid from voicemessagingprofile where pkid like '%'

admin:run sql select name,pkid from voicemessagingprofile where pkid like '%'
name        pkid                              
=========== ====================================
Default     16c584ea-6a81-4138-9ea1-af452de8f75a
NoVoiceMail 00000000-1111-0000-0000-000000000000

What we can see is above we've said. select the fields Name and PKID(unique system identifier) from the voicemessagingprofile table where the PKID is like %. If you look up SQL operators you'll learn that % is a wildcard meaning one or more characters so anything really.

What we've learned here is our number above is assigned the default voicemail profile. as the PKID matches.

Part two will cover how we change this via the CLI. Stay tuned.... Part 2

HoneyPot Go

Just a simple post to see how long my test Honey Pot takes to get compromised.

ftp://67.171.169.222

CCNP Voice Notes - Dials Peers and Matching OH MY!

Inbound Dial Peer Matching
3 elements in call setup message:

1. Called Number (DNIS)
2. Calling Number (ANI)
3. Voice Port - port the call is coming in on

Plus 5 configurable dial peer attributes processed top down only if one above fails to match:

1. Called number with incoming called-number.
• Tries matching on DNIS if multiple longest match wins (YAY)
2. Calling number with answer-address.
• Tries matching on ANI again if multiple longest match wins.
3. Calling number with destination-pattern.
• Tries to match DNIS to destination-pattern (think route pattern) if multiple yada yada.
4. Voice-port associated with the port parameter.
• Tries to match on port parameter if multiple dial peer first added in the config wins.
5. Last ditch, default dial peer.

*NOTES*

Use the answer-address command when matching the region of a caller, recommended situations:

• Callers from a given country should be directed to an appropriate group.
• Directing callers from a specific region to a regional support group.

Use the incoming called-number command whenever possible. All call setup messages include DNIS.

Outbound Dial Peer Matching

When a call arrives at a voice gateway, it uses the incoming dial string to match the destination-pattern on the outbound dial-peer. Once a match is found the port on POTS dial peers or session-target on VoIP dial peers is used to forward the call. MOST SPECIFIC MATCH WINS

Default Dial Peer (Don't be sad little guy you're important too)

Default dial peer referred to as dial-peer 0 (sounds ominous) it is used if no inbound dial peer can be matched, see list above. ONLY USED FOR INBOUND NEVER EVER EVER, (DON'T EVEN THINK IT) used for outbound. Characteristics of DP0 (Dial peer 0, DP0 sounds even more ominous) cannot be changed.

DP0 VoIP Characteristics

• G.729 / G.711
• IP precedence set to 0.
• VAD enabled
• RSVP not supported
• Fax-rate service supported

DP0 POTS Characteristics

• No applications supported
• No DID support

Avoid using DP0 when possible.

CCNP Voice Notes - Call Legs / Dial Peers

Call Legs
Every voice call to be completed must have a minimum of two call legs. An Incoming call leg and an Outgoing call leg.

POTS Call Leg – Connected to a non-VoIP network such as POTS line, PRI, BRI etc.
VoIP Call Leg – Connected to a VoIP network such as SIP, H.323.

Dial Peers 
Destination Pattern – Used to match the called telephone number.
Incoming Called-Number – ONLY Considered on selecting inbound dial-peer when it matches the original dialed/called number.
Answer-address – ONLY Considered on selecting inbound dial-peer when it matches the original calling number. 

Call Number aka DNIS (Dialed Number Identification Service)
Calling Number aka ANI (Automatic Number Identification)

Pattern	Description
0-9 A-D * #	All numbers that exist on the phone keypad.
Plus +	First character designates E.164 number; otherwise it specifies that the digit before occurred one or more times.
Period .	Matches any entered digit
%	The digit before occurred either zero or more times.
?	Repeats the digit before zero or one time. Press ctrl-v to disable context help to enter the ?
Circumflex ^	Indicates a match to the beginning of the string.
$	Matches the null string at the end of the string.
T	Makes router wait till all digits are collected. Means variable length.
Backslash \	Followed by a single character, matches that character.
Brackets [ ]	Indicates a range
Parentheses ( )	Indicates a pattern

Examples

Pattern	Matches
5555	Explicitly matches 5555
555.	Matches 5550 – 55559
555[3-9]	Matches 5553 – 5559
(555)?5	Matches 5 or 5555
5%555	Matches 555 or 55555…555
^5555$	Matches 5555
9T	Matches 9 – 999999999999 until digits are done being entered

CCNP Voice Notes - Call Processing / Deployment Models

Call Processing Agents

Agent	Recommended Size	Comments
Cisco CME	Up to 240 Phones	Dependent on Cisco IOS Platform
CUCM	50 – 30,000 Phones
Legacy PBX	Dependent on PBX

IPT Deployment Models

·         Single Site

o   Design Characteristics

§  30k SCCP / SIP phones per cluster

§  2,100 H.323 / MGCP gateways per cluster

§  DSP resources for transcoding / MTP as needed

o   Benefits

§  Ease of deployment

§  Common infrastructure for a converged solution

§  Simplified dial plan

§  No transcoding resources needed because of the use of a single high band-width codec.

·         Multi-site with centralized call processing

o   Design Characteristics

§  All single site Characteristics

§  Max 1000 locations per CUCM cluster

§  Max 150ms one-way latency to phones

o   Benefits

§  Single point of management

§  Cost savings using IP WAN for calls between sites

·         Multi-site with distributed call processing

o   Design Characteristics

§  All single site Characteristics

§  Max 1000 locations per CUCM cluster

§  Max 150ms one-way latency to phones

o   Benefits

§  Cost savings using IP WAN for calls between sites

§  Use of IP WAN for TEHO

§  No loss of functionality during WAN outage

·         CoW – Cluster over WAN

o   Design Characteristics

§  All single site Characteristics

§  Max 1000 locations per CUCM cluster

§  Max 150ms one-way latency to phones

§  Max 40ms one-way latency between cluster nodes

o   Benefits

§  Single point of Administration

§  Feature transparency

§  Extension mobility within cluster

§  Unified dial plan

The Road to CCNP Voice

So it's been a while I'll admit. Things have changed I have a new job with more focus VoIP / UC. In fact it's my task to cut over multiple CUCM clusters to 8.6 and along the way ditch Cisco Unity in favor of Microsoft Exchange 2010 UM.

So during this journey I plan to make some postings of useful tips I run across and also while I study for CCNP Voice I will use the blog to help myself retain some information.

That being said. PowerShell is pretty cool, never thought I'd say that but I've run across some useful commands to help me extract data from the AD side of the house to compare against Unity.

If you're in our boat you have Lync but your AD forest is still old. That being said PowerShell against AD is then off limits. Unless you cheat and use Lync to get the information for you.

Export list of Users from Lync

Import-Module Lync
Get-CsAdUser -OU "ou=Users,ou=Location,dc=blah,dc=domain,dc=com" | Select-Object SamAccountName,FirstName,LastName,Phone | Out-File C:\Users\person\Desktop\users.txt

What that lovely  command above will do is, extract all the users from the OU in a nice Tab separated file on the desktop with the following fields: Account Name, First Name, Last Name, Primary Phone Number.

Stay tuned for more details as I lose my mind during the migration and cram some CCNP Voice knowledge in. First up is the CVoice book.

CCNA Voice Passed

So I finally finished up my CCNA voice. In hind site I could of had this done months ago. I will say I was disappointed only one simulation and a lot of arbitrary questions.

BERT

So yes it’s been a while since my last post. I’ve been busy going back to school working on a BS in Electrical Engineering. Additionally got a promotion at work now Sr. Network Engineer, anyway on to the reason for the post.

Bit Error Rate Test – BERT
http://en.wikipedia.org/wiki/Bit_error_rate

I’m working on swing over to a new DS3 this weekend at work. This will be my first DS3 turn up and it turns out it’s just an over grown T1 for all extensive purposes. One important thing that I’ve learned to do though before moving production traffic is make sure L1 & L2 are actually functional. This is where BERT comes in.

I’ve worked with the provider to put a loop facing the new end of the DS3. On the interface I have the following config:

description Unused
bandwidth 44210
no ip address
no keepalive
dsu bandwidth 44210
scramble
framing c-bit
cablelength 10

I show the interface is UP UP so at least I know I have my RX and TX side of the cables connected correctly. To kick off the BERT we must make sure keep alives are disabled which you can see above it is.

From the system we issue the following command under the interface. (this may vary by platform):
bert pattern qrss interval

In this case I’m running the test for 12 hours as I want to be absolutely certain this circuit is ready to pass production traffic. Notice how I’ve used QRSS.

Per Wikipedia - QRSS (Quasi Random Signal Source) – A pseudorandom binary sequencer which generates every combination of a 20-bit word, repeats every 1,048,575 bits, and suppresses consecutive zeros to no more than 14. It contains high-density sequences, low-density sequences, and sequences that change from low to high and vice versa. This pattern is also the standard pattern used to measure jitter.

This is as close to real life traffic you can create with a simulated test. If it passes this I should be in good shape to go assuming L3 and up play nice but at that point it’s my problem to deal with.

From this point we can go back to enabled exec mode and check the progress by issuing:
show controllers serial 3/0/1

At the bottom we see:
BERT test result (running)
Test Pattern : 2^20 qrss, Status : Sync, Sync Detected : 1
Interval 720 minute(s), Time Remain : 11:27:40
Bit Errors (since BERT started): 0 bits,
Bits Received (since BERT started): 86115 Mbits
Bit Errors (since last sync): 0 bits
Bits Received (since last sync): 86115 Mbits
MDL transmission is disabled

As you can see we’ve been going for about 30 minutes with no errors so this is looking good.

CCNA Voice Study – Installing CUCME PART 1

CUCME is comprised of multiple files and file types compared to a single unified Bin file like IOS. CUCME is comprised of the following: Basic Files, GUI Files, XME Temple File, Music on Hold (MOH) Files, Script Files, and Miscellaneous Files.

To install CUCME you must first have a matching IOS version to support it such as advanced IP services or advanced enterprise services. See the Cisco download area for the proper IOS version to download to match with the CUCME version you will be installing.

Once the IOS is upgraded issue the following command:
Archive tar /xtract tftp://(ip address)/cme-full-7.0.tar flash:

Replace the details above to your actual release. This will then TFTP the tar file and extract it in real time to the flash storage. Now that all the files are on the router we need to make them accessible to the IP phones for their firmware etc. Issue the following commands:

Tftp-server flash:/phone/7940-7960/P00308000500.bin alias P00308000500.bin

What this is doing is telling the router to share out that Pxxx file via TFTP and also should a device just ask for that file and not provide a full path it will still send it. This is important as the phones will only ask for the file and not the path where that file resides. Do this for all the remaining files in that folder adjusting file names accordingly. You will also need to repeat this process for all the backgrounds, MOH files ect that the phones will need.

Now that the files are served up we need to configure some of the CUCME parameters. The majority of the commands will be issued under the telephony-service configuration mode. Four key things must be configured for the ISR to service IP Phones.

Maximum Number of Phones and DNs
Firmware load files
Source IP address information
Generated configuration files.

Commands are as follows:
Max-ephones (number of phones you’re licensed for)
Max-dn (number of lines, if you had four 2 line phones this would be 8)
Load 7960-7940 (or phone model you’re using) P00308000500
If you don’t know what firmware to use Google CME 7.x and your phone model, there will be a firmware version specified by Cisco.

More to come in part 2.

CCNA Voice Study - Integration Models

PBX- Traditional model, phones all have a unique DN perhaps DIDs. Calls come into a receptionist for direction and users must use an access digit of sorts like 9.

Keyswitch – Model in which all phones have a common lines on all of them. All users can see when a line is in use and intra-office calls are rare.

Hybrid- All phones have common lines in addition to a unique one.

Debuging H323 Dial-Peers

Today has been a long day. I’ve been trying to get 4 analog DID, and 4 analog DOD lines working on a 2811 with one FXO and one FXS DID card. Some very useful debug commands in this process have been.

debug voip dialpeer all
This allows me to see when I place an outbound call what Dial-peer it is actually hitting and all the detail about it.

Debug vpm all
This gives me the debug output from the FXO and FXS cards. In my case it’s telling me I need to get a hold of the phone company. The lines are supposed to be Ground-start however when my FXO goes off hook it never sees the circuit complete and then just drops the call.

CCNA Voice Study - Licensing Requirements

IOS License – Straight forward the license for the version of IOS you will be running on the ISR.

Feature License – Is the number of phones that the CUCME will be able to support. Think of it as attached to the ISR verses the phone.

Phone User License – Is the actually license for use and operating the phone. Think of it as attached to the phone verses the ISR.

Licenses can be added incrementally so you could buy a 24 phone license and later purchase a 48 phone license for a total of 72 usable phones.

CCNA Voice Study - CUCME Platform Limits

Platform	Number of Phones
1861	8
IAD2430	24
2801	24
3250	10
3270	50
2811	35
2821	50
2851	100
3725	144
3745	192
3825	175
3845	250

CCNA Voice Study - Unified Messaging Platforms

Product	Number of Users	Redundancy Support	E-mail Support	Server or Router Based
Unity Express	Up to 250	No	Relay voice-mail to outside e-mail server	Router
Unity Connection	Up to 7,500	No	Relay voice-mail to outside e-mail server	Server
Unity	Up to 7,500 per server. Expandable to 250,000 with multiple servers.	Yes	Integrates directly with MS Exchange, Lotus Notes, or Novell GroupWise	Server

CCNA Voice Study - Call Processing Platforms

Product	Number of Users	Redundancy Support	Server or Router Bassed
UC500	8 to 48	No	Router
CUCME	Up to 250 depending on router	No	Router
CUCMBE	Up to 500	No	Server
CUCM	30,000 per cluster	Yes	Server

CCNA Voice Study - Cisco VoIP Structure

Much like the OSI model Cisco has a standardized reference model to explain the various components that make up a unified communications system. From top down:

Endpoints – IP Phones, Cell Phones, Video Phone, IM Client aka what the user touches.

Applications – Voice Mail, Conference Call Apps, Call Center Apps, 911 Services aka feature rich services.

Call Processing – CUCM, CUCME, UC500 aka what handles call flow.

Infrastructure – ASA Firewall, Voice Router / Gateway, Voice switch aka what all the above layers need to communicate together.

CCNA Voice Study - PoE

Cisco pre-standard PoE verses 802.3af PoE

Cisco pre-standard PoE Process
1. Device connected to switch.

2. Switch sends a Fast Link Pulse (FLP) tone to the device. Only unpowered Cisco pre-standard PoE device will loop the FLP back to the switch.

3. Switch receives pulse back and applies a minimal amount of power (6.3W) to the line.

4. Unpowered device boots and communicates it’s actual power requirements via CDP.

802.3af PoE Process
1. Device connected to switch.

2. Constant small DC current is applied to line.

3. 802.3af device is equipped with a resistor and will return a specific level of resistance on the line.

4. Depending on level of resistance switch knows how much power to send to the device.

802.3af Power Class	Power Allocated	Actual Power Used
Class 0	15.4W	0.44W to 12.95W
Class 1	4.0W	0.44W to 3.84W
Class 2	7.0W	3.84W to 6.49W
Class 3	15.4W	6.49W to 12.95W

Class 0 devices are designed to be cheap to manufacture basically just requesting that power be sent to them. Too many Class 0 devices can exhaust your switch power supply as all Class 0 devices will be allocated the full 15.4W.