[sr-dev] domain attributes

Jan Janak jan at iptel.org
Thu Jul 2 14:03:13 CEST 2009


Juha,

On 02-07 14:33, Juha Heinanen wrote:
> i'm thinking of extending domain module to support domain attributes.
> the idea is that domain_reload would also load domain's attributes to
> memory, where they can be accessed fast without db operations.  when
> is_domain_local(domain) is called, attributes of the domain would get
> automatically loaded into avps.

I think that this is a good idea and also something we have already done in
the ser version of domain module. What about adopting the ser version of the
domain module?

> if people consider this worth implementing, the next question is, where
> in the db domain attributes would be stored.  it might be possible to
> use avpops usr_preferences table, but it contains fields uuid and
> username that are not relevant for domain attributes.  perhaps a special
> uuid and/or username value could be used to denote that the record
> defines a domain attribute?  if not, a new table would need to be
> created, which might be cleaner anyway.

In SER we introduced a new table called domain attrs. Our version of domain
module has been extended this way:

1) We added column did to the domain table. did stands for "domain
identifier" and it uniquely represents virtual domains within
SER. Retrospectively I think "did" was a bad name, because in traditional POTS
world it has a different meaning (which I didn't know when I added it).

Our domain table looks like this:

mysql> describe domain;
+--------+------------------+------+-----+---------+-------+
| Field  | Type             | Null | Key | Default | Extra |
+--------+------------------+------+-----+---------+-------+
| did    | varchar(64)      | NO   | MUL | NULL    |       | 
| domain | varchar(128)     | NO   | PRI | NULL    |       | 
| flags  | int(10) unsigned | NO   |     | 0       |       | 
+--------+------------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

Every virtual domain (represented by did) can have a number of domain names
assigned and they are all treated equally by all other SER modules. For
example, here is how the iptel.org domain can be represented in the domain table:

mysql> select * from domain where did=3;
+-----+-----------------+-------+
| did | domain          | flags |
+-----+-----------------+-------+
| 3   | iptel.org       |    33 | 
| 3   | sip.iptel.org   |    33 | 
| 3   | proxy.iptel.org |    33 | 
+-----+-----------------+-------+
3 rows in set (0.00 sec)

In all other tables in the SER database schema we replaced column 'domain'
with 'did'. Thus, I can be reached as 'sip:jan at iptel.org',
'sip:jan at sip.iptel.org', or 'sip:jan at proxy.iptel.org'.

All extra configuration information for virtual domains is then stored in
domain attributes that are stored in domain_attrs table:

mysql> describe domain_attrs;
+-------+------------------+------+-----+---------+-------+
| Field | Type             | Null | Key | Default | Extra |
+-------+------------------+------+-----+---------+-------+
| did   | varchar(64)      | YES  | MUL | NULL    |       | 
| name  | varchar(32)      | NO   |     | NULL    |       | 
| type  | int(11)          | NO   |     | 0       |       | 
| value | varchar(255)     | YES  |     | NULL    |       | 
| flags | int(10) unsigned | NO   |     | 0       |       | 
+-------+------------------+------+-----+---------+-------+
5 rows in set (0.00 sec)

The contents of domain_attrs is loaded into the memory by domain
module. Domain attrs are always cached and they can be reloaded from the
database with a rpc/mi command.

For example, we store digest authentication realm for each virtual domain in
that table:

mysql> select * from domain_attrs where did=3;
+------+--------------+------+-----------+-------+
| did  | name         | type | value     | flags |
+------+--------------+------+-----------+-------+
| 3    | digest_realm |    2 | iptel.org |    33 | 
+------+--------------+------+-----------+-------+
1 row in set (0.01 sec)

This allows us to configure the digest authentication realm separately from
the domain name. This can be used, for example, to share digest authentication
realm across multiple domain, we can keep the realm when we change the domain
name, etc.

If this is what you are after then I would suggest to adopt the ser version of
domain module.
 
   Jan.



More information about the sr-dev mailing list