• ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
The HP Community is where owners of HP products, like you, volunteer to help each other find solutions.
HP Recommended

My Lync users can call into our RMX bridge rooms using Lync either internally or from the outside through my Lync Edge server.  However my federated Lync partners are unable to call into my RMX successfully through my edge server.

 

Specifically I have been testing with outside Office 365 Lync users.  We use Lync on-premise that is integrated with our RMX with an AD account.  It appears like ICE/TURN are configured correct as my users are able to hit the RMX rooms through the edge.

 

Primary SIP Domain:   contoso.com

RMX FQDN:  rmx.corp.contoso.com

RMX Trused Application in Lync:     video.contoso.com points to rmx.corp.contoso.com

 

Any suggestions on where to start troubleshooting?

 

1 ACCEPTED SOLUTION

Accepted Solutions
HP Recommended

For federated Lync users to reach the RMX you will need to define your selected MatchURI as a SIP domain in Lync.  Only your own Lync users are aware of the static route defined in the topology (actually your internal servers are aware of the route).

 

Option one would be to define video.contoso.com as a secondary SIP domain in Lync and then configure it for federation, including the Federation TLS record if you want anyone (Open Federation) to use that domain and have access to your RMX (typically not desired).

 

Option two would be to delete the route and re-create it with a MatchURI of contoso.com so that the federated calls to the RMX work transitively over the already established federated namespace.

 

A third (and most recommended) option would be to enable SIP registration of specific virtual Meeting Rooms in the RMX which would use the your default SIP domain name (e.g contoso.com) regardless of what the MatchURI is defined as (e.g. video.contoso.com).  This is because the registered VMRs utilize actual Lync user accounts so calls to them are idientcal as calls to a normal Lync client (the static route is not used).  These also provide presence unlike, routed calls.  You can also limit federated call to only the VMRs you configure and thus federated partners can't just guess VMRs and attempt to call into one you may not want them to have access to.  You can register up to 100 meetings rooms to Lync in the RMX.

 

See this blog article for directions on configuring VMR registration: http://blog.schertz.name/2011/05/rmx-virtual-meeting-room-registration-in-lync

View solution in original post

7 REPLIES 7
HP Recommended

For federated Lync users to reach the RMX you will need to define your selected MatchURI as a SIP domain in Lync.  Only your own Lync users are aware of the static route defined in the topology (actually your internal servers are aware of the route).

 

Option one would be to define video.contoso.com as a secondary SIP domain in Lync and then configure it for federation, including the Federation TLS record if you want anyone (Open Federation) to use that domain and have access to your RMX (typically not desired).

 

Option two would be to delete the route and re-create it with a MatchURI of contoso.com so that the federated calls to the RMX work transitively over the already established federated namespace.

 

A third (and most recommended) option would be to enable SIP registration of specific virtual Meeting Rooms in the RMX which would use the your default SIP domain name (e.g contoso.com) regardless of what the MatchURI is defined as (e.g. video.contoso.com).  This is because the registered VMRs utilize actual Lync user accounts so calls to them are idientcal as calls to a normal Lync client (the static route is not used).  These also provide presence unlike, routed calls.  You can also limit federated call to only the VMRs you configure and thus federated partners can't just guess VMRs and attempt to call into one you may not want them to have access to.  You can register up to 100 meetings rooms to Lync in the RMX.

 

See this blog article for directions on configuring VMR registration: http://blog.schertz.name/2011/05/rmx-virtual-meeting-room-registration-in-lync

HP Recommended

Excellent information Jeff -- That's why you're the expert! 

 

A few followups to your suggestions:

 

Option One -- This sounds like the way I will be going, but a bit messier than I would prefer.

 

Option Two -- This sounds too easy??  If I delete the trusted app with a MatchURI of Contoso.com..does that break anything with DNS on my domain..or is this purely for SIP/Lync related processing/call control?  I'm curious why none of the guides on RMX/Lync integration seem to use this idea..most use video.contoso.com or vmr.contoso.com.

 

Option Three -- I understand what you are saying, however because we use the Polycom Conferencing Plugin for Outlook, this option is not good for us.  Since the plugin (PCO) generates a random numbered virtual room each time it's used, then I can't set them all up with individual accounts on the Lync server.

HP Recommended

You don't delete the Trusted Application, only the Static Route.  (You can't modify a route so you have to remove, recreate it).  you can use this article for assitance in recreating the route:

http://mikestacy.typepad.com/mike-stacys-blog/2011/05/deleting-static-routes-in-lync-server-2010.htm...

 

The general guides do not cover the differences between shared or disparate SIP domain names spaces currently.  The general rule of thumb is to share the namespace in small deployments or labs, with enterprise deployments using a separate namespace (e.g. video.sipdomain.com) for a few different reasons.  But ideally this is a design discussion and is one of the reasons that professional services of some sort are recommended.  Sure it's easy enough to document the how-to part, but the impact to an existing overall environment is key and it not always black-and-white.

 

Correct on your last statement; if you are using PCO or DMA then using static, registered VMRs is not ideal for your scenario.

HP Recommended

So for Option Two -- If I make the MatchURI (Contoso.com) be the exact same as my primary SIP domain, does that cause issues?

 

For example, my SIP URI/username is LPHELPS@Contoso.com.

 

Thanks,

 

Lucas

HP Recommended

Also, on option one -- to define an additional SIP domain, do I have to get new public TLS certificates or change the ones I have?

HP Recommended

This depends on the size of the environment.  When selecting the same namespace for Lync and RMX then all unresolvable SIP requests which hit the Lync server will be forwarded on to the RMX.  In large environments this is not advisable as you'll end up send a ton of SIP traffic to the video equipment that it doesn't care about in the first place (not video calls).  With enough traffic this could theoretically impact performance of the entire solution.  To put some framework around it, we are talking Lync environments with several tens of thousands of active registrations, so smaller environments can handle the additional (yet wasteful) SIP traffic.

HP Recommended

Exactly what I was looking for.

 

Thanks Jeff.

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.