Call routing

When an entity on your network (for instance, a gateway or a SIP server) has to establish an outgoing call, it must find out where the call is being sent to. To do this, it can use its internal configuration (for example, dial-peer on the gateway) or some external entity (e.g., gatekeeper), or it may ask billing for a list of possible routes. This last method has several advantages: the routing configuration is in one central location, and billing can use information about termination costs to choose the best route (least-cost routing).

Thus, for SIP calls, PortaSIP obtains the routing information directly from billing.

The following happens after the customer making the call has already been identified, the phone number has been translated according to dialing rules (e.g., into E.164), and all the required authorization checks (e.g., if the account is allowed to call the destination) have been performed:

• If the call is made to one of the access numbers for IVR applications, route the call to the PortaSIP Media server and launch the IVR application.
• If the call is made to one of the service codes (e.g., *70 is the call parking prefix), perform an action according to the service code.
• If the call is made to an extension number within the PBX environment, route the call to the account (see the description below) with this extension assigned.
• If the call is made to one of the speed dial codes in the phone book, replace the speed dial with the phone number and route the call to vendor connections for termination, according to the routing rules specified in PortaBilling.
• If the call is for one of the phone numbers provisioned in the system (there is an account with an account ID identical to the translated dialed number), route the call to the account (see the description below).
• Otherwise, route the call to vendor connections for termination, according to the routing rules specified in PortaBilling.

As soon as any condition is met, all the following steps are skipped.

Routing the call to the account means:

• Direct the call to the PortaSIP server where the IP phone is currently registered.
• Route the call to the IP phone.
• If an account has follow-me numbers configured, route the call like in step 5 or step 6 depending on whether the follow-me number is another account or not.
• If an account has a voice mailbox, route the call to the PortaSIP Media server and launch the voicemail application.

As the first step in routing calculations, PortaBilling checks if there is an account with an account ID equal to the dialed number (given in E.164). If such an account is found, it is clear that the call is designated for one of the subscribers provisioned on the system. PortaBilling then extracts the latest known location for this account from the location database, in order to determine which PortaSIP server the account is currently registered on, and routes the call there. The SIP server maintains information about all currently registered SIP user agents, so it is able to properly communicate with the SIP user agent handling this number.

You can have different vendors for terminating off-net calls. For example, you can terminate calls to the US either to AT&T, via a T1 connected to your gateway in New York, or to a remote gateway from Qwest.

Ordinarily, tariffs define the termination costs for each connection to a vendor. Rates in the tariff with the Routing enabled have a few more fields:

• Route category – you can split rates into categories such as “Premium”, “Cheap”, etc., and use these categories in routing plans. All the rates in the system are assigned the “Default” category unless otherwise specified.
• Preference – routing priority (0–10), where higher values mean higher priority. “0” means do not use this rate for routing at all. By default, all the rates have preference “5”.
• Huntstop – signals that routes with a route category or preference lower than the one where the huntstop is set should not be considered.

This allows you to easily manage both termination costs and routing from a single location on the web interface. Thus, when such a routing tariff is associated with a connection, you can send calls for termination to all destinations which are allowed in the tariff.

It is risky to have only one termination partner: if it is down, your customers will not be able to make any calls. Normally, you will try to find several vendors and add their rates to the system. Each connection to a vendor (with routing tariff) will produce one possible route, and PortaSIP will automatically skip to the next route in the list should the previous route fail, thus providing fail-over routing.

Least cost routing (LCR) is the method for computing route lists based solely on vendors’ cost (a comparison is made on the Price_Next rate parameter). When default values are used for all other routing parameters, the route list will have the routes ordered according to the LCR which is from the lowest to the highest price.

For example, you have six vendors (A, B, C, D, E, F) with the following rates:

When you make a call, the system will list them in the following order:

This is simple least-cost routing: all of the available vendors are arranged according to cost.

Routing preferences in the rate allow you to override LCR. Unless a specific preference is set during tariff upload, all rates are assigned the default preference 5.

Let’s say you would rather send a call to vendor A than to vendor B regardless of the price when your customers call China. You can do that by increasing preference for the rate in vendor A tariff or decreasing preference for the rate in vendor B tariff. Note that the decision is “global” and it will apply to calls made by all the customers in your system.

