Differences

This shows you the differences between two versions of the page.

--- tbd:mass_virtual_domains [2009/04/29 00:35]
janakj
+++ tbd:mass_virtual_domains [2009/04/29 15:46] (current)
janakj
@@ Line 3: / Line 3: @@
 **Contact**: [[jan@iptel.org|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. The domain module of sip-router maintains a
+domains hosted on the same server. Currently there are two ways how it can
-list of all supported domains.
+be configured.
-Currently, the domain module stores the list of all supported virtual domains
+The first possibility is to list all supported domains in the configuration
-in the database. The table named 'domain' contains the list of all domains
+file, something along the following lines:
-supported by the sip server. To add support for a new domain, the
+<code>
-administrator of the sip server has to add the new domain to the table.
+alias="iptel.org"
+alias="sip.iptel.org"
+alias="proxy.iptel.org"
+</code>
+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.
-This is often not necessary, because we can try to figure out whether a domain
+The second option is to use the ''domain'' module. The domain module stores
-is local by consulting the DNS. If the sip-router server receives a request
+the list of all supported virtual domains in the database. The table named
-for a domain that is not on the list of supported domains then the domain
+'domain' contains the list of all domains supported by the sip server. To add
-module can lookup the SRV record for _sip._udp in that domain and if it points
+support for a new domain, the administrator of the sip server has to add the
-to the server itself then the server is reponsible for the domain. In such
+new domain to the table.
-case the domain module will add the domain to the list of supported domains
-automatically.
-The advantage of this approach is that there is no need to modify the contents
+This is better then the first approach, because the contents of the table can
-of the database each time a new domain is added to the system.
+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.
-The goal of this work is to extend the domain module with support for
+===== Goals =====
-dynamically configured virtual domains that have not been pre-configured in
+The goal of this work is to make this process fully automatic, without the need
-the database, but have been obtained from DNS instead.
+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.
-In version 2 the domain module should also check the TTL of DNS records and
+==== Deliverables ====
-delete dynamically configured virtual domains if the records do not point to
+  * 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.
-the server anymore.
+  * 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 [[http://kamailio.org/docs/modules/devel/domain.html|documentation]]
+  * [[http://www.ietf.org/rfc/rfc3263.txt|RFC 3263]]: Locating SIP Servers
+  * [[http://www.ietf.org/rfc/rfc2782.txt|RFC 2782]]: A DNS RR for Specifying the Location of Services (DNS SRV)A DNS RR for Specifying the Location of Services (DNS SRV)
+  * [[http://www.ietf.org/rfc/rfc2915.txt|RFC 2915]]: The Naming Authority Pointer (NAPTR) DNS Resource Record
+  * [[http://www.ietf.org/rfc/rfc1035.txt|RFC 1035]]: Domain Names - Implementation and Specification
+  * [[http://www.dns.net/dnsrd/rfc/|DNS related RFCs]]

Trace:

Differences

Navigation

Search

Toolbox

QR Code