Knowledgebase
19Important & Helpful Info 2Sales & Quoting Tools 8Add Customers & Services 9Customer Billing 12Phone Numbers 107Hosted PBX 15SIP Trunking 15Microsoft Teams Direct Routing 6IP Fax 2Audio Conferencing 15Platform Settings 7Platform Reports 10DLC - SMS Registration Requirements 25Router & Network Help 4VoIP Troubleshooting Tools 7Release Notes
Knowledgebase: VoIP Troubleshooting Tools
How Inbound Calling Works
Posted by Wayne Landt, Last modified by Wayne Landt on 09 April 2024 03:35 PM

How Inbound Calling Works

The following is a detailed, technical article that explains the inbound calling process. This is an invaluable aid to a technician in troubleshooting inbound calling issues and working with RingLogix Customer Support.

1. When someone calls a phone number belonging to your customer, the DID Carrier will send a SIP INVITE to our SBC.


2. The instance our SBC receives the INVITE it will immediately attempt to get a real-time authorization from the billing engine. The following is verified during this check.

  • Customer Status: Open/Closed/Suspended
  • Available Credit Limit
  • Available Call Paths
  • Inbound Tariff Matching
  • Rate Lookup
  • Free Minute Bundle Check
  • Dial Permission: Allowed/Blocked
  • Maximum Call Duration
If this step fails, and based on the failure type, our SBC will either answer the call and play an error message for the caller or send a SIP rejection response to the DID Carrier which will likely trigger some sort of error message or busy tone further up the chain (I.e. at the DID carrier or the caller’s provider).


3. After a successful billing check, our SBC will then continue to route the call.
  • If the call is routed to a service like a SIP Trunk or T38 Fax line, then the SBC will send an INVITE directly to the customer’s equipment (aka “CPE”)
  • If the call is routed to our Netsapiens PBX, then the SBC will deliver the call to the PBX for further routing.

4. Once the call connects, the SBC will instruct the real-time billing engine to start the accounting process. Upon either party ending the call, the accounting will stop, and the customer’s billing records are immediately updated.



Looking at a very simple call flow

Below is an example of a typical simple inbound SIP flow.

In this example it does not really matter if the call is routed to the Netsapiens PBX, a customer’s IP-PBX, or any other form of ATA or Gateway.

The intent is to illustrate a typical inbound call flow from DID Carrier to the RingLogix SBC and then the final system.

A screenshot of a computer Description automatically generated



Tech talk: Follow this sample log….

  • All endpoints involved are referred to as UA’s (User Agents).
  • The call begins with a DID Carrier sending an INVITE to the RingLogix SBC. The INVITE contains essential information like the dialed number, caller ID, identity parameters, supported media capabilities and much more about the call.
  • The SBC begins its internal billing and routing process while starting a typical SIP dialog with the carrier.
  • Once the billing check has been accepted, the SBC sends an INVITE to the CPE.
  • The CPE immediately responds with a 100 Trying. This is usually confirmation that it received and processed the INVITE.
  • The CPE quickly follows up with a 180 Ringing message. This means its ringing locally and it’s the flag for the calling side to start playing ringing to the caller.
  • Once the CPE answers the call, it sends a 200OK message with SIP and RTP instructions for the connection. The RTP instructions are in the SDP body of the SIP message.
  • The SBC then ACK’s (“Acknowledgement”) the CPE and relays a 200OK message to the carrier and acts as a media proxy between the carrier and the CPE that’s behind NAT.
  • The carrier will then reply with an ACK and the call is officially connected.
  • Once either side hangs up, that side will send a BYE, and the other side will complete it with a 200OK.
  • Since the call is officially over the SBC will now stop the billing process.


Looking at a basic Netsapiens PBX call flow

Here is the call simply being dispatched to users 101 and 102 and then answered by 101.

A diagram of a diagram Description automatically generated




