locked
Received a failure sip response RRS feed

  • Question

  •  

    Hi All,

     

    I've been banging my head against this problem for a couple days now and I'm hoping someone might have some suggestions as to what I'm doing wrong - trying to run the front end server validation wizard, and I receive the following error:

     

    DNS Resolution succeeded: 192.168.200.17
    TLS connect succeeded: 192.168.200.17:5061
    Routing trust check and MTLS connectivity: Received a failure SIP response
    Routing trust check and MTLS connectivity: MTLS connection establishment succeeded but received a SIP
    failure response. This usually indicates lack of routing trust between the remote
    server and the current machine. Check the local and remote server certificates for any
    misconfiguration. In addition, check whether the local server is recognized
    as a trusted server by the remote server.

    Suggested Resolution: Routing trust check and/or MTLS connection establishment failed.
    This is usually caused by the remote server not accepting the certificate presented by the
    current machine. Check the local and remote server certificates for any
    misconfiguration. In addition, check whether the local server is recognized
    as a trusted server by the remote server.

    Here is what I know / have checked:

     

    - Both certificates are issued by our internal certificate authority

    - the edge server trusts the domain certificate authority (If I remove it as a trusted source I get a different error)

    - I get this error in the "Check all trusted servers" and the "checking global federation route" checks.  Seems like everything else is fine.  

    - The edge server validation wizard succeeds.

     

    I've read through the deployment guides a number of times, but can't seem to figure it out.

     

    Thanks in advance for any ideas.

     

    Rob.

    Friday, February 22, 2008 10:37 PM

All replies

  • Hi,

     

    Have you installed Root CA on the edge server? is Edge server part of the domain or in a workgroup?

     

     

    Ram Kinker
    MCSE 2003 - Messaging, MCTS- (LCS 2005 & OCS 2007)
    http://www.OCSPedia.com
    http://www.ITCentrics.com

    Sunday, February 24, 2008 7:34 AM
  • Hi,

     

    Thanks for the reply.

     

    As per the installation guide, the edge server isn't a member of the domain, but I've installed the root ca on it.  If I remove our CA from the edge server trusted root list, I receive a different error in the validation check (about the certificates not being issued by a trusted source).

     

    Any ideas?

     

    Cheers

    Rob.

     

    Monday, February 25, 2008 1:32 AM
  • Hi,

     

    I haven't seen this error before, have you tried doing any debug logging?  I would try setting up a debug log session on your front end server and your edge server, then run the validation wizard.  After the validation is complete, check the debug output on both servers. 

     

     

    -Joe
    Monday, February 25, 2008 1:15 PM
  • I got distracted from this for a while, but I think I've figured it out (of course it helps that microsoft published a kb explaining the problem). (;

     

    Basically, it looks like the fqdn of the internal interface must match the machine name on the edge server.  If you use a DNS A record to resolve the internal interface, you get this error.  I don't think this was spelled out clearly at all in the deployment guides which I guess is why they published the KB.

     

    Anyways, if anyone else has the problem, here is the KB in question:

     

    http://support.microsoft.com/kb/948260

     

     

    Rob.

     

    Thursday, March 6, 2008 4:41 PM
  • Did this actaully solve the problem, or does anyone else know if it fixes the issue?

     

    I get this message and I've tried various cert names and Subject names etc.

     

    The KB isn't worded properly and I find it confusing. E.g. I have an access adge server with the FQDN of edge.company.local but servers refer to it as edge.company.net

    So what should be on the certificate in the Subject name field and the SAN field? And is the article talking about checking just the hostname portion (edge) against WMI or is it the whole FQDN (edge.company.local)? And what is this WMI value exactly..?

     

    Thanks,

    Steve

    Thursday, April 10, 2008 11:00 PM
  • The EDGE Server needs to have certificates with Public FQDN of the EDGE Server so if external A Records are configured as edge.company.net you need to add edge.company.net in the certificate

     

    Friday, April 11, 2008 3:55 PM
  • I've changed things so that the Std OCS server looks for edge.company.local and the certificate has the following details:

    subject - edge.company.local

    SANs - edge.company.net,edge

     

    The validation works perfectly, but I still get Limited External Calling messages when I sign into Communicator. I believe this is down to audio traffic not reaching the right places? Do you have to force the edge server to send internal traffic from external remote users via the internal IP interface so that the OCS server 'sees' the traffic coming from inside the network?

     

    Steve

     

    Friday, April 11, 2008 4:08 PM
  • You need separate Certificates for your EDGE Server

     

    Certificate 1 (private certificate)

    Internal interface : edge.company.local

     

    Certificate 2 (public certificate)

    External interface : edge.company.net

    SANs edge.company.net & conf.company.net (external conferencing FQDN)

     

    Certificate 3 (private certificate)

    Internal AV Authentication : av.company.net (external FQDN of av authentication service)

     

    Did you run the Configure Pool wizard to add the EDGE Server configuration to the OCS Environment?

     

     

    Friday, April 11, 2008 6:52 PM
  • Yeah I ran the configure pool wizard, set it up for direct access (no director as it's just simple consolidated server setup) usual settings and ports. I still get this error:

     

    DNS Resolution succeeded: 172.16.0.9 85.189.xxx.xx

    TLS connect succeeded: 172.16.0.9:5061

    Routing trust check and MTLS connectivity: Succeeded

    TLS connect succeeded: 85.189.xxx.xx:5061

    Routing trust check and MTLS connectivity: Received a failure SIP response

    Routing trust check and MTLS connectivity:: MTLS connection establishment succeeded bu received a SIP failure response. This usually indicates lack of routing trust between the remote server and the current machine.

     

    It's the usual error and its telling me the routing trust check failed. So what exactly does this check do? I've a funny feeling it uses reverse lookup somehow as the error changes to 'Timed Out' when I modify the DNS settings to just point the external fqdn to the internal IP. So it's basically saying there's a problem with the external side of things? Which is why I get no federation and Limited External Calling messages on OC clients externally?

     

    Steve

     

     

     

    Saturday, April 12, 2008 9:21 AM
  • You may need to rerun the Configure Pool Wizard and configure External Access so that your EDGE Server and Pool can talk to each other

     

    Monday, April 14, 2008 11:21 AM