internal sip domain differs from external domain, SRV records RRS feed

  • Question

  • Hi,
    We have a OCS R2 pool deployed in the internal network and a single edge server in a perimeter-network.
    the SIP uri used is someone@local.domain.tld but we use a automatic translation for the e-mails to someone@domain.tld
    What SRV record should I create ? _sipfederationtls._tcp.local.domain.tld or _sipfederationtls._tcp.domain.tld ?
    Changing the SIP URI is absolutly not an option.
    Could you also provide me with the link to the forms for the PIC provisioning ?

    Thank you very much,

    Wednesday, April 8, 2009 2:41 PM

All replies

  • To support Automatic Configuration the internal SRV record should be "_sipinternaltls._tcp.local.domain.tld" as the domain in the FQDN needs to match the user's domain name.  This is asuming you have setup local.domain.tld as a SIP domain within OCS.

    For PIC you can follow the links on this page:
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, April 8, 2009 6:11 PM
  • All SRV records must match with your SIP domain
    You should actually use your email domain as the sip domain (you don't want to confuse federated users with wrong email/sip addresses)

    - Belgian Unified Communications Community : http://www.pro-exchange.be -
    Wednesday, April 8, 2009 10:43 PM
  • Thank you for replying,

    I would like to understand how public IM users will be able to add the OCS internal user, because if they try to add someone@domain.tld, how the edge will understand that it is actullay someone@local.domain.tld ? Where is the translation done ? With the SRV ?

    Totaly different question,

    TLS outgoing connection failures.

    Over the past 30 minutes Office Communications Server has experienced TLS outgoing connection failures 3 time(s). The error code of the last failure is 0x80090308 (The token supplied to the function is invalid) while trying to connect to the host "federation.messenger.msn.com".
    Cause: Wrong principal error could happen if the peer presents a certificate whose subject name does not match the peer name. Certificate root not trusted error could happen if the peer certificate was issued by remote CA that is not trusted by the local machine.
    For untrusted root errors, ensure that the remote CA certificate chain is installed locally. If you have already installed the remote CA certificate chain, then try rebooting the computer.

    I've seen this question left unreply on an other thread, I hope I will be luckier.
    My certificate SN matchs the FQDN, the CA is rapidssl.com

    Thank you very much

    Thursday, April 9, 2009 8:05 AM
  • There is no translation performed on the SIP domain; whatever SIP domain you have activated and set for users is what must be used for DNS records.  In your case you will want to add domain.tld as a SIP domain and use that for all users accounts.  As Johan stated you should ideally be using the same namespace as your SMTP addresses for SIP.

    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Thursday, April 9, 2009 12:31 PM
  • So does that mean you cant use autoconfigure if you arent using split brain DNS?
    Monday, April 20, 2009 5:06 PM
  • No, on the contrary a split DNS setup works BETTER for Automatic Configuration as using the same records internally and externally causes problems for the client.  A typical deplyoemt would use something like pool1.company.local for an internal server FQDN (Enterprise FE pool) and sip.company.com for the external FQDN.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Monday, April 20, 2009 5:51 PM