Strip “+” from RequestURI - Lync 2010

Recently I ran to interesting case – a colleague from another organization uses SIP Trunk provider who does not “like” E.164 number format, thus had problem with outbound calls and Lync user Caller ID presentation. While stripping “+” is now made easy with the new “Trunk Configuration” feature in Lync…

***Note the simple RegEx. Because Lync uses E.164 format, the number will always begin with “+” and we remove 1 “digit”, thus the number sent in TO header to the trunk/gateway will be non-RFC 3966 compliant.

...the problem was that while we sent non -RFC 3966 compliant TO header, FROM header still contains "+": FROM: "Drago Totev"<sip:+14785550001@fe.drago.local;user=phone>;epid=754CB7883F;tag=48b2223f97, and since the provider cannot handle it, as a result, the called party sees "Anonymous" as Caller ID.

Fortunately, Lync Management Shell cmdlet “Set-CsTrunkConfiguration” can resolve this issue.

First, we run “Get-CsTrunkConfiguration”. In this example, because I have not created new trunk, only the default – Identity “Global” is presented.

***Note the parameter “RemovePlusFromUri” is currently set to “False”. It is important to understand the fact setting this to “True” will force Lync to convert ANY E.164 in the RequestURI header to non-RFC 3966 compliant.

In the case above, we run “Set-CsTrunkConfiguration -Identity "Global" -RemovePlusFromUri $true”

Now my FROM header is non-RFC 3966 compliant.

FROM: "Drago Totev"<sip:14785550001@fe.drago.local;user=phone>;epid=754CB7883F;tag=4

Lync 2010 Deployment Guide (Edge role with 3 IP addresses)

Now that I have verified Edge configuration with singe IP address, let’s look now a configuration with three separate IP addresses would look like.

***One so misleading message! It should read “If the external IP address of the AV interface of this pool is translated by NAT…”

***Because we will use unique IP addresses for each service, we can safely leave the default ports here.

***Alert! This is the MOST often omitted OR misunderstood part. It should read “Because the external IP address of the Edge’s AV interface is translated by NAT…”. Here we will enter the Public routable IP address which will be mapped to the internal IP, assigned to AV service.

 

Looks good and so I can proceed with the steps described in earlier posts to publish the topology, expert it to .zip file, import it to my edge, configure the firewall, and make the changes necessary in my public DNS.

Lync 2010 Deployment Guide (Verifying Edge functionality)

To check our Edge functionality, first we must enable at least one account for External Access and Federation.

In Lync Control Panel, we will modify the Global External Access Policy:

 

***Since this is a Lab, I will not enable “Communications with Public Users”.

Next, I will modify the Access Edge Configuration to enable Federation and Remote user Access.
 

Because I modified the Global policies, my two test users are now automatically enabled for External access and Federation.

I will not cover the networking side – this is job for the network admin. However, there are few things to remember:

1.       We elected to use single public IP address. Because of this, our SRV records must be as follow:

a.       _sipfederationtls._tcp.drago.ws pointing sip.drago.ws on port 5061

b.      _sip._tls.drago.ws pointing to sip.drago.ws on port 5061

At this point, our external clients will now how to discover our edge and sign in and our partners how to discover and federate.

Let’s check what http://recite.microsoft.com will say:

Because this all test were successful, let’s try to establish IM session with federated partner:

…start desktop sharing…

…start an audio call from within this session...

…and also add video.

All basic functions on our Edge are now verified and I have to think what would be the next post...

Lync 2010 Deployment Guide (adding Edge Role - part II)

It is now time for the Big Bang – the actual Edge deployment.

 

On the previous step, we added the new Edge to the topology and published it. The assumption is that our Edge server is on the perimeter network and so, we must export the topology from our FE and transfer the file to the edge somehow.

I will run “export-CsConfiguration -filename C:\TopoExport.zip” from Lync management shell.

...and transfer the file to the Edge

Next we run the setup.

Because our Edge is not a member of Domain (i.e. CMS cannot be read, we must point to the .zip file moved to this server on the previous step.

Have patience – SQLExpress installation takes time (good time for trip to the fridge).

Ah, certificates. A major pain point.

Edge server must have two certificates – one with the CN = FQDN of the machine, assigned to the internal interface (edgeint.drago.ws in our example), and one with the FQDN we entered earlier in topology builder (sip.drago.ws in this case). Note that because we are building our Edge server with ONE Public IP address only, all three roles will use “sip.drago.ws” and so, I need certificate for CN = sip.drago.ws – i.e. no SAN is needed.

First, I will create CSR (Certificate Signing Request) for the internal interface. Later I will use it to sign it from my internal Domain Certificate Authority.

Here I will add sip.drago.ws (our sip domain)

Open the CSR with Notepad and copy the content.

Go to your AD Certificate Authority and request certificate signing.

Paste our request in the “Saved Request” field and select “Web Server” from “Certificate Template” list.

Download and save the certificate.

***Note that I have already save the Domain Root Certificate. Edge is not a member of domain and so, the Root CA must be imported manually.

First, install the Domain Root Certificate

Proceed with the import of our certificate

 

***Note that because we created the CSR, the Private Key is stored locally (we just asked to be signed).

 

 

Our internal certificate is now assigned.
 

Perform the steps above to generate CSR, have it signed and assign it to the Public interface.

***This certificate must be signed from Public CA in order to have fully functional federation capabilities.

We are ready to start the services now.

Next step will be to verify the functionality of our Edge.