Lync Client Authenticaition

Here is a great article on how Lync Client authentication works, from both an internal and external perspective.

Amazed at some of the posts on the Lync NextHop website...

http://blogs.technet.com/b/nexthop/archive/2012/11/28/lync-2010-client-authentication.aspx

Lync 2013 Client Address Book Update

The Lync client by default will download the address book from the Lync FE server after a random amout of time once the address book is more that 24 hours old.

There is a Registry Key that can be updated to set the initial delay to 0 mins, in other words as soon as your local file is either: 

1. Not on the PC (has been deleted)
2. Or is more that 24 hours old

The following reg add is the key, its slightly different to from the 2010 client as Lync 2013 policies now reside under the office 15.0 side of things.

reg add HKLM\Software\Policies\Microsoft\Office\15.0\Lync /v GalDownloadInitialDelay /t REG_DWORD /d 0 /f

The address book files on the client are now also stored at a different location.

%userprofile%\AppData\Local\Microsoft\Office\15.0\Lync\sip_<lync_signin_address>

Lync Client Comparison Tables

I attended the Lync 2013 Ignite training the other week in Sydney and was keen to get some more information around Lync client capabilities.

Well Microsoft have published a nice little article on what each client functionality is:

http://technet.microsoft.com/en-us/library/gg425836%28v=ocs.15%29

Lync Server Install Fails on SQL Express Install

Have run across this issue a few times now and it always take me a while to find to find the registry key that needs to be updated so thought I would port about it.

The issue is that the SQLExpress install fails as the systems thinks there are pending file deletes to happen during a reboot, but even after the reboot you get the same error.

The below is the error that is seen.

The registry key that needs to be updated is under:

HKLM > SYSTEM > ControlSet001 > Control > Session Manager > PendingFileRenameOperations

Just open the entry and delete the contents, close the Lync Deployment Wizard and re-run the Lync Bootstrapper.  All should be good.

Lync IP Phones Software Update

The update process for Lync IP Phones is a simple process with five (5) steps:

1. Download the UCUpdates.zip file from MS for the required phone types
2. Unpack the .exe file to get the .cab file
3. Upload the phone firmware to the Lync Front End Servers
4. Approve the update from Lync Control panel
5. Wait for the phone to update

Step 1.

Phone firmware can be found from the MS site at: http://technet.microsoft.com/en-us/lync/gg131945

Step 2.

The downloaded file from step 1 is an .exe file, this file needs to be run to get the required .cab file.

Double click the UCUpdates.exe file

Agree to the MS Licencing Agreement

Select the location for the .cab file to be stored

Click Finish, this will now have create a file called UCUdates.cab in the required location

Step 3.

Next step is to upload the .cab file upto the web server service on the Lync Front End Servers, this step needs to be completed for all FE severs in your Lync deployment.

From the Lync Management Shell run the following command:

Import-CsDeviceUpdate -Identity service:webserver:lyncserver.FQDN -FileName "path to file just extracted"

Step 4.

From the Lync Server Control Panel, select "Cleints --> Device Update"

This will show the updates for Phones installed, approved versions of firmware and Pending versions.

Select the phone hardware type, select "Action --> Approve", this will allow ALL phone to update to the newly installed version of firmware.  

If you wish to only update selected phones for "testing" select "Clients --> Test Device", this will show a list of phones addressed via either Serial number or MAC address that the update will be available for.

Step 5.

Once a Lync IP phone has been idle for approx 10mins it will check the web service to see if any available updates are available. If updates are available the phone will start the update process.

The update process generally requires the IP Phone to reboot, if PC are network attached via the Phone they will loose connectivity.  So be careful when you approve the updates.

Lync Server 2013

There has been some information released overnight with a preview release of Lync 2013.  Hoping to have some time over the next few days to get it installed in my lab and see how it looks.


Some links if you are after more information.

• Lync Server 2013: http://technet.microsoft.com/en-US/evalcenter/hh973393
• Lync 2013 Client: http://technet.microsoft.com/en-US/evalcenter/hh973391 (need to install the Office 2013 cloud software to get the client)
• Technet Articles: http://technet.microsoft.com/en-us/library/gg412892%28v=ocs.15%29

NET UX MoH

