Lync integration B2BUA and Presence

[ryan_oconnell]

Hello,

I'm trying to get presence working between Lync and VCS. I'm using the Findme methodology oulined in Microsoft OCS 2007, Lync 2010 and Cisco VCS

Deployment Guide Cisco VCS x7.1.  We are using x7.1 and we have a dedicated VCS control and a second dedicated VCSLyncGW, we are using C20 codec's running 4.2 and 5.1. We followed the guide and put all the endpoints in a sub-domain so that Lync would be able to route to VCS for endpoints that are not setup with Findme accounts.

Presence seems to work as it should for the staticly assigned endpoints, but for the findme endpoints we can't seem to get presence working. Calls will work just fine between Lync Clents and endpoints that are setup with Findme accounts.

When I go on the VCSLyncGW and look under OCS/Lync user status it shows the "findeme" uri with a Presence state of "offline" but its "registered" and "subscribed"

I made sure the Lync account was setup first, and logged into it waited 10 min's before setting up the findme account.

Any tips on how to troubleshoot?

[awinter2 · Accepted solution]

Ryan,

have you made sure to associate devices to these FindMe accounts using URI's (alias@domain)?

Could you perhaps post a screenshot of one of the FindMe accounts, showing its devices and locations?

The presence server is only enabled on the Lync GW VCS, and not the other VCS Control?

[ryan_oconnell]

Hi Andreas,

That's exactly what it was. I had Presence server enabled on both the Lync GW and VCS Control. But I turned it off on the Lync GW VCS and left it on the VCS control because I figured that's were the endpoints are registering that's where it should be. It seems to be working. Should I move it to the Lync GW VCS instead?

[awinter2]

Ryan,

when using B2BUA in combination with FindMe, it is recommended that the OCS/Lync GW VCS also has the presence server, as this is required in order to make presence aggregation for FindMe work properly.

This is mentioned in the latest OCS/Lync deployment guide:

The “OCS/Lync gateway” VCS that connects to the OCS/Lync Server must be the presence server for the SIP domain that the “OCS/Lync gateway” VCS shares with OCS/Lync server. It should also be the presence server for any other sip domains that OCS/Lync server might want to look at for presence; this limits the number of VCSs that OCS/Lync server’s presence requests will travel through.

Presence requests use up SIP resources and with OCS/Lync typically having thousands of MOC/Lync clients connected that may be requesting presence, it is best to limit the range of where the presence requests can go, especially not letting them reach VCSs that may already be heavily used for taking calls.

The “OCS/Lync gateway” must also be the presence server for the domains of all devices that are referenced in the FindMe users that register to OCS/Lync, as FindMe will only aggregate presence data for devices where their presence state is known on the same VCS as the FindMe resides.

The presence server will handle presence for all domains that VCS has been configured to be authoritative for, so check the correct domains are set up on the Domains page (VCS configuration > Protocols > SIP > Domains)

- Andreas

[ryan_oconnell]

Andreas,

When I disable Presence server and UA on the VCSc and only enable it on the VCSLyncGW all presence stops working on Lync. The only way it seems to work is when Presence Server and UA is turned on on the VCSc which is where the devices register to.

I did read that exerpt you put in the post above as I'm using the same guide, but it's mis-leading because the section right above it mentions to enable it on the VCS control where the enpoints register to. Do you have it setup like you explained and it's working?

It seems to work fine with Presence just turned on the VCSc but I also don't want this to come back to bite me because it's setup wrong.

Thoughts?

Ryan

[awinter2]

Ryan,

you are not supposed to disable the Presence User Agent on any of the VCS's, this is the component which generates presence publications for endpoints registering to a VCS, it is only the Presence Server which should be disabled on your VCS-C, while it should be enabled on your Lync GW VCS.

- Andreas

[ryan_oconnell]

Andreas,

When I set it up as you discribe above with the Pres UA active on both VCSc adn VCSLyncGW. And turn the Presence Server On for just the LyncGW where Findme is installed. Presence fails all together in Lync. Both my Static entries and my Findme entries.

I have my endpoints in subdomain vc.example.com my findme account is set to example.com. I have vc.example.com and example.com setup as SIP Domains on the VCSLyncGW and only vc.example.com setup as a SIP domain on the VCSc.

On the LyncGW B2BUA I have it set to "register Findme Users" using the example.com domain.

On the LyncGW, I see "NO PUBLISHERS" of presence, and my LYNC user status shows Presence status offline.

I can make calls just fine.

As I mentioned before. I have no issues with Presence when I just have the Presence Server and UA set on the VCSc and both turned off on the VCSLyncGW

[Alok Jaiswal]

Hi Ryan,

