The past video conferencing integration articles have primarily discussed the Real-time Media eXperience (RMX) platform, but the Distributed Media Application (DMA) also supports direct integration with OCS and Lync and is the preferred SIP path when both devices exist in an environment.
Out-of-the-box DMA integration instructions are included in the Polycom UC Deployment Guide for Microsoft Environments document, but the steps shown don’t address the scenario where an RMX is already integrated in the network and DMA is being introduced. The documented approach would be to simply define DMA as another Application Pool and define a new route for video calls.
But there is a simpler way to approach adding DMA into an environment where there is already a functional RMX integrated into Lync. The premise is that SIP signaling will primarily be directed to the DMA instead of the RMX for the chosen routing domain, yet signaling and certificate-based TLS signaling will still be supported for the RMX. As the RMX should typically remain a Trusted Application to support certain integration features or outbound SIP calling into Lync then it would not be a good approach to simply replace the RMX configuration with the DMA information.
Calling Scenarios
Before addressing the configuration steps it is important to take a step back and understand the various call routing scenarios that are available with RMX and DMA integration with Lync Server.
Lync Video Call to RMX
This is the most basic integration and is the default approach when no DMA is involved. Because the called SIP URI is not defined on any SIP-enabled Lync user in the forest then Lync will fail to locate any presence information for the contact; this is by-design. But when attempting to call this contact Lync will find the configured static route for the Match URI (mslync.net) and then send the request to the defined FQDN in the route’s Transport parameter (rmx.schertz.local).
Media is then negotiated directly between the endpoints over RTP or encrypted STRP and depending on the capabilities of the specific RMX model either Real-time Video (RTV) or H.263 codecs are used.
Note: Although the same approach applies to Office Communications Server as it does to Lync there was a limitation which prevented the using a MatchURI value that was the same as a defined SIP domain in OCS. Thus past recommendations were to typically use a unique entry like “video.contoso.com” when routing calls to the RMX. With Lync Server it is now possible to use the same namespace which simplifies both deployment and end-user experience, as well as provides native federation access to the RMX for external partners. The examples in this article reflect this best practice of using the primary SIP domain as the MatchURI value.
Lync Video Call to DMA
In this scenario a Lync user places a video call to a meeting room defined instead on the DMA (71444@mslync.net). Identical to the scenario above this SIP URI is not defined on a Lync user so no presence is shown and the defined static route is used to send the request to the defined FQDN in the route’s Transport parameter (dma.schertz.local).
For this simple integration only the DMA needs to be configured in Lync Server as a trusted host and issued an SSL certificate as all TLS encrypted SIP signaling is sent from Lync to the DMA. During call setup SDP instructions in the SIP messages will facilitate media negotiation directly between the Lync client and the RMX (or through an Edge Server for external or federated calls). Because the RMX’s media interface IP address is offered during this process and the endpoint will attempt to connect directly to it then there is no need to define the RMX within the Lync Server topology.
Lync Video Call to a Registered Virtual Meeting Room
With the addition of Virtual Meeting Room (VMR) registration in RMX release 7.2 there is now a calling scenario that offers presence registration for the meeting room but this is handled directly by the RMX and not via DMA. Thus supporting this scenario in the same environment would require that the RMX is also defined in Lync as a trusted host and issued an SSL certificate, although no routing configuration is needed.
Here a Lync user places a video call to a meeting room (msdemovmr@mslync.net) that is defined on the RMX (and not on DMA) which is also directly registered as a defined Lync user. Presence for the standard Lync user appears and when a video call is started Lync sends the traffic directly to the RMX in the same manner if it was any other Lync endpoint. The call flow is identical to a native Lync peer-to-peer call.
Lync Inbound Video Call from an RMX
This final scenario is less common, but is often used for testing calls or when a specific virtual meeting room on an RMX is preconfigured to place outbound calls to invite other SIP participants automatically. A common use for this would be to automatically call specific Lync users when someone dials into a certain virtual meeting room. In this case the RMX sends the initial SIP INVITE to the Lync Server and thus SIP signaling would be handled directly between the RMX and Lync without the DMA involved at all.
Configuration
In order to configure the new DMA in an environment with RMX already configured in Lync yet still support all of the above calling scenarios then here are the four basic areas to be addressed:
- Define a new FQDN for DMA and create a new DNS Host (A) record
- Request a a new SSL certificate and import it into DMA
- Add DMA as a trusted application to Lync
- Update the current static route in Lync with a new route to DMA
1. Name Resolution
Create a new DNS Host (A) record in the same domain namespace where the current RMX DNS Host record exists for DMA. The address should be the virtual IP address assigned to DMA (or the DMA cluster) as this is where signaling traffic needs to be routed to.
- Using the same domain name space as the Lync Server a new record is created for dma.schertz.local and set to the virtual IP address of the DMA.
2. SSL Certificate
Using the directions outlined in this previous blog article submit a new online certificate request against a Windows Enterprise CA using Internet Information Services (IIS) Manager on the Lync server (or any other Windows 2008 Domain member server).
- Using the DMA FQDN of dma.schertz.local as the certificate Common Name a new certificate is created and submitted to an internal CA.
The Certificates MMC snap-in should be used to export the certificate to a PFX file. Do not export the file using the IIS Manager as it will not provide the option to include the Root CA’s public certificate in the package which DMA needs in order to trust the issuing CA of the Lync Server’s SSL certificate (assuming that the DMA certificate is being requested from the same CA that issued the Lync Server certificate).
- From the Certificate Export Wizard select the option to Export the private key.
- Also select the option to Include all certificates in the certification path.
- Enter a very basic password for the PFX file when prompted as some formats of complex password strings can prevent the PFX from expanding inside the DMA (or RMX). Something very easy like password works every time, avoid numbers, spaces, or any other special characters. (Don’t get too creative here unless you enjoy troubleshooting TLS errors; you’ve been warned.)
Finally the certificate package needs to be imported into DMA.
- From the DMA web management interface select Configuration > System > Certificate Management then browse to the exported PFX file and enter the password used to protect the PFX file during the original export.
- Restart DMA to apply the new certificate. It is recommended to delay this restart until the following Lync Configuration steps are completed.
3. Lync Trusted Application
Assuming that the RMX was previously integrated using the best practice recommendation of defining a multiple server application pool in Lync then the DMA is simply added as another trusted computer to the existing pool. As the pool itself is trusted by Lync then any new servers entered into the pool will automatically inherent the existing trust configuration.
- Using Topology Builder locate and expand the existing Trusted Application Server pool where the RMX is currently defined.
- Select the New Server action while focused on the application pool object and enter the DMA FQDN which was defined in the first step for the DNS Host record (dma.schertz.local).
- Publish the Topology to save these changes.
4. Lync Routing
Because static routes in Lync cannot be modified the previous route to the RMX needs to be deleted and then a new route created for DMA.
- Simply running the Get-CsStaticRoutingConfiguration cmdlet will show all defined routes in a single value and can be difficult to identify the correct data. Run the cmdlet with the additional parameters as shown below to expand any additional routes separately.
Get-CsStaticRoutingConfiguration | Select-Object -ExpandProperty Route
Transport : TransportChoice=Certificate=Microsoft.Rtc.Management.
WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=
rmx.schertz.local;Port=5061
MatchUri : mslync.net
MatchOnlyPhoneUri : False
Enabled : True
ReplaceHostInRequestUri : False
- If there is currently only a single route in the Lync environment then it is easiest to simply null-out the route parameter using the following cmdlet.
Set-CsStaticRoutingConfiguration -Identity Global -Route $null
- But if multiple routes exist for other unrelated applications then only the RMX route must be deleted manually using these two separate cmdlets. The first cmdlet recalls and stores the desired route value into a variable and then the second cmdlet deletes the specified route.
$delroute = Get-CsStaticRoutingConfiguration -identity global | Select-Object -ExpandProperty Route | Where-Object {$_.MatchUri -eq “mslync.net“}
Set-CsStaticRoutingConfiguration -identity global -Route @{Remove=$delroute}
At this point the new routing configuration is re-entered using the DMA FQDN as the target instead of the previous RMX FQDN. The same MatchURI will be used in the new route.
- Run all of the following cmdlets to store the new route data into a variable, write the data into the Lync routing configuration, and then save the changes to the topology.
$route = New-CsStaticRoute -TLSRoute -destination “dma.schertz.local” -port 5061 -matchuri “mslync.net” -usedefaultcertificate $true
Set-CsStaticRoutingConfiguration -identity global -route @{Add=$route}
Enable-CsTopology
- To validate the new configuration run the Get-CSStaticRoutingConfiguration cmdlet again with the additional parameters just like before.
Get-CsStaticRoutingConfiguration | Select-Object -ExpandProperty Route
Transport : TransportChoice=Certificate=Microsoft.Rtc.Management.
WritableConfig.Settings.SipProxy.UseDefaultCert;Fqdn=
dma.schertz.local;Port=5061
MatchUri : mslync.net
MatchOnlyPhoneUri : False
Enabled : True
ReplaceHostInRequestUri : False
Given the flexibility shown in this article then if desired there could actually be multiple static route configured so that calls could be directed to either DMA or RMX in the same configuration. The approach used here is the least-complicated and supports the best-case scenario of routing all normal calls to the DMA yet still supports the additional configuration steps for calling presence-enabled, registered meeting rooms directly on the RMX.
Great article, thank you! Can you describe how to add multiple DMAs to an application pool, for the purpose of load balancing and failover?
Jeff, I just figured out the answer to my previous question. Some steps my not be needed. I'll do more testing.
1.Create the supercluster
2.In network configuration on each DMA, make the IP address of the DNS server of the AD domain the primary DNS server.
3.Using the AD domain’s CA, request and install web server certificates (with certification chain) on all DMAs.
4.In the Lync Server Management Shell, create static routes for all DMAs.
5.Also using the management shell, create one trusted application pool, and then create application servers (one for each DMA) in the pool.
6.In DNS, create A records for all of the DMAs, each with the same hostname (I used the real hostname of one of the DMAs, but don’t know if that is necessary) and their correct, respective IP addresses.
I confirmed that calls from Lync to a VMR were hosted on DMA-1, rebooted DMA-1, and as the same Lync user as before tried to dial into the same VMR. It took it took longer, but the user was connected to the VMR, hosted on DMA-2.
This sounds really good Christopher, do you have more detailed documentation or screenshots? 🙂 I am getting my DMAs, RMX, CMA etc very soon to start building, testing and demo'in in combination with Lync…
[…] http://blog.schertz.name/2011/08/polycom-dma-and-lync-integration/ Polycom DMA and Lync Integration August 30, 2011 by Jeff Schertz […]
Hi, Jeff. I have one question.
how to make sure that the picture quality is good if there is packet loss, I just tried to find out if there is any I-frame reuqest in Lync System, and I also did some tests, but I can't find out.
Thanks!
Jeff,
Is there a way to get DMA VMR's to automatically show presence within lync. If I"m enabling 1,000+ users to have VMR would I have to create contact for all 1,000+ users? Also how would SIP factories play into the Polycom/Lync solution?
Thanks
Not currently as SIP registration is limited to 24 or 48 rooms depending on the RMX model. The DMA does not yet support SIP registration of individual rooms. Using LDAP integration with the DMA you can define a specific AD attribute to store each user's personal VMR ID in so then you do not have to create the thousands of rooms in the DMA. Inbound calls to the DMA will attempt to match the defined AD attribute value (if one exists) in real-time.
[…] pool configurations shown side-by-side (Single versus Multiple Computer) as well as two different potential call flow paths depicted top-to-bottom (Registered VMR versus SIP URI Dialing). Only one of these two types […]
Hello Jeff, i have an scenario like this, so i´m thinking about start to configure it the next week.
Otherwise, just wanna know if you know some way to configure the DMA to work as a Gateway H323/SIP, to translate calls directly from h323 endpoints to lync clients.
If you know some tips about it, i really appreciate.
Sorry for my english. 🙂
Best regards.
Diego, the official UC Deploment guide covers DMA configuration steps for Lync integration: http://support.polycom.com/global/documents/suppo…
Jeff – I'm looking at your comments about joining Lync-hosted calls from the HDX. My HDX is connecting to Exchange and showing the calendar properly. I'm trying to get the "Join Now" button showing up on my HDX for scheduled meetings (Lync meetings), but don't get that option. In the Polycom docs, I see some indication that the Polycom Outlook Plug in may be needed, but couldn't confirm from the blog post. Any thoughts?
Best,
Brandon
Do you have the RTV Options key enabled on the HDX? This is required since RTV is the only video codec supported on the Lync Server AVMCU. When RTV is not enabled then the 'Join Now' button will not be displayed.
Jeff,
Yes, I have the key. In fact, I found the issue was related to some attribute settings in Exchange that were documented by Polycom.
That said, I still have an interesting issue. Your blog shows where you use an HDX with Click-to-Join to connect to a Lync MCU interface. I've tried to extend that, by installing the PolycomOCSConfigurator plugin to Lync. My understanding from the release notes is that this should allow Lync to hand off MCU calls to my RMX. It seems to do that, as when I click "Meet Now" in my Lync client, I get a dynamically created room on my RMX. However, when I try to use the same Lync https://meet.whatever.com url from more than one location (including the HDX), I find that the RMX ends up getting multiple conference rooms created each with one user in them (instead of all the participants connecting to the single room). I show a vauge error in the Lync event log that seems to be related to the integration between the Lync MCU and the RMX, but not enough information to chase. Wasn't sure if you had any experience with this…I think my issue is getting a little complex, and I'd be happy to engage you professionally on it, if that were possible.
Many thanks,
Brandon
Brandon, unfortunately that is expected behavior with the current Click-To-Conference solution; the HDX does not get placed into the same VMR as the Lync clients.
Hey Jeff,
We have got our DMA talking to our Lync environment no problem and it all seems to be working great. However, we found a problem that when dialing into a VMR from our Lync clients we get disconnected after 29 minutes and 55 seconds everytime. I have tested both Lync to Lync video calls and straight calls to the SIP registered HDXs and they are all allowed to go as long as we need. I have also tested a call to the VMR using the Polycom CMA and it will stay connected past the 30 minute mark. Just wondering if you have run into this problem before or not.
Thanks
Marshal
Marshal, I have not seen this behavior before myself but I do see a support request has just been opened with the same description; I'm assuming that was you who opened it. If not then I suggest opening a support ticket to troubleshoot the issue as if it's happening in two separate deployments there may be a commonality between then we can use to help identify the root cause.
Thanks for the reply Jeff, it was me who opened it. We have inspected all the traffic and the BYE packets are coming from the DMA. We opened a ticket with our Polycom vendor and, of course, they are saying that Lync is the one hanging up the call. Still trying to get a packet trace from them showing that though.
Hi Marshall
We have exact same issue – lync clients gets disconnected after 30 minutes (might be 29:55). Do you have any news regarding this?
This has been address with a new hotfix for DMA version 4.0.3. Please reach out to your official Polycom support contact to acquire this hotfix.
We have exact same issue with DMA 4.0.3 – DMA disconnects after exactly 29 minutes and 55 seconds. If you have any new information about your case then please do share.
Best regards Soren
We have the same problem – any update to the 29:55 problem?
This has been address with a new hotfix for DMA version 4.0.3. Please reach out to your official Polycom support contact to acquire this hotfix.
Thanks..we just noticed to bug as well! Glad there is a patch already out.
Hi Jeff,
If I decide to only integrate Lync and DMA, like you explain in "Lync Video Call to DMA", do I need to do anything on the RMX like SIP register it against the DMA or Lync or create the certificates for TLS or anything? I have the environment set up fine for H.323 but for SIP I seem to be lacking something. The integration Lync DMA seems fine since I can see the signaling happening in the DMA logs when calling the VMR from a Lync client, but it breaks with the error "no media path available", I even see the DMA starting the meeting on the RMX but immidiately breaks. The Lync logs says no bandwidth available? Thanks before hand if you can point me in the right direction.
Chris, you still need to configure the RMX as you would even without the DMA in place but do not create a static route for it. Only a single static route will exist in Lync, pointing to the DMA (which you already have) but the RMX needs to be enabled for Microsoft SIP (which enables RTV on the bridge) and also configured to register to the Lync Server (which enables ICE functionality, VMR registration features, etc).
Thx for your respons Jeff,
I have come a bit further, RMX is now integrated and I kept the default route in Lync against the DMA, all sip registered VMR:s works fine but I still have the same problem when calling via DMA, no media path available.
There are two things I would like to confirm with you,
1. In the call details on the DMA in the signaling I see nothing that states the media IP of the RMX, I only see information about the remote Lync Client, it gives me all the ICE/STUN candidate IPs. Shouldn't I see responses including the RMX media IP aswell?
2. I have configured a SIP peer in the DMA but however I configure it, it states "false" on outbound. I don't believe that would be the cause or could it?
Thx again Jeff, for your advises
I have found the problem, it was ok to dial from internal registered Lync-clients but not for external. The RMX was registered to the Front End pool not the edgepool. The new problem is that I cant register against the edgepool for some reason, is there a way the register against the internal interface of the edgepool, or should I add SRV records in the internal environment pointing to the external side and do the integration that way?
The RMX is only registered to the Front-End, you can't register any internal endpoints (native or third-party) to the Edge Server, nor do you need to. The A/V Edge FQDN and ICE details will be passed to the RMX by the Front End server. You need to enable Microsoft ICE support on the RMX as detailed on page 67 of the UC Deployment Guide. There is no need to make any configuration changes in the Lync environment to support this, just create a Lync user account for the RMX as detailed in the guide.
Thx Jeff!
I really appriciate your help.
I was actually believing what you say aswell since I see the ICE kicking in when calling the Lync registered VMRs, however on page 70 in the same document this is written:
To configure the RMX for Federated Dialing:
1 In the RMX Web browser, in the RMX Management pane, expand the
Rarely Used list and click IP Network Services ( ).
2 In the IP Network Services pane, double-click the Default IP Network
Service ( , , or ) entry.
The Default IP Service – Networking IP dialog box opens.
3 Click the SIP Servers tab.
4 In the SIP Server Type field, select Microsoft.
5 Make sure that the IP address of the Lync Server edge server is specified
and the Server Domain Name is the same as defined in the Lync Server
edge server and in the Management Network for the DNS.
6 Click the SIP Advanced tab.
7 In the Server User Name field, enter the SIP URI that was defined for the
user you created in Active Directory. For example, enter rmx1edge.
8 In the ICE Environment field, select MS (for Microsoft ICE
implementation).
You see in #5 they state that the Lync Edge server should be used? Or am I missunderstanding it?
Anyway I have opened a ticket with polycom to understand better, there documentation is not always top notch.
Thx
Chris, unfortunately that section of the documentation is incorrect and will be corrected in the next update. Just configure the RMX account and do not modify the SIP registration configuration of the RMX, only the SIP Advanced section is touched when enabling ICE support.
Thx Jeff!
It is a loadbalancing error, I have drained my half Lync environment (I have 2 Edges and 2 FE) After draining everything works fine.
So time to check the loadbalancing.
But anyway thanks alot Jeff, you made things alot clearer!!
/Chris
You can test this without draining the pool by simply pointing the RMX to the FQDN of a Lync FE server and not the load balanced pool FQDN. Calls from any Lync user regardless of their home pool will still work as the RMX will accept inbound calls from any FE server in the Lync environment. The SIP Server setting only is used to locate a pool server for initial registration and for any outbound calls (placed from the RMX to Lync by use of the RMX Management Console).
Just wanted to add something I ran across when I was doing this implementation this week. I already had an RMX integrated with Lync and was adding a DMA. After adding the DMA and updating the routing, remote Lync clients could not connect to a VMR. On the DMA/RMX I could see the call initiate, then almost immediately drop. Looking at the Property Changes in the CDR we saw "Rejected:No network path between endpoints." This led us to add a site link between our site hosting the DMA and the built-in Internet/VPN site. That resolved the issue.
Hi Jeff,
We have only one central DMA and several Lync Pools. On OCS we created one route per pool but now is not possible because a trusted application can only be created once and asigned to one pool and once this is done and you try to create it for other pool… it says that the a trusted application with that FQDN is already created.
Thank you and Regards
Luise, only a single Trusted Application pool and application is required, you don't create multiple trusted pools for multiple usages. Once the hosts are defined and trusted you can use them for any service. So the integration is identical except that instead of creating a single route on the Global identity you'll create multiple routes using the same MatchURI but with unique destinations (different DMAs or RMXs) and unique registrar identities. But if you have a single DMA then you should still only be creating a single Global route as it's used by all pools in the topology (hence 'global').
Hi Jeff,
I have a DMA super node cluster running in my environment. I was just wondering what the route is then. Do I need to create an fqdn for DMA.mslync.com with the recored including the 2 two virtual nodes? Today I have as recommended two dns entries for xxxxxx1-virtual.mslync.com and xxxxxx2-virtual.mslync.com.
Thanks Alex
Alexander, there are two options for integration with DMA Superclusting: either using DNS Load Balancing or leveraging the DMA's built-in DNS service for delegated zones. This is an advanced topic and may be covered in a future article.
Jeff, thanks for the reply I will go further with leveraging the built-in DNS capabilities of the DMA.
Hi there Jeff….
First off thanks for all the docs you submit. Without them I think I would have a pile of maunals next to me and still no closer to a solution.
I am wondering if you can guide me with the following scenario.
I have a RMX that has been integrated into Lync with full presence etc and federation all working great.
Adding a DMA to the mix, I have defined the DNS, added to the application pool and run the scripts. I have added the SIP Peer and defined the dialling rules and finally configured a user for a VMR on the DMA. I find that dialling out from M100 via SIP to Lync works great and can hit the RMX via the DMA to the dynamic VMR too but when my Lync clients try call the VMR it either indicates offline or if I try from a federated user it indicates connecting call and remains there. Is there something basic I am missing?
Regards
SIP URIs which are routed statically to the DMA will not show presence (just as the same calls routed to an RMX will not either). Only SIP registered meeting rooms on the RMX will provide presence. For the federated users make sure that ICE is functional on the RMX.
Hi Jeff,
We have been experiencing an intermittent issue. Our Lync intergration works fine 'most' of the time, but sometimes when a Lync client trys to conncet to the RMX it just spins and will not connect. This affects all Lync clients who try to connect. The only way to correct this is to reboot the RMX and then everything works fine.. until the next time. Any ideas? We recently added a DMA, but this behavior occurred both before and after the DMA addition. Thanks.
What version firmware is running on the RMX? An updated version is due out soon which will included a number of hotfixes, some of which may help resolve this issue for you.
After I integrate with DAM the call btw Lync 2010 to DMA will work for 30 min and then stops working.
if i restart the DMA system again the call flow will start working for 30 min
the error from Lync event viewer states”TLS outgoing connection failures.
Over the past 15 minutes, Lync Server has experienced TLS outgoing connection failures 13 time(s). The error code of the last failure is 0x80090327 (An unknown error occurred while processing the certificate.) while trying to connect to the server “dmadc.xxx.com” at address [10.xxx.xxx.xxx:5061], and the display name in the peer certificate is “Unavailable”.
Cause: Most often a problem with the peer certificate or perhaps the DNS A record used to reach the peer server. Target principal name is incorrect means that the peer certificate does not contain the name that the local server used to connect. Certificate root not trusted error means that the peer certificate was issued by a remote CA that is not trusted by the local machine”
I Have installed proper certificate through DMA Application.
What version of software are you running on the DMA and RMX?
DMA is 5.2 and RMX is 7.7
RMX 7.8 would be ideal but it should still work correctly with 7.7. I suggest contacting support to troubleshoot this issue.
Anish I had a similar issue until I eventually generated a certificate request from the DMA and loaded it via the web cert service, the generated the certificate and the copy and pasted the cert back to the DMA. This then updated the DMA cert store and the SSL assigned to the DMA and seem to have resolve the issue. Possible solution.
Hi Jeff! I was wondering if you could help us out with an issue…
We got our Lync 2010 environment integrated with our Polycom environment today. We're running DMA 5.2 with three RMX bridges registered to it via. SIP. My Polycom endpoints are all registering to the DMA as well with SIP.
We're using Shared Number Dialing / Virtual Entry Queue on the DMA so our users can connect to their video conference by just having to dial into "Conferencing Service" (the VEQ – 7123456@sipdomain.com) and then input their conference ID when prompted.
Our Polycom endpoints work just fine with the virtual entry queue but our Lync clients don't seem to like it. When I dial sip:7123456@sipdomain.com from Lync, the call connects to one of the RMXs in the MCU pool and the IVR prompts for the conference ID. After entering the conference ID, I'm taken to my VMR as I normally should but when I try to add video, all I see is the window grayed out. The webcam preview shows the preview as normal… I can't seem to figure this out. When I view the sent/received video from RMX manager, the video looks normal. I also noticed when I hang up the call, RMX manager still shows the Lync client as "connected" even though it's not. If I dial directly into the VMR instead of using the entry queue, everything works fine!
Any help is GREATLY appreciated. THANK YOU SO MUCH SIR! Cheers!
Alexander, I've tested that scenario before with mixed results. I'm not sure if that is a fully supported use-case so I suggest contacting support if you have not already done so.
Thanks Jeff! I have contacted support and it looks like we have to get professional services out here.
why would we neeed DMA , if the best option to connect with RMX?
DMA is primarily used with Lync when multiple RMXs are deployed as it will manage all conferencing resources as pools to provide for efficient routing, balancing, and scale of media traffic.
Hi Jeff-
Very strange thing started about a week ago. Wondering if you have any ideas.
Our setup –
Rmx1500 – Sip – Registered to the DMA
DMA7000 – Sip – Gateway
Lync 2010 – Trusted application pool, domain.vmr points to dma next hope Lync 2010 server.
We have been able to make calls from lync to the "vmr#"@dmain.vmr and have had no issues. But now when we try to call the call ends up failing with a Lync error ID 487. On the Lync monitoring server I can see the call but it fails due to unknown user or user unregistered. The Call is setup on the DMA and the RMX but I never fully connect before the call ends.
Not too sure what other details you would like so please just let me know. We did do the upgrade to 8.2 on the RMX but that broke other functions with our group 500's So we went back to 8.1.7. Everything else is at the latest Ver.
Thank you
Josh
It should work with 8.1.7. If you force a reboot of the RMX do calls start working again?
No calls do not work. I am at 8.3 on the RMX now and still not working
Hi,
I have integrated DMA to Lync as explained above. The video call from RPD to Lync client prefixed by 99 works well. But the call from Lync to RPD over SIP URI (registered to DMA) works as audio only saying video not supported. However if we call the H.323 ID/Extension@domain.com of RPD, the video call works well. What could be wrong? Can any one help me?
Thanks,
Pramod
Are you doing this with Lync 2010 or 2013? Currently the peer gateway capability of DMA is only supported with Lync 2010, and not yet with 2013.
I am using Lync 2010. I have noticed if Lync make calls to RPD over SIP URI which is different than Lync URI then there is no problem in video call.
Another issue I am facing at one other palce where the customer is having mutiple domains in the network e.g. abc.com, xyz.com, xlr.com, etc. We have done the integration with the main domain (forest) i.e. abc.com
The call between RPD & Lync lands to each other but the moment we accept the call, it gets dropped. The Lync/RPD SIP URI is not on abc.com instead it is on xyz.com
What could be the issue? How deployemnt should be done multi-domain concept.
Thanks,
Pramod
It sounds like you are talking about peer-to-peer calls between RealPresence Desktop clients registered to a DMA with Lync 2010 clients. In these calling scenarios the media codec and ICE requirement dictate the supported call paths. If calls connect and/or ring but drop immediately these are typically related to ICE negotiation which is not supported end-to-end on the DMA + Lync peering model
I have a Lync 2010 pool with two RMX 2000s as trusted applications with their own static routes. Things work great for a while and then periodically one or more of the Front End servers will stop attempting to send packets to one or the other RMX and instead sends the requests to the Edge server. In the mean time other Front End servers are successfully integrating with the same RMX. I find that if I delete and recreate the static route for the RMX the front End in question starts integrating just fine with that RMX.
My guess is that the Front End has marked the trusted host (rmx) as down. Any direction you can provide me?
Mack, I've seen this randomly myself and have never been able to find a root cause. It's definitely something inside of Lync as it simply stops using the defined static routes and acts like SIP messages to that route's MatchURI are undefined and then falls back to the Edge, assuming the namespace is external. I've only seen it some environments though as it's not very common. Unsure if the Lync CU or topology has any impact on it.
I have seen this randomly in the past and do not know the root cause as the issue is intermittent.
Hi Jeff,
I have integrated a Lync 2013 with a Polycom infrastructure (DMA 6.04, RMX 7.8) and put in place the equivalent of scenario 2 (Lync Video Call to DMA).
Lync 2013 clients are able to dial in VMRs created in the DMA and hosted on a RMX by dialing xxxx@conferencing.company.com which is great. However, as this as a managed service and for more flexibility in terms of scheduling I have been asked to do the same with meeting rooms directly created on the RMX.
To me this is the same appart from the fact that the DMA handles the MR creation on the RMX in the first case while in the second case the MR is already created when the lync client dials in….. however, it does not work !
The call arrives on the DMA which then tries to process the received SIP invite but it seems there is a SDP multipart problem. I can see the following error in the DMA Reports -> Call history:
Multipart SDP Invite is rejected with 415. The inviting endpoint will send a new invite with no multipart.
Have you ever encountered such an error ?
I have been trying to find the difference between the two cases (lync clients calling VMR created on DMA or lync clients calling MR created on RMX through DMA integration) but I really do not see where the problem comes from !
I’m not quite following what you are trying to accomplish but you can’t mix DMA defined VMRs and RMX defined VMRs. If you are attempting to register DMA-defined VMRs directly in Lync that feature was not added until the DMA 6.1 release.
Is it possible to make call from a trusted application (without trusted application endpoint SIP uri) to a Lync client?
Sure, the Trusted Application configuration allows for bidirectional traffic to be allowed. But understand that simply means the SIP traffic will be allowed though, it doesn't mean everything will work end-to-end. For example if you are talking about calls from a DMA-registered endpoint placing a video call to a Lync 2013 client the call will make it through but the media session will not be established for a multitude of reasons
When I configure a trusted application in lync server , I saw there is only a listening port. So if there is no connection from lync server to a trusted application, how can I send any message or call to lync server?
The listening port define where Lync send SIP message to on the Trusted Application Host. Messages coming from that host to Lync have to arrive on the default Lync listening ports, 5062 for TLS.
Hi Jeff,
Can I do integration between the Lync 2013 (locate in domain a.com) and DMA (locate in domain b.com)?
Hi Jeff
We are setting up Lync integration with the DMA. We were wondering if the Lync and DMA-servers have to be in the same domain? (it seems the guy above me had the same question).
As of now they are in different domains. The necessary Lync setup is done.The CSStatic-route point at the DNS-name of the DMA. Polycom environment has a valid certificate (wilcard SAN) and Polycom DMA/RMX have the root certificate of our Lync-server installed.
Lync-server is setup as SIP peer on the DMA. RMX is registered to our DMA SIP-wisely. We don’t see any SIP-traffic coming from Lync to RMX whenever we dial.
Servers are also in different networks and have a VPN-tunnel between them (we know about the cons of VPN – delay etc.).
RMX is defined in our topology builder, which I since have read is not necessary as the RTV stream is transfered directly between Lync clients and RMX’es.
RMX is 8.4 and DMA is 6.1.1.
The error on our Lync client when we dial VMR’s on the DMA is “operation was unsuccesful”
Any ideas?
The domain name are irrelevant as long as the Trusted Application is defined, this is not optional. Both DMA and RMX need to be defined and their FQDNs reflected in DNS and in the individual server certificates. There is no requirement that the FQDNs be int he same domain as the Lync server’s FQDNs (although that is recommended). Wildcard certificates are not supported and the FQDNs must be included. Simply follow the latest deployment guide.
Thank you Jeff. Everything but video now works for us. I have read that we may (it’s a bit ambigious) need SVC. At this moment we don’t have the SVC license for our RMX. The error on the Lync client is similar to “video not allowed”. Can you shed some light at this?
Here is my infra:
Lync 2013 pool
Lync Edge
Polycom DMA 7000 (6.0.2_11)
Polycom HDX 8000
Lync 2013 pool is registered to DMA. Al configuration has been done following the Polycom UC deployment guide.
RMX in integrated to DMA with SIP(can only be connected to one SIP)
Internally everthing works great. Lync 2013 client can initiate Video to RMX thru DMA
But does not work externally. Client cannot initiate a Video to Polycom.
(Yes my Lync infra works great externally)
thx
Most likely yo do not have ICE configured correctly on the RMX, preventing it from leveraging the Edge server for ICE/STUN/TURN media traversal to/from the Internet for your external and federated Lync clients. You should contact you Polycom support channel for further assistance.
Old blog, I know. But maybe you’re around still.
Any possibility of getting this to work with an external video supporting PBX? Like Freeswitch? I would very much like to be able to route calls from standard SIP infrastructure (specifically WebRTC endpoints) to Lync users.
Nope. Lync strips the video portion of SDP (m=video) in the SIP invitations when they are routed over the Mediation components.
Hello Jiff,
I have followed literally your blog and the UC deployment to integrate the Lync with DMA and RMX. The RMX integration is fine, have deleted the static route to the RMX and added the primary DMA. however when dialing a DMA VMR, the call hit the RMX entry queue and decided to add hoc the meeting room although the existing static route is pointing to the primary DMA of a supercluster configuration.
From Polycom side, I can reach the VMR’s but the case is different when Lync clients are dialing VMR@match-uri
any thoughts ?
No sure what is happening here but I would run a trace on the calls to make sure that Lync is in fact routing the calls to the DMA and not still using the previous configuration to send traffic to the RMX. If that is not the case then the DMA configuration would need to be fixed to resolve how the calls are landing into VMRs.
HI Jeff, we have a problem weve been having a couple of weeks now after integrating Lync 2013 to our DMA running 6.1 and RMX running 8.3. Two issues actually:
#1 We get error: “Video is not supported” on the Lync client but I think this is a config issue so im working on this with support.
#2 The other I need help on is internal Lync clients dialing into our DMA VMR solution. It seems like we only get one way media (to the RMX) because the internal lync clients use a direct connection to the public IP of our RMX media card which causes a problem with media not NATing properly. Our externally registered Lync clients work ok because it uses TURN or the edge server to route calls between the public IP of the Edge and the Public IP of the RMX media card.
Looking at your comments above, weve done everything properly for the simple flow of Lync clients calling into VMR solution, nothing is configured on the RMX, is there something im missing here? I can see internal Lync clients not sending back a reflexive address for STUN and im guessing thats because its on the same network. Not sure if this is the problem? I can see it attempt to send a BIND to the RMX IP but since it doesnt get a response I was hoping Lync would fallback to the relay server but this is not the case. Any guidance would be appreciated!
Internal Lync clients should not be talking to the external Edge interface. You will see those clients attempt to connect to the external Edge A/V IP during their candidate connectivity checks, but the actual media session is always relayed to the internal Edge interface (as provided during in-band client provisioning). The RMX will act the same, but internal Lync clients often are able to connect directly to the Edge server’s internal IP so Edge relay is not even used for that. The video unsupported error can come from a media encryption mismatch, make sure that both Lync and the DMA/RMX are set to compatible media encryption settings.
Jeff – I have a successful Lync integration with my DMA and two collaboration servers. I plan to use VMRs on the DMA, but curious about how Lync clients will connect to those VMRs if Lync isn’t already installed and I don’t have a “Join Lync Meeting” link in an invite. I have tried to get to the LWA interface, but it appears the LWA will not launch unless I have the “Join Lync Meeting” link.
I’m sure I know the answer to this question, but thought I’d hit you up with my quandry. What do you think, can I get a web interface that allows guests to enter the VMR and connect with the Lync client without needing the “Join Lync Meeting” link generated by an Outlook Meeting?
Thanks for your time. By the by, this and your other blog posts were critical to getting my integration running…if not simply to understand how the whole thing worked in the first place.
Toby
Toby, you should be using the ‘RealConnect’ workflow and not the legacy ‘VMR’ approach to achieve this.
Hi Jeff,
I have environment Lync (Front-End and Edge) is placed on domain corpA.local with sip domain corpA.com. My environment Polycom (RPAD/DMA/RMX) is placed on domain corpB.local with sip domain corpB.com.
Can I integrate both environments?
Sure, you’ll simply define domain corpA.com as the namespace used in Lync on the SIP Peering configuration. The server namespace is irrelevant.
Hi Jeff,
I am having the same issue as Mack reported in August 2014 and just wondered if you know anyone that has fixed this issue? Current having remove the static route completely and re-add the same static route again. Just wondered if MS have identified the issue and created a fix?
Mack says:
August 14, 2014 at 11:30 am
I have a Lync 2010 pool with two RMX 2000s as trusted applications with their own static routes. Things work great for a while and then periodically one or more of the Front End servers will stop attempting to send packets to one or the other RMX and instead sends the requests to the Edge server. In the mean time other Front End servers are successfully integrating with the same RMX. I find that if I delete and recreate the static route for the RMX the front End in question starts integrating just fine with that RMX.
My guess is that the Front End has marked the trusted host (rmx) as down. Any direction you can provide me?
I’m not aware of a root cause or fix for this. With the movement of most deployments to RealConnect the static route is no longer a part of the configuration.
Hi Mate, We were able to connect to the polycom as well as S4B. But client wants to make use of the vmr on polycom to be accesible by all S4B that is federated.
Meaning one from client A S4B and another one from b S4B and then another from c S4B be able to connect to the polycom VMR configured for federation on Client A.
Is this possible? How do we go about it?
regards,
Yes it is possible, simply setup standard federation between the various SIP domains. This more recent article explains your options: http://blog.schertz.name/2013/09/selecting-matchuri-lync/
Do we need to create SIP enabled user in case we configure DMA integration, like dma@mslync.net?
A SIP user is required for RealConnect integration only.
Hi Jeff
Is it possible to add DMA as trusted application with out certificated based trust, I do not want SSL based communication between skype and polycom?
It may be possible, but may not function and may also not be supported at this point. You’d have to configure TCP instead of TLS in the Trusted Application PowerShell cmdlets.