Symptom or Need

The customer reports unavailability or failures in outgoing calls from their network. This may be evidenced by the following:

• The calls don't connect.
• There are immediate errors when trying to score.
• A massive failure of call management occurs on one or more servers.

Context / Scenarios

Two main scenarios can occur:

1. Wolkvox telephony: The operation uses the minutes and routes package provided by Wolkvox.
2. Customer Telephony (Own Trunk): The operation uses its own telephony provider connected to the platform.

Answer / Solution

1. Minimum Required Information (Triage)

Before intervening, it is essential to gather the following data:

• Name of the operation , server(s) where it is hosted and server(s) status/resource consumption.
• Percentage of impact: Is it a single agent, a campaign, or the entire operation? Validate this percentage with the client and confirm it with evidence.
• Scope: If you have more operations, validate if the failure occurs in other operations.
• Evidence: Telephone numbers with the exact date and time of the failed calls.
• For Client Trunks: Source IP (Client) from where the traffic is sent and destination IP (wolkvox).

2. Initial Validations (Level 1)

Perform the following checks in order:

• Server Status: Check if there have been recent updates or if there are spikes in resource consumption.
• Dialing Test: Enter the operation and make test calls manually.
• Log Analysis: Access the operation server, validate the test call log, and analyze the dialing results.
• Route Configuration: Verify that the prefixes and routes are correctly configured.
  • If it's a Wolkvox carrier: Verify that the carrier has sufficient funds and make direct calls from the carrier. Also, confirm whether the problem occurs with all carriers or only with a specific one.
  • If it is a Client Trunk: Check the status of the client trunk, whether the client IP is blocked, whether there were changes in its infrastructure, or whether it has blocks towards the wolkvox IP.
  • Validate the path name: Verify that the path does not contain spaces or special characters, except hyphen (-) and underscore (_).
• Cross-Test (Customer Telephony Only): Create a test trunk, route, and prefix using a Wolkvox bag. Validate whether calls originate correctly through Wolkvox but not through the customer's trunk. If this scenario occurs, the problem is associated with the customer's infrastructure.
• Server update: Based on the start time of the issue reported by the client, review the update schedule and verify if the failure coincides with recent changes to the server.

3. Escalation

If the validations performed by Level 1 do not resolve the case, proceed as follows:

• For the Wolkvox trunk: Request Level 2 to review the call status in the SBS Manager and verify if the issue occurs with a specific provider.
• Escalate to Level 2 to validate the case with the telephone provider.
• Request Level 2 verification of signaling traces to validate response codes, codecs, states, and IP addressing.
• Level 2 reviews the logs on the platform, in addition to the DID trunk configurations and routes.
• Level 2 requests the TELCO leader to analyze the previous validations in order to determine if, based on these validations, it is necessary to request RTP (Real Time Transport Protocol) traces from the Cloud team.
• In cases of customer trunking: Request from Infrastructure the traces of SIP traffic to and from the customer's IP address, in order to analyze the call flow.
• Escalate to Level 2 the detailed review of traffic on the telephony server and the configuration of the client trunk.
• Coordinate with the client's technical team to validate any potential blocks, restrictions, or configurations on their firewall or BPX.

Possible Causes

Outbound call failures can originate in one of the three pillars of communication. Identifying the source allows for precise escalation:

• Wolkvox infrastructure:
  • Instability in servers / platform: Technical failures in the telephony and operations server, or ongoing platform and/or server update processes.
  • Resource saturation: Exhaustion of CPU or memory on the server, preventing the processing of new call requests.
• Telephone Provider (Carrier):
  • Security restrictions: Preventive blocking due to suspected SPAM or detection of unusual traffic.
  • Commercial limitations: Insufficient balance in the minutes bundle or expiration of the contracted plan. Additionally, the bundle may be blocked due to simultaneous attempts to call the same number.
  • Carrier Saturation: Technical unavailability or channel congestion in the provider's network.
• Customer Infrastructure (Own Backbone):
  • Network Changes: Modification of the client's public IP address or Firewall rules that prevent SIP/RTP flow to wolkvox.
  • PBX Misconfiguration: Alterations in the customer's telephone exchange or errors in the structure of the dialing prefixes sent.

Considerations:

• Security : Verify that the system has not generated an automatic IP block due to multiple failed connection attempts or incorrect credentials.
• Responsibility Matrix:
  • Level 1 Support: responsible for initial triage, manual marking tests and direct communication with the client.
  • Wolkvox infrastructure: responsible for performing in-depth analysis of SIP traces and verifying the stability of the nodes.
  • Client / Third Party: Responsible for auditing their own network, firewall and confirming the status of their routes with their local telephony provider.

Recommendations

• Documentation Accuracy: When reporting, it is mandatory to attach examples with the exact time (HH:MM:SS). This allows the infrastructure team to filter traffic traces in real time and drastically reduces diagnostic time.
• Contingency Plan (Temporary Solution): If the failure is external to Wolkvox (customer infrastructure or external provider), we recommend enabling a Wolkvox emergency minutes package. This ensures business continuity while the underlying problem is resolved.