Interview with Damaka

This week I am doing my first interview on VoIPNorm. Having been inspired by Justin Morris and his “Interview with a UC Pro” series I  have a short interview with Damaka’s Sales VP Bogdan-George Pintea. Damaka were one of the first partners to produce a mobile client for Lync (Xync) and are working hard to quickly release new features. If you haven't seen  Xnyc its available on iTunes App Store and the Android Market.

How did Damaka get started ?

We started the company in 2004 driven by the vision of building a  total software solution which is standards-based and secure for mobile Unified Communication and Collaboration, targeting Service Providers and Enterprises.  Our team has a telephony background, having built one of the most popular softswitches in market, and we are very standards-centric. We made purposeful efforts to make video conferencing available broadly and we were the first company to release a commercial mobile video conferencing solution in 2007, on Windows Mobile 6.1.

What kind of early success has Damaka had with Xync?

We released an early version of the Xync product line to the App Store and the Android Market and reception has been tremendous. Individual downloads led to many enterprises testing Xync globally.

How does Xync connect back into the Lync infrastructure?

It is worth mentioning that Xync is the only native mobile client for Lync/R2 in market today, connecting directly to Lync servers, without  the need for a gateway. The advantages of this approach include lower cost of ownership, ease of deployment and flexibility in feature development.

What OS's is Xync currently available on?

Currently we are targeting iPhone, iPad and some specific Android smartphones and Android tablet models, Symbian. We are eager to support Windows Phone 7.5 and we hope to have some good news soon.

Any upcoming features you can talk about?

We just completed a group of features that we are particularly excited about: the ability to join scheduled meetings (through Calendar integration), shared whiteboard, PowerPoint sharing and  4-party video conferencing initiated from Xync.

Thanks to Bogdan and good luck to Damaka with the Xync product moving forward.

Comments welcome.

VoIPNorm

Learning Plan for Deploying Microsoft Lync Server 2010 Enterprise Voice

Learning Plan for Deploying Microsoft Lync Server 2010 Enterprise Voice

This learning plan will provide you with the knowledge and skills to deploy a Microsoft Lync Server 2010 Enterprise Voice solution. Lync 2010 Enterprise Voice provides the telephony features of a traditional Voice over Internet Protocol (VoIP) PBX system with rich presence, instant messaging, and conferencing to improve communication and lower costs.

VoIPNorm

Lync Native Features Versus Plugins: Where Does The Real Complexity Reside?

The published API’s have opened up Lync and Lync Server to the developer world and allowed developers to extend the value of Lync. Even the development of the third party applications for VoIP are indeed proof of the flexibility Lync provides as a development platform. But in the same vein replacing elements of native features even though it is possible can raise questions of the value of doing so.

“We believe that the native functionality in Office Communicator provides a much better and more complete user experience …… is a less complex and more cost-effective integration technique than adding additional software to every desktop”. BJ Haberkorn, OCS Senior Product Manager.

BJ makes some interesting comments but what’s really going on in the back ground that makes adding a third party application for telephony more complex than native Lync features?

This particular post is describing all third party Microsoft Lync plugin applications that aim to remove native functionality and replace it with their own. Often competitors pitch this as a way to avoid paying for E-Cal or Plus Cal but you are losing much more than just telephony by dropping down to Standard-Cal licensing. When you look at UC platforms it’s important to consider what you are buying as a whole and not just one portion. Often when moving a portion of functionality to another system you are adding more complexity than first realized and in the long run more cost both in licensing and manageability.

Amidst the claims of lower costs and multiple dial plans, the end user experience when using the plugin is often overlooked. Native features are focused on bringing about the best user experience for a collaborative environment. Plugins on the other hand are by design focused on preserving legacy PBX systems where desktop usability and integration are secondary unless it is promoting other competitive services such as voicemail, conferencing or external web collaboration. Also, this often means deploying group policies or in extreme cases adding custom Active Directory attributes to get a plugin to register and function as desired adding to the complexity which its meant to be avoiding.

Third party application for telephony and video integration…

image

Versus

Native Lync telephony and video…

image

 

I wanted to paint a complete picture of what’s happening with this type of integration from a generic point of view. Depending on which vendor you choose the features may change somewhat and may even look more or less complex than is presented here. Remote call control has been omitted as most vendors are not providing it through this integration but through a separate CSTA gateway that is unrelated to the third party application for VoIP (see diagram 2). So from the top diagram:

1) LDAP information in some circumstance comes from direct integration from the client plugin.

2) SIP/TLS for IM and presence. Some vendors are recommending turning off all Communicator features other than IM and presence.

3) Call signaling flowing from the third party softphone integration to control call( either a soft switch or IP PBX)

4) API integration to pass presence and other desktop level integration

5) Video integration if available. This may or may not be the same application that provides telephony integration so it may require additional signaling depending on the manner in which it is deployed.

There is a lot going on in this diagram and most of it at the desktop. This is purely from separating out one service (telephony), two if you count video as well if it is supported by the plugin. If video is not supported then you are back to doing it with Microsoft Lync or another application. Most times though the vendor providing the plugin recommends disabling Lync voice and video even for peer to peer communications. Comparing the different end-user experiences with the plugin you will see various Lync menus greyed out and when using the plugin multiple windows for voice and video where with Lync you would see only one.

So stepping through each point for the native Lync experience:

1) SIP TLS encrypted call signaling when using Lync for IM, presence , voice and video.

2) SIP TLS encrypted call signaling Lync phone edition for voice and presence.

3) SIP Trunk to IP PBX or Soft switch much like any traditional tie trunk between two PBX’s.

4) SIP call signaling to the IP phone.

