Service configuration

On the Service configuration panel you can change connection settings for Voice calls and Messaging services.To save the changes, click Save.

The protocol used to transport data to a remote gateway.

This shows how an internal connection is used:

• Route to internally registered SIP accounts (SIP-UA) transports calls/messages among your end users.

• SIP-to-External SIP proxy (SIP-URI) redirects calls/messages directly to an external SIP proxy.

• Unified messaging service (INTERNAL) provides unified messaging services for your end users.

This allows you to balance the connection load based on the number of simultaneous calls established via this connection. Enable the Limit utilization by capacity toggle to set the load threshold. When the threshold is reached, some of the load is shifted to other carriers from the routing list.

Specify the load threshold. This is a specific number of simultaneous calls. The connection operates in normal mode until the number of connected calls reaches this threshold.

This describes the NAT traversal capabilities of the remote gateway (its default value is set to Optimal):

• Direct – RTP stream is sent directly to this node; RTP proxy should not be used.

• Optimal – this node is capable of NAT traversal; no RTP proxying is required unless specifically requested.

• OnNat – this node is not capable of NAT traversal; engage RTP proxy if the other party is behind NAT.

• Always – when sending a call to this node, always engage RTP proxy, so that no media stream goes to it directly.

Sometimes callers request privacy, i.e., they want their number hidden from a callee. This describes how such outgoing calls are to be displayed to the vendor.

• Do not Supply – PortaSwitch will remove all information about the caller from the call initiation info sent to the vendor.

• Supply – the call initiation request will include special privacy headers that will contain the information about the real CLI number.

Enable this option to prohibit the routing of calls with invalid CLI via the vendor connection.

Note that you need to set up CLI validation on the configuration server web interface beforehand.

This allows you to convert CLD from/to a vendor-specific format into/from the E.164 format used in billing. This is only applicable if the node that routes the call (e.g., PortaSIP or MVTS) retrieves the routing information from PortaBilling.

Select one of the following options:

• Do not translate, send to the Vendor E.164 – the number is not converted from/to a vendor-specific format and is treated as defined in E.164 format.

• Translation rule name – select the existing translation rule from the list.

If you have several connections with the same IP address (e.g., the same carrier offers you routes of different quality) and these can only be distinguished using the tech prefix in the destination number, enter that tech prefix here. This also automatically modifies the translation rules for this connection, such that when a call is routed there the tech prefix is appended to the number, and removed from it when CDRs are being processed.

Also, use the Tech prefix to indicate that a call must actually be charged based on ANI (CLI). Specify the prefix for toll-free numbers (e.g., 1800) sent via this connection. Please refer to the Billing by ANI (CLI) handbook for more information.

Note that Tech prefix must be specified in the same format as that in which the vendor sends you the number, since connection matching is performed before the number translation rules are applied. If the vendor sends you 10-digit format (e.g., 8005551234) US toll-free numbers, you need to specify the prefix as 800 and then define the translation rule, which will add “1” to the number for any further rating-specific format (e.g., 800). In this case, PortaBilling will use this connection for calls that come from a particular IP address/username where CLD matches the specified prefix.

This allows you to convert CLI (ANI) to/from a vendor-specific format when routing a call to/from the vendor’s network. This is only applicable if the node that routes the call (e.g., PortaSIP or MVTS) retrieves the routing information from PortaBilling.

Select one of the following options:

• Do not translate – the number is not converted from/to a vendor-specific format and is treated as defined in E.164 format.

• Translation rule name – select the existing translation rule from the list.

Use this field to add location IDs to vendor connections, when you route calls to a vendor who has a number of PoPs (Points of Presence). Please refer to the Routing based on vendor point of presence location handbook.

This section provides access to the Routing filters panel where you can define the capabilities of the remote party such as delivering caller identity and filtering for call media features.