The Debugging section of your Telnyx portal account will contain several tools you will use for the purpose of debugging SIP calls and call control flows.

Video Walk-through for Debugging Tools

Coming soon! This walk-through will demonstrate usage of our Debugging tools.

Guide to the Debugging Tools

The Debugging section can be found on the left-hand list of portal modules in between the Reporting and API Keys sections. Once you have entered the Debugging section there will be 3 headers, Sip Call Flow Tool, Call Control Flow Tool and Web Dialer.

Sip Call Flow Tool

Using the Sip call flow tool is straightforward. You can specify a date range that extends back 3 days maximum, and the calling and/or destination numbers.

Additional filters include:

  • Billed duration - which can filter out calls with a billed duration greater than, equal to, or less than the value you specify.

  • Direction - which let's you filter out inbound or outbound calls.

  • Tags - which lets you filter by calls from/to numbers that have a specific tag.

  • Result code - which lets you filter based on the SIP response code received for the calls.

More info on SIP response codes can found here.

Below is a screenshot of an example call flow found using the Call Flow Tool.

Call Control Flow Tool

The Call Control Flow Tool is a much simpler tool, and can be used to view Call Control call flows provided you can supply the Call Leg ID or the Call Session ID of the Call Control call in question.

Below is a screenshot of an example flow found using the Call Control Flow Tool.

Web Dialer

The Web Dialer is a powerful debugging tool that will allow you to make test calls without needing to setup a softphone or PBX system. This is useful if you are having issues with calls and want to eliminate your PBX or softphone client as a potential source of the issue. In order to use the web dialer, you simply need a Credentials Connection, a DID number assigned to that connection and then you can assign a Caller ID name value if you wish to test that also. Once these pre-requisites are met you can make test calls straight from the web interface.

You can also receive incoming calls from the Web dialer – this is useful for testing inbound failures.

To receive an inbound call, simply dial the DID number assigned to the SIP Connection that you have entered in the steps above.


On the Debugging tab, is the TeXML & Fax tool. You will see a history of your recent activity, and hence you can either select or search for the relevant TeXML or FAX call.

Faxes and calls can be found by Fax ID or Session ID, or filtered from a list of all fax and TeXML events by time, product, originating number, or destination number. For each event, you can inspect the associated webhooks to see exactly when each was sent, and locate the source of any errors in the application.

When selecting a call ID (for example, FAX) you will see a list of all events that occurred on this call, and the relevant status & response codes:

Clicking the event will reveal further details, including the medial_url (i.e. the actual document to be faxed), the status of the event, and webhook information, including if the webhook was delivered:

Also shown under event details is the webhook inspector. This provides additional details for each webhook:

Webhook Deliveries

This tool shows a history of webhooks sent over a customers account. You can either search by webhook delivery id, or filter according to time, status and webhook name (eg. “call.initiated”).

You can use this tool to assist with debugging cases:

  • Locate and analyze specific webhooks using their webhook ID

  • Verify the delivery of a webhook

  • Verify the contents of a webhook

  • Analyze all webhooks sent in a certain timeframe or containing a certain text string (e.g., call.initiated) to find anomalies

  • Analyze all webhooks with "failed" status

The Message content, and metadata is also included in the webhook delivery tool:

QoS (Quality of Service) Reports

***Only if RTCP Capture is set to ‘ON’ ***

This feature provides customers with a visual representation of the Quality of Service (QoS) of any given call on a timeline with two separate graphics, one for each of the RTP media streams that are established for each call.

The new report feature is available in the Mission Control Portal through the Advanced View of our SIP Debugging tool. Reports are based on RTCP reports that are sent between SIP devices and Telnyx.

NOTE: As stated above, the customer must have RTCP Capture set to ON, under SIP CONNECTION OPTIONS.

See pic below:

When a call is established media starts flowing over two RTP streams, one in each direction. Periodically, each side also sends RTCP reports to report transmission and reception statistics during the interval. Each report includes the number of packets sent (packets), the accumulated packets that were expected but never received (packets_lost), the jitter perceived from the received packets (ia_jitter), and more.

QoS Reporting Streams

RTP streams and RCTP reports between Telnyx and the user

The QoS report feature uses the data on these RTCP reports to display 4 different quality metrics on a timeline for each RTP stream. Let’s take a look at what these metrics mean, and how it is displayed in the report:

  • MOS (Mean Opinion Score)

    • Our QoS report shows MOS stats based only on network metrics, any other audio issues won't be captured by it. The scale goes from 1 (Bad) to 4.5 (Excellent)


Mean Opinion Score


IA Jitter

IA Jitter

  • Packets Lost

    • “Packets Lost” represents the accumulated number of RTP packets perceived as lost by the reporter.

Packets Lost

  • Packets

    • “Packets” represents the accumulated number of RTP packets that were sent by the reporter


Can't find what you're looking for? Click the chat bubble at your lower right-hand corner and talk to the support team!

Did this answer your question?