So everyone knows by now that the Lync IP phones don't support Music on Hold (MoH), the some of the early Lync phone clients would let you place calls on hold from the Lync client on the PC and then MoH would be played from the PC.  But this seems to have been "removed" as a feature during a CU update.


From version 2.1.x of the NET UX gateway you can now have MoH played to PSTN callers when a Lync IP Phone places a call on hold.

The supported file types include:

• PCMA
• PCMU
• WAV 
• PCM
• G726

The supported file must have a sampling rate of 8KHz and be a mono channel.

There is also a limit to the size of the file that can be uploaded. On the UX1000 the max file size is 1MB and 4MB for the UX2000.


Steps in configuring the UX for MoH include:
Upload the selected file to the DSP of the UX gateway, from the Settings tab, select "Media --> Media System Configuration" and select "Upload Music File"

Once the upload has been completed you will get the following "Upload Status"

Verify that the MoH file has been uploaded into the UX DSP's by selecting "System --> DSPs"

The next steps involve updating the signalling groups to allow for the MoH, select the SIP signalling group to the Lync Mediation server, there are three (3) options

• Disabled
• Always Enabled
• Enabled for 2-Way Hold Only

MoH	Meaning
Disabled	Music is never played
Always Enabled	Music is always played for the extension placed on hold. This is one-way only
Enabled for 2-Way Hold Only	Music is only played when both parties to a call have placed the call on hold. For example, if party A and party B both place the call on hold music will be heard by whichever party takes the call off hold first, indicating that the other person has placed the call on hold.

The usual setting for this value is "Always Enabled"

NET UX Tone Tables - Australia

The tone tables is a PSTN gateway is used to play different tones for specific actions, tone include ring back (used when the phone is ringing), busy (used to let the caller know that the phone number is busy), now not having these set wont break anything, as far as I have seen, but it will confuse callers as they are used to getting a specific tone for these scenarios.


In the NET UX gateway, tone table are configured under "Settings --> Tone Tables"

The following table outlines the required frequency and settings:

Tone Type	Freq 1	Amp 1	Freq 2	Amp 2	Cadence Configuration
					Continuous Tone	Cadence On	Cadence Off	Double Cadence	Cadence On	Cadence Off
Ringback	400	-19	450	-19	Cadence	400	200	Yes	400	2000
Dial	425	-13	450	-13	Yes
Busy	425	-24			Cadence	375	375	No
Congestion	480	-24	620	-24	Cadence	250	250	No
Call Waiting	440	-13			Cadence	300	9700	No
Disconnect	480	-24	620	-24	Cadence	250	250	No

The following screen shots show the tone tables from the UX Gateway;

Call failed due to network issue

The error message "Call failed due to network issue" can be caused from a number of different reason, the following post outlines some of the issue that I have so far found.

Monitoring Server
The first thing to check is to check the monitoring server reports for an error message.  Usually the error is some thing like "Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote"

Candidate information
Checking the  candidate information from the SIP packets during the call.  What we are looking for is that both the Edge AV Service IP address and the NAT IP address (of your home router etc) is being sent and received by the two clients.

DNS
If the candidate information is not being sent first thing to check is that the internal client can resolve the DNS host name of the Edge Server to the INTERNAL interface.  

If the DNS results returned don't match the IP address of the internal check DNS to make sure that a error hasn't been made with a static entry and check that the Internet facing NIC's in the edge server.  If there are dynamic entries in the DNS check that the "Register this connection's address in DNS" 

From the NIC properties select "Internet protocol Version 4 (TCP/IP)

Select Advanced

Select the DNS tab, then un-tick the "Register this connection's address in DNS"

Firewall:

The Media Relay Authentication Service (MRAS) is responsible for notifying the Lync client of the STUN and TURN IP address for ICE.  This service run on UDP port 3478.

To check that the UDP port is open on the firewall between the Internal Lync clients and the Edge server running this service you can use the Microsoft tool PortQry

PortQryUI: http://www.microsoft.com/en-us/download/details.aspx?id=24009

PortQry: http://www.microsoft.com/en-au/download/details.aspx?id=17148

Lync Client Policy

