Service discovery (Integrated Mode)
Similar to the discovery process between the ConnectStations, the smartphone clients running our MobileConnect/CinemaConnect App (“the App”) need a way to find at least one ConnectStation in your network. The process is roughly similar to the cluster discovery described above, except the DNS SRV records are accompanied with a single PTR record to adhere to the DNS-SD specification more closely. Finally, the App can discover the ConnectStation cluster via DNS A records (i.e., “hostnames”).
Order of methods for Service Discovery
The discovery process again follows a strict order:
1. Explicit DNS-SD (PTR/SRV)
When starting up, the App will query your DNS for
_cnct._tcp PTR records. If it finds entries, it will resolve the corresponding
SRV records and try to connect to any of the specified server(s).
2. Multicast announcement on overridden address
If no DNS PTR records are found, or none of the specified servers are reachable, it will query your DNS for a
_cnct._udp SRV record that can specify the multicast group and port for discovery. If found, it will use these values for the discovery process as described below.
3. Multicast announcement on default address
If not specified in your DNS, it will use the default multicast group address
224.2.2.2 and port
32001 for the discovery process as described below.
4. Simple hostname “sennheiser-connect”
If none of the methods above yield a valid result, the App will try to resolve the hostname
“sennheiser-connect” (searching within any search domains given via DHCP). If it can be resolved, it will connect to this station.
5. hostname/TLD “local.connect”
As a last resort, the App will try to resolve the hostname “local.connect”.
6. Pause, repeat
Finally, if all of the method fails, the App will pause and restart the discovery from step 1.
Explicit service registration via DNS-SD (PTR/SRV)
Explicit Service Registration is the preferred discovery method because it is standardized, explicit and usually well understood. It closely follows the DNS-SD specification (RFC6763 - see:
At the moment, only a single service name should be registered with a PTR record; multiple SRV records can be set to provide redundancy. The service name for MobileConnect/CinemaConnect discovery by Apps is
_cnct._tcp. Contrary to Cluster Discovery (see
"Cluster discovery (Integrated Mode)"), Apps will not directly look up a SRV record for _cnct._tcp, but instead take the indirection via a PTR record. Also, the ConnectStations registered via this method do not assume the “server” role for clustering; instead, any ConnectStation in a cluster can serve as the entry point for service discovery. If multiple SRV records are found, the App will probe them until it finds a station that is available. Apps will honor any search domains set via DHCP.
Example:
1. Let‘s assume that you want to register a cluster of three ConnectStations in your DNS. They discover each other with any of the Cluster Discovery methods described above.
2. Your DHCP hands out IP addresses to the ConnectStations connected via their LAN2 port- we’ll assume they are: 192.168.0.101, 192.168.0.102 and 192.168.0.103.
3. Your DHCP sets the domain field (DHCP Option 15) to an arbitrary domain name, let’s assume it is “your-domain.com”.
4. The ConnectStations form a valid cluster via a Cluster Discovery method described above.
5. Create a PTR entry with an arbitrary name for a service instance that adheres to the DNS-SD specification; here, we use the name “XConnect”. Set the TTL to a sane value according to your network requirements.
► 
6. Create SRV entries for some or all of the ConnectStation in your cluster. The priority and weight field are currently irrelevant. Set the TTL to a sane value according to your network requirements. Set the port to 8000:
► 
7. When started up, the App will discover all registered ConnectStations via these entries and try each of them in turn until at least one responds. It will serve as the entry point for all streaming channels on the cluster.
Automatic discovery via multicast announcement
When no DNS PTR records for _cnct._tcp are found, the App will resort to listening for multicast announcement packets on the same multicast address and port as used for Cluster Discovery. See above for details and information about overriding the default group address and port. The ConnectStation that is sending the multicast announcements (the cluster server) will be used as the entry point for all streaming channels on the cluster.
Note: ConnectStations only send the multicast announcements when they aren’t clustered with each other via a DNS method, so Service Discovery via multicast announcement works only if multicast announcements are also used for Cluster Discovery!
Discovery via hostname “sennheiser-connect”
As a third option, you can register a single ConnectStation to be the entry point for Apps by registering it’s IP as a DNS A record (or indirectly via a CNAME record):
Example:
1. Your DHCP hands out IP addresses to the ConnectStations connected via their LAN2 port- we’ll assume they are: 192.168.0.101, 192.168.0.102 and 192.168.0.103.
2. Your DHCP sets the domain field (DHCP Option 15) to an arbitrary domain name, let’s assume it is “your-domain.com”.
3. The ConnectStations form a valid cluster via a Cluster Discovery method described above.
4. To select a ConnectStation as entry point for the App, register an A record to its IP address under one of your search domains:
► 
5. Alternatively, register a CNAME and an arbitrary host name for the ConnectStation:
► 
► 
Discovery via hostname “local.connect”
The final service discovery was used by ConnectStation releases prior to 3.0.0 supported mainly for legacy installations. Similar to the “sennheiserconnect” hostname, a single ConnectStation serves as the entry point for Apps. It has to be registered with hostname “local” under the top-level domain “.connect”.
► 
Note: Registering “.connect” as a subdomain of an existing domain, i.e. registering the host “local.connect.your-domain.com” will not work with iOS clients.
DHCP and DNS Search Domains
If you opt for a Cluster and/or Service Discovery method that uses DNS-SD or SRV records, please make sure you correctly set the search domains via DHCP for the Clients. If you use static IP configuration on the ConnectStation, make sure you set the “Search Domains” field correctly.
Setting a single Search Domain with DHCP Option 15
If you only need a single DNS search domain, simply set it via DHCP Option 15. This is standardized and well supported across all operating systems. Again, if you use static IP Configuration for LAN2 on a ConnectStation, make sure you manually set the “Search Domains” field there.
Setting multiple Search Domains
Most Operating Systems allow multiple search domains for their DNS lookups which will be used one by one for DNS lookups. By standardization, the DHCP Option 15 allows setting only a single domain, and there is a further DHCP Option (119) to set multiple additional search domains.
Note: We found that Option 119 is not supported widely enough to be functional for the purposes described here. Most notably, Android smartphones ignore the option completely in all versions we tested (4.1 to 6.0.1).
If you do need to set multiple search domains, we can suggest to add multiple search domains separated by space characters into DHCP Option 15. From our tests, this correctly works across iOS versions, it works for the ConnectStation, and it “mostly works” for Android clients. Although our tests have not been exhaustive, Windows-based clients seem to ignore any domain after the first entry in this list.
On Android, our Apps (MobileConnect and CinemaConnect) correctly use the full list of search domains passed via Option 15 to look up PTR and SRV records. Discovery via hostname “sennheiser-connect” works only if the hostname is configured with the first domain in the list.
Beware though that this use of Option 15 is outside the standard use of DHCP, yet seems a common practical solution to setting multiple search domains. If you have services in your network that depend on the primary domain setting from DHCP, make sure to test these after setting multiple domains.