For example, you have the same six vendors (A, B, C, D, E, F) for which you set the different preferences e.g., according to call quality.

When you make a call, the routes will be sorted as follows:

In some cases, you don’t want to send the call to the vendors with low preference e.g, the termination quality is usually poor. Huntstop works well for those cases. You set the huntstop on the rate, and the rates with the lower preference will be ignored by the system. For example, vendor B and vendor F have constant quality issues such as delays. To exclude these vendors from the route list, set the huntstop on the corresponding rate in vendor tariff with higher preference (vendor C – 5). The route list will now look as follows:

Vendor	Destination	Route category	Preference	Price, USD	Huntstop
A	8610	Default	7	0.04
D	86	Default	6	0.025
C	86	Default	5	0.03
E	86	Default	5	0.06

If you want to customize routing for specific customers, e.g. configure vendor A to be the first route for John Doe, vendor B to be the first route for Mary Smith, and vendor A to be the only route for Amy Adams, use routing plans.

• A routing plan is a list of route categories in a specific order. It defines which vendor connections should be used for termination (based on route categories used in connection tariff) as well as in which order they should be arranged.
• Every route category within the routing plan has an order. Routes with a category of higher order are used before routes with a category of lower order.
• If a huntstop is set in the tariff for some route category, the routes with categories of lower order are excluded from the route list.
• The routes with categories of the same order are arranged according to preference.
• The routes with the same preference are arranged according to price, so that the routes are sorted from the cheapest to the most expensive. When all parameters coincide, the routes are ordered randomly.

PortaBilling has a default routing plan, All available routes, which uses all available vendor connections sorted according to preference and price. This routing plan is always present in the system and is assigned to the account by default.

To create a routing plan, you need to create specific categories first. For example, you create route categories: for vendor A – “Wholesale” and for vendor B – “Premium”. “Default” route category is already in the system, thus there is no need to create the route category manually. After that, you create three routing plans with route categories listed in the following order:

• Standard – includes “Default” (order 70), “Wholesale” (order 40), and “Premium” (order 10) route categories.
• Advanced – includes first “Premium” (order 90) and then “Wholesale” (order 50) route categories.
• Basic – includes only “Wholesale” (order 99) route category.

The route list calculated by the PortaBilling will contain a different set of routes depending on which routing plan is assigned to the account making a phone call.

You have the same six vendors (A, B, C, D, E, F). Vendor A and vendor B have the route categories, so you create and assign the route categories for the rest of them:

Vendor	Destination	Route category	Preference	Price, USD	Huntstop
A	8610	Wholesale	7	0.04
B	86	Premium	4	0.11
C	86	Wholesale	5	0.03
D	86	Default	6	0.025
E	86	Wholesale	5	0.06
F	8610	Residential	3	0.09

The already created “Standard” routing plan, which includes “Default” (order 70), “Wholesale” (order 40), and “Premium” (order 10) route categories is assigned to the customer, John Doe.

When John Doe with the “Standard” routing plan makes a call to 8610234567, the system will arrange the possible routes as follows:

Vendor B is excluded from the list as their rate has “Premium” route category (order 10), but the huntstop is set on the rate with “Wholesale” route category (order 40) in vendor C tariff. Vendor F isn’t included in the routing, since their “Residential” route category is not in the “Standard” routing plan.

PortaBilling supports a “profit-guarantee” mode for routing. If this mode is activated in a routing plan, all routes where the price per minute which your vendors apply to you is higher than that which you apply to your customers will be removed from the route list by the billing engine during real-time route calculation. Or, to put it in simpler terms, a route will not be selected if it is more expensive than what you charge your customers.

There are two possibilities for choosing which routing plan is used to find available vendors and terminate a call:

• Each account is assigned an individual routing plan. When the end user simply dials a number in the normal way, this routing plan will be used.
• If the end user wants to choose a specific routing plan for a particular call, he dials a routing plan selection code before the number. For example, if he wants to use the “Premium” routing plan to call US phone number 12065551234, he would dial 2312065551234, where 23 is the selection code defined as a property of the “Premium” routing plan.

The selection code is a property of a routing plan, and so obviously each routing plan has its own unique selection code. If you want to have a routing plan which cannot be specifically selected by an end user, simply leave the selection code field empty.

By including a routing plan in the rating table definition of the product, you can allow every account that uses this assigned product to use this routing plan.

