Domain Policy Module

This is URL of the database to be used.

Default value is “mysql://openserro:openserro@localhost/openser”

modparam("domainpolicy", "db_url", "postgresql://openserro:pass@db_host/openser")

Name of table containing the local support domain policy setup.

Default value is “domainpolicy”.

modparam("domainpolicy", "dp_table", "supportedpolicies")

Name of column containing the domain policy rule name which is equal to the URI as published in the domain policy NAPTRs.

Default value is “rule”.

modparam("domainpolicy", "dp_col_rule", "rules")

Name of column containing the domain policy rule type. In the case of federation names, this is "fed". For standard referrals according to draft-lendl-speermint-technical-policy-00, this is "std". For direct domain lookups, this is "dom".

Default value is “type”.

modparam("domainpolicy", "dp_col_type", "type")

Name of column containing the AVP's name. If the rule stored in this row triggers, than dp_can_connect() will add an AVP with that name.

Default value is “att”.

modparam("domainpolicy", "dp_col_att", "attribute")

Name of column containing the value for AVPs created by dp_can_connect().

Default value is “val”.

modparam("domainpolicy", "dp_col_val", "values")

This parameter defines the name of the AVP where dp_apply_policy() will look for an override port number.

Default value is “portoverride”.

# string named AVP
modparam("domainpolicy", "port_override_avp", "portoverride")

Name of the AVP which contains the override transport setting.

Default value is “transportoverride”.

# string named AVP
modparam("domainpolicy", "transport_override_avp", "transportoverride")

Name of the AVP which contains a domain replacement.

Default value is “domainreplacement”.

# string named AVP
modparam("domainpolicy", "domain_replacement_avp", "domainreplacement")

Name of the AVP which contains a domain prefix.

Default value is “domainprefix”.

# string named AVP
modparam("domainpolicy", "domain_prefix_avp", "domainprefix")

Name of the AVP which contains a domain suffix.

Default value is “domainsuffix”.

# string named AVP
modparam("domainpolicy", "domain_suffix_avp", "domainsuffix")

Name of the AVP which contains a send_socket. The format of the send socket (the payload of this AVP) must be in the format [proto:]ip_address[:port]. The function dp_apply_policy will look for this AVP and if defined, it will force the send socket to its value (smilar to the force_send_socket core function).

Default value is “sendsocket”.

# string named AVP
modparam("domainpolicy", "send_socket_avp", "sendsocket")

Checks the interconnection policy of the caller. It uses the domain in the request URI to perform the DP-DDDS algorithm according to draft-lendl-domain-policy-ddds-02 to retrieve the domain's policy announcements. As of this version, only records conforming to draft-lendl-speermint-federations-02 and draft-lendl-speermint-technical-policy-00 are supported.

Non-terminal NAPTR records will cause recursion to the replacement domain. dp_can_connect() will thus look for policy rules in the referenced domain. Furthermore, an AVP for "domainreplacement" (containing the new domain) will be added to the call. This will redirect SRV/A record lookups to the new domain.

In order to simplify direct domain-based peerings all destination domains are treated as if they contain a top priority "D2P+SIP:dom" rule with the domain itself as the value of the rule. Thus any database row with type = 'dom' and rule = 'example.com' will override any dynamic DNS-discovered rules.

For NAPTRs with service-type "D2P+SIP:fed", the federation IDs (as extracted from the regexp field) are used to retrieve policy records from a local local database (basically: "SELECT dp_col_att, dp_col_val FROM dp_table WHERE dp_col_rule = '[federationID]' AND type = 'fed'). If records are found (and all other records with the same order value are fulfillable) then AVPs will be created from the dp_col_att and dp_col_val columns.

For NAPTRs with service-type "D2P+SIP:std", the same procedure is performed. This time, the database lookup searched for type = 'std', though.

"D2P+SIP:fed" and "D2P+SIP:std" can be mixed freely. If two rules with the same "order" match and try to set the same AVP, then the behaviour is undefined.

The dp_col_att column specifies the AVP's name. If the AVP start with "s:" or "i:", the corresponding AVP type (string named or integer named) will be generated. If the excat specifier is omited, the AVP type will be guessed.

The dp_col_val column will always be interpreted as string. Thus, the AVP's value is always string based.

dp_can_connect returns:

This function can be used from REQUEST_ROUTE.

...
dp_can_connect();
switch(retcode) {
	case -2:
		xlog("L_INFO","Errors during the DP evaluation\n");
		sl_send_reply("404", "We can't connect you.");
		break;
	case -1:
		xlog("L_INFO","We can't connect to that domain\n");
		sl_send_reply("404", "We can't connect you.");
		break;
	case 1:
		xlog("L_INFO","We found matching policy records\n");
		avp_print();
		dp_apply_policy();
		t_relay();
		break;
	case 2:
		xlog("L_INFO","No DP records found\n");
		t_relay();
		break;
}
...

This function sets the destination URI according to the policy returned from the dp_can_connect() function. Parameter exchange between dp_can_connect() and dp_apply_policy() is done via AVPs. The AVPs can be configured in the module's parameter section.

Note: The name of the AVPs must correspond with the names in the att column in the domainpolicy table.

Setting the following AVPs in dp_can_connect() (or by any other means) cause the following actions in dp_apply_policy():

If both prefix/suffix and domain replacements are used, then the replacement is performed first and the prefix/suffix are applied to the new domain.

This function can be used from REQUEST_ROUTE.

...
if (dp_apply_policy()) {
	t_relay();
}
...

This example shows how a secure peering fabric can be configured based on TLS and Domain Policies.

Let's assume that an organization called "TLSFED.org" acts as an umbrella for VoIP providers who want to peer with each other but don't want to run open SIP proxies. TLSFED.org's secretary acts as an X.509 Certification Authority that signs the TLS keys of all member's SIP proxies. Each member should automatically allow incoming calls from other members. On the other hand, the configuration for this federation must not interfere with a member's participation in other VoIP peering fabrics. All this can be achieved by the following configuration for a participating VoIP operation called example.com:

This example shows how a peering fabric based on a central SIP hub can be configured.

Let's assume that an organization called "HUBFED.org" acts as an umbrella for VoIP providers who want to peer with each other but don't want to run open SIP proxies. Instead, HUBFED.org operates a central SIP proxy which will relay calls between all participating members. Each member thus only needs to allow incoming calls from that central hub (which could be done by firewalling). All this can be achieved by the following configuration for a participating VoIP operation called example.com:

This example assumes that a set of SIP providers have established a secure Layer 3 network between their proxies. It does not matter whether this network is build by means of IPsec, a private Layer 2 network, or by simple firewalling. We will use the 10.x network (for the walled garden net) and "http://l3fed.org/" (as federation identifier) in this example.

A member of this federation (e.g. example.com) can not announce its SIP proxy's 10.x address in the standard SRV / A records of his domain, as this address is only meaningful for other members of this federation. In order to facilite different IP address resolution paths within the federation vs. outside the federation, all members of "http://l3fed.org/" agree to prefix the destination domains with "l3fed" before the SRV (or A) lookup.

Here is the configuration for example.com: