Planning for Mediation server Role

Mediation server Role plays a crucial role in Lync/SfB system for establishing a call between a Lync/SfB and PSTN or any VoIP system.  There is a Microsoft TechNet article which discusses about the Capacity planning for Mediation server Role.
 [ MS articles

https://technet.microsoft.com/en-in/library/gg398399.aspx  

https://technet.microsoft.com/en-us/library/gg615015.aspx ]. 

However, after going through it i felt that the information provided in the TechNet article is not conclusive. So before we have the Design work shop for the SIP Trunk I went through some of Channel 9 videos regarding the Enterprise Voice features found that there are several important points to consider while planning for Mediation server Role.  So, we will discuss about  some scenarios where Media Bypass can be used and CANNOT be used.

Media Bypass:

One of the main question people have is, can we reduce the number of servers required for the Mediation server role if we have Media By pass enabled for a network.

What is Media ByPass?

Source: https://technet.microsoft.com/en-us/library/gg412740.aspx

Media bypass refers to removing the Mediation Server from the media path whenever possible for calls whose signaling traverses the Mediation Server.  Media bypass can improve voice quality by reducing latency, needless translation, possibility of packet loss, and the number of points of potential failure. Scalability can be improved, because elimination of media processing for bypassed calls reduces the load on the Mediation Server. This reduction in load complements the ability of the Mediation Server to control multiple gateways. Picture from the TechNet article about the Media bypass.

Media By pass is a feature which when enabled will allow the Agents to talk directly to the certified Gateways (bypassing the Mediation server). However, if Media By pass feature is not enabled or not configured for the network, then all the media traffic has to traverse Mediation server.

Media By pass is a great feature and it significantly reduces the load on the Mediation servers and improves the call quality. However, it is good to understand the certain scenarios where the Media Bypass is irrelevant. It is also important to consider the following scenarios (where though the Media By pass feature is enabled) but it will not work even if a Lync/SfB call is made from a Network where Media Bypass is enabled.

Features  / applications / devices  which does not work with Media Bypass:

•  Mobile devices does not use Media By pass. So if you have several thousands of Mobile devices in your infrastructure, then the all the Media traffic has to go through the Mediation servers.  Hence planning for Mediation servers needs to consider this situation too.

•  Response Group does not use Media By pass. So if you have a user calling a Response Group number then though the Calls are originated from a network segment where Media By pass is enabled, the Media Bypass feature will not be used and the media traffic will be going to and from the Mediation server.

•  If you have any trusted third party application like for Contact center solutions      then again Media bypass will not work.

•  CAC issues:As per TechNet artcile [source: https://technet.microsoft.com/en-us/library/gg413028(v  =ocs.15).aspx ]  If you have already optionally configured call admission control (CAC) note that the bandwidth reservation performed by call admission control does not apply to any calls for which media bypass is employed. 

• The Media Bypass feature does not work for the  Dial in Conferencing scenarios.

• The UCWA Applications and AV MCU does not support Media Bypass.

I hope  this post was intersting and please share your views. In case, if you feel that i have missed any other points to be considered while planning for Mediation server Role please share.

How to find the number of devices a user is Logged into using Lync/SfB Client logs ?

Recently, we had issue reported regarding the trusted application. While troubleshooting the issue, we had a requirement to understand the number of devices on which a user is logged in.

In our client environment we are using a third party Contact center solution as a trusted application. It was a kind of weird one, where the callers of a Contact center number where complaining they are not able to reach any agents. Whereas, the agents complained us that they are NOT receiving any calls.  

While we were discussing this issue with my colleagues we had a question, can we find the total number of registered end points for a sip account using the Lync/SfB client logs. That was a very good question. Because we have seen some third party applications actually providing the details like a user with a sip address say UserA@uctest.com has signed to 3 devices. So,  it was interesting to find out how a third party reporting applications can get the list of  devices to which a users had signed in to ? So, I tried to understand if there are anyways to get this information from the client/server  logs and understand the number of End points on which a user is logged into. 

NOTE:

I am writing this article in order to help those administrators who don't have Monitoring/Reporting solution available at their environment. Since, some Lync/SfB environment do not have the Monitoring server role or any third party Monitoring/Reporting solutions. 

There are two ways  to find out the list of get this information one using the Server logs and the other using the Client logs.

Solution #1: From the Server  logs

My first suggestion was to enable logging on all the Lync/SfB FE server and then make a test call to that the end point. Since Front End server will fork the incoming calls to all the registered end points we will get multiple 180 Ringing SIP Response if a user has signed on to multiple devices. 

So, if a user is signed on two devices like computer and a mobile phone, then I will get two 180 Ringing in the FE server logs.  Though this is helpful, this requires little bit of time and effort (to collect the logs on all the Lync/SfB servers during business hours will end up generating more logs). Moreover, if you have 10 servers in a pool then the amount of logs generated and analyzed from all the servers in the Lync/SfB FE pool will require more effort.

Solution #2: Using the Lync/SfB Client logs

But later, I realized that there is much better way to get this information and with less effort. All you need to do is, ask the user is to Sign in to another computer once again and provide the Lync/SfB client logs.  So, is it possible to get the find the number of devices on which a user is logged into using the recently gathered Lync/SfB client logs ? The answer is Yes J

I will explain this with an example. I singed into one computer, say Computer #1, then a mobile device. Later,  I singed to another computer,  Computer #2. So, now I am signed into my Lync accounts from 2 computers and one mobile client, so I have multiple registered end points for my sip account.

I collected the Lync client logs from the second computer Computer #2 (this is the latest computer on which I signed in). Then, I looked for the response 200 OK for the SIP REGISTER packet (In this 200 OK response there are three Contact: headers in it.

NOTE: You have to ask the user to Sign-in to Computer once again and then collect the client logs.This is a very important step, if you skip this step then you might not get the correct details.

07/04/2016|21:46:11.303 1834:1838 INFO  :: Data Received -10.1.92.181:5061 (To Local Address: 172.24.41.159:59266) 1640 bytes:

07/04/2016|21:46:11.303 1834:1838 INFO  :: SIP/2.0 200 OK

ms-keep-alive: UAS; tcp=no; hop-hop=yes; end-end=no; timeout=300

Authentication-Info: TLS-DSK qop="auth", opaque="F8084D77", srand="468DD1A4", snum="1", rspauth="2891b96442e3e7c7af0ef004a7babb9063fd48ba", targetname="FE01.uctest.com", realm="SIP Communications Service", version=4

From: "SOMASUNDARAM Yogesh"<sip:yogesh.somasundaram@uctest.com>;tag=cc0f68ce68;epid=6c1409c121

To: <sip:yogesh.somasundaram@uctest.com>;tag=99C17913B0B71378DCADCD792D587E29

Call-ID: d8060b5307124a1787e243e9ff587edc

CSeq: 12 REGISTER

Via: SIP/2.0/TLS 172.24.41.159:59266;ms-received-port=59266;ms-received-cid=39F2FF00

Contact: <sip:172.24.41.159:59266;transport=tls;ms-opaque=61fe165797;ms-received-cid=39F2FF00>;expires=7200;+sip.instance="<urn:uuid:aa39a11c-7a67-5d34-a985-7418ff06799c>";gruu="sip:yogesh.somasundaram@uctest.com;opaque=user:epid:HKE5qmd6NF2phXQY_wZ5nAAA;gruu"

Contact: <sip:FEPOOL01.uctest.com:5088;ms-fe=FE02.uctest.com;transport=Tls;ms-opaque=43b8303fcf7aa2b4>;expires=1295940;+sip.instance="<urn:uuid:aad6c08c-7dd8-5733-8b9e-cdcb8b0a1827>";gruu="sip:yogesh.somasundaram@uctest.com;opaque=user:epid:jMDWqth9M1eLns3LiwoYJwAA;gruu"

Contact: <sip:172.24.41.172:50900;transport=tls;ms-opaque=353dd698df;ms-received-cid=3A42B400>;expires=6311;+sip.instance="<urn:uuid:b9cc1792-d0cf-51ae-8c7e-6a0504a8b81c>";gruu=sip:yogesh.somasundaram@uctest.com;opaque=user:epid:khfMuc_QrlGMfmoFBKi4HAAA;gruu

If you have a mobile client then you will find that the Contact: header has the  FE pool name with the port number 5088 (unlike the IP address of computer).  This is because, the UCWA sip Listening port is 5088. In order to find this port number, on a FE server if you run the Get-csService | Fl *UC*  this will let you know that the UcwaSIP PrimaryListeningPort  is 5088.

So with the Contact header field present in the 200 OK, we can confirm that a user is logged into two different computer and one mobile client. And there is no need to collect the logs from the FE server’s logs in order to find this out J

Hope you find this information helpful.

NOTE:  I am sure, there are many ways to get his information and it is possible from SQL database too. However, if you are not having access to write a SQL query (like me) then it is easy to check the Client SIP logs rather than writing a SQL query. 

 
Blocking incoming calls from a PSTN number to Lync extension permanently (from AudioCodes PSTN Gateway)








Today we got a complaint from a user that he gets calls from a specific PSTN  number (+xxxxxxxxxx) repeatedly everyday and hence the user  wanted  to block any calls from that number.






Unfortunately, there were no much help in AudioCodes forum or Microsoft Forums related to this topics. Some Forums were suggesting to use MSPL script to block such calls those details are mentioned below, (you may go through if you find it interesting).




The MSPL script will block the calls from a particular number reaching the Lync end point.




https://gallery.technet.microsoft.com/MSPL-Blocking-Calls-on-e6d52de9 [ To download the MSPL script ]

https://blogs.technet.microsoft.com/uclobby/2014/07/31/calleridblock/ [ Step by step guide to use the MSPL Script on the Lync / SfB servers ]



https://blogs.technet.microsoft.com/uclobby/2016/04/01/missed-call-notification-when-the-call-is-blocked-by-calleridblock-mspl-script/  [ To block the Missed call notification ]





However, in our client environment since we were using several trusted applications, implementing these chances on a Critical application like  Lync servers would take several weeks (for tests and approvals).

So we were trying to find a way to block the  PSTN number at the PSTN Gateway end.

In order to replicate the issue, i tried to block all the calls to my Lync  extension from my mobile phone number.  So, first i tried couple of manipulations like creating a Rule in the Gateway such that the calls from a Number to the user's extension are forwarded to Trunk Group #  20 (which is not available in the Gateway). However the calls from my mobile number were still hitting my Lync extension (not sure how it gets a different route though).

So, i worked with my colleague (Will Talbot) on this topic. He suggested  to create a Rule for Destination Number Tel -->IP in the AudioCodes gateway.

Logged in to the AudioCodes  PSTN Gateway.

 Configuration section --> VOIP  -->   GW and IP to IP --> Manipulations --> Destination Number Tel to IP section.

The Rule my colleague (Will Talbot) suggested was to strip all the digits and add athe prefix as all 0's. We tried the rule and test it.

It worked immediately !! All calls from my mobile number to my Lync Extension were blocked successfully.  So I followed the same steps in order to block the annoying calls from the actual PSTN number to the User's Lync extension :-)


Hope this post is  useful for someone who is struggling to block all calls from particular (annoying) PSTN number to a Lync Extension.

AudioCodes and Lync Issues (488 : Invalid Incoming Gateway SDP)

Hello Everybody,

Today I just completed fixing an Lync server 2013 / Skype for Business 2015  and AudioCodes related issue and I am happy to share this experience so that it would help someone in future !

Issue:

Users are  not able to receive inbound calls from the PSTN to their Lync Extension. For this same customer we did the Lync Enterprise Voice project few years ago. The calls were working fine for years, but the customer complained that the calls started failing recently. 

Error: From the Gateway logs we got the following message. It looks like the Mediation server is  rejecting the SIP request.

SIP/2.0 488 Invalid incoming Gateway SDP: Gateway did not offer SRTP Keys which is required by Mediation Server.

Troubleshooting:

Since the Error had SRTP Keys, I first doubted it to be  a certificate issue. Because normally in a branch site there are possibility that the administrators not renewing the certificates once it is expired.

Checked  the Gateway certificates for its validity,  and found that the certificate was valid for another 200 days.

So tried to assign the extension of test account to my account, started testing and collected the Gateway logs.

On checking the SIP error message from the Gateway logs it was clear that the Mediation server is rejecting the connection because it is expecting SRTP keys from the Gateway. Check the SIP Message  Flow diagram below.

SRTP is used for the Media. So checked the Media Security configuration on the AudioCodes Gateway.

Logged in to the AudioCodes Gateway.  Configuration (Full) à  VoIP à Media à  Media Security Page.

The setting the Media Security was set to Disable.  So selected the DropDown box and then Set the option to Enable and did a Gateway Reset (in AudioCodes - Reset is required when you make changes to the Gateway Configuration. It is like Rebooting the Gateway for the new Configuration changes to take effect).

Once the Gateway came back online, I tried to make some test calls and it worked fine. I am providing the SIP ladder diagram of the working scenario below.

Thank you for reading this post and hope it was helpful !