To allow a specific customer to select this routing plan for a call, enable it in the customer’s dialing rules. If the routing plan selection is disabled, calls will be routed using the account’s default routing plan.

In order to be able to use dynamic routing plan selection and have these calls charged properly, adequate support is required on the switch side, i.e. the node which processes these calls. This derives from the fact that, although the customer initially dials the selection code, this information is not included in the phone number sent to the vendor, and therefore is not visible in the call accounting information. Therefore, the node must provide this information to PortaBilling as a separate attribute, so that the call can be charged properly.

PortaSIP supports this functionality by default, while for switching equipment supplied by a third-party vendor it is recommended to consult with the vendor directly.

Based on the information above, the routing algorithm is as follows:

• The SIP server (or some other entity) asks PortaBilling for a list of routes for a given number.
• PortaBilling checks every tariff with routing extensions associated with a vendor connection to find rates matching this phone number. The best-matching rate is chosen in each tariff. This rate defines the routing parameters, i.e. it supplies a list of all vendors who can potentially terminate this call, including their cost and other related parameters.
• A list of possible termination addresses will be produced (this will include remote IP addresses for VoIP connections and IP addresses of your own nodes with telephony connections). Entries assigned a route category not included in the routing plan and entries which do not satisfy the profit-guarantee criteria will be removed.
• The route list will be sorted according to order of route categories, where the routes with categories of the same order are arranged according to preference. The routes with the same preference are arranged according to cost. If some entry has a huntstop defined, entries that have a lower route category or preference will be ignored.
• If there are several routes with an identical cost/preference, load sharing will be applied so that each potential route has an equal chance of being the first. Consequently, if your terminating carrier provides you with three gateways to send calls to, each gateway will, in the final analysis, receive approximately the same number of calls (33%).
• If adaptive routing is used, then routes to vendors currently penalized for not meeting the quality criteria will be moved to the very last positions in the routing list.
• A list of these IP addresses (with optional login and password for SIP authentication) will be returned to the SIP server. (To avoid extremely long call setup time, only a certain number of routes from the beginning of the list are returned; the default is 15, but this can be changed in the configuration).

The routing list, computed according to the costs and preferences of individual vendors, is “static” – meaning that each vendor will always maintain his respective position in the list (first route, second route, last route, etc.) unless the vendor changes his cost or the administrator manually adjusts the preference for that vendor. Let’s look at the following example:

In this case, after the sorting is done according to cost, Vendor A will occupy the first position in the list – and the first routing attempt will always be made to that vendor. Only if the call cannot be connected to Vendor A will it then be routed to Vendor B. This basically means that under normal circumstances, Vendor A will get most of the traffic, and a call will be routed to Vendor B only if all available capacity of Vendor A has been exceeded or if there is some temporary problem with connecting the call. Although this scheme offers maximum profit, conducting business this way is usually undesirable in real life. If the cost of several routes is comparable, it is better to allow a portion of the traffic to go further down the routing list via other carriers (Vendor B in our example). This will ensure that the other routes are maintained in an active state, that there is a sufficient amount of data for producing quality reports and that your contracts with those vendors will not be canceled due to inactivity.

The idea is to allow a portion of all traffic to be directed to the vendors who are further down the routing list – though of course, this can only be done if the cost difference between the vendors is acceptable. In our example, Vendor C has a price per minute of $0.15 – so this route should obviously not be mixed with those of Vendors A and B, since the difference in cost ($0.10/min) is unacceptable.

By setting up the cost difference threshold (Round-robin cost difference option) in the routing plan, the administrator specifies the maximum acceptable difference in cost between two carriers, thereby indicating when routes to these carriers can potentially start “swapping” positions in the routing list.

How does this value affect the route sorting in exact terms? After the list of potential routes is produced, but before the actual route re-arrangement according to cost takes place, each route cost is slightly changed by a random value. The adjusted cost may be increased or decreased compared to the original one, but the spread between the minimum possible value and the maximum possible value will be specified as the cost difference threshold (Round-robin cost difference option).

For instance, when the cost difference threshold is set to $0.02, then Vendor A’s cost ($0.05) may be increased or decreased by $0.01 (one half of $0.02), changing the cost to a random value between $0.04 and $0.06. Naturally this adjusted cost is purely fictional; these changes would only take effect during the sorting of routes and would not affect the actual call billing.

