locked
DNS Entries Needed for Hosted OCS Deployment - Provide Auto-Config Connection for Client Console RRS feed

  • Question

  • Hi all, I am running OCS through its paces with IM and Web Conferencing and I sent out a Web Conferencing invitation to someone external.  They are unable to connect, which makes sense due to the fact that their Advanced Connection Options settings don't point to my OCS Server for usage.  So this begs the question...What DNS entries are required to provide external Web Conferencing user with a successfull connection?

     

    If DNS entries aren't possible, would entering the FQDN of the OCS Server in the Advanced Connection Options settings be sufficient to instruct the console to connect to the invited meeting?  Of course, if the user is also participating in other OCS meetings, they will have to change this setting in order to connect to different internal/external OCS meetings.

     

    Can anyone please advise me in this scenario regarding what DNS entries will provide a successfull connection and logon when using the Advanced Connection Options.

     

    Thanks

    ....Ryan

    Monday, July 23, 2007 6:37 AM

Answers

  • I can't comment on whether this is a bug or documentation error.  However, SRV records have been in the RFC for quite a while and have been supported by Bind since 4.9.7 (released in 1998-1999 time frame).  I would suggest taking a closer look at your DNS environment to see if there's any way you can get somewhat up to date there.
    Thursday, July 26, 2007 4:27 PM
    Moderator

All replies

  • The answers to these questions are outlined starting at the bottom of page 69 in the Planning Guide.  Take a look at that and let us know if you have follow-up questions.
    Monday, July 23, 2007 2:00 PM
    Moderator
  • Mike,

     

    Thanks for your guidance.  We have followed the Planning and Deployment Guides, and encountered the following text specific to DNS entries required for client connectivity:

    Client DNS Queries

    During DNS lookup, SRV records are queried in the following order:

    1.          _sipinternaltls._tcp.domain - for internal TLS connections

    2.         _sipinternal._tcp.domain - for internal TCP connections (performed only if TCP is allowed)

    3.         _sip._tls.domain - for external TLS connections

    4.        _sip._tcp.domain - for external TCP connections

    If any query succeeds, the client uses the SRV record that is returned and does not continue querying for any other SRV records.

    After the SRV record is returned, a query is performed for the DNS A record for the host name that is returned by the SRV record. If no records are found during the DNS SRV query, the client performs an explicit lookup of sip.domain. If the explicit lookup does not produce results, the client performs a lookup for sipinternal.domain. If the client does not find sipinternal.domain, it performs a lookup for sipexternal.domain.

     

    Our problem is that our non-Microsoft DNS server DOES NOT SUPPORT SRV RECORDS.  Therefore we have created A records for our servers for "sip.domain" as above assuming that the client will explicitly query for this A record once the SRV record queries fail.  However, we are finding that these queries do not occur - a packet sniffer run after an ipconfig /flushdns shows the four SRV record queries as above in order, but then the client returns an error message, without making any of the three explicit A record queries mentioned above.  What's going on here, is this an error in the documentation, or an error in the behaviour in the client, and will this be fixed for GA?  This will cause serious problems for any organizations that do not or cannot implement SRV records.

     

    Thanks, Ben.

    Wednesday, July 25, 2007 2:50 PM
  • I can't comment on whether this is a bug or documentation error.  However, SRV records have been in the RFC for quite a while and have been supported by Bind since 4.9.7 (released in 1998-1999 time frame).  I would suggest taking a closer look at your DNS environment to see if there's any way you can get somewhat up to date there.
    Thursday, July 26, 2007 4:27 PM
    Moderator
  • Its a bug and is fixed now, are you using the RC version of Communicator client?

    I had the same problem with no SRV support from my DNS provider.

    I'm using an A record for sip.domain and its working fine.

    Cheers

     

    Thursday, August 2, 2007 8:32 AM