IETF RFCs Supported by Lync

I was responding to an RFP, and one of the questions was a list of the IETF RFCs that Lync supported.  There didn't seem to be a central list anywhere, so I compiled a list myself.  If you're in a similar situation where you need this kind of info, hopefully this will help!  Much of this was taken from Microsoft's official protocol documentation at http://msdn.microsoft.com/en-us/library/cc307282(v=office.12).aspx.  If the RFC was listed in the Normative References section, I added it here.  The RFC may not be followed to the letter, and may have been added on to as well.
Any additions or corrections would be greatly appreciated. 

RFC #	Description	Relates To	Link
RFC 1321	The MD5 Message-Digest Algorithm	Security	http://tools.ietf.org/html/rfc1321
RFC 2045	Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies	Conferencing	http://tools.ietf.org/html/rfc2045
RFC 2104	HMAC: Keyed-Hashing for Message Authentication	Security	http://tools.ietf.org/html/rfc2104
RFC 2111	Content-ID and Message-ID Uniform Resource Locators	Telephony	http://tools.ietf.org/html/rfc2111
RFC 2118	Microsoft Point-To-Point Compression (MPPC) Protocol	Base	http://tools.ietf.org/html/rfc2118
RFC 2132	DHCP Options and BOOTP Vendor Extensions	Base	http://tools.ietf.org/html/rfc2132
RFC 2141	URN Syntax	Base	http://tools.ietf.org/html/rfc2141
RFC 2190	RTP Payload Format for H.263 Video Streams	Media	http://tools.ietf.org/html/rfc2190
RFC 2198	RTP Payload for Redundant Audio Data	Media	http://tools.ietf.org/html/rfc2198
RFC 2246	The TLS Protocol Version 1.0	Security	http://tools.ietf.org/html/rfc2246
RFC 2315	PKCS #7: Cryptographic Message Syntax Version 1.5	Security	http://tools.ietf.org/html/rfc2315
RFC 2459	Internet X.509 Public Key Infrastructure Certificate and CRL Profile	Security	http://tools.ietf.org/html/rfc2459
RFC 2474	QoS Differentiated Services	Network	http://tools.ietf.org/html/rfc2474
RFC 2716	PPP EAP TLS Authentication Protocol	Security	http://tools.ietf.org/html/rfc2716
RFC 2743	Generic Security Service Application Program Interface v2, Update 1	Security	http://tools.ietf.org/html/rfc2743
RFC 2782	A DNS RR for specifying the location of services (DNS SRV)	Base	http://tools.ietf.org/html/rfc2782
RFC 2818	HTTP Over TLS	Base	http://tools.ietf.org/html/rfc2818
RFC 2976	SIP INFO Method	Base	http://tools.ietf.org/html/rfc2976
RFC 2986	PKCS#10: Certificate Request Syntax Specification	Security	http://tools.ietf.org/html/rfc2986
RFC 3261	Session Initiation Protocol (SIP)	Base	http://tools.ietf.org/html/rfc3261
RFC 3262	Reliability of Provisional Responses in SIP	Base	http://tools.ietf.org/html/rfc3262
RFC 3264	An Offer/Answer Model with the Session Description Protocol (SDP)	Conferencing	http://tools.ietf.org/html/rfc3264
RFC 3265	SIP-Specific Event Notification	Base	http://tools.ietf.org/html/rfc3265
RFC 3311	SIP UPDATE Method	Base	http://tools.ietf.org/html/rfc3311
RFC 3323	A Privacy Mechanism for the Session Initiation Protocol (SIP)	Base	http://tools.ietf.org/html/rfc3323
RFC 3325	Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks	Telephony	http://tools.ietf.org/html/rfc3325
RFC 3326	The REASON Header Field for SIP	Base	http://tools.ietf.org/html/rfc3326
RFC 3327	SIP Extension Header Field for Registering Non-Adjacent Contacts	Base	http://tools.ietf.org/html/rfc3327
RFC 3350	Real-time protocol for media	Media	http://tools.ietf.org/html/rfc3350
RFC 3361	DHCP option for SIP servers	Telephony	http://tools.ietf.org/html/rfc3361
RFC 3389	Real-Time Transport Protocol (RTP) Payload for Comfort Noise (CN)	Telephony	http://tools.ietf.org/html/rfc3389
RFC 3420	Internet Media Type message/sipfrag	Media	http://tools.ietf.org/html/rfc3420
RFC 3428	Session Initiation Protocol (SIP) Extension for Instant Messaging	Base	http://tools.ietf.org/html/rfc3428
RFC 3515	SIP REFER Method	Base	http://tools.ietf.org/html/rfc3515
RFC 3550	RTP: A Transport Protocol for Real-Time Applications	Media	http://tools.ietf.org/html/rfc3550
RFC 3551	RTP Profile for Audio and Video Conferences with Minimal Control	Media	http://tools.ietf.org/html/rfc3551
RFC 3581	SIP Symmetric Response Routing	Base	http://tools.ietf.org/html/rfc3581
RFC 3605	Real Time Control Protocol (RTCP) Attribute in Session Description Protocol (SDP)	Media	http://tools.ietf.org/html/rfc3605
RFC 3611	RTP Control Protocol Extended Reports (RTCP XR)	Media	http://tools.ietf.org/html/rfc3611
RFC 3629	UTF-8, A Transformation Format of ISO 10646	Conferencing	http://tools.ietf.org/html/rfc3629
RFC 3711	Secure real-time protocol for media	Media	http://tools.ietf.org/html/rfc3711
RFC 3761	Telephone Number Mapping (ENUM)	Telephony	http://tools.ietf.org/html/rfc3761
RFC 3840	Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)	Base	http://tools.ietf.org/html/rfc3840
RFC 3842	A Message Summary and Message Waiting Indication Event	Telephony	http://tools.ietf.org/html/rfc3842
RFC 3852	Cryptographic Message Syntax (CMS)	Security	http://tools.ietf.org/html/rfc3852
RFC 3863	Presence Information Data Format (PIDF)	Base	http://tools.ietf.org/html/rfc3863
RFC 3891	SIP REPLACES Header	Telephony	http://tools.ietf.org/html/rfc3891
RFC 3892	SIP Referred-by Mechanism	Telephony	http://tools.ietf.org/html/rfc3892
RFC 3960	Early Media and Ringing Tone Generation for SIP	Telephony	http://tools.ietf.org/html/rfc3960
RFC 3966	Tel URI for Telephone Numbers	Telephony	http://tools.ietf.org/html/rfc3966
RFC 3986	Uniform Resource Identifier (URI): Generic Syntax	Base	http://tools.ietf.org/html/rfc3986
RFC 4028	Session Timers in the Session Initiation Protocol	Conferencing	http://tools.ietf.org/html/rfc4028
RFC 4119	A Presence-based GEOPRIV Location Object Format	e911	http://tools.ietf.org/html/rfc4119
RFC 4120	The Kerberos Network Authentication Service (V5)	Security	http://tools.ietf.org/html/rfc4120
RFC 4121	The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2	Security	http://tools.ietf.org/html/rfc4121
RFC 4122	A Universally Unique Identifier (UUID) URN Namespace	Base	http://tools.ietf.org/html/rfc4122
RFC 4145	TCP-Based Media Transport in the Session Description Protocol (SDP)	Media	http://tools.ietf.org/html/rfc4145
RFC 4235	An INVITE-Initiated Dialog Event Package for SIP	Base	http://tools.ietf.org/html/rfc4235
RFC 4244	An Extension to SIP for Request History Information	Base	http://tools.ietf.org/html/rfc4244
RFC 4353	A Framework for Conferencing with the Session Initiation Protocol (SIP)	Conferencing	http://tools.ietf.org/html/rfc4353
RFC 4480	RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)	Base	http://tools.ietf.org/html/rfc4480
RFC 4559	SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows	Security	http://tools.ietf.org/html/rfc4559
RFC 4566	SDP: Session Description Protocol	Media	http://tools.ietf.org/html/rfc4566
RFC 4568	Session Description Protocol (SDP) Security Descriptions for Media Streams	Media	http://tools.ietf.org/html/rfc4568
RFC 4571	Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport	Media	http://tools.ietf.org/html/rfc4571
RFC 4574	The Session Description Protocol (SDP) Label Attribute	Conferencing	http://tools.ietf.org/html/rfc4574
RFC 4575	A Session Initiation Protocol (SIP) Event Package for Conference State	Conferencing	http://tools.ietf.org/html/rfc4575
RFC 4733	RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals	Telephony	http://tools.ietf.org/html/rfc4733
RFC 5139	Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)	e911	http://tools.ietf.org/html/rfc5139
RFC 5245	Interactive Connectivity Establishment (ICE)	Media	http://tools.ietf.org/html/rfc5245
RFC 5280	Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile	Security	http://tools.ietf.org/html/rfc5280
RFC 5389	Session Traversal Utilities for NAT (STUN)	Media	http://tools.ietf.org/html/rfc5389
RFC 5652	Cryptographic Message Syntax (CMS)	Security	http://tools.ietf.org/html/rfc5652
RFC 5766	Traversal Using Relays around NAT (TURN)	Media	http://tools.ietf.org/html/rfc5766
RFC 6797	HTTP Strict Transport Security (HSTS)	Security	http://tools.ietf.org/html/rfc6797

