VCS X7 B2BUA to Microsoft Lync integration

[mgildberg]

I am trying to integrate our Cisco VCS Control and Microsoft Lync server but cannot get it to work.

I made my first attempt some months ago using VCS X6.1 and the corresponding deployment guide. The configuration on the Lync server was also made following the X6.1 guide.

Now I have upgraded to VCS X7.0.2 to try the new B2BUA but I am still having problems. The configuration seems pretty straight forward but there is obviously something I have missed. I just can't see what it is.

The steps for configuring the Lync server are slightly different in the X7 deployment guide compared to X6.1. Is it enough to just change to port for the VCS application on the Lync server from 5061 to 65072 when upgrading the VCS to X7 and switching to the B2BUA?

The status of the B2BUA on the VCS is Connected, and the status of VCS and OCS/Lync is both Alive.

When I log the calls I can see that the VCS and Lync are communicating but the call attempts end with the following errors:

Calls from a Lync client to a video endpoint: Call Rejected / 400 Bad Request

Calls from a video endpoint to a Lync client: 405 Method Not Allowed

Does anyone have an idea to what might be the problem?

Thanks.

/Mads

[awinter2]

Hi Mads,

regarding upgrading from X6.1 to X7.x and switching to B2BUA, there is a separate appendix in the deployment guide.

When you see '400 Bad request' in calls from Lync towards a video endpoint, that could indicate that the SIP INVITE has not been translated from Microsoft-SIP to standards-based SIP, and the most common cause for that (When using B2BUA) is that the INVITE arrives on the VCS from an OCS peer which has not been added as a B2BUA trusted host, so make sure to check that all Directors/FEP's which might be sending calls to the VCS has been added as trusted hosts.

For the '405 Method not allowed' response for calls from video endpoints to Lync, I assume that these calls are placed using H323? For interworked calls from VCS towards OCS/Lync, the VCS will send a SIP INFO request to check if the called alias exists on the OCS/Lync side. MOC/Lync clients support the INFO method, but I have seen in a few cases where third-party SIP software is in use on the Microsoft side that the VCS receives this type of response when the 3rd party SIP software doesn't support the INFO method, so you might want to look further into which UA is actually sending this response to the INVITE, as I doubt that this response comes from the Lync client.

You can quite easily find this information by starting a diagnostics log on the VCS with the 'Network' flag set to 'DEBUG', once the logging is active set up a call from a video endpoint towards Lync. When you see the 405 response simply stop the logging, download the log and search for the 405 response. The response message will most likely contain a 'User-agent' header which will tell you exactly which UA generated this response.

I would also expect that if you place the call from the video endpoint as SIP rather than H323, it will most likely work.

Hope this helps,

Andreas

[mgildberg]

Thank you for your reply Andreas,

I had missed the appendix about upgrading - thanks.

We have two FEPs and they are both in the trusted hosts list. The INVITE is correctly received but the VCS Control forwards the INVITE to our VCS Expressway through the traversal zone. The Expressway responds with a ‘404 Not Found’. The endpoint is registered locally on the VCS Control and the search rules work fine when I test them with the Locate tool, so I don’t understand why

I have installed a third party Lync client on my smart phone and if I use that to call the video endpoint the search completes correctly on the VCS and the call is passed to the endpoint. However the call is not established; presumably because we do not have an Enhanced OCS collaboration option key.

Yes, SIP calls from an endpoint to a Lync client work fine. It is H323 calls that fail. In the Lync FEP server log the error is ‘481 Call Leg/Transaction Does Not Exist’. Then the FEP routes the call to another Lync server on port 36001. That fails with error ‘405 Method Not Allowed’ which is what is returned to the VCS.

Can you suggest anything else I might try?

/Mads

[awinter2]

Mads,

you mentioned initially that for Lync -> VCS calls you see a '400 Bad request' response, while in your latest reply you mention that the INVITE arrives at the VCS, gets proxied to the VCS-E which responds with 404 not found. Where and when do you see the 400 Bad request? Which user agent generates this response, the VCS or some endpoint?

For VCS -> Lync calls, what type of Lync server is the one which responds with 405 Method Not Allowed? What is the User-Agent header set to for this response? The 481 Call/Transaction does not exist is a legitimate response and the one we want to get in return for our INFO request, and the fact that Lync chooses to respond with 405 rather than 481 causes a problem with interworking.

Regards

Andreas

[mgildberg]

Hi Andreas,

Sorry for not getting back to you sooner.

Calls from Lync to the video endpoints are now working. There was a static route in Lync pointing the video domain to port 5061 on the VCS instead of 65072.

The Lync server responding with 405 Method Not Allowed is an application server handling voice calls.

The User-Agent header in the 481 message is ‘UCCAPI/4.0.7577.314 OC/4.0.7577.314 (Microsoft Lync 2010)’ and Peer is the ip-address of the Lync client.

The 405 message does not have a User-Agent header but the peer is the Lync application server.

I have looked through the configuration and debug logs with one of our Lync consultants. He believes that the problem is caused by the VCS initiating calls originating from H323 endpoints with an INFO message instead of an INVITE. Because the call has not been properly established the Lync client responds with 481 Call Leg /Transaction Does Not Exist.

Regards,

Mads

[awinter2]

Hi Mads,

the 481 response is actually the desired one for the VCS, with a 481 response we know that the AOR exists and is registered (As opposed to the 404 Not Found response we would see if the AOR is not registered), and the fact that Lync chooses the 405 response over the 481 is actually what's causing the call to not get set up. I'm not sure if Lync can be configured to respond with 481 rather than 405, but that would be the way to solve this issue.

The VCS is correctly sending an INFO request for the called destination on interworked calls, that is our way of 'probing' whether or not the called alias is registered on the Lync/OCS side.

Another workaround would be to place the call with SIP rather than H323 to begin with, as that will omit the INFO request and dependency on 481 response from Lync.

Hope this helps,

Andreas

[mgildberg]

Hi Andreas,

You were right. The 405 response is generated by a third-party application on one of the Lync servers. If I stop the third-party service on that server, calls from the video endpoints go through to the Lync clients without errors.

Thank you very much for your help, detailed explanation and trouble shooting.

Regards,

Mads

[awinter2]

Mads,

for future reference, would you mind explaining what type of third-part application this is?

Thanks,

Andreas

[mgildberg]

The product is called TeamView Mobile Status for Lync and is made by a company called Scantalk. It is used to receive mobile phone status from the mobile operator and update the user’s status in Lync accordingly.

In our deployment TeamView runs on a separate Lync application server and the service communicates with the Lync frontend servers on port 36001.

I don’t know why the INFO requests intended for the Lync clients are forwarded to the application server at all, but I have contacted the developer to have them look at the problem.

Would the correct response from the TeamView service also be 481?

Regards,

Mads

[awinter2]

Mads,

the 405 response from the Mobile Status application simply means that this application does not consider SIP INFO to be a valid method for the address specified in the request-URI. The 405 response should also contain an Allow-header with a list of the methods which the application considers valid for the given alias.

If the application did consider SIP INFO as a valid request, the application should respond with 481 since we are sending an INFO request for a non-existing transaction.

Regards

Andreas

[muazam ali]

Hi andreas,

i am integrating VCS running software 8 and lync 2013 for the first time, can you please guide me how the integration works between both and what configuration i have to do on VCS and LYNC