Sunday, March 13, 2011

Route International calls to an alternative Workflow (MSPL)

I ran to very interesting case the other day. Someone asked on the Lync forums if there is a way to examine the Caller ID and direct the call to either native language prompts AA/RGS or English one. My first reaction was – yeah, you can do that on the gateway. But what if we do not use gateway? It is highly unlikely the SIP Trunk provider will re-program their softswitch for a single case…
Last year I was experimenting with Microsoft SIP Processing Language (MSPL). In fact, the Edge Server federation routing is driven by MSPL scripting and so, MSPL would be a good candidate for our test. Information about MSPL can be found here.

Prerequisites:

Our native language AA E.164 number: +14785550000
Our English AA has sip-uri: English_AA@domain.tld (that is, you are not a Canadian, where I’ve heard they cannot decide what to be played first – "La Marseillaise" or “God Save the Queen”…

There are five steps involved in our example (script):
-               - Get the Caller ID

 
-               - Examine if we don’t have REINVITE


-               - Examine if the call comes via the Mediation Server

 
-               - Examine if the call is for our Auto Attendant / Workflow and check if the Caller ID begins with “+31” (native for Netherlands) and if Yes, proxy the request to the original destination (native language AA)


-               - If not (+31), redirect the call to alternative AA. ***Note that you cannot redirect to DID. Looks like MSPL supports “302 Moved Temporarily” only to sip contact…


The entire script can be downloaded here.

Steps to install and enable the script.
Download the script to “C:\inetpub\wwwroot” on your Lync FE server. Open the text file with Notepad, make the changes to reflect your environment and save it.


Change the extension from “.txt” to “.am”



Open Lync Server Management Shell and run the following command:

New-CsServerApplication -Identity "Service:Registrar:your_fe.domain.tld/AltRGS" -Uri http://your_fe.domain.tld/AltRGS -Critical $False -ScriptName "C:\inetpub\wwwroot\AltRGS.am" -Priority 1

…where “your_fe.domain.tld” is the Fe server you registering the script-only application.

Verify that the script appears in Lync CP (on second position, after “ClientVersionFilter”). You might need to refresh once.


Highlight the line with our script and select “Enable application” from Action menu.


The application is now enabled.


Wait a minute and check Lync log for this event:


Now make a call and observe the behavior.

***It is very important to make sure how exactly your provider passes the Caller ID (i.e. FROM header). Mine, for example, sends 10 digit numbers – NPANXXYYYY and so, I cannot actually deploy it in production, but hey – we don’t have Canadian clients neither…


7 comments:

Anonymous said...

Thanks for sharing MSPL script.
Do you have any kind of other implementations of MSPL scripts. If you have can you please post?

Thanks,
Suresh.

Drago said...

I did some experiments back in 2010. See this post: http://www.lynclog.com/2010/02/distinctive-ring-tone-with-ocs.html

MSPL is very cool, but not so flexible. I just dream for the day I will have time to buld an UCMA application...

Anonymous said...

Hi,

the link for the script is broken
Is it possible to have it ?

Thanks

Drago said...

The link is now fixed.

Stephen said...

Hello, and thanks for this link.

I tried it but can't make it work.
I've got :
- a Lync 2013 standard edition server
- a lync client user.2@poclync.fr : +33123456012
- a lync client user.9@poclync.fr : +33123456019
- a lync client user.7@poclync.fr : 33123456017
I used the script, changed the 4 fields so that when I call +33123456019, from user.2@poclync.fr, it is supposed to call user.7@poclync.fr but it doesn't ring neither on user.9 nor on user.7, I just can hear some bips when calling.
Here is the 302 SIP message I get:

03/07/2013|09:38:16.537 194C:738 INFO :: Data Received -15.129.22.236:5061 (To Local Address: 16.17.54.17:60505) 592 bytes:
03/07/2013|09:38:16.537 194C:738 INFO :: SIP/2.0 302 Moved Temporarily
Authentication-Info: TLS-DSK qop="auth", opaque="14019B7C", srand="B49CDE13", snum="23", rspauth="1176018802d1e1dd9889dee9b73f288315ffe643", targetname="HPFE01.poclync.fr", realm="SIP Communications Service", version=4
Via: SIP/2.0/TLS 16.17.54.17:60505;ms-received-port=60505;ms-received-cid=5ABE00
From: ;tag=af4f24fabc;epid=a5616385db
To: ;tag=2632A9FBED2D38C4F7E3833B5A9D83A7
Call-ID: 299dd2c5abbf48aab3b0657ab0a9ff70
CSeq: 1 INVITE
Contact:
Content-Length: 0

It is changing the "Contact" field but the "To" field stays on user.9, and the call isn't forwarded to user.7.

Is there something I did wrong?
Thanks,
Stephen

Drago said...

Stephen,

The concept here is to examine if the Caller ID begins with specific country code and process the call based it. In the screenshot we see that “if the ordinate caller ID begins with +31”, the call will be moved to alternative Auto Attendant…

What is that you are trying to achieve?

Stephen said...

You mean that the call will not be processed to +14785550000@domain.tld but to intl_AA@domain.tld, right?
I'm trying to change the header so that a call from user.2 in destination of user.9 goes to user.7.