Lync Normalization Rules, RCC and You

A little publicized feature of Lync is its ability to remotely control a deskphone from another vendor (say Cisco).  This is known as Remote Call Control (RCC).  Your desk phone rings, and you get the Lync pop-up telling you about the call. Clicking the pop-up will answer the call on your deskphone.  You can make calls via Lync, but the call will be dialed via your deskphone.  In this scenario, you're not using any of the features of Enterprise Voice, but it does provide some semblance of integration between another vendor's PBX and Lync.  The mechanism that allows this coordination is called Computer Supported Telecommunications Application (CSTA).  If the PBX doesn't support it natively, then you would usually deploy a SIP/CSTA gateway between Lync and the PBX.

This post isn't about how to setup RCC.  There is already lots of information out there about that.  As the post title infers, it's about phone number normalization and RCC and some confusing information from Microsoft. 

If you read through the official Technet documentation on RCC, you may have noticed the following bit of info (from http://technet.microsoft.com/en-us/library/gg558630.aspx):

Lync clients download phone number normalization rules as part of the Address Book Service (ABS) file download. In remote call control scenarios, Address Book Service phone number normalization rules are applied to both incoming and outgoing remote call control calls.

From that, you'll probably think that all you need to do is to setup normalization rules as part of a Lync dial plan, as I've described before.  So, you go through the motions of creating a dial plan, but you'll soon realize that the normalization rules you created are not being applied to RCC calls.  If you do some more digging, you might come across this seemingly contradictory statement from Microsoft (from Remote Call Control Features not Working):

Issue: You are using remote call control with Microsoft Lync 2010 and are unable to do one or more of the following:

• Download normalization rules (emphasis mine)
• Use video calling
• Transfer meetings to your own number(s)
• Join meetings by using the Join From dialog box

Resolution: Lync 2010 does not support the remote call control features in the preceding list. There currently is no workaround for this issue.

While these two statements might seem to contradict each other, they are actually both correct.  The key difference is that the first statement says Lync will download normalization rules as part of the Address Book Service file download.  The documentation doesn't go into much more detail on that, but what they are referring to is the normalization rules stored in the Company_Phone_Number_Normalization_Rules.txt file. 

The original purpose of this file was to store normalization rules that are applied to phone numbers associated with Active Directory user accounts. If your users' phone numbers in AD are not in E.164 format, then Lync won't show them to you when you click on a user.  The normalization rules defined in the Company_Phone_Number_Normalization_Rules.txt file are used to normalize those AD numbers into the proper E.164 format.  I won't go into more detail, because there is already an excellent post on the subject by Jeff Schertz. 

The little known part is that this same file is the ONLY method used for normalizing phone numbers  typed into the Lync client for outbound dialing, when that user is enabled for RCC.  Lync dial plan normalization rules are not applied (hence the statement about RCC Lync users not downloading normalization rules). 

For instance, if your PBX requires a 9 in front of local numbers and an 8 in front of long-distance numbers, you would have to create these rules in the Company_Phone_Number_Normalization_Rules.txt file like this:

^(\d{10})$
9$1

^(1\d{10})$
8($1)

When a user types a 10-digit number into Lync like 4165551111, it will normalize to 94165551111, which can be sent to the PBX for proper remote call control functionality.  Likewise, typing 16132223333 would normalize to 816132223333

An additional example would be 4-digit extensions that need to be translated to 10-digits:

^(\d{4})$
905222$1

You may notice that these examples don't normalize to E.164, which is something I preach regularily on this blog.  When you're dealing with a legacy PBX, you're at the mercy of whatever rules are defined for it.  Those rules often don't use E.164 formatting.  You just have to work with what you've got.

Now, what if you've got multiple sites that you want to use RCC, but each site has its own special rules on how to deal with particular numbers?  You can have a different Company_Phone_Number_Normalization_Rules.txt for each Lync pool, so it shouldn't be too difficult to make RCC work in most scenarios.

In essense, when deploying RCC, don't bother creating Lync dial plans, normalization rules or any other Enterprise Voice related content.  Remote Call Control simply does not use any Enterprise Voice functionality.  The Company_Phone_Number_Normalization_Rules.txt file is the only way to do any number manipulation.

Hopefully, this will help anyone attempting to deploy Lync RCC and has come across this stumbling block.

Lync Desktop Sharing UI Issue

I love the Lync client (I also love lamp).  It's a slick, easy-to-use application that handles, IM, voice, video, conferencing, whiteboarding and desktop sharing.  But like everything in life, you've got to take the good with the bad.  The bad things in Lync are really more minor annoyances to me, but when I see them trip up users over and over again (myself included), I think "there's got to be a better way to do this".  I'm a stickler for a well-designed user interface, so when I see something missing, it gets on my nerves a bit.

The thing I'm talking about today is related to desktop/application sharing.  UI-wise, it works like a charm in most cases, but there's a scenario that more often than not, confuses the hell out of people.  Let me take you through it:

You start a desktop sharing session with one of your colleagues.  You easily find the Sharing button in the Lync client and click Share desktop.

You share your desktop, and everything is great.  You'll notice a yellow bar notifying you that you're sharing your screen. 

If you click the Preview button, it will open the "stage" which shows you what other people are seeing. The stage will show you one of those cool things that happens when you have 2 mirrors opposite each other....the scene just keeps repeating itself smaller and smaller and smaller until its the size of atoms (or so I imagine).  Normally, you don't want to show your stage, because it just gets in the way, so you click "Hide stage".

Now, the other guy wants to show you something on his desktop, so he shares his desktop out.  He'll get a notification saying his sharing will replace yours..

And your screen sharing session will just go away and you'll see this yellow bar notification.

However, even though the double arrow beside the user sharing is "lit up", you won't see his desktop.  You'll thrash around in confusion until either you quit your job because Lync has "beaten you" or you stumble onto how to see the other person's desktop.  If either of those cases don't apply, I'll share the secret.  You have to click on Share - Show Stage for the other guy's desktop to show up on your screen.

A very simple way out of this little UI conundrum is to add a button on the yellow notification bar to "Show stage".  If the right people see this blog, maybe we'll see it incorporated in a future patch.

Until next time, cheers!

Lync Deskphones and Wildcard Certificates

A critical component of any Lync deployment is the deskphone.  While some users may be comfortable with using a headset/PC combo as their primary telephony interface, I've found that most users still prefer a deskphone.

However, getting a Lync deskphone to work with Lync can be a bit tricky if you aren't diligent about following Microsoft best-practices to the letter.  You may have a Lync environment that works perfectly well for computer-based Lync clients, but you may come across various connectivity issues when you plug in a Lync deskphone that does presence and Exchange calendaring. 

I recently came across a client who were having Exchange connectivity issues with their Polycom CX600 phones.  The Polycom CX600 is likely the most popular Lync deskphone. It provides a very slick interface into Lync and Exchange so you can see your presence, contacts and upcoming meeting information. It is also very cost-effective compared to other similar products.

When users signed into Lync on their CX600 (either via keypad or USB-PC integration), they were soon presented with the following error:

Microsoft Exchange integration unavailable.  Connection to Exchange is unavailable due to invalid network credentials.

The CX600 uses Exchange Web Services (EWS) and autodiscover to find the connection to Exchange.  If there are issues with either service, it will pretty much guarantee that the CX600 won't connect.  I verified that both EWS and autodiscover were working properly.

When I reviewed the certificate loaded on the Exchange Client Access Server, I saw that the common name (CN) was set to their public domain (ie. contoso.com).  The Subject Alternate Names (SAN) included all the required names.  Microsoft Lync documentation recommends that you do not use certificates with the CN set to a wildcard domain name.  You CAN use wildcards in the SAN, but the CN really should be a valid name.  In this case contoso.com is the same as *.contoso.com. 

The client replaced the certificate with one whose CN matched the externally accessible name of the CAS server (owa.contoso.com) as reported by Exchange.  They issued an IISReset, restarted the CX600 and the error went away.  They now have full connectivity to Exchange via the CX600.

I've seen variations on this many times on both Exchange and Lync.  If you're only using Lync PC clients, you may never notice any issues, but as soon as you bring deskphones and even mobile phones into the mix, these sort of things often come up. 

So as a general rule, if you're creating certificates for Lync or Exchange, DON'T use a wildcard as the first name.

Block Premium Rate Numbers with Dialing Rule Optimizer

I'm always on the lookout for ways to improve the Lync Dialing Rule Optimizer.  I got a request from a frequent user to add an option to block premium rate phone numbers.  Premium rate phone numbers are numbers that charge a higher than normal fee for calls...like those TV ads that promise incredibly hot women in bikinis are waiting to talk to you for only $4.99 per minute. 

The usual way to block these numbers was to program an exception for them in the relevant route regular expression.  I was on my way to figuring out how to programatically do this through the Optimizer when I stumbled upon this little gem of a post from Brian Rubart's UC Blog.  He came up with the brilliant idea to use the Lync Announcement and Unassigned Number service to block these numbers.  So, rather than just returning an uninformative fast-busy when someone tries to call a premium rate number, the Announcement service will tell the user why the call cannot be completed.

The only downside I can see to dealing with premium numbers in this manner is that its a setting that will affect all users.  There isn't a way to allow specific people to call premium rate numbers.

In the latest revision of the Dialing Rule Optimizer, you now have the option to use the Announcement service to block premium rate numbers.  All you need to do is to put a checkmark beside Block Premium Numbers.  It will create the relevant Powershell commands at the bottom of the resulting PS1 file. 

The Powershell commands will create the announcement using text-to-speech synthesis in the language of the selected country. You can modify the announcement text as you see fit. You can also modify the default premium number ranges or add your own if you wish.

An example is below.  Don't try to run these commands outside of the context of the Optimizer-generated script.  It relies on variables set earlier in the script:

New-CsAnnouncement -Parent $AppSrv.Identity -Name 'Announce_BlockedNumber_NA' -TextToSpeechPrompt 'The number you have dialed is prohibited due to corporate policy. If you need to reach this number, please notify your manager.' -Language 'en-US'

New-CsUnassignedNumber -Identity 'PremiumRate_NA_1' -NumberRangeStart '+19002000000' -NumberRangeEnd '+19009999999' –AnnouncementService $AppSrv.Identity -AnnouncementName 'Announce_BlockedNumber_NA'

New-CsUnassignedNumber -Identity 'PremiumRate_NA_2' -NumberRangeStart '+19762000000' -NumberRangeEnd '+19769999999' –AnnouncementService $AppSrv.Identity -AnnouncementName 'Announce_BlockedNumber_NA'

If you are so inclined, instead of using text-to-speech, you can use an audio file (in WAV/WMA format). Import the file using the Import-CSAnnouncementFile command as below...

$a = Get-Content ".\GreetingFile.wav" -ReadCount 0 -Encoding Byte

Import-CsAnnouncementFile -Parent ApplicationServer:redmond.litwareinc.com -FileName "WelcomeMessage.wav" -Content $a

...and then assign it to the announcement using the -AudioFilePrompt switch in the New-CSAnnouncement command. 

You can also send blocked calls to a SIP URI like sip:yournamehere@contoso.com or a phone number like "sip:+14255551212@litwareinc.com;user=phone", by using the -TargetURI switch in the New-CSAnnouncement command. That way, you can shame your users verbally when they try to call blocked numbers. Fun times!

If you have any suggestions for additional features, corrections to the premium number list, or if you can help me correct the Google-translated text I used for the other languages supported by the Optimizer, please drop me a line.

Verifying Lync Trunk Translation Rules with your Phone

Greetings all.  It's been a while since the last real blog update.  This past summer was quite busy both work-wise and life-wise, so the blog posts fell by the wayside.  Consider it a summer hiatus, like TV.  As fall brings a new TV season, it also brings new blog posts, so read on....

If you've used trunk translation rules in Lync (and if you've followed my Enterprise Voice Best Practices series, you should be), you may have discovered a very annoying omission in the Voice Route Test Case window. 

