Lync and ‘telephone-event’ in the sdp

An interesting little nugget in the nice new Lync client now it has the (love it or hate it) dial pad.

When an incoming SIP Invite sdp offer includes the ‘telephone-event/8000’ payload (also known as RFC 2833 out of band DTMF) the UI looks like this:

When it doesn’t, it looks like this:

Notice that the dial pad button has now disappeared.

Me, Myself and I

Cool – testing PIC making a call between Lync and Windows Live messenger on the same PC  with two webcam’s.

Lync reverse proxy using IIS ARR

Disclaimer : this is part of my Lab install series of posts, it works for me in my lab with a  small number of users but is neither a recommended or supported topology (AFAIK).
I have Lync standard edition server with mediation on the front end running in media bypass mode, Lync Edge server and Exchange server 2010 running on a single server with all roles.
I have decided to use IIS ARR + URL Rewrite as my reverse proxy for Exchange OWA, web services, etc and Lync reach client and web services all on my Lync Edge server. I did this because its already internet facing (and therefore ‘at risk’) and I figured its better to keep machines like this at a minimum. It is also the only machine not domain joined and has very few permissions on my network. Of course I could have setup ISA / TMG / whatever, but I want to focus on building software, not maintaining infrastructure.

1. Ensure IIS and .net are installed.
2. Download & Install ARR (includes rewrite).
3. Add a binding for your certificate (As this is on my edge server and I use the same certificate for both SIP and HTTPS I already have it installed on the machine)
4. Setup server farms for Exchange and Lync
1. 
2. (select advanced settings, choose ports 8080, 4443 – which point to the external bindings on the front end server))
3. (Choose Yes if you see this)
4. (double click routing rules)
5. (ensure URL rewrite is checked and optionally SSL offloading – depending on your bindings on the target server you may need this checked)
6. Repeat from step 4 for Exchange
7. Go to the URL rewrite configuration, either by clicking the link on the right pane on the routing rules screen in step 5 or on the main URL Rewrite icon under IIS when on the Features page for your server.
8. Modify the Lync rule as follows:
   
   Choose Using Regular Expressions and enter this expression :
   

   ((?:^dialin|^meet|^Fonts|^Abs|^CertProv|^ColabContent|^GroupExpansion|^LMStaticData|^MeetingContent|^MeetingFiles|^Reach|^RequestHandlerExt|^RgsClients|^WebTicket).*)

   
   
9. Same for Exchange with this expression :

   ((?:^owa|^OAB|^Microsoft-Server-ActiveSync|^EWS|^ecp|^Autodiscover).*) 

   Also select https protocol (depending on your bindings for exchange)
   
10. For completeness I have an OCS R2 CWA server in my Lync farm and have added a similar proxy for that too.

Now lets test

1. Go to https://yourdomain/owa
   
   
2. You should also run the tests here https://www.testexchangeconnectivity.com/
   
3. Go to https://yourdomain/meet
   (you can also create and join a meeting in outlook)
   
4. Go to https://yourdomain/reach/client/webpages/reachclient.aspx
   

Federating with everyone.

In order to use federation with OCS, OCS R2 and Lync you must obey this:

• The certificate must be issued by an approved public CA that supports subject alternative name. For details, see Microsoft Knowledge Base article 929395, "Unified Communications Certificate Partners for Exchange Server and for Communications Server," at http://go.microsoft.com/fwlink/?LinkId=202834.

This is a short list of official certificate providers :

Entrust
http://www.entrust.net/microsoft/ (http://www.entrust.net/microsoft/)

Comodo
http://www.comodo.com/msexchange (http://www.comodo.com/msexchange)

DigiCert
http://www.digicert.com/unified-communications-ssl-tls.htm (http://www.digicert.com/unified-communications-ssl-tls.htm)

Now in reality (and if you don’t need to be in a fully supported configuration) you just need a certificate that is issued back to a root certificate that you know everyone has. So assuming you might be federating with partners using OCS, OCS R2 or Lync Server 2010 we can assume their edge is running Windows 2003, Windows 2003 R2, Windows 2008 or Windows 2008 R2. So to narrow down your requirements you want a certificate that we know is installed by default on those platforms. In theory on Windows 2008 the root certificates are supposed to auto download on demand – however it seems OCS R2 doesn’t demand them, so they don’t get downloaded . Ok… so this is now quite a short (and getting shorter) list. So if you encounter weirdness that you can federate with some partners but not others then chances are that their certificate is issued by a root cert not installed in your system.

