Medianet Service Discovery and Auto-Registration: Building the dynamic media system – Part 1

We’re already seeing the beginnings of the transition from unified communications to pervasive video. Companies are not only starting to leverage video to enhance their communication experience but also they are finding new and innovative ways to leverage video to improve business operation and improve customer interaction. You only have to walk into a retail store or get on public transport to see video being used at the heart of the customer experience. As video becomes more ubiquitous this will drive two trends that impact how video endpoints and applications are deployed.

The first is the need to simplify deployment of those IP enabled endpoints. Deploying large numbers of video endpoints, often in a diverse range of locations and by personnel who are not skilled in IT and network deployment. We’ve already seen enhancements in earlier versions of medianets that enable devices such as surveillance cameras and digital media players that enable the installer to plug the devices in and have the network configuration automatically applied to the switch port. This simplifies the network configuration but challenges still remain in configuring the endpoint or application to connect to and register to application services. To address this issue, there are a number of service discovery mechanisms that can enable a newly deployed endpoint or application to automatically discover and register to its application server.

One option is DHCP service discovery. This involves the endpoint automatically requesting the address of its application server by making a DHCP service discovery request using options 43 and 150. This is ideal for the corporate environment which has a DHCP server where the addresses of the application servers can be configured centrally. A second option is DNS Service Discovery (DNS-SD) which is related to multicast-DNS. As with DHCP Service discovery, DNS-SD enables the endpoint to send a DNS query to learn about the address of its application server. This is particularly useful when the endpoint is not on the corporate network but it is also already used by devices such as Apple i-Phones that enable them to learn about services on devices its not directly connected to.

Stay tuned, as we continue our discussion on the second part of this blog!

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.