Once you've created all your normalization rules, its a good idea to validate your dial plan and voice policies by running some numbers through the Voice Routing Test Case window.  The voice routing test case dialog box can be accessed from any of the tabs in the Voice Routing section of the Lync Control Panel.  Just click the little downwards facing chevron to expand the window.  The window will stay active no matter which tab you click on, which can be handy for testing changes as you go.


I usually find it best to select the checkbox beside Populate from user and selecting a valid Enterprise Voice-enabled user, so you can be sure you're testing the right dial plan and voice policy.

You'll notice that when I plug in a test 10-digit local phone number for a Vancouver based Lync deployment, it shows that it applies the correct normalization rule, picks the correct usage and the route.  If you've used the Dialing Rule Optimizer or followed my best practices for creating routes and trunk translation rules, a trunk translation rule should strip the +1 from the number before sending it to the PSTN.  However, the test case results do not show the trunk translation rule that would be applied to the number. 

The omission of the trunk translation rule from the results window can lead to the mistaken belief that the number isn't being sent out correctly.  It can also lead to general confusion, heart palpitations, sweaty palms and mild to severe incontinence.  I believe this is a serious omission that limits the usefulness of this otherwise great tool. 

Normally, the only way to verify the number is being formatted correctly once it leaves Lync is to use the Lync Logging Tool or IP gateway logs (if you've got one) to sift through until you find the information.  Either that or if the call completes successfully, that's a pretty good indication things are working as expected.  However, if you happen to have a Polycom CX500/600/700/3000 series Lync phone or Aastra Lync phone, you can easily validate what number is sent to the PSTN. 


When you dial a local number, the normalized number will be shown first (which will always start with +1), but the actual number sent to the PSTN will be shown in a smaller size below.  The first screengrab shows what it looks like when you dial a local number that should have the +1 stripped out.  The second shows a long distance number that should only strip the +.

Local Call

Long Distance Call

If you happen to have a Polycom or Aastra Lync deskphone, this is a great way to validate your trunk translation rules.  Hopefully, Microsoft will update the Voice Test Case app to include trunk translation rules in the future.

Many thanks to Tim from Rolling Thunder, who pointed this out to me during a discussion about trunk translation rules this morning.

Ken's UC Blog Turns 1!

It was a year ago that I first dipped my toe into the blogosphere.  I really had no idea what I was going to blog about, outside of a few vaguely formed thoughts.  At first, there was very little traffic.  Every day, I would get excited over seeing anybody visiting my blog.  Now, I've built up what I hope is a fairly respectable set of posts that seem to regularly turn up in searches and I get just under 10,000 page visits a month.

I hope I can continue providing helpful information about Lync and Exchange UC related in the next year and beyond!
Here are some of my site stats collected over the last year....

Top 5 Visits by Country
USA        38%
UK            9%
Canada      6%
Germany    4%
Australia    3%

Top 5 Browsers
Internet Explorer  60%
Firefox                 19%
Chrome               13%
Safari                    4%
Opera                   1%

Top 5 Operating Systems
Windows    90%
Macintosh    4%
Linux            1%
iPad             1%
iPhone          1%

Lync Bug with Incoming E.164 Phone Numbers?

If your company uses internal extensions instead of DIDs for your users, you may have come across my blog post on how to best setup Lync Enterprise Voice for internal extensions.

There appears to be an issue with using my method of using the main office number as a base for all internal extensions in certain circumstances. The issue seems to arise when the incoming phone number coming from the PSTN is prepended with a plus sign (a properly formatted E.164 phone number). When Lync sees an incoming call that starts with a +, it assumes the number is properly formatted and does not apply any translation rules. Since my method relies on a translation rule to add a ;ext=<ext> to ensure the incoming call is going to a unique number, Lync will return a 485 Ambiguous (because there are many numbers with the main number as a base) and drop the call.

This only occurs in situations where incoming calls are prepended with a plus sign. This will typically occur when using SIP providers or PSTN gateways (AudioCodes, Dialogic etc) that prefix incoming calls with a +.  I verified this with a client that has both a PSTN connection via a Dialogic (that doesn't add a + to incoming calls) and a SIP provider that does add a + to incoming calls).

There are several workarounds:

1. If you are using a Direct SIP provider, they may be able to not send the + to your Lync server. Call your provider and ask if this is an option.
2. If you are using a PSTN gateway or IP-PBX that is sending a +, you should be able to easily modify the incoming rule to drop the + sign (as your rule is most likely explicitly adding a +)
3. Use an MSPL script to re-route incoming calls to the appropriate auto-attendant.

I've confirmed that this behaviour is by design.  I've brought up these cases as an example to the proper people, so maybe we'll see this changed in a future release.  

Configuring Lync for External Access

Out of all the posts I've made on this blog, the one post that gets the most page hits and has generated the most comments is my post on Lync External Web Services without Reverse Proxy. Obviously, there are a large number of users that don't want to deal with putting in a reverse proxy solution such as ISA or TMG.

I always recommend that companies do use a reverse proxy instead of going direct to the front-end, simply because its more secure.  Opening up any domain-joined server to the Internet directly is risky, but as long as the company understands the risks, I will configure Lync to work without a reverse proxy.

The majority of comments on my aforementioned post are questions around which DNS names point to what, and what ports to open to where.  This post will attempt to clarify how to configure Lync for external connectivity by using a simple example with a single Standard Edition Lync front-end and a single Lync edge server.  This is the minimum number of servers required to provide all Lync functionality, and is the most likely configuration for a lot of small companies with limited resources.

The Lync team has done an admirable job of simplifying what has typically been a complicated install process.  The Topology Builder and the Deployment Wizard make it so that complex Lync installations can be done with relative ease.  However, I have found that administrators get confused fairly early in the deployment process and if things aren't done right, problems will arise later.

Web Services URL
Imagine a small company called Contoso (yes, original, I know).  Their external web presence uses contoso.com and their internal Active Directory domain name is contoso.local.  They are in the initial stages of their Lync deployment and are using the Topology Builder to configure their deployment.  As with a lot of administrators, rather than spending days reading the reams of documents around Lync, they have decided to dive right in.  Things go well using the Topology wizard, and most things are clearly explained and the admin can click Next with confidence.  They set the SIP domain to contoso.com and the front-end server name to FE.contoso.local. 

However, once they get to the Specify the Web Services URL screen, things will be set incorrectly if they accept the default and click Next.

The Web Services URL is a hidden URL used to direct Lync clients to the proper place to download address book files, meeting content and other things.  This connection is done via HTTPS.  Internally, the client uses the internal FQDN of the server (FE.contoso.local), but externally, they will need to use a publicly accessible URL.  Since contoso.local is not a publicly accessible domain, they should use contoso.com.  It doesn't really matter what the URL is (clients never see this), but I will use LyncWeb.contoso.com in this example.  For deployments with multiple front-ends and/or directors, I would use something a bit more descriptive like LyncFE1.contoso.com.

Edge Configuration
Now, with that set properly, the administrator can continue on to the edge configuration.  The FQDN of the edge pool should be something like Edge.contoso.local, but it could really be anything.  The next critical thing is the external FQDNs.  Again, since clients need to be able to access this URLs externally, it must be a publicly available URL.  With the edge, you can either use a single URL or 3 separate ones for the Access, Web Conferencing and A/V URLs.  I recommend using 3 separate URLs if you have the available external IP addresses.  If you elect to use a single URL, you may have A/V issues  with companies that still use OCS.  In this imaginary case, we used SIP, WC and AV (all contoso.com).

If you are NATting your edge server (and you selected The external IP address of this Edge pool is translated by NAT on the Select Features page), you will be presented with a page that will likely make you pause and wonder:

If you are using only a single IP for SIP/Web/AV, then it should be pretty straightforward what to put here.  You would put the public IP address that external users will connect to.

If you are using separate IPs for each service, then you need to type the public IP address of the A/V service.  Lync needs this information so A/V services will work reliably across the NATted interface.  I'm hoping Microsoft will make this dialog box more informative in a future release. 

Meet/Dialin URLs
Once you enter the required IP addresses and finish the wizard, you should have all that is required to install Lync on your servers.  At the main Topology Builder screen, you will notice the Simple URLs have been automatically set to https://meet.contoso.com and https://dialin.contoso.com.  These URLs are used by clients to join meetings, view dial-in access numbers and change their PINs. You can accept this default, or if you are trying to minimize costs, you can change the URLs to something else like https://Lync.contoso.com/meet and https://Lync.contoso.com/dialin.  This way, you can get a cheaper certificate without a SAN.

External Network Configuration
For all this to work, you will have to make several firewall rules and DNS entries.  Since a picture is worth a thousand words, I figure I'd summarize it with this snazzy Visio I made for a design doc for a client (click on it for a larger view).

The main points to notice is that both Lync.contoso.com and LyncWeb.contoso.com end up pointing to the internal Lync front-end server. If you follow my blog post that describes how to configure external access without a reverse proxy, you can eliminate the ISA/TMG server shown here (again, can't stress enough that you SHOULD use a reverse proxy if possible).  Everything else points to the edge server. 

Certificate requirements should be relatively self-explanatory.  One exception is the internal SRV record.  You will notice that I used contoso.com instead of contoso.local for both the SRVLync clients will automatically query for an SRV record for contoso.com, but by default will reject the connection if the SRV record points to a different domain (ie. contoso.local).  You can override this with a registry key, but its likely easier if you create a FE.contoso.com A record (and add that name to the front-end certificate). 

Hopefully, this post will clear up the questions that often come up as a result of my Lync without a reverse proxy post.  If not, please let me know in the Comments section.