Why am I writing this?
I have been using and testing CounterPath’s SIP products with Cisco Unified Communications Manager (CUCM) of and on for a while now. Several write ups have been posted here. This all started off as a search for a viable soft phone to run on the Mac OS and then evolved to something to have fun with. The main reason I wanted to test the Bria for iPhone product was to see how well the video features work.
For my testing I used:
- CUCM 8.5(1)SU2 [and SU3]
- CounterPath Bria 2.0 for iPhone (tested on an iPod Touch). Supported devices:
- iPhone 4S, 4, 3GS, 3G
- iPad 1 and 2 (WiFi and WiFi + 3G)
- iPod Touch 2nd, 3rd, and 4th generation
- 4th Generation iPod Touch running iOS 5.0.1
Basic Configurations for CUCM
The configurations for CUCM follow the same theme as other CounterPath products I have tested. The basics:
- Configure a SIP Profile and SIP Security Profile
- Provision the end user object in CUCM
- Provision the Third-Party SIP device in CUCM
Configure a SIP Profile
You can use the standard SIP profile for Bria for the basic integration discussed in this blog. However, I suspect that once I am able to test running the application in the background on iOS that I will need to modify the keep alive and registration expiry timers. Therefore, I created a separate SIP profile in anticipation of version 2.0.1.
NOTE: During testing I was unable to test running the Bria application in the background on my iPod. This is due to an incompatibility in how the ingress calls (from Bria's perspective) are presented when using TCP transport. This is discussed at the end of this blog.
Configure a SIP Security Profile
To enforce digest authentication, you will want to create a phone security profile that enables the option to enforce digest authentication. You could keep the transport type to TCP+UDP or you can use UDP only.
Using TCP only does not work with version 2.0.0 of Bria.
Provision the End User
The end user (User Management > End User) object can be provisioned locally on the CUCM or synchronized from a supported LDAP directory. The user ID assigned to this object will be the authorization user when configuring Bria. For example:
- User ID: wjb (used by Bria)
- Password: blahblah (not used by Bria)
- PIN: 12345 (not used by Bria)
- Last Name: Bell (not used by Bria)
- First Name: William (not used by Bria)
- Digest Credentials: MyD1g3stCr3d (used by Bria)
Provision the Device
I used the 3rd Party SIP Device (Advanced) for my testing. Primarily because I wanted to test video to/from the device. Go to Device > Phone. Click on Add and select “Third-Party SIP Device (Advanced)”. 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 Bria
- Description: WJB Bria iPod
- Set it to something meaningful to you, it doesn’t matter to Bria
- 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. If you need G.729 then an in-app purchase on Bria is required.
- 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 (Advanced) – Digest Required
- Digest User ID: wjb
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: +13011055200
- You aren’t required to use E.164, my lab just happens to be setup this way
- Partition: CL_DN-1_PT
- Place the DN in your “phones” partition
- CSS: Apply line level CSS per your design
- For example, I like to use line-level COR CSS approach
- Voicemail Profile: Use the VM profile that you normally would
- Call Forwarding: Configure Call Forwarding as you would normally.
- Note that Bria supports a “Decline” option on ingress call presentation. Call Forward Busy (CFB) needs to be provisioned for this feature to function properly.
- Display and Alerting: Configure these as you would like
Basic Configurations for Bria
When modifying Bria’s settings you have four configuration areas: Accounts, Preferences, Advanced Settings, and Premium Features. I am going to address these in the order I configured the client. To access the settings options, load Bria and choose Settings.
When you purchase the CounterPath Bria application from the App Store you are getting the base SIP client. CounterPath has three premium feature options that you can purchase from within the Bria application:
- G729 Audio Codec: This provides the right to use the G.729 audio CODEC. By default, Bria support G.711 u-law, G.711 a-law, SILK(-HD), G.722, iLBC, and GSM.
- Presence and Messaging: Bria can be a XMPP or SIP/SIMPLE client
- Video Calls: This feature enables the use of H.264 video
The first step under the Advanced Settings is to configure the Network Traversal Strategy. In my lab scenario, I was testing an enterprise, on-prem solution. Therefore, I had not need for network traversal mechanisms like STUN or ICE. I set the strategy to “User Specified” and turned off STUN and ICE.
If you want to provide some level of redundancy for SIP UA registration then you will want to leverage DNS SRV. You can enable DNS SRV in the Network Traversal settings area. Then you can use a SRV FQDN for the SIP domain when provisioning the user account. I successfully tested registration with and without DNS SRV.
Other advanced settings will depend on your environment. I used the following:
- Use VPN if Active: Off (I was not testing VPN this time around)
- Voice Activity Detection: Off
- Noise Reduction Tx: Off
- Noise Reduction Rx: Off
- QoS: Off (I was not testing QoS this time around)
- Wi-Fi Audio Codecs: I enabled G.711u, G.722, and iLBC. I tested with G.711u and G.722. You can (and should) order the codecs by “dragging” them into proper sequence.
Preferences will vary by environment. I was testing video, so I turned on the “Enable Video” option and tested various “Video Quality” settings. The video quality in my lab wasn’t stellar but I did see that all options appeared to result in successful video call establishment.
Client-side forwarding, which is akin to a Cisco IP phone Call Forward All softkey, is engaged from the Preferences panel. To turn on client-side forward you set “Forward Calls” to On and set the “To Number” to a valid directory number. Some considerations to keep in mind:
- Enabling call forwarding from the SIP client does not modify the CUCM CFA entry for the directory number. So, when the device is unregistered, the client-side forwarding destination is not applied.
- To support redirection from the SIP client, the SIP device in CUCM must have the “Rerouting Calling Search Space” configured.
- The “To Number” applied on the Bria client should use digit patterns that can be routed using the Rerouting Calling Search Space.
Now that we have our preferences and client-side settings configured the way we want, we need to provision the SIP account. When adding an account, you have basic and advanced settings. In my lab I used the following configurations.
The first noteworthy piece of info is that my Bria is successfully registered (see above, left). You can manually register/un-register from the SIP account settings. The Account Name is locally significant and can be anything you want. You do need to enable the account to use it with CUCM and, if you want video, you need to enable the Video feature.
Under “User Details”, we provide the basic parameters that CUCM uses to associate the Bria UA register request to the SIP device provisioned earlier. The following parameters were used in my testing:
- Display As: Doesn’t matter, line settings in CUCM override any calling name presentation specified here
- Username: This is the primary line DN assigned to the SIP device in CUCM (+13011055200)
- Password: This is the digest credential assigned to the end user in CUCM (in our example: MyD1g3stCr3d)
- Domain: This is the IP address or FQDN of a call processing node in your CUCM cluster. This can also be a DNS SRV entry (if you enabled DNS SRV in the network traversal settings)
I tested voice mail using Cisco Unity Connection 8.5(1). The VM number is my internal pilot number as configured in CUCM.
After configuring the basics, we now have to tweak the advanced account settings. The following screen shots provide the modifications I used in my lab testing.
The “Auth Name” identifies the end user object provisioned in CUCM and associated to the digest credentials configured in the basic account settings for Bria. Since we are not leveraging network traversal, I disabled Global IP. For DTMF, leave the default as RFC 2833.
Under “Transport and Security”, I had to enable UDP because of an issue with how Bria implements the TCP transport mechanism in version 2.0.0 of the client. This is related to the running in background issue mentioned earlier. We will discuss this momentarily.
If you want to receive calls on the Bria client, then you need to enable Incoming Calls. Single register is only applicable when leveraging Global IP, so I will not discuss it in this blog. The refresh interval is used by the client when registering to CUCM. The default value is 900, however if you want to facilitate running the application in the background on iOS, you want a value that is less than ~600, according to CounterPath. I plan on testing registration timers when Bria version 2.0.1 is released.
The Bria interface is very intuitive. In the Bria interface you can navigate between a DTMF keypad, a list of contacts, a call history, and settings. There are some subtle visual cues that Bria uses to convey key status information. Note in the following figure we have voice messages on the line associated with this device, as signified by the “vm” on the Phone soft key. We also have client-side forwarding enabled as signified by the “FW” hovering over the Settings soft key. Nice touches.
Placing and receiving calls is standard fare. When you receive a call you can choose Answer or Decline. Declining a call gracefully will require some configuration in CUCM. Specifically, you need to configure a valid Call Forward Busy (CFB) destination. Basically, declining a call acts like iDivert for standard Cisco phones (except you can send the call to any valid DN, not just voice mail).
When a call is active, Bria displays mid-call functions in the center of the screen (see below). You can mute, hold, toggle the speaker phone, or open the keypad from the main in-call function screen. You can also select the “more” option to get a list of functions such as recording a call and transferring the caller to another extension.
You can initiate a conference call by selecting “add call” while in an active call. You can swap between calls (see middle screen above) or you can select “merge”. The “Swap Calls” feature also works with call waiting, but I didn’t see a way to join two calls from Bria.
I do have an issue with the “hold” functionality in Bria. Basically, hold is not engaging even though it appears to do so from the client interface. I am still looking into this to see if there is a SIP message compatibility issue. Though, other 3rd Party SIP clients (including Bria for Mac) have handled this functionality correctly in the past.
To add video to an active call you can either use the “more” soft key and select Add Video or you can swipe the call plane to the left. You can toggle on/off video (see the rightmost image in the “triptych” above). So, it couldn’t be any easier to add/remove video from an active call.
The main reason I loaded this version of the application was to test video. In my lab, I haven’t bothered to deal with QoS over my WLAN. That being said, the video quality to a Cisco 9951 station was sub-par and not usable. The video quality to another Bria client (on Mac OS X) was marginally better.
The first thing I figured out was that the Cisco 9951 cannot handle the portrait layout. I had to rotate the iPod to landscape mode to get a full size video display on the 9951. I still had some poor video quality. My WLAN may be contributing to the video quality but I ran Bria on my MBP on the same WLAN as the iPod and the quality on the MBP was way better.
It should be noted that Bria 2.0.0 was just released earlier this month and CounterPath has already submitted version 2.0.1 to Apple (1/24/2012) for release in the App Store. Version 2.0.1 is going to include improvements to the video feature set. So, I am not worried. Kinks like this take a few revs to work themselves out.
A Word on Background Processing and IP Transport
I did not do much testing on how this application behaves when told to run in the background. I didn’t tweak timers or check battery life, etc. Primarily because I couldn’t get the application to run in the background. There is an option to enable/disable this feature. How this feature behaves is apparently linked to the transport used to communicate with CUCM.
When I leverage UDP to register with CUCM, enable Bria to run in the background, and then load another app calls to Bria won’t ring out (no alerting). When I enable TCP, I can’t call Bria at all. The UDP+Background behavior is actually not recommended anyway, so I didn’t expect it to work.
The TCP issue can be narrowed down to the fact that when the Bria 2.0.0 SIP-UA registers it sets the contact information in the Contact header to use a different TCP port than is actually used by the socket. The CUCM honors the TCP port in the Contact header and tries to signal ingress calls to Bria using that port. Unfortunately, iOS sees this as a problem and blocks the ingress connection. To illustrate, assume CUCM receives the following SIP REGISTER message:
REGISTER sip:laurel.cnclab.priv SIP/2.0 Via: SIP/2.0/TCP 10.3.197.16:60415;rport;branch=[stuffdeleted];alias Max-Forwards: 70 From: "Bill" < sip:+email@example.com > tag=[stuff deleted] To: "Bill" < sip:+firstname.lastname@example.org > Call-ID: [stuff deleted] CSeq: 48433 REGISTER User-Agent: Bria iOS 2.0.0 Contact: "Bill" < sip:+email@example.com:60414;transport=TCP > Expires: 600 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0
The “Via” line actually shows the TCP port used on the Bria device (5060 is the server port). The contact line shows a TCP port that is different. When a remote station calls the Bria device, CUCM will use the TCP port in the contact line and the call will fail.
CounterPath is addressing this issue in release 2.0.1 as well (see notation in video section, above). So, I expect the issue to be fixed in the near future. Once 2.0.1 is out, I will do more testing with running Bria in the background.
I had some minor issues with version 2.0.0 of this product but I am hopeful that most of the bugs I encountered will be worked out in version 2.0.1. CounterPath puts out solid products for sure and CUCM has proven to have decent interoperability with 3rd party SIP clients.
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
10 responses to “CounterPath Bria for iPhone and Cisco Unified Communications Manager (CUCM)”
from your point of view what are the advantages/disadvantages in comparison to the native cisco mobile/jabber client for iPhone?
Your question is timely. I was planning on doing a feature comparison test between my favorite 3rd party SIP clients and Cisco Jabber. I haven’t had a chance to do that yet but can provide my gut opinion. At first blush I would say that Cisco Jabber on iPhone/Android will offer a more seamless integration to both end user and admin features of CUCM. This may be obvious but I know from testing the 3rd party SIP integrations that there are a few features that are just not compatible.
Actually, the first thing that comes to mind is the fact that changes on the CUCM are not pushed to the client until you manually re-register the client. IOW, when I reset/restart/apply changes from CUCM it has no effect on the client. This can be a tad bothersome. This is an admin feature.
There are differences in mid-call feature support. The primary features (hold, transfer, ad-hoc conference, call waiting) work well on 3rd party and Cisco Jabber. Though, conferencing on Cisco Jabber leverages media resources on CUCM, which I feel is more preferred. Not just from a traffic eng standpoint but from a UI experience one.
There are other considerations to take into account such as cost, power consumption, background operations, stability, interaction with VPN, and behavior with mobility features (like SNR, transfer to 3G/4G, etc.). I have to reserve comment on these features for the time being as I have not thoroughly tested all necessary aspects.
In production deployments we (NetCraftsmen) typically lead with the Cisco Jabber offering first. We recently deployed this solution for a customer and they have been very happy with it. I did come across a customer who was testing the idea of using 3rd party SIP clients on mobile platforms. Their driver was to enable video and to use a client they have used with their residential SIP service provider. They haven’t gone to production yet. I imagine the video "gap" will be addressed on the Jabber client in the near future.
Useful stuff. Have you ever found a third party SIP client for Blackberry that works with CUCM?
The only SIP clients I have found are:
Of these VMobile seems the more developed but it is very basic compared to Bria. I can get it to work with my ITSP (Sipgate) but no luck with CUCM.
It would be interesting know if you have looked for a BB solution.
Actually, I have not looked at BB integration with the Cisco UC portfolio in quite some time and I have never tested a SIP client on the BB platform. I don’t even have a BB device to test with any more. Sorry.
Did you ever happen to complete your 3rd Party/Bria to Jabber feature comparison? If so, would you be willing to share your document? I’m looking to test the two devices and would appreciate being able to see your data.
I haven’t done a side-by-side comparison on the iOS platform. I have been working on other things. I started to come back around to doing a comparison for my personal blog but caught wind of some changes on the horizon. A future Jabber for iPhone client will combine voice, video, and IM/P on the same client. Which brings Jabber closer to an apples for apples comparison with Bria.
The new Jabber release was showcased at Cisco Live and I am hoping it will be available soon. Sorry I don’t have better data but I did get some hands on with the new Jabber client for iPhone and I was impressed.
Thanks for all the info! I still have one issue. I am testing Bria on a HTC One in combination with CUCM 9.1 now, and during work hours everything works fine. But when someone goes home and looses the connection with wifi, the next day bria won’t automatically register with the CUCM.
When i disable wifi for just 30 minutes on-site, bria is automatically registering. So it will only go wrong, when they take their HTC home… Do you have any suggestions?
One main point to make with Bria compared to Jabber Voice is that Bria has wide support on a variety of device platforms and OS versions.
Unfortunately Jabber Voice is very limited as it is only officially supported on about 6 android devices (which need to be running the appropriate Android version) and IOS.
This is very limiting.
I don’t know if I would characterize Jabber as "very limited" with regards to cross-platform adoption. Though, I do agree that maintaining a consistent product across the various Android platforms does demand a software dev lifecycle that is more aggressive than what we have seen from Cisco. Which, BTW, Cisco’s dev cycle has ramped up its pace over the past couple of years.
Clearly, Cisco is prioritizing their Jabber efforts based on how popular a specific platform is. Jabber for Windows gets more cycles than Jabber for Mac. You will typically see releases lag by 1 – 2 months. iOS platforms are getting a lot of attention based on their popularity.
Cisco focuses Android development on a specific portion of the ecosystem. I am not sure how they select the platforms they validate for interop testing. The most recent data sheet (http://www.cisco.com/c/en/us/products/collateral/unified-communications/jabber-android/data_sheet_c78-649887.html?cachemode=refresh) lists a variety of Samsung Galaxy devices, the Google Nexus, and Sony Xperia devices.
Honestly, I switched from Android to iOS ~2 years ago and haven’t kept up with the evolution of the Android platform(s).
I have installed Bria on my iPod very recently, http://www.qspray.com/ I was not aware that the video add-in was not available with this, so I am waiting to update the same to get the video add-in. I have installed it to stream the videos in ipad.