So, first let’s level things out:
Versions and Other Information
I’m running a rev or two behind in my lab when compared to Bill. Recently, I’ve been focused quite heavily on working with Cisco Unity Connection for large enterprise deployments so my CUCM version is running on 220.127.116.1101-1.
What SIP clients are out there for the iPhone? There are a number of them. They come in various names and flavors. Most tout how many different providers they’ve been tested to work with and some even mention Cisco or generically an “enterprise IP PBX”. If there are free SIP clients in the App Store, I didn’t find any myself. So, since they run anywhere from $4 to $8 each, I chose to test two based on three criteria – research, reviews, and word of mouth. I ended up with:
Acrobits Softphone 3.0
Both are available from the iPhone App Store and do not require anything out of the ordinary (like a “jail-broken” phone).
I’m not going to rehash the CUCM configurations in detail because Bill already outlined them in his blog. You can refer to it for specifics. I’ll provide a brief recap:
- Create a Phone Security Profile for basic 3rd-party SIP devices and enable Digest Authentication.
- Add a 3rd-Party SIP (Basic) phone and configure it as you would any other phone but under Protocol Specific Information specify the new phone security profile with digest authentication enabled (from Step 1) and set the profile to Standard SIP profile. Also, note that the MAC address is insignificant when you configure endpoints of this type.
- Create an End User (or a Digest User as it is referred to by some applications and in the device configuration). Make sure you set the Digest Credentials for this user. This is the only “password” that matters in this configuration.
- Associate the SIP device and the Primary Extension to the user.
- In the 3rd-Party SIP device configuration, set the Digest User to the appropriate End User and save the configuration.
Allow me to save you some trouble before proceeding…
To quote Bill’s blog, he says “….the resources I have found on-line, including CounterPath’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.”
So, in Bill’s example the End User that he configures as the Digest User has an alphanumeric user ID (ex: bbellsip). Makes sense, right? A lot of companies configure user ID’s to be indicative of the user’s actual name. Well, unfortunately I have found that this doesn’t really work in my testing of SIP clients for the iPhone. In our setup and testing, we are managing users and authentication directly within CUCM (no LDAP). So, I can safely say that if you are operating in this type of environment and you wish to use either of the SIP applications for iPhone that I tested, then you need to configure your End User such that the User ID = the primary extension assigned to the 3rd-Party SIP device. For example, my End User configuration for Acrobits Softphone looks as follows:
- User ID: 7031821006
- Password: cisco
- PIN: 12345
- Last Name: Acrobits
- First Name: Softphone
- Digest Credentials: strongpassword!
Likewise, when you select the Digest User on the 3rd-Party SIP device the user will be 7031821006.
With that said, I must note that I have not yet tested either Acrobits or WeePhone interoperability with a CUCM that is enabled for LDAP integration and authentication. I’ll save that for another blog at some point.
Configure the SIP Client for iPhone
Depending on which application you use, the configuration screens vary slightly but they ultimately have the following settings that need to be configured as follows:
User Name/SIP User: 7031821006
Server/Domain: X.X.X.X (IP address of the server)
The Application Reviews
My personal preference is the Acrobits Softphone client. I found it to have an intuitive interface and a sleek, professional design. In the sake of brevity, I’ll break it down to a list of pros and cons:
- It works (always a plus)
- Intuitive interface (a plus when configuring accounts)
- Can create multiple accounts (i.e., a generic profile for CUCM, a vendor-specific profile for Vonage or multiple other supported providers)
- Support for STUN, proxy, various codecs, etc – plenty of features
- Quickdial button allows you to access Speed Dials
- Direct access to Contacts from dial pad
- Aethestically pleasing and professional design
- Bluetooth support (toggle on/off via preferences)
- Best feature (IMO) is the “Log SIP Traffic” (toggle on/off via preferences), this writes ALL SIP traffic to a log and is very useful for troubleshooting or just looking at traffic flows
- $7.99 in the App Store (I can’t think of anything else at this time)
Ok, so now to WeePhone. WeePhone was the first client I purchased. Over time, I’ve found that I wouldn’t care to use it in any sort of extensive way. I’ve experienced some application crashes, odd behavior (ex: screen immediately goes black after launch), etc. It also has a more basic look and feel to it than Acrobits. Maybe you could care less about that, but Bill and Andre can tell you that I’m a stickler for aesthetics. Anyway, on to the pros and cons.
- It works (mostly)
- Simple interface, minimal use of non-essential menus
- Generic SIP client, should be able to use it with various providers
- Support for STUN, proxy, various codecs, etc – plenty of features
- Direct access to Contacts from Main Menu
- Displays SIP transactions as you dial, can be helpful for watching how a call takes place
- Manual/Help Access from within Settings explains what each field/setting does
- Help Menu provides the option to send diagnostics to the developer
- Best pro (IMO) is the developer is very quick in responding to diagnostic submissions
- Application, at least for me, has been a bit buggy (crashes, etc).
- No access to logs unless you send diagnostics, then they are pasted into email and you can view
- All settings for the application are listed in a row – this might confuse some folks who are overwhelmed by too many options
- Response is slow at times (e.g., toggle speaker on/off might may have a bit of a lag)
- I’d like to see some design tweaks – has a bit a bit of “homegrown” feel to me
Let me end by saying that I have no personal investment in either of these applications or the companies/developers that provide them other than the few dollars I spent to purchase them from the App Store. My opinions are strictly that, my opinions. That’s all folks.