Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
tbd:mass_virtual_domains [2009/04/28 16:10] janakj created |
tbd:mass_virtual_domains [2009/04/29 15:46] (current) janakj |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Dynamically Configured Mass Virtual Hosting ====== | ====== Dynamically Configured Mass Virtual Hosting ====== | ||
| + | **Contact**: | ||
| + | ===== 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=" | ||
| + | alias=" | ||
| + | alias=" | ||
| + | </ | ||
| + | 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 '' | ||
| + | the list of all supported virtual domains in the database. The table named | ||
| + | ' | ||
| + | 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 | ||
| + | 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, | ||
| + | |||
| + | ===== Reading List ===== | ||
| + | * The domain module [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
