SIP SoftPhone Registration with Cisco CME

   This I'm sure this is no revelation to seasoned Cisco voice engineers, but for those just building their skills, I wanted to put out a little how to for attaching and registering SIP softphones to your Cisco Call Manger Express router.

I've integrated many Cisco phones with CME using the native SCCP protocol- Cisco's native signaling and communications protocol otherwise known as Skinny for short.
Assuming all your prerequisite router\CME configurations are in place.... ie...interfaces, tftp-server phone loads files for your phone types, dhcp pool, telephony-service entries etc..... you would add the MAC address of the SCCP phone under the corresponding ephone section of your router config...like so

ephone  1
 mac-address 0021.A075.D474
 after-hours exempt
 paging-dn 30
 type 7941
 button  1:1 2:21
 pin 1111

This ephone would have a matching ephone-dn section to define the line for the ephone (or skinny phone)...like this:

ephone-dn  1  dual-line
 number 1001
 label Tony Montana
 name Tony Montana

But SIP phones require similar configurations under similar sections, but with different syntax.

First you need to allow sip to sip connections under voice service voip

voice service voip

 allow-connections sip to sip

Also...do not forget this part--as I did! You need to turn on the registrar for SIP...so the sip phones have something to register to. Add this to your voice service voip section

sip

registrar server expires max 600 min 60  turns on the SIP registrar! 

Next you'll add your global configuration lines under voice register global- this would be similar to the telephony-service section used for SCCP phones

voice register global
mode cme
source-address 192.168.0.254 port 5060
max-dn 5
max-pool 5
authenticate register  optional for remote phones- digest authentication is used-don't use if you want to use MAC address authentication                                                                          
authenticate realm mydomain.local
timezone 13
voicemail 2222
tftp-path flash:
create profile sync 0025196614655748

Note the create profile command-this command builds the sip cnf and xml SIP phone files in the path specified by the tftp-path command above it.  The sync xxxxxxxx.. is appended automatically by the IOS. I'll come back to the authenticate register command later.

Now, you'll define your dn and line number with the voice register dn # command...like this

voice register dn 1
number 1041
allow watch
name 3cxOffice
label 3cxOffice
mwi

Next, you'll tie the actual phone to the DN with the


voice register pool 1
id mac 0000.0000.0000 Not relevant when using digest authentication- if not, put actual MAC here

number 1 dn 1
presence call-list
dtmf-relay rtp-nte
username 1041 password cisco   Digest Authentication
codec g711ulaw

Now...if you use the authenticate register option in your global settings (see above), you will NOT be able to authenticate your phone via mac address as you normally would a SCCP phone. This option makes the id mac line your voice register pool section irrelevant. This, from what I understand, tells your phone to use Digest Authentication...hence the user name and password. This would normally be used for remote phones- phones not connected on the same lan....due to ARP not passing the MAC of the remote device across routers- makes sense! An excellent explanation can be found here: thanks to the author )

http://ciscovoiceguru.com/tag/registrar/

So,,,there you have it. If all is straight, you should see your SIP phones register now. You can check it with this command- you would see similar to the output below

show sip status registrar

Line          destination      expires(sec)  contact

transport     call-id

             peer

============================================================

1041          192.168.0.38     85            192.168.0.38

UDP           YTE0MTBjNjk0YTVhZDFiNWQ2NzEwMjk5MWE0Nzg0NWM.

             40001

Or, you can check them like this too:

show voice register dial-peer

Dial-peers for Pool 1:

dial-peer voice 40001 voip

destination-pattern 1041

session target ipv4:192.168.0.38:64375

session protocol sipv2

dtmf-relay rtp-nte

codec  g711ulaw bytes 160

 after-hours-exempt   FALSE

Exchange 2013 Public Folder Migration- PublicFolderToMailboxMapGenerator.ps1 script Error

   When migrating our public folders to Exchnage 2013, from 2007....I came across a little oddity. An oddity? From Microsoft? How can that be!! Public folder migration is well documented online...so I won't rehash that. I used the Technet guide found here:

http://technet.microsoft.com/en-us/library/jj150486(v=exchg.150).aspx

So you basically download and run the various scripts as outlined from the Exchange Shell. After you've run the PublicFolderToMailboxMapGenerator.ps1 script:

.\PublicFolderToMailboxMapGenerator.ps1 <Maximum mailbox size in bytes> <Folder to size map path> <Folder to mailbox map csv path>

