CounterPath Bria for iPhone and Cisco Unified Communications Manager (CUCM)

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.

Version Information

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.

Premium Features

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

Advanced Settings

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

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.

Accounts

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.

Testing

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.

The Basics

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).

Mid-Call Features

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.

Video

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:+13011055200@laurel.cnclab.priv > tag=[stuff deleted]
To: "Bill" < sip:+12011055200@laurel.cnclab.priv >
Call-ID: [stuff deleted]
CSeq: 48433 REGISTER
User-Agent: Bria iOS 2.0.0
Contact: "Bill" < sip:+13011055200@10.3.197.16: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.

Conclusions

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