-
×InformationWindows update impacting certain printer icons and names. Microsoft is working on a solution.
Click here to learn moreInformationNeed Windows 11 help?Check documents on compatibility, FAQs, upgrade information and available fixes.
Windows 11 Support Center.
-
×InformationWindows update impacting certain printer icons and names. Microsoft is working on a solution.
Click here to learn moreInformationNeed Windows 11 help?Check documents on compatibility, FAQs, upgrade information and available fixes.
Windows 11 Support Center.
- HP Community
- Poly Video Conferencing
- Collaboration & Conferencing Platforms
- DMA & Lync Federation Error
Create an account on the HP Community to personalize your profile and ask a question
12-04-2013 09:06 AM
Hi,
We've setup a Polycom DMA which integrates into Lync as per the UC deployment guide. There is one RMX registered to the DMA which is working fine for internal calls to meeting rooms, e.g. 1005@contoso.com. These are not registered VMRs but access via the static route as documented in the deployment guide. The Lync environment has an Edge server which is working fine for external users and federation (all have been thoroughly tested). External Lync users registered to the pool which is linked to the DMA can call the VMRs registered to the DMA. However, federated users cannot connect to the meeting rooms. I've followed the guide, checked it several times and the setup appears to be sound on Lync and the Polycom side. When making a call you get the following errors registered in Lync which I captured via debugging logs.
SIP/2.0 489 Bad Event
TL_INFO(TF_PROTOCOL) [contoso-poc-les01\contoso-poc-les01]09F8.0994::12/04/2013-12:27:57.230.00000005 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265)) [418594689]
Trace-Correlation-Id: 418594689
Instance-Id: 36A
Direction: incoming;source="internal edge";destination="external edge"
Peer: contoso-poc-lfe01.contosopoc.com:5061
Message-Type: response
Start-Line: SIP/2.0 489 Bad Event
From: "Test User 1" <sip:test1@testdomain.com>;tag=951cc15793;epid=052379e773
To: <sip:1005@contosopoc.com>
Call-ID: 2389e838e2704a79823cdd40bdc9c461
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 172.16.32.11:49185;branch=z9hG4bK14401EB4.221E3DFF26EFC68D;branched=FALSE;ms-received-port=49185;ms-received-cid=26600,SIP/2.0/TLS 172.16.34.1:49190;branch=z9hG4bK1FD95F38.91EAE6BA14EE568D;branched=FALSE;ms-internal-info="cdEesSqRDOkY-Fg0nL9Gyqw6NmcG15R0aBNnFw0T8qFoS65uqRNdU08QAA";ms-received-port=49190;ms-received-cid=1900,SIP/2.0/TLS 172.16.33.10:50791;branch=z9hG4bKD4755552.250BD79A11E9268D;branched=FALSE;ms-received-port=50791;ms-received-cid=3400,SIP/2.0/TLS 172.16.33.101:64762;ms-received-port=64762;ms-received-cid=12100
Content-Length: 0
ms-diagnostics: 1033;reason="Previous hop server component did not report diagnostic information";Domain="contosopoc.com";PeerServer="proximo-node1.contosopoc.com";source="contoso-POC-LFE01.contosopoc.com"
$$end_record
This is in a lab environment at the moment. "proximo-node1" being the DMA. In terms of what is logged on the RMX it gets a BYE SIP signal but I believe this is sent as a result of this error. There's not a great deal online about troubleshooting these issues so any help would be greatly appreciated.
Thanks
Solved! Go to Solution.
Accepted Solutions
12-13-2013 09:02 AM
Turns out this was an encryption setting on the the VMR. It was set to no encryption when it should have been set to either where possible or always. The domain that was integrated with the Polycom kit had the encryption level in get-csmediaconfiguration set to "SupportEncryption" hence why that worked. The federated domain had it set as "RequireEncryption" thus it failed when connecting to the VMR.
There were no errors anywhere in the logging to indicate a certificate or encryption error
DP
12-13-2013 09:02 AM
Turns out this was an encryption setting on the the VMR. It was set to no encryption when it should have been set to either where possible or always. The domain that was integrated with the Polycom kit had the encryption level in get-csmediaconfiguration set to "SupportEncryption" hence why that worked. The federated domain had it set as "RequireEncryption" thus it failed when connecting to the VMR.
There were no errors anywhere in the logging to indicate a certificate or encryption error
DP
Didn't find what you were looking for? Ask the community