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 nested within the Reporting header. Once you have entered the Debugging section there will be 4 headers, Sip Call Flow Tool, Prog. Voice Call Flow Tool, Detail Record Search and Webhook Deliveries.
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.
The Programmatic Voice Call Flow Tool is much simpler, and can be used to view Call Control, TeXML or Fax API flows provided you can supply the Call Session ID of the call in question.
By clicking on the example that appears once you hit Search, you can open up the Call Inspector which illustrates the flow of the call. Below is a screenshot of an example flow found using the Prog. Voice Call Flow Tool. There is also a clickable drop-down beside each call event that will open up it's associated webhook.
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.
Call State: done (CALL_REJECTED)
If you come across this websocket response, make sure to check out the specific call rejection within the message. You can see a list of error responses and their resolutions here.
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 anomaliesAnalyze 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 SIP Call Flow Tool. Simply search for your call, click the blue "Call Data Debugging" button to the right of the sample and click the "QoS" tab. 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.
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” represents the value of Interarrival Jitter, as measured by the reporter.
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
Packets
