Why am I writing this?
First, I just wanted to add some 3rd party SIP phones to CUCM to start testing feature behaviors. X-Lite seemed like a reasonable choice as it was free and apparently pretty popular. Second, the resources I have found on-line, including CouterPath’s own write up (which is a bit dated) and an article on Cisco’s “community” collaboration site, were just too light on details. The examples would have things like this:
Display Name: 1234
User Name: 1234
Authorized User Name: 1234
I ask you, what am I supposed to do with that if I try to deploy this application in the real world? Now, I am not saying that I am going to cover all bases adequately in this example. Every one of us has a slightly different environment that we operate in. But, I hope to provide some examples to give you a better feel for how to add 3rd Party SIP endpoints to the CUCM. I like X-Lite, so I am using it as the example.
Versions and other information.
For my testing I used CUCM 220.127.116.11900-1 (that is 7.1(3b)SU1 for the uninitiated). The X-Lite version is 3.0. From looking at some of the examples on line (dating back to CUCM 5.0), the basic configuration we are going to discuss is pretty applicable to all CUCM appliance models. I suspect that procedures for 6.0 to 7.1 would be near identical.
It all starts with a download.
First, you will need to download the X-Lite application here. The install is pretty straight forward and relatively quick.
I like to get the station configured in CUCM before I start playing around with the client. In CUCM you will need to create a SIP device and a user object. You will need to make some associations between the two and perform some other ancillary activities in preparation.
Add a SIP Security Profile
I suppose you could consider this an optional step if you don’t mind SIP endpoints just registering to your CUCM cluster without a password. I don’t, so we are going to create a SIP security profile that forces the use of Digest Authentication. If you go with the standard SIP security profile, digest authentication is not used. This means that a client can connect by simply providing the extension number and a user ID.
NOTE: In the X-Lite configuration examples I have seen, it is suggested that you specify the password
you assigned to the user in CUCM when you configure the Account Settings in X-Lite. This is incorrect.
Connect to your CUCM server (http://mycucm/ccmadmin) and go to System->Security Profile->Phone Security Profile. Search for profiles that contain the string “third-party” and copy the profile named “Third-party SIP Device (Basic) – Standard SIP Non-Secure Profile”. Configure the new profile as follows:
Save your settings.
Add the User
Go to User Management->End User. You can add a new user or use an existing user. You can also use a user that was replicated from LDAP using the DirSync service. The information you need to configure (values shown are used in our example):
- User ID: bbellsip
- Password: (this is not used by X-Lite, but you should always have one)
- PIN: (this is not used by X-Lite, but … you get the idea)
- Last Name: Bell
- First Name: Bill
- Digest Credentials: ******* (this is used by X-Lite!)
Click on Save. We will come back to the user object in a moment.
Add the SIP Phone
Go to Device->Phone. Click on Add and select “Third-Party SIP Device (Basic)”. At a minimum, you should configure the following settings (values shown are used in our example):
- MAC Address: DEADBEEF0000 (set it to something unique, it doesn’t matter to X-Lite)
- Description: Bill Bell X-Lite (set it to something meaningful to you, it doesn’t matter to X-Lite)
- Device Pool: HQ_User-SoftPhone_CSS (You should use a device pool that makes sense in your environment. I like to stick my softphones in a separate bucket. You will want to make sure that if you are using regions, to keep everything G.711. The free X-Lite doesn’t support G.729 or other CODEC. Also, a Cisco tidbit – the default inter-region CODEC is G.729)
- Calling Search Space: HQ_User-Std_CSS (this should be a CSS that fits into your dial plan, just like a standard Cisco SCCP station)
- Device Security Profile: Third-party SIP Device (Basic) – Digest Required
- Owner User ID: bbellsip
- Digest User ID: bbellsip
Other phone parameters can use the default settings. I didn’t test Device Mobility yet. I played with Presence subscriptions with marginal success (later blog maybe). I also tested Trusted Relay Point (TRP) and it worked as it should (TRP will be a topic in a later blog).
Click on Save. After saving the phone, you can add an extension. Add the extension as you normally would. The bare minimum settings I used for testing:
- Directory Number: 2025550208 (I use 10d extensions)
- Partition: CL_DN-1_PT (place the DN in your “phones” partition)
- CSS: Apply line level CSS per your design
- Voicemail Profile: Use the VM profile that you normally would
- Call Forwarding: Configure Call Forwarding as you would normally, for example CFNA and CFB to voicemail
- Display and Alerting: Configure these as you would like
Click on Save.
Edit User Object
Now go back to the user you are assigning this soft phone to (e.g. bbellsip). Edit the user object. Go to Device Associations and associate the device you just created.
Click on Save.
Launch the X-Lite application. You may get prompted for software updates, etc. After the application loads, you will have a screen similar to the following:
Right click on the “LCD Screen” and choose Account Settings. Click on Add to create a new SIP account. Go to the “Account” tab and configure as follows:
The figure above gives you some guidance on what should be configured in each field and what needs to match CUCM configuration fields. It should be noted that you can use DNS names in the Domain field. I did some testing with SRV records. I found that if you have an SRV record for SIP (e.g. _sip._udp.netcraftsmen.net) that is configured with the correct UDP port (5060), the X-Lite client will query your DNS domain for the SRV record and register.
Click on OK. If you setup everything correctly, you should see a screen similar to the following:
You’ll notice in the Account settings screen that there was a dial plan field. If you want the user experience on the X-Lite phone to mimic what your CUCM dial plan does for standard SCCP phones, then you will need to configure the dial plan on the X-Lite client. Otherwise, your users will need to dial the phone number they wish to reach and click on the dial button (green phone going offhook) a second time to place the call. This is because the X-Lite phone doesn’t support the Key Press Markup Language (KPML). Also, SIP Dial Rules in CUCM don’t apply to third-party SIP devices, so you are left with little option.
The X-Lite dial plan syntax is provided in Appendix-B of the X-Lite User guide. It would take some typing to cover all of the details. But we’ll give one example:
The above string will translate “0” to “50207” and immediately route the number. The 911 and 9911 are also immediately routed, with the 911 (match=2) having a 9 prefixed. There is also a 5-digit pattern for abbreviated extension dialing and an offnet pattern example. There are lots of variations and definitely a few things missing form the above string to match all dial plan behaviors. The goal is to mimic the digit patterns and lengths that your users are used to dialing. Have fun!
I tested the X-Lite application with voicemail (Cisco Unity Connection). This was relatively straight forward. You configure the Unity Connection mailbox as you normally would and you configure the line forwarding settings in CUCM to redirect callers to voicemail during busy and no-answer events. In X-Lite, you configure the SIP account Voicemail tab and enter the voicemail pilot number. Use the pilot number you assigned to the voicemail profile in CUCM. The MWI notification functions as shown in the following figure.
When you see the MWI envelope, you can click on it with your mouse and if you configured the voicemail pilot number correctly in X-Lite, you should be sent to your voicemail system and prompted to logon.
Well, I am still playing around with the application and I have not concluded whether I would deploy this in a production environment or not. A few features don’t behave the way I would like them but that could be I am not configuring them correctly. If something substantial is discovered I will plan on posting the findings here.
William Bell is the Collaboration Practice Lead for Chesapeake NetCraftsmen. Bill has over 10 years of experience in the IT industry with a focus on communication and collaboration technologies. In addition to blogging on the NetCraftsmen site, Bill also maintains the UC Guerrilla blog: http://ucguerrilla.com. You can follow Bill on Twitter: @ucguerrilla