Lync-Skype integration or rather peering is going to grow geometrically as Microsoft drives the point home of being the “one stop” solution for business communications and applications. AudioCodes, Asterisk and others already have developed some interesting Lync-Skype gateway solutions. AudioCodes is the only one I know of (let me know if I missed anyone) who has an end-to-end solution though there are some feature limitations. Aside from the Lync Federation initiative, Lync-Skype peering connections will help businesses of all sizes. Of course, contact center, hotel/motel, prison/security and many other environments require unique solutions where neither Lync nor Skype are ideal or even viable.
Click on either image for the animated tutorial.
If you look closer at the technical aspects of Lync-Skype peering here’s where calls could go haywire. Of course, the gateway providers have great solutions but it is your behind that is on the line when the CEO calls goes badly and you don’t want this to be a “resume-generating event.”
Here are some other technical considerations:
- Lync Server uses SIP with Transport Layer Security (TLS) using Transmission Control Protocol (TCP), while the Skype SIP trunk works on the SIP over User Datagram Protocol (UDP) transport type. In this situation, DSP-digital signal processing errors, AD-analog-digital conversion, SIP protocol mismatch, encapsulation-serialization, jitter buffer and other problems can often emerge. Here are two examples of problem. Problem: Broken Speech and Dropped Calls. One solution, check QoS policy rules on router. Problem: Congestion may occur from other applications taking precedence. One solution: adjust router policy rules until fixed.
- Transcoding support: Lync supports G.711 A-law and G.711 µ-Law CODECs (coders), while the Skype SIP Trunk also supports G.729. Microsoft uses RTAudio where Lync is deployed. G.711 and G.723.1 are the CODECs used for Exchange Voice Mail. In other words, the inbound stream for calls placed by using Play on Phone will use the G.711 or G.723.1 codec. In some cases, RTAudio processing by a Unified Messaging server consumes more CPU cycles than any of the other codecs. One of the main drawbacks is signal distortion due to multiple encodings called asynchronous or tandem encodings. For example, when a G.729 voice signal is tandem encoded three times, the MOS score drops from, according to Cisco from 3.92 (very good) to 2.68 (unacceptable). Another drawback is codec-induced delay (latency) with low bit rate codecs. Echo can also occur as a result of Asynchronous Transcoding. Transcoding is the process of conversion between circuit-switched (PSTN-Public Switched Telephone Network) and packet-switched networks such as IP-internet protocol, Frame Relay, or ATM-Asynchronous Transfer Mode. Asynchronous transcoding refers to a situation when, for example, one endpoint is talking G.711 to another endpoint talking G.729 (two different encodings). Changing the number of bits sampled and quantized can dramatically impact voice quality. However, LAN-Local Area Network and WAN-Wide Area Network bandwidth limitations may have an equal or greater impact.
In case you need a refresher:
- G.711 µ-Law compresses frames of 14-bit linear (additive) PCM-Pulse Code Modulation samples into frames of 8-bit logarithmic (multiplicative) PCM code words and 14 to 8 bits is µ-Law transformation used in North America and Japan.
- G.711 A-Law compresses 13-bit linear (additive) PCM samples into 8-bit logarithmic (multiplicative) PCM code words. 13 to 8 bits is A-Law transformation used in Europe, For example, natural steps increase in an additive fashion (linear scale) or in a multiplicative fashion (logarithmic scale).
If you have any experiences especially any “ah-ha” moments and solutions, please send them along.
