Polycom DMA and Lync Integration

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.

image

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.

image

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.

image

 

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.

image

 

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.

image

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.

image

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.

image

  • Also select the option to Include all certificates in the certification path.

image

  • 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.

image

  • 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.

image

  • 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).

image

  • 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.

About Jeff Schertz
Site Administrator

Comments

62 Responses to “Polycom DMA and Lync Integration”
  1. Christopher Chalfant says:

    Great article, thank you! Can you describe how to add multiple DMAs to an application pool, for the purpose of load balancing and failover?

  2. Christopher Chalfant says:

    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.

    • Jan Z says:

      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…

  3. Louis says:

    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!

  4. TSloan says:

    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

    • jeffschertz says:

      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.

  5. Diego says:

    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.

  6. Brandon LaBonte says:

    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

    • jeffschertz says:

      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.

      • Brandon LaBonte says:

        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

        • jeffschertz says:

          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.

  7. Marshal says:

    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

    • jeffschertz says:

      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.

      • Marshal says:

        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.

        • sfleron says:

          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?

          • jeffschertz says:

            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.

  8. Sfleron says:

    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

  9. Sfleron says:

    We have the same problem – any update to the 29:55 problem?

    • jeffschertz says:

      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.

  10. JChavez says:

    Thanks..we just noticed to bug as well! Glad there is a patch already out.

  11. Chris says:

    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.

    • jeffschertz says:

      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).

      • Chris says:

        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

      • Chris says:

        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?

        • jeffschertz says:

          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.

          • Chris says:

            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

          • jeffschertz says:

            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.

    • Chris says:

      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

      • jeffschertz says:

        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).

    • Sean says:

      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.

  12. luise says:

    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

    • jeffschertz says:

      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').

  13. Alexander Hecht says:

    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

  14. jeffschertz says:

    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.

  15. Gekko says:

    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

    • jeffschertz says:

      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.

  16. Stuart says:

    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.

    • jeffschertz says:

      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.

  17. Anish says:

    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 0×80090327 (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.

    • jeffschertz says:

      What version of software are you running on the DMA and RMX?

    • Gary says:

      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.

  18. 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!

  19. @TariqaMs says:

    why would we neeed DMA , if the best option to connect with RMX?

    • jeffschertz says:

      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.

  20. joshbaugher says:

    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

  21. Pramod Kumar says:

    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

    • jeffschertz says:

      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.

  22. Pramod Kumar says:

    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

    • jeffschertz says:

      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

  23. Mack says:

    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?

    • Jeff Schertz says:

      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.

    • Jeff Schertz says:

      I have seen this randomly in the past and do not know the root cause as the issue is intermittent.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!