Monday, May 26, 2014

Microsoft Lync Voice gateway failover - SipResponseCodeTranslationRules

In Lync environments that utilize multiple gateways for path failure it is important to understand the differences between a voice gateway hard and soft failure.  Lync does a great job with a hard failure and will mark that gateway down and proceed to try the next gateway/trunk that has been selected in the users Voice Policy.

There are two different types of Voice gateway failures in the Lync world. They include:

1. Hard down with the voice gateway being unreachable and marked down by Lync
2. Soft down with the voice gateway is reachable but the Carrier is having an issue.

The concentration will be focused on handling a soft down failure. Our example is based on a pair of Audiocodes Mediant 2600 SBC's that have independent circuits terminating to each gateway to provide high availability and failover. In the event of a soft failure the Audiocodes gateway responds with a 408 Request timeout which is defined as "couldn't find the user or determine the location of the user in time".  Because this is a client side response Lync will not failover to another gateway.  In order to get Lync to try the next gateway the response code must be a 5XX Server response failure.




So we need a way to tell Lync Server when it receives a 408 client response failure to try another gateway.  By using SipResponseCodeTranslationRulesList on the Lync Trunk we can translate both Sip and ISDN response codes to different Sip Response codes. In this case we will create a rule to map the client response code failure of 408 to a server side response code failure of 503 Service unavailable. Lync recognizes this as a gateway down issue and will try next PSTN usage record that is associated with the route and gateway/trunk as defined in the users Voice Policy.

Below is the command we used on the Global Trunk Configuration to convert 408 response code into a 503 response code.


New-CsSipResponseCodeTranslationRule -Parent Global -Name "Rule-408-to-503" -ReceivedResponseCode 408 -TranslatedResponseCode 503

 

 Viola! Lync will now try secondary route to alternate SBC gateway

Sunday, September 8, 2013

Exchange UM AA does not recognize spoken names (Galgrammargenerator.exe)

I was recently integrating a pair of Exchange 2010 UM servers to a Avaya CM 6.21 via Session Manager and ran across an interesting issue. After enabling several mailboxes for Exchange UM the users were not available in the Directory when speaking the subscribers name.  Though I could reach them using the touchtone menu by specifying the extension numbers.

I've seen this issue before and thought to myself - this is a just a case of the grammar files not updating.  I ran the following command to update the grammar files that contain the users recorded name or system generated name:

Galgrammargenerator.exe -d 'ACME UM Dial Plan' -o c:\temp\galgrammarresults01.txt and got the following output:

------------------------------------------
Generating Grammar: Grammar for all UM-enabled users in dial plan 'ACME UM Dial Plan'
Filter: ((((HiddenFromAddressListsEnabled -eq 'False') -and (((RecipientType -eq 'MailContact') -or (RecipientType -eq 'UserMailbox') -or (RecipientType -eq 'MailUser') -or (Phone -ne $null))) -and (((DisplayName -ne $null) -or (FirstName -ne $null) -or (LastName -ne $null))))) -and (EmailAddresses -like '*phone-context=ACME UM Dial Plan.acme.com') -and (EmailAddresses -like 'EUM:*'))
Downloading Entries: 09/03/2013 11:51:44
Downloading Entries Complete: 09/03/2013 11:51:44
The user "Henry E. Jensen III" with the e-mail address "hjensen@acme.com" was not added to the speech grammar because the speech recognition service has determined that it can be said in at least 10 ways. The maximum allowed is 1.
The user "Greg D. Rapp" with the e-mail address "grapp@acme.com" was not added to the speech grammar because the speech recognition service has determined that it can be said in at least 10 ways. The maximum allowed is 1.
Compiling grammar file E:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\grammars\en-US\59e94d9d-355c-4e1e-a4c6-b45dcc013998.grxml -> C:\Users\hejadmin\AppData\Local\Temp\ad8e619f-1cf4-4941-95e1-a4ea5f2bbd4d.cfg

Wowzers 10 different ways to say a name and only one allowed. After digging through the following Blog http://blogs.technet.com/b/exchange/archive/2006/10/30/3395749.aspx it is the display name where the users given name is generated from and then inserted into the speech grammar.
In this case the Display Names had periods, and designations like III that the speech grammars did not like. 

There are two solutions:
1)  Modify the display name attributes.
2)  Populate the PhoneticDisplayName attribute