And created the actual PF Mailboxes on your Exchange 2013 server (a single PF mailbox sufficed for our environment) with this command...

New-Mailbox -PublicFolder PFMailboxName -HoldForMigration:$true -Database MailboxDatabaseName

You'll want to open and edit the PF mailbox name in the csv file you just created with the PublicFolderToMailboxMapGenerator.ps1 script. Make the PF mailbox name or names match the the name(s) of the actual PF Mbxs you created. Sounds easy enough.... well, when I did this, and saved the the file, and then ran the migration request command next as such... (which references the PFFoldertoMailbox map csv file)

New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server <Source server name>) -CSVData (Get-Content <Folder to mailbox map csv path> -Encoding Byte) -BadItemLimit $BadItemLimitCount

I ended up receiving an error and the migration would not kick off. Turns out that Excel botched the file syntax ever so slightly for whatever reason...or maybe the script itself did. Took me some time to notice.... so take note of this if you get this behavior. Your FFoldertoMailboxMap csv file should look like this:

"FolderPath","TargetMailbox"

"\","PFMailbox1"

My PFmailbox name being PFMailbox1. I made the change using Notepad++ or similar this time..saved it...and re-ran the migration command. All was fine after...

Happy migrating!

BYOD with PEAP MSCHAPv2 Authentication for 802.11 Devices

   So you have a school district....you have kids...kids have smartphones...add a wireless system and now your in BYOD land! Implementing BYOD w PEAP and MSCHAPv2 I'm sure has been widely documented by now, but it wasn't so much last year when we rolled out our Meraki wireless system and decided to let the kids have at it. I'd figure I'd throw my little procedure up as guide for other systems looking to go BYOD. This is how I configured authentication and wireless access for our students and staff, whom already had user accounts in AD. 

I won't go into to our existing wireless and network infrastructure, but we opted to go with Meraki, which has turned out to be a nice cloud based controller system. We are a MS shop, so we looked for a way to marry the two.

First install the NPS role (Network Policy Server) on your server- we choose Windows 2012

Next thing to do once you have your NPS server up and running is configure your RADIUS clients. These will be the IPs or most likely the IP range of your wireless APs.

Now configure a Connection Request Policy- I just did the NAS Port type here

Next up...Network Policy. This is where you'll specify your conditions, domain groups authentication methods, etc to control access (see the screen shots below for the configuration I used). I should mention, you'll want to have a certificate for your NPS server installed prior to defining this policy. See below- we used a Go Daddy cert.

Now....after your NPS server is setup, you would configure your wireless controller to use the RADIUS\PEAP authentication you've just defined. This will tie it all in. Below is our Meraki dashboard settings for  our student SSID configuration. Other additional SSIDs if needed, would be the same. You can use the Called Station ID condition specified in the above screenshot to direct certain users to a particular SSID by combining it with a User Group condition.

Now, you'll probably want to set up some logging so you can see what's going on and if your setup is working. That;s done from the Accounting node of the NPS Snapin.

Well...there you have it. Pretty straight forward- as long as everything is configured as such, you'll have your devices logging in successfully. You may notice on some user's IOS devices, the NPS server certificate may still not be trusted....even though you are using a well known compatible cert vendor such as Go Daddy. You'll get a warning- this will happen the one time on initial login. Not a huge deal..We did not experience this with Android devices though. It's a nice setup over all- cool to have centralized access control using NPS, especially if you're MS shop to begin with. 

Hope this helps fellow BYODers !  ...

My first blog post!

   I guess the time has come to join the party on this great super highway of information! Being a tech guy by trade and an all around "how to" type, it's only natural to dump what's rattling around in my noggin before it's obliterated by old age and one too many "adult beverages". Also, I've come to believe that that the greatest catalyst and ambassador for learning, is sharing. And there's no medium more convenient and persuasive for sharing than the Internet. I could never have been a successful, fully- functioning adult IT Tech without the scores of individuals who are generous enough to share their experiences and time, and document them for the world to see! You peeps are awesome! The days of reading the owner's manual and plugging it in are over-- nothing works as it should in technology. So with that...I hope to contribute and share my experiences with my fellow techies...and hell....maybe I'll even spare someone from an all-nighter hunched over their workstation, 10 cups of coffee coursing through their blood stream...praying their server comes up before the morning! I know you guys and gals have spared me many a time.....)


Until next time ...Dennis