Wholesale scenario

By wholesale VoIP  is understood wide range of voip services like  traffic termination,  DID/SIP trunks delivery,  mobile number portability services, ENUM,  SMS termination and other that are directed to service providers rather than to endusers. The type of offered services determines the approach as to what equipment to select in order to handle serious traffic volumes (often measured in thousands of conncurent calls), how to handle sophisiticated billing and reconcilations with suppliers when often only a fraction of cent makes provider's margin, and at last but  not least the way of communication with clients, which includes notification services (low balance triggers, quality alerts etc.), invoicing, reports, detailed billing sent via email and accessible through web portal as well. This section presents selected implementations that are often met in wholesale carrier services roll-out.

The most basic scenario is "gateway to gateway" termination.  In this scenario both client (origination side) and the supplier (carrier, termination side) are reffered as to gateway. It implies that traffic from client to carrier will be realized in direct mode i.e. calls will be sent directly to provided IP address (or URI) without having to register. It means also that we should expect multiple simultaneous connections (serveral calls to several E1s or more). In this approach voipswitch's role is to carry out  the authorization process, billing, negotiate connection parameters and to control calls/sessions status through the entire duration from initiation untill they are ended.

Gateway to gateway connections are authorized  usually by IP address or range of addresses, to other methods belong SIP username/password authentication and its equivalent in H323 - by h323ID string containing username and password separated by a chosen character (for example user@password). Sometimes the client (gateway) requires to be registered to termination endpoint in order to send traffic - in this case client's gateway registers to voipswitch. Also the termination party may require a client (in this case voipswitch) to be registered first before it can accept connections. Also in some scenarios the destination party may need special protocol as to for example determine routing before voipswitch send calls further to proper termination gateway (ENUM, Mobile Portability).

[The general example of call flow from the moment an incoming call hits voipswitch untill it is sent out to a destination party is shown here.]

Below is presented the basic concept of wholesale services.

 In all above scenarios voipswitch is always in between the client and supplier. It allows to control the traffic exchange and when needed to hide the termination infrastructure from the client. The termination side can be a carrier - another wholesale provider, in this case voipswitch is a mean for running broker bussiness, buying at lower price from carrier and selling at higher rates to clients. Also the termination endpoint can be a gateway like Quintum or Cisco, either digital or analogue connected to PSTN through E1s (T1s) or to regular analogue lines, or can be a cellurar gateway with mobile sim cards inside. If it is our own gateway then can be placed in LAN (local area network), voipswitch will  be in front of the gateway exposing public IP to clients and blocking direct access to gateway - thus providing a security central point between the open Internet and corporate network. The central point advantage can be also easily achieved even if for some reasons it is not feasible to keep voipswitch at the gateway's location or when operating multigateways architecture with equipment located in remote areas. In such scenario voipswitch can reside at e.g. colocation center in UK or anywhere in the world and still control incoming connections and avoid unauthorized access to remote gateways.

There are numerous different approaches in deploying wholesale services. Each entails different questions related to remote provisioning, media and signalling flow, security, call quality, bandwidth usage and many others. Below are examples of some of the broad spectrum of wholesale VoIP services and roll-out approaches supported by voipswitch platform. They are followed by step by step implementation guides. Please note that despite our efforts to keep the information contained by voipswitch-wiki space actual, the VoIP  market is growing at astounding rate causing that some of the functionality might not be covered. Should it happen please feel free to post your enquiry on forum or send us email to sales@voipswitch.com . There are features  not described yet (or are in different section), also  some other can be in our development plan
 

 What you should know about voipswitch before going to scenarios section:

• voipswitch platform is a software running on Windows operating system family (see: hardware/software recommendations, architecture recommendations)
• voipswitch is designed to operate as a carrier class switch capable of handling even thousands of conncurent calls (see: platform performance, architecture recommendations, cluster configuration)
• voipswitch does not have any physical interface for connecting PSTN lines, it is purely IP to IP solution, in order to connect to PSTN a gateway is required (both for origination and termination)
• instead of owning a gateway  carrier's services can be utilized for both origination (DID providers) and termination  
• voipswitch is compatible with all SIP or H323 compliant equipment, it has been tested with most of the popular manufacturers such as Cisco, Quintum, Avaya and others
• voipswitch is compatible and has been tested with most of the world carriers like Level3, IDT (Net2phone), iBasis and others

 Sample wholesale scenarios:

1.1. Gateway to voipswitch to gateway traffic termination

 
Configuration procedure:

1. Add new client in GWclients menu in VSM (voipswitch configuration manager), see: http://update.voipswitch.com:8080/display/VDoc/2.0+Clients#2.0Clients-Commonfeaturesofclients 
   • create login and password (note that even if the authorization is IP address based these fields have to be filled; login is always connected with traffic logs, using it you can filter statistics, generate reports, invoices etc. basically it is the main reference of the account.  The password is also required so as to enable client to log in  to the Web Portal interface - CDRs, account balance and other information)
   • assign a tariff that will contain rates  according to which the calls sent from the client will be charged. Rates are divided per country/area codes and can be set  active for selected day of the week and time of the day only (e.g. for the same destination code  given rate is valid only through weekends while other on working days, further distinction can be that higher rate is in peak hours while lower at nights) . Some of the billing properties are also associated with the tariff rather than with a client account. Therefore by associating particular tariff with a client we can differentiate the billing properties for specific client or clients group. To  billing properties configurable per tariff belong:
     • per destination/code: grace period, minimal duration, resolution (billing step)
     • per tariff (for all codes within tariff): minimal duration, resolution (billing step), surcharge amount, surcharge time
   • (do zmiany ten format, nie powinno byc punktora) There is no limits in number of tariffs defined on the system. Many clients or groups can share the same tariff or each client or group can have a separate tariff. The tariff should be created before adding new client's account. Detailed explanation on creating new tariff and setting associated billing properties: http://update.voipswitch.com:8080/display/VDoc/5.0+Tariffs
   • add funds, set currency and billing type - prepaid or limited credit (postpaid), see: http://update.voipswitch.com:8080/display/VDoc/2.0+Clients#2.0Clients-Currency
   • select authorization method:
     • by IP address - to enable this method  add IP address or whole subnet (IP addresses range), if you do not want to allow authorization by IP simply leave this field empty see: http://update.voipswitch.com:8080/display/VDoc/2.0+Clients#2.0Clients-ipaddr
     • by h323ID or SIP user/password - select authorize by login/password checkbox,
     • by ANI (callerID) - some phone services require authorization by caller ID, for instance in preselection phone services where calls are redirected from pstn telco when user dials special code before number, authorization by callerID allows to bill particular user. This is however not typical wholesale but more retail offer and is explained in different section of the guide (one stage scenario tutaj link)
   • select allowed voice codecs, select prefered codec or allow any codec proposed by client's side (you may want to block bandwidth consuming notcompressed codecs like g711 and allow only g723.1 or g729). Voipswitch support following codecs (link to codecs)
   • add the client's dialing plan prefix and/or tariff prefix or leave these fields empty, see: working with prefixes
2. Add new entry (new termination gateway) in "Gateways" menu in VSM, see: http://update.voipswitch.com:8080/display/VDoc/3.0+Destinations#3.0Destinations-2.1Gateways
   • assign a cost tariff that contains the rates according to which calls sent from voipswitch will be billed by the termination carrier (gateway). Voipswitch will be calculating our costs which then can be netted against our income (calls from clients) showing profits from the service. Calculating carrier's cost is not obligatory, it is only for our information and at any rate is not required by the system architecture. It is recommended not to enable this option when configuring the scenario for the first time
   • configure gateway's connection parameters like protocol and protocol specific settings, all those information are provided by the carrier, if any of the parameters is missing the best is to leave the field empty. Required fields are described in Gateways section of the documentation