As a result of these cost fluctuations, when the list of routes is sorted according to cost, the route sequence “shuffles” and the probability of two routes swapping places increases when they have similar prices. If in our example, above, we set the cost difference threshold to $0.02, the adjusted cost of A would be in the range of $0.04 and $0.06, and the adjusted cost for B would be in the range of $0.05 and $0.07. If for instance, the new cost of A happens to be $0.053 and the adjusted cost for B happens to be $0.052 – Vendor B would move into the first route position.

Overall, in about 25% of all cases both values would be randomly distributed in the same range ($0.05-$0.06) and therefore, B would become the first route for about 12,5% (25%/2) of all call attempts. In comparison, if B’s cost were $0.051 – this algorithm would result in B receiving an almost equal share (49.5%) of all calls that A is receiving, since adjusted cost values for A and B would be randomly distributed throughout two nearly 100% overlapping intervals ($0.04-$0.06 and $0.041-$0.061) and thus each vendor would have nearly the same chance of his adjusted cost being the lowest.

This process of randomly adjusting the cost followed by re-arrangement is done for every new call. So for each call the actual routing list may look slightly different from previous lists and the overall call volume is properly distributed among multiple vendors.

So if in our example the route to Vendor A has a preference of 6 and the route to Vendor B still has a preference of 5 – load-balancing would not happen, and A would remain in the first route position.

Aside from the price difference, another important consideration when arranging multiple routes is the number of already connected calls for a particular connection and the maximum number of calls it can potentially handle. Without this, a connection to a carrier may become overloaded, resulting in decreased sound quality and a higher number of failed call attempts, etc., while other carriers with just a slightly higher price may be underutilized.

This is why PortaBilling offers you the ability to factor in connection utilization when computing the routing list and perform load balancing among multiple connections accordingly. Load-balancing based on connection utilization may change route precedence even in cases where the price difference between vendors is too high for normal load-balancing (as described earlier).

For each connection, the administrator defines two parameters: the maximum connection capacity and the load threshold (on PortaBilling web interface it is the Start Utilization Balancing After attribute).

As long as the number of connected calls remains below the load threshold, the connection is considered to be operating in normal mode (sufficient available capacity), and calls are routed to this connection based solely on cost and assigned preferences (if the load-balancing threshold is defined, the shuffling of routes with similar prices may also take place).

If the number of simultaneous calls established via the connection exceeds the load threshold, the connection is considered to have surpassed the desired limit and therefore some of the load shifted to other carriers that possess an acceptable price difference. This is done using an algorithm similar to the one used for load-balancing (described in the previous chapter). The administrator sets the overload handicap parameter (defined per routing plan) that specifies how far above the desired limit a load may “weigh down” the connection. A portion of this value (proportional to the actual load on the connection) is added to the route cost during route sorting so that the vendor’s cost (whose route was the first ‘unconditional’ route due to its lower price) now becomes comparable with the other vendors’ costs, and load-balancing can commence.

If the connection load increases even further, the added “handicap” value increases as well. The calculated vendor’s cost (that is used during sorting) would rise higher and higher, leaving less chance for this vendor to be the first route.

Finally, when the quantity of calls in progress reaches the maximum connection capacity threshold, this connection becomes excluded from the routing process; no further calls will be routed there until some already connected calls are disconnected.

Let’s extend the example used for load-balancing to consider connection utilization. There are three vendors:

And finally, when the load on Vendor A’s connection reaches the maximum allowed limit, this connection will be excluded from call routing. All further call attempts will be routed to Vendors C and B (with C becoming the first route because of its lower adjusted cost).

Sometimes it is necessary to make minor adjustments to one or several routes. This configuration can be done with the help of the Routing Override functionality for individual routing plans.

For example, a pool of connections is created in which 70% of the calls should go to carrier A, 20% to carrier B and 10% to carrier C. Suppose that the system has a total of 1,000,000 minutes. The administrator expects that 700,000 minutes will go to carrier A, 200,000 minutes to B and 100,000 minutes to C.

In order to achieve this, the system will randomly change the routing list for each call and place one of them in first place according to the specified percentages. If you look at the statistics at the end of the day, you see that you obtained the required ratio.

