Help save net neutrality! Learn more.
Close

#55 Add HTTPS to autodiscover probe

closed-fixed
nobody
SIPE Core (15)
1
2013-03-02
2012-12-08
KwikSilvr
No

The autodiscover routine seems to cycle through 5061 & 5061, but my organization seems to use standard https (443/tcp). The "Ports Required by Office Communications Server" page on microsoft.com makes it sound like this would be in spec, so i think it would be a useful feature.

Discussion

  • Stefan Becker

    Stefan Becker - 2012-12-09

    Autodiscovery is based on DNS records (see --debug log), e.g. _sipinternaltls._tcp.company.com. Either your company a) doesn't have set up DNS records, or b) those DNS records are incorrect, or c) the DNS records are for SIP/VoIP, not for SIP/OCS.

    You'll have to use the server:port field on the Advanced Tab.

    Closing as INVALID.

     
  • Stefan Becker

    Stefan Becker - 2012-12-09
    • status: open --> closed-invalid
     
  • KwikSilvr

    KwikSilvr - 2012-12-11

    I disagree as closing this as invalid since the discovery mechanism is inferior when compared with the official client fro MS.

    I agree that my company's DNS configuration is suboptimal; they only have SRV records defined internally. So SIPE autodiscovery works in the office or on VPN. But not on an outside network. However, they do have public A records which the official client is able to use for discovery over the internet.

    The official client does the SRV lookups first:

    _sipinternaltls._tcp.<domain>
    _sipinternal._tcp. <domain>
    _sip._tls. <domain>
    _sip._tcp.<domain>

    If it does not find any SRV records it then queries the following A records:

    sipinternal.<domain>
    sip.<domain>
    sipexternal.<domain>

    If one of the A records resolves it attempts connection on 5061 followed by 443.

    The details are on microsoft.com if you want to look for them but here's a quick copy/paste:

    Which DNS record the client is first able to resolve and connect to depends largely on the user’s connection method. Typical OCS or Lync deployments publish an SRV record to internal DNS servers and to external DNS servers. Both SRV records point to an A Record and specify the appropriate port: 5061 for internal port and 443 for external port. If the client cannot resolve an SRV record, the client moves on to the A Records. Typically, OCS or Lync deployments publish the A Record, sipinternal.<sipdomain>.com, only to internal DNS servers. Similarly, the A Record, sipexternal.<sipdomain>.com, is only published to external DNS servers. However, the A Record, sip.<sipdomain>.com, is typically published to both internal and external DNS servers. Also, the A Record is frequently in associated SRV records. When the client tries to connect to the A Record, sip.<sipdomain>.com, the client will always do so over port 5061 first. If that fails, the client will try port 443. All external traffic must come in on port 443, but internal traffic will use port 5061.

     
  • KwikSilvr

    KwikSilvr - 2012-12-11
    • status: closed-invalid --> open-invalid
     
  • Stefan Becker

    Stefan Becker - 2012-12-11

    So M$, as usual, added something undocumented outside the standards, RFC2782/3263 in this case.

    Guessing from your copy & paste, you are referring to this M$ KB article <http://support.microsoft.com/kb/2619522>, which indicates that this has been added in OCS2007. There are no references in this article to where this behaviour is documented.

    This will require new implementation as DNS A records don't contain port numbers. Anyway, set to lowest priority as server:port works for these cases.

     
  • Stefan Becker

    Stefan Becker - 2012-12-11
    • priority: 5 --> 1
    • status: open-invalid --> open
     
  • Stefan Becker

    Stefan Becker - 2013-03-02

    Implemented in commit a3d8216. Leaving comment posting open for feedback.

     
  • Stefan Becker

    Stefan Becker - 2013-03-02
    • status: open --> closed-fixed
     

Log in to post a comment.