Issue with Live Meeting only using port 443 and not 5061 when external RRS feed

  • Question

  • I seem to have hit a bit of an odd situation and wonder if other people have had the same issue and if there are any fixes\work arounds

    Under some circumstances, particular to this customer, an external live meeting client is able to resolve both the srv record for internal and external addresses.

     _sipinternaltls._tcp.company.com => resolves to  sipinternal.company.com (The client is not able to route to this address as it is external)
     _sip._tls.company.com => resolves to sip.company.com (The edge server which the client is able to connect to)

     The access edge box listens only on port 5061.

    This seems to cause the following behavior

    Looking at the network traces live meeting attempts to connect to sipinternal.company.com on 5061 (which fails as the client is external) and then it tries sip.company.com on 443 (Which fails)

    When the client is only able to resolve
    _sip._tls.company.com => resolves to sip.company.com it works perfectly and it uses port 5061.

    Finally if the live meeting client is hard coded for the servers to use again it works perfectly and uses port 5061 for the external address.

    Is the failure to use port 5061 a fault with the client and is there a fix or does anyone have any other suggestions?
    (Communicator 2007 does not show this problem)

    Thanks for any help

    Tuesday, June 16, 2009 9:59 AM

All replies

  • Is the external SRV record configured for Port 443 or 5061?  I can't tell if you are saying you can't get Live MEeting to attempt connectiong to the desried port (5061) or that it is trying that but failing to connect?

    I' assuming you are not using Federation and have changed the Access Edge lisenting port to 5061 (from the default of 443).  Have you also changed the Web Conferencing listnening port to something other than 443?  The Live Meeting client will sign-in to the advertised Acecss Edge service first, then connect to the FQDn passed in-band for Webconf services.

    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Tuesday, June 16, 2009 12:23 PM
  • SRV points to 5061.
    You have triggered a few thoughts for me to try re DNS.

    It is far from ideal _ basically issue is with split tunnel vpn plus there is split DNS.
    There are good reasons behind the setup! (Relating to voice call quality when VPN is running)

    If you didn't have an srv records and just had a record sip.company.com
    What port would live meeting default to using? 5061 or 443.


    Tuesday, June 16, 2009 2:08 PM
  • By default when Office Communicator connects to an internal server they communicate to the server via 5061, when they are connected externally they connect via 443.

    The main caveat is that if you use Manual Configuration then you need to specify the port on the external server setting as 443, otherwise it will default to 5061.  So a proper Manual Configuration example would be:

    Internal Servername or IP Address: ocspool.contoso.local
    External Servername or IP Address: sip.contoso.com:443

    Also, the network trace info is interesting as the clients don't make multiple connection attempts to subsequent FQDNs.  Only the DNS lookup portion has any type of steps like that.  Once a valid DNS entry (either SRV or fall-back A records) is resolved, the client will immediately attempt connection to that host.  If the connection fails is does not go back to the DNS process and look for other potential hosts, it will only connect to the first record it resolves.

    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Tuesday, June 16, 2009 2:27 PM
  • Thanks Jeff _ leave this with me to have a "play with".
    I am actually seeing the client attempting multiple connection attempts. (I have also turned on logging and seeing in the event log the client starting attempling connection to ocspool.contoso.local, 5061 and then sip.contoso.com, 443. Also seeing in net monitor)

    Tuesday, June 16, 2009 2:34 PM
  • Are you using Manual configuration?  I believe the client will attempt an 'internal' connection first, then followed an 'external' connection.  The client never really has any idea of whether it's 'internal' or 'external', so the assumption that an internal server will only be available internally allows the client to first assume it can reach the Front-End server, and if that fails then it will try to locate an Edge server assuming it's outside of the network.

    With Automatic Configuration it's the configuration of DNS records and the ability to resolve them correctly that tells a client whether it's internal or external, based on what it can locate.  That's why not using a split-brain DNS configuration can cause all sorts of sign-in issues if the internal FQDN is resolvable outside the network (not reachable, but just A-to-IP resolvable).

    I have some more details on the process here:

    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Tuesday, June 16, 2009 2:46 PM