Pages

Tuesday, April 26, 2011

Mobility in Lync

While waiting for Microsoft to release mobile clients for Lync, there now are some alternatives available.

Audiocodes Mobility Plus definitely looks promising.


Damaka is a company demonstrating video calls between an Ipad2 and Lync on their homepage.


There is also an unofficial mobile Lync client for Windows Phone 7 available.


(With a little Niklas included! :-)

Please comment if you have any experience with these solutions!

Wednesday, April 20, 2011

Troubleshooting Lync Edge 101

We installed a "simple" Lync Edge system with collocated Front-End and Mediation server and Enterprise Voice connected to the PSTN via a Nortel CS1000 PBX.


After configuring (among other things)
  • Internal DNS
  • External DNS
  • Routing on the EdgeServer
  • Internal Certificate
  • External Certificate
  • Public IP addresses
  • Primary DNS suffix on the EdgeServer
  • Open ports on the Internal Firewall
  • Open ports on the External Firewall
  • The mediation server to find the PBX
  • The PBX with a SIP Trunk
  • The topology, exported it and imported it on the EdgeServer
  • Users with external access, enterprise voice and a valid line URI
  • A Voice Policy, PSTN Usage and Route
  • Automatic login internally and externally
and checking the configuration a few times, we could call…

External Lync <---> Internal Lync
Internal Lync <---> Mobile Phone

But not…

External Lync  ---> Mobile Phone
Mobile Phone  <---  External Lync

The signalling from the External Lync client to the Mobile phone went through, the phone would ring and we could answer the call. On the external Lync client the status shifted from "Calling" to "Connecting call", where it sat for a few seconds and finally displayed "Call failed due to network issues". This indicated that the signalling path were working fine and the problem was happening as the system tried to setup the media stream.


We then used the Lync Server 2010 Logging tool to find this error message:
"Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote"

Which led us to this post on the Lync forums: Incoming PSTN call to external user fails to connect

After investigating the logs some more we saw that the mediation server tried to establish a media path straight to the external client!? Did it not know we had an edge? - No, it actually did not!

After looking in the Lync Control Panel / Topology / Standard Edition / Mediation Server, we noticed that the EdgeServer setting were "Not Set"

With Power Shell we could check this with the following command:

Get-CsService -MediationServer

Identity                 : MediationServer:standard.kressmark.com
Registrar               : Registrar:standard.kressmark.com
EdgeServer            :
SipServerPort         : 5070
SipClientTcpPort     : 5060
SipClientTlsPort      : 5067
AudioPortStart        : 49152
AudioPortCount       : 8348
DependentServiceList : {PstnGateway:10.10.10.40}
ServiceId             : 1-MediationServer-4
SiteId                 : Site:Stockholm
PoolFqdn             : standard.kressmark.com
Version               : 5
Role                   : MediationServer

Also, in the Lync Control Panel / Topology / edge.kressmark.com / Edge Server / Dependents, we could only find “Registrar:…” and “ConferencingServer:…” and no "MediationServer:....

So our Mediation Server did not know we had an Edge, and the Edge server did not know about the Mediation server. My guess is that internal calls to PSTN worked simply because the Mediation server were collocated with the Standard server.

However, we used the following command to make things right:

Set-CsMediationServer -Identity "MediationServer:standard.kressmark.com" -EdgeServer edge.kressmark.com

And after restarting the Lync control panel it displayed correct data, and calls from the external Lync client via the collocated mediation server to PSTN worked (and the other way around as well!)

Puh!

Tuesday, April 19, 2011

Psychology in Unified Communications - Part I

When moving circuit based communications to digital packet based networks a large concern is bandwidth. There never seem to be enough bandwidth, so the engineers designing voice (over IP) codecs have developed techniques to limit the need for bandwidth. The media sent over the network is basically a bunch of 1's and 0's, where a 1 indicates a value, activity or sound on the line, and 0's, or rather a bunch of 0’s indicates silence. So, if there are constant silence we could send a quadrillion zeros from one device to the other, but this would not be very efficient bandwidth-wise. Add to this the dynamics of telephone call - you are talking and I am listening, or I am talking and you are listening; we realize that a lot of bandwidth could be wasted here.

The solution to this problem is called Silence Suppression. With this technique a telephone system will only send digits (1's or 0's) when someone speaks or when there is voice activity detected.