So as a certificate buyer, you really should buy a cert from an officially approved vendor. That said, after a bad experience with federation using GoDaddy certs, in my lab, I use (in an unsupported manner – as I use a single CN and don’t list any SAN’s) a RapidSSL cert from ServerTastic for $13.00 per year for a single domain cert – conveniently its issued from a root cert by GeoTrust / Equifax, which is far more prevalent than GoDaddy. I have had no issues since using this cert.

As a federating partner, if you want to expand your scope to ‘cheap’ federation partners, try installing the latest root certificate package here – after reading the warnings here .

Lync (and OCS) presence–the hard way!

So assuming that the easy way ( - the easy way is to use UCMA 3.0, see the ‘Microsoft UCMA 3.0\SDK\Core\Sample Applications\QuickStarts\PublishPresence’ sample in the SDK) is not for you for some reason – such as your implementing your own application using a 3rd party SIP stack on a non-windows platform and you don’t want to build a simple web service that does the heavy lifting for you on a windows box..
To get started you should read the dry but informative protocol spec, [MS-PRES]. And you should also review presence basics (that article is OCS, so doesn’t include the new Lync bits like location and pictures, but it’s a good overview). You will also find the Enhanced Presence Schema download handy – this consists of all the schema mentioned in the protocol specs so you can use a tool to create strongly typed objects in your language of choice as well as a help file (for windows) which is a little more digestible than [MS-PRES].

Lync Server depends on J# – are you serious? its 2010 you know!

So I just noticed that Lync Server has J# as a pre-req – this fills me with yucky feelings, Am I the only one who feels uncomfortable with a pre-req that doesn’t support the OS we are required to install to and is due to expire support long before the product itself?
I quote a few nuggets of nastiness:
From the redist download page :

• Supported Operating Systems:Windows Server 2003, Enterprise x64 Edition;Windows Server 2003, Standard x64 Edition;Windows Vista Business 64-bit edition;Windows Vista Enterprise 64-bit edition;Windows Vista Home Basic 64-bit edition;Windows Vista Home Premium 64-bit edition;Windows Vista Ultimate 64-bit edition;Windows XP Professional x64 Edition

From the J# Developer center homepage :“Product Announcement - January 10, 2007: … Visual J# 2.0 Redistributable Second Edition is targeted for release in the second quarter of 2007, with support continuing through to 2017 (5 years mainstream and 5 years extended support) on EN-US locales.”

Do UC what I See?

One of the most exciting things I saw in the Lync launch last week which really got me excited was the ProtoSphere virtual world offering from Proton Media

This is a virtual reality world application that has been in use in the life sciences industry for collaborating on scientific models for quite a while. Just recently they integrated with Microsoft Lync (for outbound audio dialing) and the potential here is amazing.

My long term vision for UC is where remote workers (which I have been for most of my career, and it seems every major corporation is trending towards) are afforded the same level of interaction and collaboration as their office bound counterparts. Within the physical space, Telepresence rooms like the Polycom OTX provide a truly immersive collaboration experience for participants in the rooms, but despite interoperability with Lync – the experience for the remote participants is still a second class citizen, and far from immersive.
http://www.polycom.com/products/telepresence_video/telepresence_solutions/immersive_telepresence/otx300.html?vid=Video_OTX300_Sexy

The next logical step of all this is to combine immersive Telpresence in the real world with a remote virtual experience – eventually of course everyone will work from home and the physical spaces will go away.
Another embodiment is for the remote worker outside fixed meetings- Microsoft Research has this – see Scott Hanselmans ‘virtual persona trolley’ / Social Proxy :


Now replace the flat screen with this spherical monitor:  http://www.globalimagination.com/products.html

Global Imagination globe screen

Now create the ultimate mobile device like this MIT creation for a true real meets virtual device.