Once you have determined which route will be in first place, you will decide what to do with the other routes. Therefore, there are two cases of routing override that are configured using the pool:

• All routes are on the routing list, and all will be used for calls, thereby reducing the number of failed calls.
• Only the first route is used for all calls, the other routes are ignored.

Several types are used for configuring the pool of connections:

• Consistent routing to one carrier (e.g., traffic to Vietnam-Mobile from customer A always goes to carrier XYZ).
• Sequential routing – The administrator creates a list of connections for a destination group in a desired routing order, and calls are routed according to this sequence, before (or instead of) applying “normal” LCR routing. An entry in the override list can be a percentage-share connection pool, where each connection has a chance to be the first route, proportionate to the assigned percentage value (e.g., 25 percent of cases send traffic via the connection Europe Premium, 40 percent of cases send via the connection Termination to UK, and the rest (35 percent), are sent based on LCR).

The configuration examples for the above-mentioned types of routing override can be found in the Routing override handbook.

In some cases, setting a single profit margin for all destinations is not flexible enough for obtaining the best results. For example, the service can be profitable when a service provider sells it to customers at “10% above the carrier’ price” but market research shows that certain destinations can be charged a higher rate and customers will buy the service anyway. The service provider sets a higher price for such destinations (e.g., 25% above the standard carrier’s price), and now wants to exclude those carriers that produce less profit from the routing.

PortaBilling supports routing margin tariffs that offer service providers an opportunity to maximize their profits. A routing margin tariff is a special tariff to be used instead of a real customer tariff exclusively in order to compare carriers’ prices against it. Only carriers having prices lower than or equal to those specified in this tariff will be selected for routing.

Consider the following example:

An administrator is configuring the profit-guarantee settings and sets the minimum profit to 10%, specifying that it must be calculated based on the routing margin tariff.

The user calls a number in the UK, 44125551155. According to the user’s product, the regular rate for destination 4412 is $0.40. If there were no routing margin tariff defined, PortaBilling would use those carries whose price for this destination is either lower than or equal to $0.40 – 10% = $0.36.

However, the routing margin tariff is set so PortaBilling first checks whether there is a rate for 4412. PortaBilling finds the rate for this destination defined as $0.10 so only carriers having a price for 4412 of $0.10 – 10% = $0.09 and lower will participate in the routing.

A regular customer tariff is used then solely to charge the customer. However, if a certain destination is not present or is prohibited in the routing margin tariff, the price from the regular customer tariff is used for calculating the profit-guarantee outcome.

PortaBilling allows you to automate the process for controlling the call quality which becomes increasingly important today. That is, if you want to evaluate acceptable vendors for terminating VoIP calls, there is no need to hire numerous human operators or network engineers, who will track and analyze the specific route. All you need is to implement adaptive routing model.

The main idea of adaptive routing is to dynamically measure a vendor’s quality parameters, and adjust the routing priority accordingly. These quality requirements are predefined in the form of threshold parameters on the Routing criteria page, and are then automatically applied to specific vendors. Any vendor who fails to satisfy your quality requirements will go to the “penalty box” – the very bottom of the routing list. This means that the system will try first to terminate calls using other carriers (with a good quality evaluation). However, if all of them fail or are unavailable, the “penalized” carrier will have a chance to terminate the call. It is still better to send a call via an inferior vendor than to have it fail completely.

Thus, if the quality requirements are applied, a carrier’s place on the routing list is determined not only by the route category, the assigned preference value, and the cost parameters (LCR model), but additionally by quality criteria.

For effective quality measurement, the following key control parameters are used:

• ASR (Average Success Rate) – The number of successfully connected calls divided by the total number of call attempts.
• PDD (Post Dial Delay) – The time interval between the connection request to a vendor and ring-back.
• ALOC (Average Length of Call).
• PPM (Profit per Minute) – The aggregated profit, i.e. the difference between the actual charged amounts in the CDRs for your customers and vendors.

Each of the above parameters requires two values, which define the warning and penalty thresholds, respectively. When the value of a parameter reaches the predetermined threshold, the administrator receives an email alert about the latest connection threats. Moreover, the administrator can track the current connection status on the Tracking page. This status is represented by different colors, as follows:

