There are many Lync installations out there in a need of a 3rd party switchboard. In some of these installations the switchboard number is non-existent for the Lync environment (it is no more than a voice route to a pstn gw through a mediation server). And if we do nothing, the incoming call to the switchboard will be rejected by the registrars as "no user configured with this number" aka user not found.
I found a "dirty way" of fixing this, by creating a unassigned rule for it. Catching the number, sending it (targeturi) to a new destination and then translate it to the correct number on the way to the switchboard application server (through a pool trunk).
The problem with this, is the way it has to be set up, with several translations and rewrites. It became rather difficult to troubleshoot.
My solution to the challenge turned out to be to create a new server application, run before any other app, to catch the call and reroute the sip call to the trunk directly. And this is how I did it:
First of all, I downloaded and installed the "Lync server 2010 sdk" (found here) on the Lync frontend servers. And then I tried to my best to understand the documentation (located in the sdk installation, or online found here).
As it turned out, I was to fresh in the game to understand every little detail I had to think of, and needed some examples to work from. After doing some searches in forums and blogs related to the subject, I finally stumbeled upon a script created for OCS 2007 R2.
I took the script, and modified it to suit my needs, and Lync's way of addressing trunks (not mediation servers) in the reroute statement. It turned out to be quite easy, and I would like to share the script with you.
First we have to create the manifest, and describe what we are looking for. This is done by using standard methods well described in the documentation. One of the important things to notice, is the appURI which has to point to an existing dns entry. The final part is case sensitive, and must match what you later use in Lync Powershell when creating the application. The other thing I want to highlight, is the "requestfilter" which has been set to inspect the "INVITE" element.
Next we look through the sip messages, and try to filter out those messages which do not concern us. Things like "ignor none sip messages, ignore re-invites and ignore calls from other servers.
Then, we have to tell the application what to look for:
And finally we do the lookup and reroute to the static information. A quick note about the new to sip uri. This is set up to route directly to the PSTN GW defined as the destination in the topology, with both port and name of the designated mediation server (to save lookup time).
With the script all finished, save it to disk on the frontend server, and note the path.
Next, it's time to add the application to the frontend server. This is done by running the new-csserverapplication cmdlet (about) (note: the name here is case sensitive and must match the statement in the application manifest. I have also set the priority to 0, so it is run first):
new-csserverapplication -identity "registrar:lyncpool.customer.com/RouteExternalToAttendant -uri "http://www.customer.com/RouteExternalToAttendant -priority 0 -critical $false -enabled $true.
Finally, if the application isn't run, try to stop and start the application server through cscp. Use the SDK apilogger to verify contact and execution. Monitor the eventviewer for application compilation errors.
That should be all. As before, I have a sample script right here for you to read through.
And thanks again to my ex-colleague and friend who helped me fix this in the middle of the night.
I found a "dirty way" of fixing this, by creating a unassigned rule for it. Catching the number, sending it (targeturi) to a new destination and then translate it to the correct number on the way to the switchboard application server (through a pool trunk).
The problem with this, is the way it has to be set up, with several translations and rewrites. It became rather difficult to troubleshoot.
My solution to the challenge turned out to be to create a new server application, run before any other app, to catch the call and reroute the sip call to the trunk directly. And this is how I did it:
First of all, I downloaded and installed the "Lync server 2010 sdk" (found here) on the Lync frontend servers. And then I tried to my best to understand the documentation (located in the sdk installation, or online found here).
As it turned out, I was to fresh in the game to understand every little detail I had to think of, and needed some examples to work from. After doing some searches in forums and blogs related to the subject, I finally stumbeled upon a script created for OCS 2007 R2.
I took the script, and modified it to suit my needs, and Lync's way of addressing trunks (not mediation servers) in the reroute statement. It turned out to be quite easy, and I would like to share the script with you.
First we have to create the manifest, and describe what we are looking for. This is done by using standard methods well described in the documentation. One of the important things to notice, is the appURI which has to point to an existing dns entry. The final part is case sensitive, and must match what you later use in Lync Powershell when creating the application. The other thing I want to highlight, is the "requestfilter" which has been set to inspect the "INVITE" element.
Next we look through the sip messages, and try to filter out those messages which do not concern us. Things like "ignor none sip messages, ignore re-invites and ignore calls from other servers.
Then, we have to tell the application what to look for:
And finally we do the lookup and reroute to the static information. A quick note about the new to sip uri. This is set up to route directly to the PSTN GW defined as the destination in the topology, with both port and name of the designated mediation server (to save lookup time).
With the script all finished, save it to disk on the frontend server, and note the path.
Next, it's time to add the application to the frontend server. This is done by running the new-csserverapplication cmdlet (about) (note: the name here is case sensitive and must match the statement in the application manifest. I have also set the priority to 0, so it is run first):
new-csserverapplication -identity "registrar:lyncpool.customer.com/RouteExternalToAttendant -uri "http://www.customer.com/RouteExternalToAttendant -priority 0 -critical $false -enabled $true.
Finally, if the application isn't run, try to stop and start the application server through cscp. Use the SDK apilogger to verify contact and execution. Monitor the eventviewer for application compilation errors.
That should be all. As before, I have a sample script right here for you to read through.
And thanks again to my ex-colleague and friend who helped me fix this in the middle of the night.