locked
Live Meeting not using SRV record RRS feed

  • Question

  • Hi All,

     

    I've got an OCS System (FE/MED/EDGE) with multiple sip domains configured.

     

    On the edge server, I have certificates for sip.mydomain.net, webconf.mydomain.net and avconf.mydomain.net.

    I also have the domain otherdomain.com.

     

    I have added a DNS SRV record as follows

     

    _sip._tls.otherdomain.com 443 sip.mydomain.net

     

    Office Communicator access from External works fine with this. However, when somebody from otherdomain.com invites an anonymous user to use Live Meeting, the following happens (I did a network trace from the Live Meeting Client)

     

    The live meeting client does a DNS SRV lookup for _sip._tls.otherdomain.com and gets sip.mydomain.net back

    It does a DNS lookup on sip.mydomain.net and gets the correct IP address back.

     

    It then seems to ignore these entries, and tries to find sipinternal.otherdomain.com, sipexternal.otherdomain.com and sip.otherdomain.com. All of these records do not exist.

     

    If I add the host record sip.otherdomain.com, the certificate is then wrong on the EDGE server, as it is issued to sip.mydomain.net.

     

    I'm sure if I added the sip.otherdomain.net certificate to the edge server, it would work. However, this is a hosting server, which will eventually cater for 100's of sip domains, and I don't fancy changing the certificate each time a new domain is added.

     

    According to the OCS documentation, the Live CMeeting Client uses the same DNS approach as the Office Communications Client, therefore I don't understand why Communicator works (and uses the aforementioned SRV record) but Live Meeting doesn't

     

    Any help would be greatly appreciated,

     

    Yours,

     

    Alginald

    Wednesday, October 15, 2008 7:17 AM

Answers

  • the A record returned by the SRV record has to match your SIP domain, if it doesn't than communicator/livemeeting will ignore it and proceed with the A-records.

     

    In your case the service record for john.doe@otherdomaim.com returns sip.mydomain.net which doesn't match the SIP domain (otherdomain.com) and fails. You should see error messages about this in your eventlog.

     

    by the way did you happen to configure your communicator client manually as it seems you where able to connect successfull this way?

     

    Sincerely,

    Tonino Bruno

    Wednesday, October 15, 2008 12:13 PM

All replies

  • Alginald,

     

    Unfortunately you need to ensure that your A-record matches your SIP domain, so in your case the DNS configuration should look like:

     

    _sip._tls.otherdomain.com 443 sip.otherdomain.com

    _sip._tls.mydomain.net 443 sip.mydomain.net

     

    on the EDGE certificate you will need to add both sip.otherdomain.com and sip.mydomain.net

     

    The only way to workaround this is to manually configure your communicator/livemeeting clients with the correct server FQDN but I understand this is difficult to manage for your "anonymous" participants. Perhaps you can create a "package"  that your anonymous participants can download and install which would automatically configure these server FQDN's.

     

    I've been looking at the HMC deplloyment of OCS and it seems they also require you to manually configure the clients. Automatic Discovery through SRV records doesn't seem to be feasible in hosted mode.

     

    Sincerely,

    Tonino Bruno

     

     

    Wednesday, October 15, 2008 8:56 AM
  • Hi Tonino,

     

    Thanks for the quick answer, however, when I read the documentation, it actually says something different...

     

    (From http://technet.microsoft.com/en-us/library/bb870389.aspx)

     

    Says...

     

    A DNS SRV (service location) record for _sip._tls.<domain>, over port 443 where <domain> is the name of your organizations SIP domain. This SRV record must point to the A record of the Access Edge Server. If you have multiple SIP domains, you need a DNS SRV record for each domain. This SRV record supports external user access through Office Communicator and the Live Meeting client.

     

    And then regarding the A record...

     

    For each supported SIP domain in your organization, an external DNS A record for sip. <domain> that points to the external interface of the Access Edge Server and resolves to the external IP address on the firewall. If you have multiple SIP domains, you need a DNS A record for each. If a client cannot perform an SRV record lookup to connect to the Access Edge server, it uses this A record as a fallback.

     

    Now what you are telling me, is that it doesn't use the A record as fallback, but that it needs to have it all the time. Or better said, the documentation from Microsoft is wrong. Correct?

    Wednesday, October 15, 2008 9:11 AM
  • The documentation is correct. If the client cannot perform an SRV record lookup it will do a A-record lookup in the form of SIP.<Domain>. The <domain> would be your SIP domain.

     

    So in your case you would create 2 different A-records:

     

    sip.otherdomain.com

    sip.mydomain.net

     

    each pointing to the same IP Address being the external interface of your Edge server.

     

    Your srv records would be

    _sip._tls.otherdomain.com --> sip.otherdomain.com

    _sip._tls.mydomain.net --> sip.mydomain.net

     

    In addition you will need to add these A records into your Edge certificate to ensure the TLS connection can be established.

     

    As a security measure Communicator and Livemeeting will verify if the server FQDN received through DNS matches the SIP domain you are trying to logon with. If you look at the eventviewer you should have an event-id that reflects this.

     

    Sincerely,

    Tonino Bruno

    Wednesday, October 15, 2008 11:02 AM
  • But in my case, it can do an SRV record lookup, which succeeds. Therefore it should not need to fallback to A records.

     

    The first DNS query that the client does is and SRV for _sip._tls.otherdomain.com which returns sip.mydomain.net port 443

    It then does a lookup on sip.mydomain.net and gets the ip address www.xxx.yyy.zzz

     

    This, in my opinion is a successful SRV lookup, and therefore does not need to fallback to A records.

     

    However, the next DNS lookup is for sip.otherdomain.com.

     

    Could it be that you mean that if the domain name returned by the SRV record lookup is not the same domain name as in the SRV record, the Live Meeting client ignores it?

     

    Thanks again,

     

    Alginald

    Wednesday, October 15, 2008 11:10 AM
  • the A record returned by the SRV record has to match your SIP domain, if it doesn't than communicator/livemeeting will ignore it and proceed with the A-records.

     

    In your case the service record for john.doe@otherdomaim.com returns sip.mydomain.net which doesn't match the SIP domain (otherdomain.com) and fails. You should see error messages about this in your eventlog.

     

    by the way did you happen to configure your communicator client manually as it seems you where able to connect successfull this way?

     

    Sincerely,

    Tonino Bruno

    Wednesday, October 15, 2008 12:13 PM
  • Alginald,

     

    Take a look at this article which walks through the process of how Automatic Configuration works on the OC client.  The Live Meeting client follows the same rules:

     

    http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=14

     

    If no SRV record is found then the fall-back is to look for standard DNS name records in the following order:

    • sipinternal.domain.com
    • sip.domain.com
    • sipexternal.domain.com
    Wednesday, October 15, 2008 12:35 PM
    Moderator
  • Jeff, thank you for the link, but once again, it states "If no SRV record is found". In my case, the SRV record IS found.

     

    Tonino, thank you for your answer, this is what I was looking for. I have not found this information anywhere.

     

    So, if the Service Record returns a pointer to a different domain, Live Meeting client ignores it, cool,

     

    Thanks again,

     

    Alan

    Wednesday, October 15, 2008 1:13 PM
  • Is there a reason you aren't putting all of your SIP domains in the SAN field on the Access Edge certificate?

    Wednesday, October 15, 2008 1:27 PM
    Moderator