SIP Trunking Overview With IOTA

Learn more about the IOTA solution at profitap.com/iota


Structure, challenges, and solutions in relation to error analysis

SIP trunks represent the current state-of-the-art technology for coupling different telephone networks. They are used in the connection between companies and public network operators and the coupling between several IP PBX systems.

If there are quality problems on the SIP trunk, features that do not work correctly, or a total failure, in-depth protocol analysis is required. Profitap IOTA can offer support here in several aspects.

On the one hand, a SIP trunk consists of signaling via the Session Initiation Protocol (SIP) for connection establishment and termination and changes in the communication patterns. On the other hand, it also handles the voice data via Real-time Transport Protocol (RTP). Multiple voice transmissions can thus be set up and used via SIP trunks. To do this, an IP PBX connects to a SIP provider. On the company side, an Enterprise Session Border Controller (E-SBC) is typically used for application-side protection and termination point. In contrast, the provider side usually uses several Provider Edge Session Border Controllers (PE-SBC). In addition, multiple firewalls are used to protect the packet level.


Figure 1: Connection of an IP PBX to a public telephone network operator via a SIP trunk. The IOTA is integrated in-line with the private and public SIP trunk. When using switches, SPAN ports can also be used to forward traffic to the IOTA.

Not all SIPs are the same. There are now over 100 RFCs dealing with SIP, often with “SHOULD” instead of “MUST” information. Every provider, but also IP-PBX manufacturer, implements SIP differently. Even interoperability recommendations, such as SIPConnect 2.0, have changed little so far. This leads to incompatible implementations that must first be diagnosed using a protocol analysis based on packet recordings.

In addition to the challenges mentioned earlier in the signaling area, a SIP trunk also has some peculiarities in voice data transmission. Users place high demands on the quality of service for telephony. However, the real-time transmission of voice via RTP places high demands on the parameters of packet loss, jitter and delay, despite the low data rate compared to other protocols.

While the delay plays an uncritical role in email transmission, a high delay on the SIP trunk results in a poor quality experience for the user. This should be less than 150ms for good mouth-to-ear quality. Excessive jitter and packet loss can result in silence or robotic voice transmission. The jitter should be less than 30ms, and the packet loss less than 1%. It is also relevant whether the losses are blocky or distributed.


Figure 2: Call detail overview showing quality metrics for voice traffic. In addition to the displayed representations, filters with jitter and packet loss in operators such as greater than/equal, and MOS score, can also provide valuable insights.

The troubleshooting methods differ depending on the error pattern. In addition, it is important to clarify on the SIP trunk whether the problem arises in the company's VoIP network or in the provider's network before proceeding to a more in-depth analysis. In many cases, this requires measurements at different points: at the gateway to the provider, between E-SBC and PE-SBC, and between E-SBC and IP-PBX.

It is also important to differentiate between signaling errors and voice transmission errors. This requires good pre-qualification with the users. In the case of signaling errors, an analysis of the SIP request methods and the associated responses is required. Since SIP is based on HTTP, you can use error codes, i.e., 400s for client-side errors and 500s for server-side errors, to draw initial conclusions about the cause of the problem. However, in the form of a baselining, it is important to note that “401 Unauthorized” on a SIP registration does not represent an error but merely an authentication request. The same applies to a “407 Unauthorized” on a SIP INVITE. On the other hand, a “404 Not Found” would indicate a dialing error or an incorrect number format. A “488 Not acceptable here” in response to an INVITE with “Session Description Protocol (SDP) Offer” indicates an incompatible codec.

If there are quality problems in the area of real-time transmission, attention must be paid to jitter, delay, and packet loss. This applies to both communication directions. Concerning one-sided or no communication, a look at firewalls and NAT transitions in combination with an analysis of the previously negotiated data in the session description protocol is necessary. For example, if a client transmits its private IP address in the SDP via the SIP trunk to the provider, the provider cannot send the voice data back to the company on the way back. This can be detected in a download of the SIP signaling in PCAP format. SIP is often released in the firewall environment, but RTP is forgotten or only released unidirectionally. A recording before and after the firewall can provide a decisive clue to the cause.


Figure 3: VoIP dashboard with a list of the calls in the selected time interval, as well as the total of SIP request methods, and associated responses.

The Profitap IOTA can provide valuable help with signaling problems, such as incompatible SIP implementations. By filtering for the relevant calls and communication directions based on SIP header data or IP address information and ports, the person responsible for the system efficiently accesses the data required for troubleshooting. This way, he or she can also meet the first-mentioned challenge of differentiating the error between the provider and the corporate network.

The placement of IOTA also plays an important role. Due to the flexible application possibilities, whether at SPAN ports of switches, in in-line mode, or combined with an aggregation TAP, the IOTA can be used at different points of SIP trunks, as shown in Figure 1. If necessary, also in parallel in several places. This is also useful for determining errors in firewall releases, as mentioned above.

The VoIP dashboard shown in Figure 3 is particularly useful for recognizing error patterns in SIP signaling. It displays the answers to SIP request methods evaluated in color and percentage, allowing the analyst to quickly identify anomalies in the VoIP network. For example, if there are frequent responses of “483 Too many hops” after a change, this indicates a call routing error in the form of a loop.

But IOTA also offers a wide range of options for troubleshooting in the area of real-time transmission. To be able to clarify where packet loss, jitter, or delays occur, you need a flexible tool that combines recording and analysis. Clear dashboards should show the analyst directly whether there is a quality problem at the recorded point. This clarification process can be greatly simplified with the portable IOTA.

As shown in Figure 2, it also provides the analyst with the option to identify whether the error originates from the caller to the callee or vice versa.


Figure 4: VoIP dashboard with filter for calls with a jitter greater than 1 millisecond from the RTP source in the last 15 minutes.

SIP trunks pose multiple challenges for analysts in the troubleshooting process. Troubleshooting can be time-consuming and complex without the right tools, such as the Profitap IOTA. In addition to the pure recording of the required data, prepared and customizable dashboards with appropriate filters help quickly find the problem's root cause.


Learn more about the IOTA solution at profitap.com/iota

  • Last modified: February 29, 2024