Please ensure that you do not have any searh rule or transform which  might strip the domain part from the URI while routing those messages fron VCS-control to lync gw and vice-versa!!

Thanks

Alok

[awinter2]

Ryan,

which search rule(s) do you have from your VCS-C towards the Lync GW VCS? Does this search rule match request sent to the 'vc.example.com' domain? The fact that you are not seeing any publishers could indicate that the presence PUBLISH messages generated by the PUA on VCS-C are not being sent to your Lync GW VCS.

Also, in the neighbor zone configuration for the zone towards the VCS-C on the Lync GW VCS, is 'SIP Authentication Trust Mode' set to 'On'?

To comment on your remark regarding presence working just fine when the presence server and PUA is disabled on Lync GW VCS, this might hold true for presence for individual endpoints, but presence aggregation for FindMe accounts will not work, which is why we recommend to host the presence server on the Lync GW VCS.

- Andreas

[ryan_oconnell]

Hello Alok / Andreas

My Neighbour Zone and associated  search rules from VCSc to LyncGW are identical to those shown on page 33 and 34 of the guide.

I don't see any seach or transform rules that would be preventing stripping the domain portion from the URI.

I don't have "SIP Authentication Trust Mode' set to 'On' it is set to off

Any other ideas?

[awinter2 · Accepted solution]

Ryan,

change the SIP Authentication Trust Mode to 'On' on the neighbor zone on the Lync GW VCS.

In addition, on the VCS-C, create a regex search rule matching .*@vc\.example\.com for the neighbor zone towards the Lync GW VCS.

Once you have done this, unregister and re-register one of the endpoints in the vc.example.com domain, restart the B2BUA application and sign your Lync client out and in again, you should then be able to see correct presence for the endpoint. Your other endpoints would have to re-register before their presence status is updated properly.

- Andreas

[ryan_oconnell]

First of all Andreas, thank you for helping me through this troubleshooting, your recommended changes above finally resolved this issue.

For my own sanity can you explain why setting the extra search rule and the SIP Authentication Trust did?

I'm new to vcs but familiar with routing rules and I'm trying to understand the logic. It seems as though i'm creating a routing loop by pointing anything at vc.example.com to the VCSLyncGW and I have more or less the same rule on the other side for Lync calls coming into LyncGW to send them to the video network.

Lastly Did i miss this in the integration guide somewhere? or is this a hidden feature

Thanks so much!!!

Cheers

[awinter2]

Ryan,

you are not really creating a loop with that search rule, since any PUBLISH you send towards the Lync GW VCS for the vc.example.com domain will be picked up by the presence server on that VCS, and never get proxied anywhere. This search rule needs to be in place in order for presence PUBLISH messages to get proxied from your VCS-C to the Lync GW VCS. I would recommend setting the priority of this search rule to something lower (Higher numeric value, lower priority) than the Local Zone search rules on your VCS-C, and higher (Lower numeric value, higher priority) than the other neighbor/traversal zone search rules on your VCS-C. This way, a call from an endpoint registered on your VCS-C to a vc.example.com alias will hit the Local Zone on your VCS-C first, while a presence PUBLISH from the PUA on your VCS-C will be sent to the Lync GW VCS before being sent to any other neighbor or traversal zones on the VCS-C.

I do not think we explicitly state in the deployment guide that a search rule has to be created to pass presence PUBLISH messages, and this is something we should probably add for the next Lync deployment guide.

Regarding the SIP Authentication Trust Mode, the reason why this has to be set to 'On' is because the PUA on VCS-C will generate a PUBLISH message with a P-Asserted-Identity authentication header in it. This is because by design, the presence server on the VCS will only accept PUBLISH messages which have been flagged as authenticated.

When this PUBLISH is received by the Lync GW VCS, coming in on the neighbor zone for the VCS-C, the Lync GW VCS will strip off the P-Asserted-Identity header if SIP Authentication Trust is set to 'Off', and the presence server on the Lync GW VCS will therefore reject the PUBLISH. The solution is therefore to set this setting to 'On', as the Lync GW VCS will then preserve any pre-existing P-Asserted-Identity header for SIP messages for local SIP domains coming in on this zone. This is also something that we will add to the deployment guide for the next version.

Hope this helps in clarifying.

-Andreas

[Alok Jaiswal]

Hi Ryan,

If you do not have any search rule or transform which might strip the domain or not routing the SIP information properly to Lync GW then there is some thing which is blocking those publish messages going to Lync GW.

As Andreas pointed create a new search rule to match the regex in URI format so that publish information should be routed properly.

Also you can collect diagnostic logs to see that where this publish is getting lost. However i feel that steps pointed by Andreas will resolve the issue.

Thanks

Alok