3. Configure the dialing plan, see: http://update.voipswitch.com:8080/display/VDoc/4.0+Dialing+plan. The dialling plan is a routing table where, based on dialed number (phone number field), voipswitch tries to find the best matching entry. As phone number is meant a string of characters, not necessarily number, in fact it can be any alphanumeric character (for example in calling user to user by username). In wholesale scenario entries in the dialing plan will represent broader range of numbers defined by area or country codes, thus directing traffic to for instance London (prefix/area code 44208) to route A, while traffic to the US will match the entry with prefix 1 and goes to route B. Once a match is found voipswitch collects details on the destination route and conneection properties to be used with this route. If one termination gateway supports more codes, the exact number of new entries have to be created in the dialling plan. Note that the prefixes/codes in the dialing plan, used for directing calls to proper carrier/gateway are not connected to the prefixes/codes defined in tariffs and used for billing. There is no need to duplicate the codes from tariff in the dialing plan, routing and billing are separate processes and even if we have one entry for example with prefix 44 for a carrier terminating UK traffic, still the calls going to different regions in UK, cities, mobile networks etc. will be charged properly according to breakouts defined in the tariff associated with client's account. The rating process and the following routing process is shown in [Call Flow diagram]
   • create new entry in the dialing plan, add a number prefix in "phone number" field (it can be area code or country code), for example 44 which is for all UK
   • in the destination area check "external gateway" checkbox, click on the button below and from the newly opened window containing  the list of existing gateways (defined in "Gateways" menu) select the one which will be used for terminating calls with phone numbers that start with characters matching the prefix defined for this entry, in our example all phone numbers begining with 44 country code.
   • make sure that the phone number format accepted by the carrier/gateway is the same as the format recieved by switch (sent from client), if they differ then translate the number into proper format using string manipulation rules (see: dialing plan/modifying call setup parameters). The proper format should be provided by the carrier along with other parameters
   • above dialing plan config represents basic approach with one main routing for all clients, sometimes we need to have particular client or clients  to use special routes, this can be accomplished by the means of client's dialing plan prefixes (see: working with dialing plan prefixes)
