Configuration examples for Cisco gateways

Typically, you do not use authentication or authorization for such “port-based billing”, since you are always sure that your customer is on the other end of the physical line. Although it might be a good idea to implement call authorization so that you can control which destinations the customer is allowed to call to, we will not discuss this here. For port-based billing, you need only do the following:

1. For each such customer, create a tariff that you want to use to bill the customer and a product. Only one row in rating entry is necessary, with the node “ANY” and the tariff you have created.
2. Now you must make sure that each call made by that customer is tagged as belonging to him. Use the corresponding application on your gateway to handle the call. You can use the PortaOne’s “Session name” application, or create your own.

   The often difficult part in gateway configuration is designing dial-peers to match certain voice ports. Dial-peers should resemble the following configuration:

   dial-peer voice 1 pots
       application client_on_port_1
       direct-inward-dial
       port 1:D

   They will be listed with an operation status of down, as the port specification must be accompanied by a number matching a specification, for example:

   dial-peer voice 1 pots
       application client_on_port_1
       incoming called-number .
       direct-inward-dial
       port 1:D

   This dial-peer is not adequate for our needs, because any number matching the specification will prefer the port specification, e.g., this dial-peer will match any port. The solution is to use a number-matching scheme that will not match any number.

   dial-peer voice 1 pots
       application client_on_port_1
       incoming called-number A
       direct-inward-dial
       port 1:D

   This solution may be considered a “hack”, yet it is functional and secure. For increased security, you may specify a 32-character string with a random sequence of “ABCD” characters. The probability of receiving such a number is near zero. So the configuration should look as follows:

   aaa new-model
   aaa authentication login h323 group radius
   aaa authorization exec h323 group radius
   aaa accounting connection h323 stop-only group radius
   !
   call application voice client_on_port_1 flash:app_session_name.2.1.0.tcl
   call application voice client_on_port_1 user-name abc_ltd
   !
   call application voice client_on_port_2
   flash:app_session_name.2.1.0.tcl
   call application voice client_on_port_2 user-name xyz_inc
   !
   gw-accounting h323 vsa
   !
   dial-peer voice 1 pots
   application client_on_port_1
   incoming called-number A
   direct-inward-dial
   port 1:D
   !
   dial-peer voice 2 pots
   application client_on_port_2
   incoming called-number B
   direct-inward-dial
   port 2:D
   !
   gateway
   !

3. Create customers who will own these accounts.
4. Create accounts with an Account ID identical to the name you entered in the configuration for the applications (abc_ltd and xyz_inc in our example).

This is fine, assuming that calls are coming in from one of your customers; but potentially anyone on the Internet can send you traffic if they know your gateway’s IP address. This could happen due to a mistake, or it could be done intentionally; in any case, it is not good for your business if this happens. How to prevent this and make sure that only your customers and you yourself are able to use your VoIP network?

There are a few methods which enable you to do this:

1. Set up an access list (ACL) on your gateways so that VoIP traffic will be allowed only from certain IP addresses / subnets. This is a very reliable method. Unfortunately, it has one drawback: it is difficult to maintain, since everything is configured on the individual gateways. For example, if you have 12 gateways and you wish to add a new customer, you have to change the ACL 12 times.
2. Set up an application to handle incoming VoIP calls. This application will authenticate the remote party (by IP address or some other parameter) in PortaBilling and, if authentication is successful, will connect the call. There are several advantages to this approach:
   • Information about authorized gateways is stored in one place, so it is easy to maintain.
   • The application can include data required for IP-based billing in the call information (so the User-Name attribute will contain an Account ID).
   • It may be combined with authorization, so that you can also check if a remote gateway is allowed to call a particular number.
   • You can use more sophisticated ways of identifying a remote gateway. For example, instead of IP address you can use an IP+MAC address combination.
3. An improved version of the previous item is a solution in which all calls to your network arrive to a proxy (such as PortaSIP) which will take care of call authorization, while your gateways will only accept incoming calls from that proxy. Again, the easiest way to implement this is by using IP authentication on both the proxy and gateways.

We assume that you will use either method 2 or 3, e,g., your terminating gateway will authenticate incoming VoIP calls (to check that the remote gateway is allowed to send you traffic). This may be done by sending an authentication request to  PortaBilling, where the User-Name contains an identification of the remote gateway; typically this is an IP address.

This is another example of how easy it is to implement different billing schemes with PortaBilling. For IP-based billing, you just have to do the following:

1. Create a tariff and a product. Since “Node” and “Access Code” are insignificant for this type of service, set node to “ANY” and leave Access Code blank for the IP-based billing product.
2. Use the corresponding application on your gateway to handle the call. You can use the Cisco application remote_ip_authenticate, PortaOne’s “Advanced Remote Authenticate” (recommended), or create your own. The only important thing is that the IP address of the remote GW be in the User-Name attribute in the AAA requests which will go to the billing. Here is a sample configuration:

   aaa new-model
   authentication login h323 group radius
   aaa authorization exec h323 group radius
   aaa accounting connection h323 stop-only group radius
   !
   gw-accounting h323 vsa
   !
   call application voice remote_ip tftp://…/portaone.tcl
   call application voice remote_ip authenticate-by ip
   call application voice remote_ip_auth password cisco
   !
   dial-peer voice 11 voip
     application remote_ip
     incoming called-number .
   !

