Call emulation tool

You can now emulate calls right from the PortaBilling web interface to find out what privacy/identity headers will be passed to a vendor.

You may need to pass the verified caller identity information to vendors in specific INVITE message headers, depending on the local regulations, the equipment capabilities of the vendor, and so on. Previously, it could take a lot of time to find the proper combination of PortaSwitch options on the account, customer, and connection level to comply with specific vendor’s requirements. You had to consider various factors such as the incoming identity information received from users’ IP phones.

Now, it’s possible to try different configurations at the SIP message emulation page and check what privacy/identity headers will be passed on in the outgoing INVITE message to a vendor. Thus, you can find the needed configuration faster and reduce time spent on troubleshooting. Once you find a suitable configuration, you can save the changed options right away.

Currently, you can emulate a call between two accounts in your system or a call from account to vendor. Since the outgoing INVITE messages are not sent for emulated calls, these tests don’t affect the regular telephony service. There’s no charging for such calls, either. Thus, you don’t need to create test entities and can make tests using existing accounts/connections. The test call logs are available along with the normal call logs.

If you need to emulate a call with specific headers that are typically received from an external endpoint, you can either add the specific headers manually one by one or copy and paste the full INVITE from a sample log.

Note that when you paste a custom initial INVITE, the SDP part must be included.

PortaSwitch supports a whole set of options that may impact the privacy/identity headers. They can be configured on the account/customer/connection level and applied via a service policy. You can change all these options for caller/callee right from the SIP message emulation page. After you test the impact of specific options on the outgoing INVITE message, you can save the changed settings for a specific entity.

• Faster troubleshooting of identity handling issues via the PortaBilling web interface.
• Shorter time to interconnect with a new vendor.

Let’s consider an example:

GlobalNet, a new vendor of service provider Panda Telecom, requires the caller’s phone number (CLI) in at least one of the following headers: From, P-Asserted-Identity (PAI), or Remote-Party-ID (RPID). Otherwise, the calls are dropped.

Panda Telecom provides their customers with the ability to hide the phone number. Adam, an engineer at Panda Telecom, needs to make sure that in this case the caller’s phone number still will be sent to the vendor. Adam performs the following steps:

1. Opens Toolbox > SIP message emulation.
2. For Caller, selects the account ID, e.g., 16045551260, in the Account dropdown list.
3. Selects a node from the dropdown list.
4. For Callee, clicks Vendor and selects a vendor connection in the dropdown list.
5. Specifies any CLD for the call emulation in the “To” field.

   

   The CLD can be specified in the E.164 format or in a custom format according to dialing rules that are set up for the customer/account.

6. Opens the Account config tab and enables the Hide CLI option for the caller’s account.
7. Clicks Test.

   

Adam can see that now the account’s phone number is not included in the From header. However, the phone number is not present in either header in the outgoing INVITE message. Thus, the vendor will reject such a call.

Adam decides to set up the PAI and RPID headers, so the call will be accepted by the vendor. He opens the Connection config tab and sees that the connection is not marked as trusted (the Caller identity option is set to Do not supply). Adam selects Supply instead and clicks Test. Adam can see that now the account’s phone number is included in the PAI and RPID headers. The resulting INVITE message complies with the vendor’s requirements.

Adam wants to save the updated configuration for the connection right away. On the Connection config tab, he clicks Save configs > Save.

1. If you save the configuration for a service policy, note that the changes will affect all entities this service policy is assigned to, not only the account/connection participating in the emulated call.
2. The configuration is saved on each tab separately. For example, you have changed configuration for the account and the connection. If you open the Account config tab and click Save config, only the changes made for the account are saved.
3. The dynamically matched service policies are not considered in the emulated calls. If you use a dynamically matched service policy, it may apply to calls where specific equipment is used. So, the INVITE message in a real call may differ from the emulated one. To consider the impact of a dynamically matched service policy, you can create a static service policy with the same configuration, and apply it to the tested entity.