Live Chat Software by Kayako |
Knowledgebase: Important & Helpful Info
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.
3. After a successful billing check, our SBC will then continue to route the call.
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. Tech talk: Follow this sample log….
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. Tech talk: Follow this sample log….
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.
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 example shows the metrics received from a Yealink phone and our switch for the customer leg of the call. 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. 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. | |
|