Tech talk: Follow this sample log….

  • You’ll see that the SBC delivered an inbound call to the Netsapiens PBX and started the dialog with an INVITE.
  • PBX then dispatched the call to Users 101 and 102 by sending dedicated INVITEs.
  • Each User’s device responded with typical dialog starting with a 100 Trying and then a 180 Ringing.
  • Once User 101 answered the call it replies with a 200OK, and the call is connected.
  • The PBX relays the 200OK back to the SBC for PSTN (Public Switched Telephone Network) access and sends a CANCEL message to User 102 so that it stops ringing.
  • User 102 replies with a 487 Request Terminated message to let the PBX know it complied and that dialog is over.
  • Although not on this simpler example, during an active call it is common to see a series of re-INVITE’s and REFER messages for things like keep-alive queries, transfers, and general call updates. These are helpful for troubleshooting strange events that occur mid call.
  • Eventually, the caller hangs up and the SBC sends a BYE message to the PBX.
  • The PBX relays the BYE to the device which replies with a 200OK, and the call is over.



About our Tools for Troubleshooting Inbound Calls


First, why do those 2 charts look different?

Good question. The first one is a simplified version of a log from our core SBC. Direct access to SBC logging is currently limited to our support team. These logs include detailed information about complex billing, internal and carrier routing operations.

The 2nd log has been integrated into the Netsapiens PBX dashboard and is available to all Partners. More information about in the next section.

Below is a behind-the-scenes sample SBC log our team would use to troubleshoot more complex matters.

It illustrates some expanded views of its internal components.

In this role the SBC serves multiple purposes.
  • Fraud and security tool for the PBX, the Partner, and the Customer.
  • Real-time rating engine for the Partner and RingLogix.
  • Intermediate between the Carriers and the Netsapiens PBX platform.
  • Media proxy for devices behind NAT
  • CALEA compliance tool.





Partner Level Access to Hosted PBX Logs

Hosted PBX SIP logs are helpful for all types of troubleshooting from non-ringing devices to audio quality issues.

They’re made possible by our infrastructure monitoring service called SIPWatch. Amongst many other things, our SIPWatch service performs a PCAP on every call made through our network.

These PCAPs are the data source for the SIP diagrams shown above and are also auto analyzed to measure their jitter, latency and packet loss. Using these metrics a MOS score is calculated and assigned to its respective call.

A SIP log is also created and recorded with a matching SIP ladder diagram.

The MOS scores are visible on the Call history page and hovering over them will provide additional details.

MOS scores, while not definitive, can be good indicators of call quality and can help identify problematic calls so that its SIP and RTP logs can be reviewed.
  • This tool gives our partners, support team, and associated parties, a glimpse into events that were experienced in the past, so they can be observed and troubleshot after the fact, mitigating the need for constant testing and issue replication.
  • RTP metrics are available as applicable for the inbound and outbound streams on both sides of the PBX switch.
  • Server side RTP quality determines the health of the media stream when it arrived at our network.
  • Far side RTP quality, for example from the perspective of the customer equipment, is available when the UA has RTCP sending enabled.
  • The received RTCP packets help indicate the health of the media received by the device and are also analyzed and displayed along the switch side metrics.

This example shows the metrics received from a Yealink phone and our switch for the customer leg of the call.

A screenshot of a computer Description automatically generated


Please note: PCAPs in general are exceptionally large files and proportionately grow with longer call durations and volume. As such, our system was designed to be able to record and store these raw files for up to 48 hours (about 2 days).

Hence, when troubleshooting audio quality issues, it is important to identify and report a call quickly so its logs can be retrieved and reviewed.


To view a SIP log simply find the affected call and click the magnifying glass on the right of the record.

A screenshot of a computer Description automatically generated



The logs will show the SIP dialog between the SBC and the PBX as well as the PBX and the Customer Equipment.

On the left side you can see each UA involved in the call along with all the SIP messages between them and the PBX.

For information about a given SIP message, click that message and its header details will show within the window to the right.

Note: Switch logic information is available by clicking on the gear icons between the SIP messages. Switch logic logs contain application-level information about things like time-based routes, dial plan chaining, auto attendant interactions, file playing, call queue agent dispatching and more. These logs are typically used by T2/3 Support Engineers.

A screenshot of a computer Description automatically generated