Service policies

The telecommunications industry is growing rapidly with new technologies and devices being introduced into the market all the time. Networks have become more flexible and customers have become more demanding about the services that they subscribe to. Under these conditions, it is essential to not only continually offer new services and products and keep up with market demand, but also to do this in the most qualitative and flexible manner. This is what PortaBilling enables you to do!

The Service policies feature allows you to fine-tune your services based on your network peculiarities, vendors’ opportunities, and customers’ demands. It facilitates the configuration of static options for multiple accounts (so it is not necessary to configure values for each account separately), thus establishing common policies for groups of accounts. It also allows you to separate the technical configuration of specific options (usually made by technical staff) from account management.

When a new policy is created, it does not have any attributes defined (all available attributes are shown in grey). To define an attribute, specify its value.

Service policies can be statically assigned at various levels: account, product, connection, and authentication (call handling rule). In addition, it is possible to apply service policies depending upon the UA type (dynamically matched policy).

The service policy has the ability to match dynamically when the Match Pattern is specified. For the calling party, PortaSIP extracts the User-Agent header from the incoming INVITE request (e.g., “Linksys/SPA941-5.1.8”) and matches it against all of the dynamic policies. If more than one policy matches, the one with the highest Match Priority is used.

For the called party, the procedure is quite similar. The only difference is that the User-Agent header of a called UA is taken from its registration information.

To illustrate how this works in practice, consider the following example:

Let’s say John Doe makes a call to number 12125554521. You want to ensure that the call passes via the G.711 codec so you configure the service policy for John’s account and define G.711 as the first codec for the codec_order_list option.

When John calls, the service policy assigned to his account is applied and this reorders the codecs.

The call is routed to the ABC vendor who requires the user identity of the user making the call. Therefore, the service policy assigned to the ABC vendor connection instructs PortaSIP to send the user identity information in the INVITE request.

What happens if there is a contradiction in service policies? For example, if a service policy matched upon initial request has the no_voice_rejects attribute set to Yes, while the service policy assigned to a called party has its attribute value set to No?

Several simultaneously applied service policies function according to the precedence of defined attributes that are exact matches:

• If there is a policy that corresponds with the SIP endpoint name of the called party, then this policy’s attributes are applied.
• If the called party has a service policy assigned via a product, then that overrides the one matched upon initial request and its attributes are applied. However, if an administrator overrides a service policy for an account, this policy takes the highest priority.
• The same attribute can be defined in the service policy assigned to the call handling rule and the one assigned to the incoming connection. In this case, the service policy assigned to the connection takes higher precedence and its attribute value is applied.

There is an attribute-specific prevalence among service policy attributes assigned to both caller and called accounts:

• The codec_order_list attribute is taken from the caller’s account (called account’s attribute is ignored).
• The “header” attributes (out_hdr_pai, out_hdr_rpid, out_hdr_history, out_hdr_diversion) defined for a called account take precedence over the ones defined for a caller account.
• The keep_alive_interval attributes are individually defined for both the caller and called parties, so there is no dominance between them. The value for the calling party is taken from the service policy assigned to that account. The value for a called party is taken from the service policy assigned to the connection or the one that’s assigned to the account if the called party is one of your accounts.