SRV records are only needed to support open federation. With your federated partners, have them add your matchingURI, the stuff after the @, in their Edge configuration to point to your Edge server or Pool (assuming you are using a sub domain).
The federated partner then calls your DMA VMR, email@example.com, which is not recognized by the Lync FE. So the calls goes to their Lync Edge which matches the domain to a record that points to your Lync Edge. You Edge server gets the SIP invite and matches the domain or matchingURI to the static route. Then the SIP invite is sent to the DMA for prcoessing.
One note - it is recommended to use a sub domain for your matchingURI for 2 reasons.
Thanks for the valuable information. That makes good sense.
So they would have to use the CsStaticRoute CMDLET pointing to our EDGE-server as well as make the topology settings on their Lync server as we did on our own?
I don't see a Lync Management Shell on our EDGE-server. So I assume the configuration needed at federated partners needs to be done at the Management Shell of their FE-servers?
I assume ICE is required for all this to work?
There is no need for a static route on the federated partner side. They would open up the Lync Server Control Panel and add your SIP domain under Federation and External Access -> SIP Federated Domain. They would add an entry with an allow, your domain, and your edge server or pool. This information gets added to the database and replicated to all the Lync servers...
Thanks a lot for your help so far.
If we want to support open federation, do you know if the Lync federation SRV record can point at the RPAD rather than Lync edge.
For us it doesn't make much sense that all the traffic has to be routed via our Lync Edge server if it ends on the Polycom infrastructure anyway.
We actually tried this, but are unable to dial from federated partners to our Polycom VMR. It looks like a TLS handshake error on our RPAD.
Although the RPAD is also a functioning firewall capable of doing port forwards which would be needed for Lync, I would not recommend this deployment. In the new RealConnect call scenarios, the lync client gets connected to the Lync AV/MCU running on the Lync Front End servers, and older H323 endpoints would get connected to the DMA/RMX which creates an automatic cascade link to the Lync AV/MCU. Using this approach, the Lync clients stay in the Lync envirnoment while the Polycom endpoints stay on the Polycom side.
We have RealConnect up and running. Lync clients can internally join the Lync AVMCU and even the RMX (via a static route on the Lync server pointing to our DMA).
But we would like to be able to demonstrate the possibility of Lync clients to join VMR's / Lync conferences from the RMX side from external side (federation) - to get customized skins, music, to conserve Lync server ressources etc.
I don't want to put my RPAD in front of Lync server as firewall. We have one domain for Lync and one domain for Polycom infra (subdomain). It's the federation SRV record of my subdomain video.company.com that I want to present for Lync clients on my RPAD. My "root" domain company.com should still be directed directly to my Lync server. Does it make sense?
I realize it's probably not a common scenario. For me it's also a technical curiousity of how to solve this issue. To further my understanding on Lync versus Polycom.
If you want to get federated lync clients into your VMRS, all youhave to do is tell the federated partner to add the subdomain to their Lync config which points to your edge server or pool. If you have a service record for this, then all is need is just the subdomain added.
There is no requirement for the RPAD in this scenario.