Decoding Call Failures: A Structured Approach to Pexip Log Analysis and Recurring Issue Prevention

Why Log Analysis Is the Foundation of Reliable Video Infrastructure

Every failed call in a Pexip deployment leaves behind a record. Signaling errors, media path interruptions, bandwidth threshold breaches, codec negotiation failures—each of these events generates log entries that, when read correctly, tell a precise story about what went wrong and where. The challenge for enterprise IT teams is not a lack of data. It is knowing which data to retrieve, how to interpret it in context, and how to translate findings into preventative action.

This guide is designed for IT administrators and network engineers who manage Pexip Infinity deployments and need a repeatable, structured workflow for investigating call failures and eliminating recurring problems before they erode user confidence.

Understanding the Pexip Log Architecture

Before diving into troubleshooting workflows, it is important to understand what Pexip actually captures and where it stores that information.

Pexip Infinity generates logs at multiple levels:

• Administrator logs: High-level records of configuration changes, system events, and administrative actions.
• Support logs: Detailed diagnostic data generated per-node, including signaling traces, media statistics, and error codes. These are the primary source for call failure investigation.
• Event Sink data: Structured event data that can be forwarded to external SIEM or analytics platforms for long-term retention and correlation.
• Conference History and Participant History: Accessible through the Pexip Management Node, these records provide a per-call summary including connection quality indicators, disconnect reasons, and participant endpoints.

For most failure investigations, the support logs—downloadable from the Management Node under Logs > Support Logs—will be your primary working document. These are compressed archives containing per-service log files for each Conferencing Node involved in the call.

Step 1: Establish a Call Identifier Before You Start

Effective log analysis begins with precision. Attempting to search logs without a clear identifier is time-consuming and often inconclusive.

Before opening a single log file, gather the following from the affected user or your monitoring system:

• The approximate time and date of the failure (in UTC, since Pexip logs use UTC timestamps)
• The Virtual Meeting Room (VMR) alias or conference ID
• The participant's display name or endpoint address
• The Conferencing Node the participant connected through, if known

With this information, you can navigate directly to the relevant section of the support logs rather than parsing thousands of unrelated entries. The support_log file within the archive is the primary target. Use a text editor capable of handling large files—tools like grep, less, or a purpose-built log viewer will significantly accelerate this process.

Step 2: Trace the Signaling Path

The majority of call failures originate in the signaling layer—the exchange of SIP or H.323 messages that establishes the call before any media flows. When a call never connects, or drops immediately after connecting, begin your investigation here.

Search the support log for the participant's SIP URI, H.323 alias, or IP address. Look for the initial INVITE (SIP) or Setup (H.323) message and trace the response codes:

• 4xx responses (e.g., 403 Forbidden, 404 Not Found) indicate authentication failures, incorrect dial strings, or routing misconfigurations.
• 5xx responses indicate server-side errors on the Conferencing Node or an upstream SIP trunk.
• 408 Request Timeout or 503 Service Unavailable often point to network reachability issues between the endpoint and the Conferencing Node.

For calls that connect briefly and then drop, look for BYE messages and examine the reason header. Pexip populates these headers with descriptive values that can indicate everything from DTLS handshake failures to media timeout events.

Step 3: Investigate the Media Layer

If signaling completes successfully but participants report one-way audio, frozen video, or poor quality, the failure has moved into the media layer. Pexip logs capture media statistics including:

• ICE candidate negotiation results: Look for ICE failures or fallback to relay paths, which may indicate firewall or NAT traversal problems.
• DTLS handshake status: Failed DTLS negotiation will prevent encrypted media from flowing, even when signaling succeeds.
• Codec negotiation: Confirm that both endpoints agreed on a common audio and video codec. Mismatches here can cause silent calls or video-only connections.
• Packet loss and jitter statistics: Pexip logs per-stream quality metrics at regular intervals. Sustained packet loss above 1–2% or jitter above 30ms during a call is a strong indicator of network path degradation.

Cross-reference these findings with your network monitoring data for the same time window. Pexip's media statistics alone can identify that a problem exists on a given path, but your network infrastructure logs will identify whether the root cause is a congested WAN link, a misconfigured QoS policy, or an overloaded Conferencing Node.

Step 4: Correlate Across Nodes and Time

Enterprise deployments frequently involve multiple Conferencing Nodes, and a cascaded failure—where a problem on one node affects calls routed through it—can be difficult to identify without cross-node log correlation.

When a pattern of failures appears to affect a subset of users or a specific geographic location, pull support logs from all nodes in that region and compare timestamps. Look for:

• Repeated authentication errors from the same endpoint or subnet
• Node-level resource warnings (CPU, memory, or port exhaustion)
• Simultaneous signaling failures across multiple participants, which may indicate a shared upstream dependency such as a SIP trunk or DNS resolver

Pexip's Management Node also surfaces node health metrics through the Status > Conferencing Nodes view, which can help you quickly identify whether a specific node was operating outside normal parameters during the failure window.

Step 5: Build a Preventative Action Log

Diagnosing a failure is only half the work. The more operationally valuable outcome is a documented action that prevents the same failure from recurring.

For each confirmed root cause, create an entry in your internal change management or incident tracking system that includes:

• The specific log evidence that confirmed the root cause
• The configuration change, network adjustment, or endpoint firmware update applied as a fix
• A verification test confirming the issue is resolved
• A monitoring alert or threshold configured to detect early signs of recurrence

For example, if log analysis reveals that ICE failures are occurring because a specific firewall rule is blocking UDP traffic on the TURN relay ports, the preventative action is both the firewall rule correction and a monitoring alert on ICE failure rates for that node. Without the alert, the same misconfiguration could reappear after a firewall policy refresh without triggering a user-reported incident.

Operationalizing Log Review at Scale

For organizations managing large Pexip deployments, reactive log analysis—triggered only by user complaints—is insufficient. Consider implementing the following practices:

• Scheduled log exports to a centralized SIEM platform (such as Splunk or Microsoft Sentinel) using Pexip's Event Sink integration. This enables proactive alerting on error patterns before they generate support tickets.
• Weekly review of Conference History data to identify VMRs or endpoints with above-average failure or poor-quality rates.
• Baseline documentation of normal log patterns for each Conferencing Node, so that anomalies are easier to identify during incident response.

Pexip's logging infrastructure is detailed enough to support a mature observability practice. The organizations that extract the most value from it are those that treat log analysis not as a reactive firefighting tool, but as a continuous quality assurance process built into standard IT operations.

Conclusion

Call failures in enterprise video environments are rarely mysterious when you know where to look. Pexip's logging architecture provides a comprehensive audit trail that spans signaling, media, and system health—giving IT teams the raw material to diagnose failures with precision and implement fixes that hold. The discipline is in the methodology: establishing clear identifiers before you search, tracing failures layer by layer, correlating across nodes, and converting every diagnosis into a documented preventative action. Applied consistently, this approach transforms log data from a reactive resource into a proactive pillar of your video infrastructure reliability strategy.