I opted for the second option and executed the following command:
set-csuser -identity hjensen@acme.com -PhoneticDisplayName 'Henry Jensen'

Next I ran Galgrammargenerator.exe again and after a couple of minutes the user was added to the directory allowing a caller to search for the user name using voice commands.

Cheers

-Paul Gurman-



Monday, August 19, 2013

Southern California Lync users Group








You are Invited!


NACR and Microsoft are proud to announce the Southern California Lync User Group – bringing together a wide range of professionals from companies including AudioCodes, AcmePacket, Polycom, Avaya, Radvision, Plantronics and Interactive Intelligence.

Organized by Paul Gurman, a Lync MCM from NACR, and Lee Reese, a Microsoft Lync Voice TSP for the Southwest, the group is dedicated to demonstrating the value of Unified Communications (UC) and exploring how the Microsoft stack can:

  • Increase ROI
  • Provide a cost-effective replacement strategy for aging phone switches
  • Integrate with contact center and line-of-business applications

 Join us and network with the experts

Our first event will feature AudioCodes presenting on Session Management with Lync and solutions for Auto Attendants at the Branch office, analog device handling and Voice Recording.



Refreshments will be provided by AudioCodes, and cool giveaways will be awarded by Plantronics.



RSVP by September 12th at the link to the below.  Seating is limited.
http://www.nacr.com/company/register-event/?event=56209

Friday, May 31, 2013

Integrating Microsoft® Lync™ with Your Avaya Environment Webinar


http://files.icontact.com/templates/v2/Divided/images/roundedTop.gif

Join NACR for a Free Webinar:
 
Integrating Microsoft® Lync™ with Your Avaya Environment
 

The best of both worlds is within your reach!
You might already own the rights to Microsoft® Lync™ , a leading tool for IM and presence. You know you have Avaya.
 
Now learn how easy it is to integrate Lync into your existing Avaya environment — combining best-of-breed voice and data capabilities to improve your business productivity and bottom line.
 
Learn how to bring the two together.
This free webinar will help you understand the value of Lync and how to use it with your Avaya voice solution — providing an overview of the total solution including:
 
• Features and functionality
• High-level architecture
• Avaya and Lync licensing
• The integration options/scenarios
 
Let NACR help.
You’ll also hear how NACR can help you take advantage of it all — with our unique expertise in both voice and data, and our best-of-breed approach to unifying Avaya and Lync in a seamlessly converged infrastructure.

Event Details:
 
Date:
Wednesday, June 12, 2013
Time:
3:00 pm ET/2:00 pm CT
 

NACR is a leader in helping businesses like yours leverage technology to improve communication, collaboration, and customer interactions. Our credentials include:
  • Avaya Platinum Business Partner
  • Microsoft Gold Communications Partner
  • In-house Microsoft Certified Master (MCM)
  • Microsoft Lync Certified Support Partner
To register for the free webinar, simply click on the RSVP link above.
 
Questions? Talk to your NACR NAM or visit: www.nacr.com
 
 
 
NACR | 3344 Highway 149 |  Eagan, MN 55121| nacr.com
 
 
http://files.icontact.com/templates/v2/Divided/images/roundedBottom.gif

Saturday, May 4, 2013

Certificate Trust issue with Firefox but not IE

Came a cross an interesting issue in that when browsing to the Lync Dial web page we were getting the certificate was not trusted.  This did not occur with Internet explorer.

Naturally, I opened up the MMC console and added the certificate snap in to confirm that the Root CA for the Domain joined computer was installed in the trusted Root Certificate store.







Because Firefox was complaining about the Intermediate Certificate not being trusted I checked to see if Firefox is reading it from the Computers Cert store or it's own.  It appears Firefox builds it's own Trust list and was not reading the RootCA from the Trusted Root Certificate Store. Notice no SeaRoot Cert.


















So I exported the Certificate from the local Machines Root Certificate Store and imported it into Firefox














Now we can see the Root CA and Firefox opens up the Dialin Webpage with out a certificate warning or prompt just like IE.

















Cheers,

Paul Gurman
 






Monday, April 22, 2013

Frankenstein Lync integration with an Avaya via Cisco Cube and H.323

I recently had an opportunity to run a Lync 2013 Production Pilot integrating Lync 2013 Standard Edition server with an Avaya S8700 Communications Manager 3.1.2
https://downloads.avaya.com/elmodocs2/release_notes/312-8700/pdf/31-87resp.pdf

