Dynamically Configured Mass Virtual Hosting

Contact: Jan Janak

Abstract

The goal of this work is to add support for dynamically configured mass virtual hosting to the sip-router server. Dynamically configured virtual hosting is a way of hosting a large number of virtual SIP domains on a single server without the need to change the configuration of the server. Such a server can figure out whether it is reponsible for a particular virtual SIP domain from DNS, adding support for a new SIP virtual domain requires no manual intervention by the server administrator.

State of the Art

The sip-router server can be configured with support for multiple virtual domains hosted on the same server. Currently there are two ways how it can be configured.

The first possibility is to list all supported domains in the configuration file, something along the following lines:

alias="iptel.org"
alias="sip.iptel.org"
alias="proxy.iptel.org"

The biggest disadvantage of this approach is that the server needs to be restarted for the changes to take effect. Thus, adding support for a new virtual domain requires a restart of the server.

The second option is to use the domain module. The domain module stores the list of all supported virtual domains in the database. The table named 'domain' contains the list of all domains supported by the sip server. To add support for a new domain, the administrator of the sip server has to add the new domain to the table.

This is better then the first approach, because the contents of the table can be reloaded on the fly, there is no need restart the server. But still, the administrator of the server has to enter virtual domains into the database manually and from time to time he/she has to check if the contents of the table matches domain names configured in DNS.

Goals

The goal of this work is to make this process fully automatic, without the need to change the configuration file or the entries in the database.

If the sip-router server receives a request for a domain that is not on the list of supported domains then the domain module can lookup the SRV record for _sip._udp (or other supported SRV records) in that domain and if it points to the server itself then the server is reponsible for the domain. In such case the domain module will add the domain to the list of supported domains automatically.

Deliverables

  • We will extend the sip-router domain module with a function which gets as a hostname as an argument and consults DNS to determine whether the hostname should be part of a new or existing virtual domain supported by the server.
  • We will modify the domain module to add missing entries into its internal memory cache of supported virtual domains.
  • We can enhance the module and make it synchronize the contents of the internal memory cache with the contents of the database. Newly added virtual domain (dynamically learned) will be added to existing entries in domain table.
  • We can implement a periodic house-keeping function to disable or remove virtual domains or domain names that no longer

appear to exist in DNS.

  • Devise a system for storing additional configuration information about virtual domains in the DNS zone of a domain. The additional information we might want to store in the DNS zone comes in form of attribute-value pairs, it can be used, for example, to configure the unique id of the virtual domain, peering policy, various options related to digest authentication, and so on.

Reading List

  • The domain module documentation
  • RFC 3263: Locating SIP Servers
  • RFC 2782: A DNS RR for Specifying the Location of Services (DNS SRV)A DNS RR for Specifying the Location of Services (DNS SRV)
  • RFC 2915: The Naming Authority Pointer (NAPTR) DNS Resource Record
  • RFC 1035: Domain Names - Implementation and Specification

Navigation

Wiki

Other

Personal Tools