So, absolute Silence Suppression would create an absolute silence at the receiving end of a call. However, this is not a good idea since the receiving human would then think the line is down. Since we all have got used to hear some background noise or some crackling static noise when using the telephone the last 100 or so years, we will miss this cosy feeling of being connected. We would actually miss it so bad so that we would complain if we did not get this crackling noise in our calls. I once tried a PBX system in development that had complete silence suppression and it was scary I must say. We both had to ask "Are you there?" several times during a short conversation. So in the time and age of digital Dolby hi-fi surround sound, we still want our phone calls to sound a little rough, crappy or noisy.

The solution to this problem is called Comfort Noise. With this technique a telephone system will generate artificial noise on the receiving end. Hence no need of sending a bunch of 0’s all the time to indicate silence. The crackling noise you hear then when calling with your shiny new VoIP system is not due to bad quality and it is not even coming from the calling party or the line. That crackling noise is added because you want it, and someone even wrote some code to add it artificially, isn't that strange? Well, to a technician it might be strange but it deals with concepts called human nature or psychology.


How can we verify comfort noise in Lync?
The easiest way is to listen; make a call between two Lync clients and on one client yank up the sound level in the computer and on the USB headset as much as you can. You should now hear some nice crackling comfort noise in the headset.

Another funny thing I noticed - on the called client mute the microphone and the noise will silence, now un-mute, but be quiet, and the noise will not reappear until you say something in the called client.

We can also check comfort noise in Lync via logs. In the Lync Server 2010 Logging tool start logging on SIP Stack, and make a call between two Lync clients. When you view this log you will find a SIP INVITE message containing the following two lines in the SDP body…

a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000

…and this indicates that Lync is indeed offering comfort noise when inviting someone to a call.

If you have connected your Lync system to a PSTN Gateway, such as a PBX, SBC or other type of equipment you can often see the "LS Mediation Server" component logging this warning in the event log of the mediation server:

The Mediation Server service has received a call that does not support comfort noise. This event is throttled after 5 calls from a single Gateway peer.
The Mediation Server service has received a call that does not support comfort noise from the Gateway peer, 10.10.10.10
Cause: The Gateway peer does not support comfort noise.
Resolution: Please ensure the comfort noise option on the Gateway has been enabled.

This does not mean that calls will fail, but you might not hear the nice artificial noise on the remote end of the call. However, if your remote device is on a mobile network or connected by copper lines there will plenty of noise anyway, so no need to add it artificially.

That’s a little something about how technology must adapt and are adapting to human nature and not the other way around. Good for us! Enjoy your noisy calls!


Tuesday, April 5, 2011

Telia CallGuide Integration with Lync

Telia CallGuide is a contact center developed by TeliaSonera in Sweden. CallGuide is mainly distributed in Scandinavia and so far there are about 275 contact centers handling some 160 million calls per year with CallGuide. One of the modules in the system is called Unifinder, which is a search tool for the contact center agent to search for people to contact while on a call. Unifinder can search several types of internal directories and also Lync or OCS directories.


Functionality
  • Unifinder will display presence for SIP-Enabled Lync users, the status might be Available, Inactive, Busy, BusyInactive, DoNotDisturb, Away, Offline.
  • The agents can participate in IM conversations with Lync users from CallGuide Unifinder
  • The agents can change their own Lync presence status from CallGuide

Lync Cumulative Updates April 2011

New fixes for the Attendant, Attendee, Group Chat, Phone edition for Aastra, Polycom, LG-Nortel phones, and for Lync 2010 (aka. Communicator) are released.

Also the Lync resource kit is out!
Microsoft Lync Server 2010 Resource Kit

I decided to try the Lync 2010 (Communicator update)
Description of the cumulative update package for Lync 2010: April 2011

So I downloaded the fix here
Lync 2010 Hotfix KB 2496325 (64 bit)

But I ran into some issues with the fix, so I posted at question at the forums. The fix seems to be updating to the January level of fixes?
I will update this post once I get an answer...
Lync Cumulative Update April 2011 - Lync 2010 Hotfix KB 2496325 (64 bit)

Ok, the issue I saw was probably due to it takes a while for the files to replicate out to the various download servers. So I patiently waited, downloaded again from the same page and voila!