5) USB cable to enable Phone Control function of the Lync Phone Edition device with Lync 2010.

Things are significantly different between the two diagrams. The lower diagram presents a clearly server side integration. Using the SIP trunk between the two systems now allows Lync to be used as softphone. This removes the burden of desktop administration of the integration displayed in the third party application diagram. Even with including Phone Control in the native solution via tethering we have been able to greatly simplify not only the signaling required but also the deployment scenarios. Removing the second application from the desktop (third party softphone) has reduced software deployment dependencies and removed the need to disable native Lync features to avoid end user confusion.

Remote Access

In the first section I covered the basics of of a telephony plugin and how it interacts with Lync. In this second section I will present remote access and how the plugin changes the remote access options. 

Third party application for telephony and video integration beyond the corporate firewall…

image

Versus

Native Lync telephony and video with remote access…

image

As you can see in the top diagram we are forced to run the third party VoIP application over either a hardware or software VPN separate from edge services that are available with Lync. We now have a more complex VPN setup having to spilt tunnel communication services and in some cases VPN services may not be designed to take large amounts of real time media traffic.

This setup also removes the use of RT Audio codec which is specifically designed for uncontrolled networks like the Internet to improve the user’s voice experience. With this setup they are more than likely only able to complete calls using G.711 or G.729 which are affected by network degradation of more than 1% whereas RTAudio will work acceptably with up to 10% packet loss.

Looking at the Lync native solution we begin to see some immediate benefits. First is an Edge specifically designed for real time communication traffic including voice, video, IM, presence and desktop sharing. The second point is that we no longer need to route media traffic back to our internal resources consuming vital Internet bandwidth when both users are remote to our internal network. If one of our users were internal the media would in fact flow through the Edge and not over a VPN service limiting reliance and lowering bandwidth consumption on VPN services. Lastly we have now removed the reliance on the desktop to complete our integration and instead have chosen interoperability at a server level.

Of course there are more reasons to enable edge services with Lync than just telephony. To me one of the most compelling reason to use the Edge has always been federation with business partners to better enable collaboration and lower communication costs.

Just to recap. Lync remote scenarios are designed to be secure and leverage the internet to allow peer to peer connections reducing bandwidth requirements and allowing Lync to scale to large enterprise needs. By removing the native functionality and replacing with a plugin not only have you increased desktop reliance but also made telephone dependent on VPN services to allow functionality. So when you consider what it takes to keep telephony control on a separate system through desktop integration there is much more to consider than just licensing and dial plans.

Comments welcomed.

VoIPNorm

Users unable to join Lync hosted conferences from Cisco Unified Communications Manager 8.5

This is a great post by Jigar on Technet. Reprinting here to help spread the word around this issue and how to resolve it. All credit to Jigar and Tech Support at Microsoft for discovering this issue.

http://blogs.technet.com/b/jigardani/archive/2011/10/04/users-unable-to-join-lync-hosted-conferences-from-cisco-unified-communications-manager-8-5.aspx

In the past couple of months we have seen increase in DTMF issue relating to Cisco Call Manager v8.5 connecting to Lync Server 2010 (Lync). I worked on a few of these issues giving me an opportunity to dive deep into this integration. Cisco Unified Communication Manager (CUCM) v8.5 is supported with Lync Server 2010 only on minor build version 8.5.1.12900-7 as noted on Unified Communications Open Interoperability Program – Lync Server.

Symptom

Cisco phones and conference room endpoints, SIP Trunk terminating on CUCM en-route to Lync would not be able to join conferences hosted by Lync MCU's. You may experience that the user keeps getting prompted for entering the conference ID. Some of the phones which have a capability of RFC 2833 DTMF MTP Passthrough work just fine when that feature is turned on.

Cause

After code level investigation we found that CUCM, when transcoding DTMF digits does not send the digits in right format.

To identify the issue, you need to collect a network trace from the MediationServer of your Lync deployment. Then trace the attempt to login to a Lync hosted conference room. Below is one such trace (obfuscated from customer environment since I do not have a CUCM here), to see the packets of interest I set the wireshark filter to (udp.length != 24 && rtpevent && rtp.marker==1)

The lower window highlighted digits show the raw data captured for RFC 2833 RTP event.

I also captured a trace when a endpoint coming from CUCM was successfully able to login to Lync MCU. To trace these DTMF digits I set up the wireshark filter to (udp.length == 24 && rtpevent && rtp.marker==1)

Again I have highlighted the RTPEvent.

Basically we are capturing UDP packets with length not equal to 24, that are RTPEVENT’s (meaning DTMF) and have RTP marker bit set to 1 - meaning the first packet in the DTMF digit - which has all the information we need.

Event Duration 800 is signified by hex 03 20 raw data - the data 00 00 after that is basically Trailer for Ethernet II as you can see above. Similarly in the bad snapshot above the duration zero should have been represented by 00 00.
However, in that place we see some data after that –

We found that we could isolate all the good packets from bad packets by filtering for the right length. In this case udp length 24. So Why length 24?

A DTMF packet is – UDP header (8 octets) + RTP header (12 octets) + RTP Payload (RTPEVENT=DTMF) (4 octets) = 24 octets.

Here is what we should have for DTMF payload (RTP Payload) RFC 4733 –

Here is what we should have for RTP header (assuming no CSRC) RFC 1189 –

Here is what we should have for UDP header RFC 768 –

So the hex data beyond 24 octets is something that should not have been received by Lync in a DTMF digit. This is what causes Lync to ignore these digits.

Resolution

To resolve this issue upgrade to the supported CUCM version 8.5.1.12900-7.