There is a Lync client policy setting called "DisableICE", from Technet the DisableICE value is described as "When set to True, Lync 2010 will not use the Interactive Connectivity Establishment (ICE) protocol to traverse firewalls and network address translation (NAT) devices; this effectively prevents users from making Lync 2010 calls across the Internet. When set to False, Lync 2010 will use the ICE protocol to enable Lync 2010 calls to traverse firewalls and (NAT) devices."  If this has been set to TRUE then the Lync Client wont communicate with the MRAS service.

AudioCodes FXO to Lync Configuration

Was setting up an FXO analog port for an in-dial today, with an AudioCodes Mediant 800, has some issues with getting the FXO to make and receive calls.  After a few email with support at VExpress finally got it sorted.

The basic configuration of the Mediant 800 is much the same as all their other gateways, the FXO port needed a little tweaking that I hadn't been able find in any other documents.

The only additional configuration that was required was under "VoIP --> GW and IP to IP --> Analog Gateway --> FXO Settings" and under "VoIP --> GW and IP to IP --> Analog Gateway --> Automatic Dialing"

FXO Settings
Change the "Dialing Mode" to One Stage

Automatic Dialling
Then we had to setup the Automatic Dialling you just need to set the phone number that corresponds to the FXO line that is being configured.

UPDATE:

So with this configuration we were seeing some issues with call quality on the Lync end.  The PSTN caller could hear with no issues at all.  It turns out that the Mediant with FXO ports needs to have the earth cable installed, once this was installed the call quality issues have gone.

Lync Dial Plan and Phone Words

So this is something new that I came across the other day, it has been around for a while but it actually affected a client, so had to figure out a way around it.
Phone Words, according to ACMA are:

Phonewords are made up from the letters of the alphabet that appear on a telephone keypad. These letters can be used to form a word, or a part word/part number combination, which can then be dialled as a telephone number to access a particular service. One example is '1300 FLIGHT'. Every phoneword has a primary underlying phone number, or in some cases more than one number, used by the telecommunications network as an 'address' for delivering the call.
The types of numbers that are most commonly used for phonewords include those beginning with the prefixes '1300', and '1800', which are 10 digits in length, and numbers beginning with '13', which are generally six digits in length.

When you think about it its actually pretty easy to solve, but first i had to get my head around what it all meant.


My original dialplan normalisation rule for 1300 or 1800 numbers was a simple

^(1[38]00\d{6})$ --> +$1

But as soon as a phone word was over the 10 total digits in length the call would fail. As a side note the number that was found to be the issue was the RSPCA number 1300 CRUELTY (1300 278 358).

So 1st plan was to remove the $ in the normalisation rule, and change it to 

^(1[38]00\d{5}\d+) --> +$1

This worked, until the call hit the gateway and was sent out with too many digits was rejected by the carrier.


So next plan was to only send the 10 digits to the gateway, this resulted in

^(1[38]00\d{6})\d* --> +$1

This only send the first 10 digits of the normalised number to the gateway and allows for the call to proceed to the carrier.

As with all pattern matching there is always more than one way to do this, so if you have a better way, please leave a comment.


Link to ACMA phone works fact sheet:
http://www.acma.gov.au/WEB/STANDARD/pc=PC_1682

Lync Normalisation Rules - Pattern Matching

The table below outlines some of the available regular expressions for Lync number normalisation.  

Element	Meaning	Example	Explanation of example
^	Match at beginning of string	^123	Match the digits 123 at the beginning of the string
()	Captures the matched sub expression	(456)	Capture what is between the parentheses into a numbered variable, starting at 1 which can be accessed as $n, eg $1
*	Specifies zero or more matches	\d(*)
+	Specifies one or more matches	\d(+)
?	Specifies zero or one matches	\d(?)
{n}	Specifies exactly n matches	\d{4}	Match 4 digits
{n,}	Specifies at least n matches	\d{3,}	Match at least 3 digits (with no limit to number of digits matched
{n,m}	Specifies at least n, but no more than m, matches.	\d{3,6}	Match at least 3 digits but no more than 6 digits
\d	Matches any decimal digit	^\d	Match any decimal digit (at the beginning of a string)
|	Matches any one of the terms separated by the | (vertical bar) character	134 | 135	Match either the string 134 or the string 135
$	The match must occur at the end of the string	^(123)$	Match exactly digits 123 (and not 1234)

The Lync number normalisation is based on .NET regular expression, more details can be found on the MSDN site: http://msdn.microsoft.com/en-us/library/hs600312