locked
OCS to CUCM via OC Mediation problems RRS feed

  • Question

  • Currently we're having some problems with getting the user via the OC client to dial out.  internal dialing is fine, and dialing from the Cisco phone system to the Mcahine is fine, but right now we're getting some errors when trying to test outside number dialing.  Based on the text of the logs we're getting from the logging tool on the mediation server, it looks like a TLS communication error, but I can't find any solid references to it anywhere.

     

    TL_WARN(TF_COMPONENT) [0]05C8.0620::10/07/2010-23:17:09.648.00000525 (Collaboration,RealTimeServerConnectionManager.CoreManagerIncomingTlsNegotiationFailed:connectionmanager.cs(5414))( 000000000234EA8E )<RealTimeServerTlsConnectionManager_234EA8E> Incoming TLS negotiation failed. Exception: Exception: Microsoft.Rtc.Signaling.TlsFailureException
    > ErrorCode: -2146893052
    > FailureReason: Other
    > DetectionStackTrace:    at System.Environment.get_StackTrace()
       at Microsoft.Rtc.Signaling.TlsFailureException..ctor(String message, Exception innerException, Int32 errorCode, TlsFailureReason tlsFailureReason)
       at Microsoft.Rtc.Signaling.Helper.MapToTlsFailureException(TLSException exception)
       at Microsoft.Rtc.Signaling.RealTimeServerConnectionManager.CoreManagerIncomingTlsNegotiationFailed(IncomingTlsNegotiationFailedEventArgs e)
       at Microsoft.Rtc.Internal.Sip.SingleThreadedDispatcherQueue.DispatcherCallback(Object queue)
       at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
       at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
    > Message: The Local Security Authority cannot be contacted
    > Source: Microsoft.Rtc.Collaboration
    Inner Exception: Microsoft.Rtc.Internal.Sip.TLSException
    > ErrorCode: -2146893052
    > Message: incoming TLS negotiation failed; HRESULT=-2146893052
    > TargetSite: Void HandleNegotiationFailure(Int32, Boolean)
    > StackTrace:    at Microsoft.Rtc.Internal.Sip.TlsTransportHelper.HandleNegotiationFailure(Int32 status, Boolean incoming)
       at Microsoft.Rtc.Internal.Sip.TlsTransportHelper.IncomingTlsNegotiation(TransportsDataBuffer receivedData, TransportsDataBuffer& pDataToSend)
       at Microsoft.Rtc.Internal.Sip.TlsTransportHelper.NegotiateConnection(TransportsDataBuffer receivedData, TransportsDataBuffer& pDataToSend)
       at Microsoft.Rtc.Internal.Sip.TlsTransport.DelegateNegotiation(TransportsDataBuffer receivedData)
       at Microsoft.Rtc.Internal.Sip.TlsTransport.OnConnected(Object localEndPoint, Object remoteEndPoint)
    > Source: SIPEPS

     

    Currently we have three machines in the communication path.  The OCS server is a VM as is the mediation server.  The CUCM server is a seperate machine wholly, and all three are on the same subnet.  The mediation server as a result runs on one NIC.  Anyone have any thoughts on this?

     

    -TRM

    Thursday, October 7, 2010 11:48 PM

All replies

  • TRM,

     

    Juding by the error "Message: incoming TLS negotiation failed; HRESULT=-2146893052" I believe you are right.  Before we dive into that just a few things to cover.

     

    1. The mediation server recommended configuration is 2 NICs.  1 on the LAN and 1 on the voice subnet (the voice subnet NIC would not have a Default gateway or DNS typically).

    2. OCS 2007 R2 voice workloads are not supported in a virtualized environment.  Although it may "work" I've seen more problems come from this scenario and would recommend either going physical, or going with Lync where virtualization will be supported.

     

    For the TLS issue, a couple of things to check.

    1. Make sure the name of your CUCM server is an FQDN (i.e. cucm.domain.com) and the certificate subject matches that exactly

    2. Make sure the name the CUCM uses to get to your mediation server resolves as the appropriate IP and the certificate on that services matches

    3. Make sure the certificates are both issues by a CA the other identity trust.  This usually can be done frmo your internal CA, then you would just need to install the Root CA Cert from this CA onto your CUCM server.

     

    If all else fails try TCP to rule out a certificate issue, since inbound calling works it may just be routing related because the mediation server only has 1 NIC instead of the recommended two.  I've never used this configuration so can't say for sure if it would cause this issue.

     

    Hope this helps!

    -kp


    Kevin Peters blog: www.ocsguy.com MVP Communications Server, MCITP: Enterprise Administration | MCTS:OCS | MCSE | MCSA | CCNA
    Friday, October 8, 2010 1:47 AM
  • Well, all three servers (OCS front, mediation, and CUCM) are all on the same vlan, so that might get interesting.  We've been using the voice option internally for a few months now, seperate from the CUCM and it seems to do fine so far.  In talking with my co-workers, the certificates could still potentially be an issue, so I'm going to focus on that first and see what we get.

    Thanks for the comments, btw!

    -TRM 

    Friday, October 8, 2010 4:05 PM
  • so, I've verified the CUCM is listed as a proper FQDN, but I'm not seeing anything in the CUCM that deals with certificates.  Additionally, it seems that based on the failure listed above it's having problems contacting the CA, even though all of the OCS servers (FE & Med) have certs from the CA and the CA is also on the same VLAN.  We only have one SIP trunk, since we're only using one NIC on the mediation server.  TCP is running between the CUCM and the mediation server, we're only using TLS from FE to Mediation.  I'm looking for any discrepancies and really not finding anything to grab hold of so far.

     

    -TRM

    Sunday, October 10, 2010 9:59 PM
  • TRM,

    You say above that CUCM "is listed as a proper FQDN" and then below that "TCP is running between the CUCM and the mediation server".  On your next hop settings on the mediation server (OCS Admin Tools>Mediation Server>"Mediation Server Name">Properties) do you have the CUCM listed as TCP and have the IP address configured?  Also, is the CUCM configured for TCP. 

    Here's a reference screenshot for the Mediation Configuration:

    http://kptheocsguy.files.wordpress.com/2010/10/medsettingtcp.jpg

     

    Hope this helps!

    -kp

     


    Kevin Peters blog: www.ocsguy.com MVP Communications Server, MCITP: Enterprise Administration | MCTS:OCS | MCSE | MCSA | CCNA
    Monday, October 11, 2010 8:57 PM
  • CUCM is configured for TCP.  The sole SIP trunk is pointed at the correct IP (mediation server) and using port 5060.  For the Med server next hop I've got the FE listed on port 5061, and the PSTN is using the correct IP given to the CUCM, on port 5060, TCP.

     

    -TRM

    Monday, October 11, 2010 11:14 PM
  • Apparently KB975858 took care of the TLS errors on the mediation server.  We're moving on from there to complete the configuration/integration. Thanks.

     

    -TRM

    Monday, October 11, 2010 11:25 PM