• Active (grey color) – The number of calls is not enough to apply filtering differentiation.
• Active (green color) – The route meets the quality requirements.
• Active (yellow color) – The route is active, but some of its quality parameters are outside the warning thresholds.
• Penalized – This route is currently being penalized.
  The penalized route will stay in the “penalty box” for the period of time specified in Penalty Time, and then will be unblocked automatically. Alternatively, you can unblock the penalized route manually by clicking the Unblock Now button.
• Restored – The route was manually unblocked; this status will remain until the next time interval for computing statistics.

A common situation is when several different carriers are connected via PRI trunks (or SS7 interface) to the same media gateway, which does the conversion from VoIP to PSTN. When a call is sent to the gateway, the question is which particular carrier should be used to connect this particular phone call (or if multiple carriers are used – in which order should they be tried)?

Most of the gateways support configuration of routing for outgoing calls via dial-peers or similar method, where the outgoing carrier or trunk group is chosen based on matching the dialed number (e.g. 447155123456) to a set of prefixes (e.g., 447 or 4471) assigned to outgoing trunks. So it is possible to maintain the routing configuration on the gateway, but it is not taking into consideration the costs of sending calls to a particular vendor, and any change in the routing requires manual re-programming of the routing table on the gateway. Needless to say, this method significantly increases the amount of work for the administrator, reduces routing flexibility and is very likely to generate routing errors, which could seriously damage revenue of the service provider, since calls are not being sent to the carrier with lowest costs.