4. Test the scenario
   • make sure that voipswitch.exe is running (see: http://update.voipswitch.com:8080/display/VDoc/1.0+Main+system)
   • send call from the client, the call should immediately appear in the Calls window, if not then check the Logs window - if there is a problem with authorization it shoudl be indicated there by proper message. If there is neither call attempts in the Calls window nor any message displayed in Logs window that means that call is not reaching voipswitch, to troubleshoot see: Troubleshooting/no call attempts from client
   • extend the call tree by clicking on +   "Making call ..." message informs us where voipswitch is trying to send the call to, the name of the destination is given in brackets. In case of the failure check the end reason, see: Troubleshooting/interpreting end reasons. When connected successfully the call icon color changes to yellow
     

1.2. Gateway to voipswitch to gatekeeper

A gatekeeper serves  the purpose of call admission control, this term refers to h323 protocol network architecture  element (see: http://en.wikipedia.org/wiki/H.323_Gatekeeper).  When a gatekeeper is combined with gateway functionality to proxy h323 calls then it is a session border controller which is voipswitch itself. In this scenario however voipswitch acts as a gateway connecting to remote gatekeeper. As oppose to gateway to gateway scenario, where calls are sent in point to point mode, when connecting to a gatekeeper an endpoint has to register first. Voipswitch is seen by the gatekeeper as a gateway (important: not as a gatekeeper even though voipswitch can work as a gatekeeper itself but only to its clients).  Either voipswitch sends traffic to terminating gateway or gatekeeper it does not make any difference to the clients.

Configuration procedure:

1. The same adding new client procedure as in the above "Gateway to gateway" scenario
2. Add new entry (new termination gatekeeper) in "GK/Registrars" menu in VSM, see: http://update.voipswitch.com:8080/display/VDoc/3.0+Destinations#3.0Destinations-2.2Gatekeepers
   • assign cost tariff that contains the rates according to which calls sent from voipswitch will be billed by the termination carrier (gatekeeper). Voipswitch will be calculating our costs which then can be netted against our income (calls from clients) showing profits from the service. Calculating carrier's cost is not obligatory, it is only for our information and at any rate is not required by the system architecture. It is recommended not to enable this option when configuring the scenario for the first time
   • configure gatekeeper's connection parameters like protocol and protocol specific settings - SIP equivalent of gatekeeper is called SIP registrar. While adding new entry specify whether the registration server is a SIP registrar or H323 gatekeeper and check appropriate box.  All those information are provided by the carrier along with authentication credentials (ID and password), if any of the parameters is missing the best is to leave the field empty. Required fields are described in Gatekeepers section of the documentation
   • after adding new gatekeeper go to voipswitch main application and follow the instruction http://update.voipswitch.com:8080/display/VDoc/1.0+Main+system#1.0Mainsystem-Gatekeepers
3. Configure the dialing plan in the same way as in "gateway to gateway" scenario, the only difference is in the destination which in this case will be "external gatekeeper", check this box and from the list of available (defined in "GK/Registrars" menu) gatekeepers/regsitrars select the one that will be receiving calls with phone numbers that start with characters matching the prefix defined for this entry, in our example all phone numbers begining with 44 country code.
4. Test the scenario
   • make sure that voipswitch.exe is running (see: http://update.voipswitch.com:8080/display/VDoc/1.0+Main+system)
   • send call from the client, the call should immediately appear in the Calls window, if not then check the Logs window - if there is a problem with authorization it shoudl be indicated there by proper message. If there is neither call attempts in the Calls window nor any message displayed in Logs window that means that call is not reaching voipswitch, to troubleshoot see: Troubleshooting/no call attempts from client
   • extend the call tree by clicking on +   "Making call ..." message informs us where voipswitch is trying to send the call to, the name of the destination is given in brackets. In case of the failure check the end reason, see: Troubleshooting/interpreting end reasons. When connected successfully the call icon color changes to yellow

1.3.  Gateway to voipswitch to SIP registrar

In this scenario similarily like in the Gateway to Gatekeeper, voipswitch resides in between. It registers to the termination party and then pass to it the traffic coming from client (gateway). The only difference is that the destination is in this case a SIP registrar - an equivalent of h323 gatekeeper in SIP protocol.

Configuration procedure:

Repeat the 1 to 4 steps from Gateway to voipswitch to gatekeeper scenario.

In step 2 when configuring parameters of the SIP regsitrar, after checking option "SIP Registrar", apart from the username and the password fields, two new fields will appear wchich represents "user domain" and "domain". They are parameters with which voipswitch regsiters to the remote SIP registrar. "Domain" is for the domain name of the remote SIP registrar, for example callto.net or sip.callto.net - this info is usually provided by the carrier  (if required). "User domain" is for the user which will be shown on the remote SIP registrar as registered user, for example kris@callto.net , thus other users can send calls to this SIP URI. Very often however registered username and authorization username are the same. Therefore in most cases a provider will give us only one pair of username and password, in such case the "user domain" should be left blank.

1.4. Working with "dialing plan prefix" (advanced dialled number string manipulation) parameter

Note: the "dialing plan prefix" name does not give the full potential of this tool, this parameter is not only for adding/removing prefixes but in fact it represents  much more advanced string manipulation procedures in which available commands  are coded in forms of string patterns.  Thus the voipswitch, based on the defined pattern, can perform broad range of phone number manipulation tasks including length validation, strings replacements, OR operators, wild cards, conditional execution (for example depending on the lenght of the string), adding suffixes, prefixes and more. Basically this powerful tool allow us to do whatever we want with the phone number. More on the string pattern syntax can be found here see:

When  looking  at the [call flow] one can realize that there are three entities that determines the phone number pattern (format). One is the originating endpoint which sends calls to voipswitch, the other is voipswitch itself which bases on phone numbers when performing routing and billing, and finally the last entity is the termination endpoint which expects the calls to come in specified format.  The role of the "dialing plan prefixes" is to modify phone number format so that the dialed number sent from client matches the dialing plan format on voipswitch and then the format in which calls are sent from voipswitch matches the format required by carrier. The main implication of this logic is that we do not have to try to match the format from client with the format expected by the destination carrier directly per each client - carrier pair. Instead we first take care that the number from client will match the dialing plan on voipswitch and that in turn voipswitch will choose proper (desired by us) route for the call.  
Firstly, we have to decide how to ogranize our dialing plan. The best is to keep it simple, prefered way is to use international standard E164 in which phone numbers start with country code without any leading 00 or 011 or other characters. In this notation we simply built our dialing plan by adding entries representing first digits of country codes, if there is the same gateway (carrier) for more countries they should be grouped into one entry with higher (more general) code than country code, for example an entry with just 4 if we have the same carrier/gateway for all countries with country codes beginning with 4.
But what if our clients send calls in different formats? Some calls come with 00, some with 011 while some in proper format? Do we have to multiplicate all the entries for all cases so as to match 00, 011 and whatever prefix the client is going to send to us? The answer is no, instead we should use Client's "dialing plan prefix" parameter and let voipswitch modify the numbers such that they meet our dialing plan  standard.
Once the inbound formats agree we have to focus on the outbound format, that is the dialled number which is sent out to destination gateway (carrier). If the destination supports same international format then no changes are required. Often however, carrier may want us to send a special prefix before the real number. It is usually to provide additional authentication or simply to divide their services. Whatever reasons lies on the carrier's side we have to comply, otherwise the calls will be rejected. For that is the dialled number modification process that voipswitch performs based on the number pattern defined in the "dialling plan/rules for modifying client's data/dialed number".

Phone number format can be modified by string manipulation procedures which are performed at two moments of the call flow. The desired actions are programmed by the mean of string patterns. String patterns can be defined in two different places, in the "dialing plan prefix" field in the client's account and in the dialing plan in "rules for modifying client's data/dialed number". The former is responsible for the process performed at the first moment of number modification in the call flow. The latter is responsible for the second moment. Both processes are shown on the below diagram:

Configuration procedure depends on what is the goal, either we want to make the incoming number format agrees with our dialing plan (case 1) (which is held constant regardless on which client is calling) or we want to make the outgoing number format match the carrier's requirements (case 2).

• In case 1 go to particular client's account, "dialing plan prefix" field and follow the instruction (see: ) 
• In case 2 go to the Dialing plan, click on "rules for modyfing cleint's data", then in the unfolded window select "dialed number" and follow the instruction on the string patterns (see: )

There is also the third case when we want calls from particular client go different route (or routes) than other clients. For example if we sell termination with different quality, for example gold, silver, bronze (or premium, mixed, standard whatever name). In this case, apart from steps described above in which we had only one main dialing plan, now we have to modify also the dialing plan by adding new entries - it is in fact creating a new dialing plan. There is no limits in type of characers that can be used as "internal" prefixes. Thus we can built multi-dialingplan containing different routing tables for different clients or groups of clients. We can also be sure that some clients will not use the routes reserved for other clients. So we can offer differently priced or with different quality, divided per client services and yet all clients can send calls in the same, simple format (e.g. E164) without having to add special prefixes on their side.

Note: the prefixes can consist of any alphanumeric characters, it can be #,&,$ or even names, for example to keep it clear in the dialing plan we can put the prefix gold or silver. In below example client A is using regular dialing plan, while the client B is sent through better carrier Gold Quality. Both clients use the same number format when sending calls to voipswitch. Please see what happens further.

1.5. Working with "tariff prefix" parameter

Note: the "dialing plan prefix" name does not give the full potential of this tool, this parameter is not only for adding/removing prefixes but in fact it represents  much more advanced string manipulation procedures in which available commands  are coded in forms of string patterns.  Thus the voipswitch, based on the defined pattern, can perform broad range of phone number manipulation tasks including length validation, strings replacements, OR operators, wild cards, explicit conditions, conditional execution (for example depending on the lenght of the string), adding suffixes, prefixes and more. Basically this powerful tool allow us to do whatever we want with the phone number. More on the string pattern syntax can be found here see:

The "tariff prefix" role is similar to the "dialing plan prefix", both are responsible for the incoming phone number manipulation, at the same moment of the call flow. But here the similarity ends and one  should not seek there any  corelations. Each "prefix" plays different role and programmed tasks are performed as  separate, parallel processes. The phone number modified by the use of "tariff prefix" is passed to the voipswitch's rating and billing process only. There is no connection with the dialing plan whatsoever. Proper understanding of this distinction avoid us from future mistakes resulting in mixing up the roles of the "tariff prefix" and "dialing plan prefix". More on the "tariff prefixes" can be found here see: .....

1.6. Setting calls limits - client side, termination side

In voipswitch, the number of conncurent calls either inbound or outbound can be limited per client or destination endpoint respectively.

Configuration procedure:

Number of calls/channels limit per client:

1. Go to GWclients menu
2. For particular client  increase the number in the "Calls limit" box, by default the parameter is set to 0 which denotes "no limit"

Number of calls/channels limit per destination:

1. Go to "Gateways" or "GK/Registrars" menu
2. For chosen record set the new value in "calls limit" parameter, by default the parameter is set to 0 which means "no limits"

The number of channels taken at given moment refers to voipswitch's side only. It does not reflect the real number of available or busy channels on the destination (gateway or carrier) side.

If we need to set different destination limits  for different clients, for example that Client A can send 30 simultaneous calls to our UK route while Client B is allowed to send only 15, we can achieve that by adding duplicate entry in the "gateways" menu for the same gateway but with different name for example, like in the picture below, CarrierUK2 and then associate this new entry with the dialing plan entry for ClientB. Thus, the traffic from both clients will be forwarded to the same gateway but with different channels limits.

11.8.  Load sharing

Load sharing is a functionality enabling  controlled traffic  distribution among different endpoints (gateways/gatekeepers or carriers). To each route a balance share value can be assigned which represents percentage of the total traffic sent to given destination. Voipswitch will control the incoming traffic and use sophisticate algorithm to achieve the distribution closest to the projected. For example if we set even distribution 33% per each of three gateways handling calls to for example UK (44 country code), the voipswitch will be directing the incoming calls to defined routes such that when at any moment we run a report we should see that the exact (or very close to it) number of calls has been sent thru each route. Note that all priorities are the same for each route included in the load balancing, that is so becouse in this scenario each route shares the same level of importance (same quality or same price etc.).

There is no limits in number of sections utilizing load sharing functionality, for example there can be different groups for UK traffic, different for US and so on.

 Configuration procedure:

1. The scenario can be implemented for any type of client and any type of destination (both gateways and gatekeepers/sip registrars are supported). About adding clients and termination endpoints in wholesale scenarios see above scenarios and related configuration procedures.
2. Go to the dialing plan, add routes that will share the traffic, specify the "phone number", the same  for each route, for example country or area code, like 44 in the example above.
3. For each of the newly created entries in the dialing plan (routes) set the same priority, for example 0 which is the highest priority but it can be as well any of the lower priorities if you want the group to take the overflow traffic (failling from the routes with the higher priority).
4. Set "balance share" parameter for each route. It is percentage of the total traffic. The total percentage, if you sum the values, should be equal 100%.
   \\\\\\

1.9.  Traffic failover

Maximization of the calls completion ratio (ASR) is one of the most important factors in every VoIP deployment. To accomplish this one  should secure  supplies of the voice termination by arranging contracts with multiple carriers instead of relying on  one source only. Voipswitch can work with multiple carriers (gteways/gatekeepers) for each destination, actually there is no limits in number of routes defined for particular code. To specify which route should be taken as first we should use priorities. This parameter can be found in the dialing plan. When adding the first entry for given code, for example 44 like in the picture below, the priority will be set by default to 0. When adding another entry in the dialing plan with the same code (i.e. 44), the priority will change to 1. When adding next it will change to 2 and so on. At any moment we can manually change the priorities and thus the routes order. Just we have to take care of that the priorities differ with each other. If we set the same priorities voipswitch will pick only one route (the first in the database) and will ignore the second with the same priority, unless we enable "balance share" option which is described in the scenario below.

The failover procedure starts with voipswitch trying to send a call to the route with priority 0 (or any other number which is highest for given "phone number"). When the remote endpoint has responded with error code or has not responded at all, voipswitch immediately starts trying next route. The whole process lasts untill the call is connected or the last entry with lowest priority failed, only then the release code is sent to the client. For the client there is no indication which route the call has been sent through.

In addition we can define on which release codes sent from destinations voipswitch should continue failover procedure and on which not. We can select any SIP or H323 end codes and exclude them from failover (see:.....).

Note: Voipswitch automatically performs failover procedures when there is higher (less detailed) code (phone number) defined in the dialing plan. For example if we have an entry for 44 ("phone number" field) and another entry for more general code 4, voipswitch will be re-trying always when the route for 44 fails. To avoid this use "special properties" selector (in the dialing plan) and choose "do not jump" option. It will cause that voipswitch stops on this route.

 Configuration procedure:

1. The scenario can be implemented for any type of client and any type of destination (both gateways and gatekeepers/sip registrars are supported). About adding clients and termination endpoints in wholesale scenarios see above scenarios and related configuration procedures.
2. Go to the dialing plan, add routes that will share the traffic, specify the "phone number", the same  for each route, for example country or area code, like 44 in the example above.
3. For each of the newly created entries in the dialing plan (routes) set different priority, for example start with  0 which is the highest priority and then for subsequent routes  1, 2...

1.10.  Least call routing (LCR)

One of the purposes of the traffic failover functionality, described earlier,  is to maximize profits by sending calls first to carriers with the lowest price (which often goes in pair with lower quality) and then in case of failure tries other routes with worse pricing. This however requires us to change the priorities depending on the changes in carrier's rates sheets. The process quickly becomes complicated as we have to compare rates for the interesting us routes, pick the cheapest and change the dialing plan. The Least Call Routing (LCR) mechanism is  intended to help us. Its task is to check the cost tariffs assigned to the carriers that belong to LCR group and compare their rates. This is performed every defined interval. When the rate has changed it is reflected in the dialing plan - the LCR service changes priorities and thus changes the failover sequence. What is left to us is only to upload new rates sheet when it comes from carrier.

Below picture illustrates the process.

Configuration procedure:

1. The scenario can be implemented for any type of destination (both gateways and gatekeepers/sip registrars are supported). About adding termination endpoints in wholesale scenarios see above scenarios and related configuration procedures.
2. Create new tariff with cost rates. i.e. with rates received from each particular carrier that is going to work under LCR. (see: working with tariffs)
3. Assign cost tariffs to appropriate carriers. Go to either "gateways" or "GK/Registrars" menu,  select "cost tariff" option and select the tariff containing the rates which we pay to the carrier.
4. Go to the dialing plan, decide on which code (country, area or other code defined in "phone number" field) should be controlled by LCR and for each of the entries activate LCR option.
5. Make sure that Least Call Routing service is running (it is shown in the "services" tool in Windows control panel)
   \\\\

1.11. Registering client to voipswitch as to  h323 gatekeeper

Despite the fact that in wholesale, clients usually send traffic in direct mode (peer to peer), yet some of them need to be registered first to gatekeeper. Voipswitch can act as both h323 gateway (switch/proxy) and as h323 gatekeeper as well. Moreover that whether client is regsitered or not does not make any difference in the dialing plan and termination scenarios (described above). To allow  clients to regsiter to voipswitch as to h323 gateekeper simply follow the steps described below.

Configuration procedure:

1. Go to "voipswitch h323 settings" menu
2. Set the h323 gatekeeper separating character, by default it is @. It is the character which is used to split the registration string sent from client, to username and password so that voipswitch can authorize the request.
3. Make sure that Gatekeeper functionality is enabled (see:.......)
4. Go to "common clients" (or "GK/Registrar clients") and create an account (see:....)
5. Provide the client with username@password (where @ is previously defined seperating character) and voipswitch's Ip address as the gatekeeper IP
6. On voipswitch's main application we should see the icon representing the registered client in "Registered clients" window. Try to click right mouse button on the icon to see the client details. In case when there is no new icon in the list check the logs window for the messages indicating that registration request has been received, every attempt should be reported there along with the rejection reason.
   \\\\

1.12. Registering  client  to vps  as to SIP registrar

In this scenario clients register to voipswitch using SIP protocol. Voipswitch acts as a SIP registrar. The configuration procedure is the same as in the scenario 1.11. (with h323 gatekeeper) with only exception that we go to "SIP settings" menu to enable SIP registrar and that there is no need for separating character (see:..............)

1.13. VoIP Tunnel - termination calls to/from blocked areas

1.14. Ported numbers (eg.  mobile termination thru gateways supporting only specific networks,  like in UK)

Mobile number portability (MNP) enables users to change GSM operators and retain their phone numbers. More about this service can be found here http://en.wikipedia.org/wiki/Mobile_number_portability 

MNP also affects VoIP wholesale services as a termination carrier, before sending call to particular Mobile Operator, has to first ensure that the number belongs to this operator. If not, the call will be charged at higher, internetwork rate.  That usually means losses to the provider which can affect the whole business especially in countries like UK where the rate of ported numbers is high. To ensure that the number belongs to given network the provider has to query a specialized service provider that offer MNP lookup. The query is sent by voipswitch to the provider before each call, the provider immediately responds with information that allows to determine the actual mobile network to which the number is subscribed. In next step voipswitch sends the call to proper termination carrier/gateway. The way how the routing is organized and what is the format of  the lookup providers responses depends on particular implementation. The provider can respond with different parameters based on which we can recognise the mobile network, usually the response contains the original number with a prefix which indicates the mobile network. Very often the prefix can be defined by the termination provider (i.e. client of the lookup provider). The protocol used to exchange the information between voipswitch and the lookup provider is usually http but also it can be for example ENUM.

The picture below shows the implementation example when the VoIP carrier has three separate GSM gateways, each with SIM cards belonging to specific mobile operator. The main mobile network code is 4860 and is pointing to lookup destination (in the dialing plan). Next entries in the dialing plan are for the 4860 code but with different prefixes and each is pointing to appropriate gateway. The same prefixes are also defined on the lookup provider's side. When a new call to 4860... comes, voipswitch sends a query to the lookup provider which in tunr responds with the translated number with one of the three defned prefixes added in front. Having received this modified number voipswitch looks for the appropriate entry in the dialing plan and send the call to the destination gateway.

Voipswitch supports several lookup providers, for example Nquire in UK. In addition it offers a flexible way of adding http strings (with various parameters) that are used for communication with the lookup provider.

More about the lookup scenario implementation can be found here ............

1.15. Roaming services - Mobile number localization

Voipswitch can be used also for so called "cheap roaming" services offered by MVNO (mobile virtual network operators) or in cooperation with them. Users when travelling abroad can be called to their mobile phone numbers (for example from UK) and the call will be routed thru VoIP, directly to temporary phone number assigned by the visited mobile network. Thus the roaming charge is omitted, which otherwise woudl be incurred by the receiver. The same way is used when the user wants to make a call. In this case however the call request has to be sent to voipswitch, for that USSD protocol (similar to SMS), is used. In fact it is like kind of callback with a difference that the call back is sent thru VoIP not to the original phone number but to the temporary number in visited network. The advantage of the USSD is also that a user does not have to create SMS but instead just simply enter the number like in regular dialling, with only difference that a special character (usually * ) has to be added at beginning of the number. 

The service can be offered also in connection wtih virtual numbers, for example users can have local UK number or local number from any other country mapped to the roaming SIM. Thus, they can be reached under local number which is then forwarded to the temporary number in visited network. 

Voipswitch supports communication procedures used for working with number location providers however each implementation will differ depending on various factors chosen during the process. To get more information please contact us at sales@voipswitch.com .

1.15.  ENUM scenario

 The main role of ENUM based services is to provide e164 numbers translations. For example before sending a call to desitnation carrier/gateway we can query ENUM server wich will respond with VoIP address (provided that the pstn number is added in the ENUM database) and in turn voipswitch will route the call directly to received address instead to the usual termination carrier. Thus we can maximize our margins on termination services as sending call directly through internet  is free. The VoIP address is usually represented by SIP URI. This method allows us to interconnect with other VoIP providers and exchange traffic among their users without sending to external PSTN networks. More about ENUM can be found here http://en.wikipedia.org/wiki/Telephone_Number_Mapping

Also interesting idea is  free internet numbering plans which enables users or VoIP providers to obtain unique international phone number or whole pool of numbers. The numbers can be then used for calling among VoIP provider clients. More information can be found at www.free164.org

Wholesale carriers should be also interested in possibility to connect to peering services, i.e. VoIP network exchanges that allows for multilateral voice (and not only voice) traffic exchange among participating networks (see: http://en.wikipedia.org/wiki/Voice_peering&nbsp

Configuration procedure:

1.18. Working with different currencies

1.19. Invoicing

            sending via email

            via web (WTP or Portal)

            customizing invoice

1.20. Low balance notification via email

1.21. Wholesale SMS

            SMS API, protocols http, SIP, SMPP (in progress)

            adding providers, etc