3. Create a customer who will own these accounts.
4. Create accounts with an Account ID identical to the IP address of the remote gateway, and enter cisco as the Service password for this account. (The password cisco has been chosen only for backward compatibility with the Cisco remote_ip_authenticate script. With PortaOne’s “Advanced Remote Authenticate” you can use a different password; just change the list in the application config).

Different termination partners often require that you send them numbers in some specific format. For example, your termination partner might require usage of the technical prefix 58901# (so you have to send him 58901#42021234567 instead of 42021234567), while your local phone provider requires that outgoing call numbers be dialed without the country code (so a call to 42021234567 has to be dialed as 21234567). The more partners you have, the more likely it is you will run into these problems with different numbering formats. It is better to use a single numbering format internally. Our recommendation is to use the E.164 format in billing and on your network. An E.164 compliant number is one consisting of <countrycode><areacode><phone#>. Examples of valid E.164 numbers are 42021234567 and 16049876543. The following numbers are not valid E.164 numbers: 6049876543 (NANP format), 01142021234567 (US overseas dialing format), 021234567 (local format).

PortaBilling provides you with a powerful tool for converting all outside numbering formats into the unified format which is to be used in billing. For every connection to a vendor you can specify a translation rule that will convert the number into E.164 format. Here are some ready-to-use examples of translation rules:

• Convert NANP (North American Numbering Plan) phone number (area code + phone number, e.g., 604 888 7766) into E.164:

  s/^/1/;

• Convert European international dialing format (00 + country code + area code + phone number, e.g., 00 1 604 888 7766) into E.164:

  s/^00//;

• Convert North American international dialing format (011 + country code + area code + phone number, e.g., 011 1 604 888 7766) into E.164:

  s/^011//;

• Convert Australian international dialing format (0011 + country code + area code + phone number, e.g., 0011 1 604 888 7766) into E.164:

  s/^0011//;

• Convert tech prefix format (tech prefix + country code + area code + phone number, e.g., 6789# 1 604 888 7766) into E.164:

  s/^6789#//;

• Convert European domestic dialing format (0 + area code + phone number, e.g., 0 5 888 7766) into E.164 (assuming that the country code is 44):

  s/^0/44/;

Always test your translation rules before entering them into the billing:

1. On your customer’s panel, click Services, then click Voice calls.
2. On the Voice calls configuration panel, click Dialing rules.
3. Click the Edit  button to edit the dialing rule.
4. Test the translation rule.

   

   

This will enable you to check if your translation rule has the proper syntax, and you can also immediately see if it performs the translation you need.

Although matching the connection by IP address is the simplest and error-proof method, in some situations it is not applicable.

It may be that your external switch uses routing via an H323 gatekeeper, where the actual IP address of the remote gateway is provided by the remote gatekeeper only during a call attempt. In this case, PortaBilling is not involved in the routing, and all that is needed is to ensure that these calls are accounted to the correct vendor. To do this, enable the Use tech prefix translation option and enter the tech-prefix in the Tech prefix field of the connection; for example, if you are using appending the tech-prefix 334567# to the phone number when sending a call to the vendor, enter 334567#.

Matching by tech-prefix takes lower precedence than matching by remote IP. Thus if a call is sent to remote IP 1.2.3.4 with tech-prefix 123#, and you have defined a connection to vendor A with remote IP 1.2.3.4 and a connection to vendor B with tech-prefix 123#, the call will be billed to vendor A.

A typical case is one in which a vendor offers you several categories of route quality. Although calls will always go to the same IP address (the vendor’s switch), the termination cost would be different based on the tech-prefix transmitted as a part of the number. In this case, PortaSwitch must also route the calls properly to the vendor, adding the required tech-prefix.

To do this, create multiple connections for the same vendor, for each one of them specify the corresponding tech-prefix in the Tech prefix field (make sure you keep the translation rules, automatically created after that) and use different values in the Gateway ID field. Obviously these connections will have different tariffs associated with them. For example, if the vendor’s proxy address is 5.6.7.8, and tech-prefix 345# offers low-cost routes, while tech-prefix 789# offers premium routes, there would be two connections, with the Remote IP field containing the same value (5.6.7.8), but the Tech prefix field will contain 345# and 789# respectively.

First of all, please make sure that both the user agents and SIP<->PSTN gateway are configured for use of the same low-bitrate codec, such as G.723.

If you use Cisco IOS and Cisco ATA 186 with PortaSIP, use the configuration guidelines below to configure your equipment:

sip-ua
  nat symmetric check-media-src

For other SIP phones or gateways, check the documentation supplied with the device.

If you are sure that the codec used for SIP calls is a low-bitrate one (for example, by inspecting the gateway logs), but the quality is still suboptimal, you need to determine where packet loss is occurring in the media path. To do this, you can use standard network tools such as ping, traceroute and the like. Keep in mind that for SIP UA<->PSTN calls the RTP audio stream flows directly between SIP UA and PSTN GW, while for SIP UA<->SIP UA calls the RTP path depends on whether or not an RTP proxy is enabled. If an RTP proxy is not enabled, the RTP flows directly from one SIP UA to another. Otherwise, each RTP packet sent by one UA goes first to the machine running PortaSIP and is then resent from that machine to another SIP UA.