So another approach is recommended: the media gateway is configured with the bare minimum of the routing information. Each outgoing carrier (or trunk group) is assigned its own prefix (e.g., 123# for carrier A and 456# for carrier B). When PortaSIP sends a call to media gateway, it appends the specific carrier’s prefix to the dialed number, so only that carrier is used to transport this call (as illustrated below).

As a result, the call routing is controlled at the single location, and one has to maintain a single set of carrier rates and related configuration.

Sometimes a network consists of multiple nodes (for instance, if you have two PortaSIP servers installed), each of them capable of doing call routing under the control of PortaBilling. In this case, two scenarios are possible:

• The node which receives the original call from the customer proceeds with routing of the call and delivers it to the “destination” carrier. This is the simplest scenario, and usually it provides the best results in terms of your network’s usage (since the call always travels the shortest possible path, with a minimum number of hops on the network). In this case, though, each node communicates with the carrier directly, which may require additional maintenance activities on your side (e.g., if the carrier uses authorization by IP address, you will need to provide him with a list of all your nodes’ IP addresses and keep that list updated as your network changes).
• The node which receives the original call from the customer does the authorization (to verify the identity of the caller) and sends the call over to the “master” node. The master node then obtains the actual list of routes for this call and establishes the connection to the terminating carrier.

The last scenario increases traffic within your network, but it allows you to handle advanced scenarios – for instance, when you have multiple PortaSIP nodes deployed in different countries (and their IP addresses change often), but only your central PortaSIP node, located in your main collocation facility, is able to communicate with the carrier because of IP address restrictions.

If the number of H323-only carriers is not too high, it would make sense to configure the system as follows:

You can use Cisco IPIPGW, or any of the SBCs available on the market as a SIP-H323 convertor. The idea is to configure it in such a way that any incoming SIP call where the destination number starts with a certain tech-prefix will be sent out to a particular carrier. For example, if the destination number in the incoming call starts with 1#, the call will go out to IP address 6.7.8.9 (SuperNet); if the destination number starts with 2#, to IP address 1.2.3.4 (X-Telecom); and so on. Although this converter is (strictly speaking) part of your network, there is no need in this case to define it as a node in PortaBilling, since it will not be exchanging any information via RADIUS.

In PortaSwitch you will configure your SIP carriers as usual. When you create a connection for an H323 carrier, you will specify the IP address of your SIP-H323 converter as the Remote IP Address and then assign a tech-prefix to this connection. In this way, although calls for multiple carriers will go from PortaSwitch to the same IP address, the system can still recognize which carrier is used in each case.

Let’s consider the following example for a better illustration of how this process works. Assume you have 4 carriers, all capable of terminating calls to the UK. Their respective rates per minute are: carrier A – 0.02, carrier B – 0.03, carrier C – 0.05 and carrier D – 0.10. Carriers B and D are H323 only, so for them connections are configured on the SIP-H323 converter (with IP address 192.168.0.3), with tech-prefix 2# and 4#, respectively.

A customer dials phone number 4412345678. The call arrives to the PortaSIP node, which, upon successful authorization, receives the following routing list:

Route 1: 4412345678 @ <IP address of carrier A>
Route 2: 2#4412345678 @ 192.168.0.3
Route 3: 4412345678 @ <IP address of carrier C>
Route 4: 4#4412345678 @ 192.168.0.3

PortaSIP will first try to establish a connection via the first route and, if that fails, it will send the call via the second route, to the SIP-H323 converter, which in turn will attempt to establish the call with carrier B. If a connection is not possible, after receiving an error message from the converter PortaSIP will try the next available route, and so on.

This method of configuration allows the SIP-H323 converter resource to be used only when it is actually required (since SBCs are usually licensed on a per-port basis), thus minimizing total network infrastructure costs.

In order for a voice call to be established, the two end-points (IP phones or media gateways) must not only be able to exchange IP packets which contain SIP messages, but also agree on a mutually acceptable way to encode the audio signal for transmission over the IP network (codec). There are many codecs available, with different features in terms of voice quality, compression rate and required processing resources. Some are free, while others require royalty payments. As a result, each device, such as an IP phone, is usually capable of supporting only the limited subset of codecs implemented by the manufacturer.

Normally, at the beginning of a call the calling party announces all the codecs it supports, and then the called party replies back with a list of codecs it is willing to accept, and so the decision is made by the two end-points only.

This approach provides great flexibility and since PortaSwitch does not have to interfere in the audio processing and utilize any codecs on its side. But since the two SIP end-points make the decision regarding the choice of the codec without any consideration of the network infrastructure or other important factors, in some situations, their choice may be less than optimal.

For instance, SIP phone A may have the G.711 codec as the first preference by default; and if that codec is supported by the other party, it will be chosen for the call. While this is great for a customer A, with high-speed broadband connectivity (G.711 provides sound quality identical to traditional “wired” telephony service, such as ISDN), if customer B attempts to use G.711 with limited bandwidth it will result in severely degraded voice quality and a negative customer experience. Such a customer B should always use a narrow-bandwidth codec such as G.729 to ensure good sound quality.

Thus it becomes increasingly important for the ITSP to actively control the choice of codecs used by the end-points, in order to optimize network performance and avoid negative customer experiences. How is it done?

Routing filters operate with the concept of call media features. A call media feature is a property of the call or call media, such as a specific codec, T.38 fax, or the ability to guarantee delivery of the correct CLI (caller identification) to the recipient of the call. Since the caller may have his own set of desired call media features, the main idea is to ensure proper “match-making” between the available carriers, while limiting the caller’s choice if required (e.g., the caller may request a video call, but this will be prohibited if he is not authorized to do so).

Be aware that PortaSwitch can convert media stream from one codec format to another. For more information refer to the Transcoding and transrating chapter.

These describe the filters applied to call media features (such as a specific codec or T.38 fax capability), as requested by the calling party. For each feature the PortaSwitch administrator can specify that:

• It is “required” – meaning that the other SIP end-point must have this feature supported in order for the call to be completed. For instance, if the “G.729 codec” feature is marked as “required” for an account making a phone call, then only those vendors specifically marked as “guaranteed to support G.729” will be placed in the routing list.
• It is “suppressed” – meaning that PortaSwitch will prevent the use of this particular feature (e.g., G.722 codec) and will not even show the information about this codec in the SIP request when sending an outgoing call to the other end-point.
• It is “not required” – meaning that PortaSwitch does not do any special processing for this feature. It will be included in the outgoing SIP request, and may be used if the other party supports it. This is the default value for any feature.

These describe the capabilities of the remote party (such as the gateway of a carrier) and our preferences on using them. For each feature it is specified whether it is:

• Supported – meaning that we know for sure that this equipment supports this feature and are willing to use it.
• Not supported – meaning that this equipment is unable to support this particular feature (e.g., G.723 codec). It could also be our administrator’s decision to prohibit it.

For example, although we do not know whether a vendor’s gateway supports the G.722 codec, by marking it as “not supported” we will ensure that, even if the originating end-point shows this codec as available, it will be removed from the codec list sent to the carrier in the SIP call initiation request, and thus never used.