At first glance you would say no problem just do a PRI integration using an Audiocodes gateway but because of Port capacity issues and costs the customer chose to use an H.323 integration leveraging a CLAN card. 

Audiocodes does not support the Avaya version of H.323 but Cisco ISR/CUBE does support Avaya's version of H.323.  Cisco Cube is on the Lync OIP list as well so you would think everything would go smoothly.  We managed to get calls back and forth between the two systems but there are several caveats.  The remaining part of this blog outlines the issues and why doing h.323 to SIP conversion is not my recommended approach.

1. DTMF - Everyone needs DTMF's and it is supported from Avaya through the Cisco ISR when    landing on the Lync Dial in Conferencing Bridge or choosing options when leaving a voicemail in Exchange UM. The issue is with the delay is takes from the CUBE to send the digits to the Lync     server.  Because Avaya version 3.1.2 appears not to be able to send a timer value within the H.245 out of band signaling for DTMF the Cisco CUBE defaults it 4000ms.  Changing DTMF to alphanumeric only provides a marginal improvement.  This is expected behavior according to Cisco TAC but the delay is not ideal for end users

2.  Caller ID -  Caller ID from the Avaya station side does not get passed.  From wireshark traces we don't see name of extension number in the from field in the H.245 signaling. Lync rewrites blank from fields with anonymous otherwise users would be confused by seeing the IP address of the  gateway.

3. Call Transfers - When an Avaya user calls a Lync user and the Lync user transfers the call back out to an Avaya end point or the PSTN the call drops after 30 seconds.  The issue is that the Avaya sends a FIN message and closes the TCP socket essentially severing the signaling and hair pinning of media through the Cisco CUBE.  The original calling party still shows the call is connected because once the FIN is sent the Cisco CUBE has no way of providing disconnect supervision as the TCP Port no longer is active.

Caller ID - Wireshark Capture:




















Call Transfer Capture:

Call leg numbering:

Avaya----(1)---->CUBE-----(2)----->Lync-----(3)---->CUBE----(4)---->Avaya

Frame 4: Setup Request from Avaya to CUBE to establish TCP connection for H.225 signaling. This shows source Port 1720 and destination port 64970













Frame 16407: This is the TCP FIN message received from Avaya. The ports indicates that it’s the same TCP connection as the original H225 connection above. Upon receiving the FIN message, CUBE determines that this call leg’s call signaling is broken, so he proceeds to send SIP BYE to Lync for the 2nd call leg, and the disconnect propagates throughout the rest of the call.









BYE sent to Lync:


However, due to the H225 TCP connection between CUBE and Avaya is the first to tear down, CUBE and Avaya can no longer exchange H225 messages to disconnect the call, which is why we never see Release Complete sent from CUBE to Avaya for the first call leg.

Then about 6 seconds after the initial disconnect, Avaya sent CUBE a release complete for the first call leg, but using a different TCP connection (1720->14108)  which is the one used for call leg 4. CUBE is not listening on this port for the first call leg so it did not recognize the release complete message.


 

Saturday, March 23, 2013

Lync Conferencing Fails when adding PSTN user

Had a recent customer where conferences initiated with outside PSTN participants would fail. Internally conferencing between Lync users worked fine. 

The customer is using a cisco ISR gateway with 2 PRI's to the carrier. There is also 4 digit dialing set up between Cisco UCM 4.x and Lync. Yes you heard right a windows version of Cisco UCM.  Additionally, ingress and egress calls from the PSTN work fine. 

So after confirming nothing was misconfigured on the Conferencing or Client Policies it was time to bust out ocslogging utility and sniff through snooper logs.

Decided to log SIP, S4 and MCUInfra and received couple of SIP 500 unexpected internal errors 

ms-diagnostics: 4099;reason="Internal Error: Failed to validate GRUU contacts";HRESULT="0xC3EE79F2(ES_E_WRONG_MCU_TYPE_IN_GRUU)";gruu="sip:seanm@acme.com;gruu;opaque=app:conf:audio-video:id:1HBHY447";source="Lync.acme.com"

The issue turned out to be the certificate assigned to the Front End server.  It was an external certificate as an internal PKI was not available at the time of install.  The issue was remedied once an internal certificate was requested and assigned from the newly installed Certificate server. There was a name mismatch on the Public cert.