SNGREP is a monitoring tool that provides a live SIP trace of a call. This can be useful in many different situations, but mostly it is used when CLIR does not provide useful information for problematic calls. SNGREP is used in the following situations:
- Dropped calls
- Audio issues
- Failed calls where the reason is not listed in CLIR
- To determine a call flow
- Registration issues
A basic user guide on how to access SNGREP can be found on this link.
How to analyze a call?
When a call is made, there will be 2 call legs shown as that represents a standard SIP communication. The first leg represents the flow from the user (device) to PBXware (Asterisk) and the second leg is from PBXware (Asterisk) to the SIP provider (Trunk provider/carrier).
1st leg
'SIP From' in the first call leg represents the Tenant number + Extension number and the Source in this case is the public IP of the phone/app that makes the call.
'SIP To' in the first leg is the dialed number and the 'Destination' in this case is the PBXware IP.
2nd leg
'SIP From' is the Caller ID that is sent to the Provider and the 'Source' is the PBXware IP.
'SIP To' is the dialed number and the 'Destination' is the IP of the carrier/trunk provider.
Now, we select both call legs as described on the basic user guide and open both legs at the same time.
Here, we observe the mentioned IPs and the call flow Device (Yellow) -> PBXware (Red) -> Trunk provider (Blue).
In the basic SIP negotiation, there will be an initial INVITE sent. As per the next screenshot, this INVITE does not contain the authentication and that is expected. The phone is sending this INVITE to PBXware (without authentication) and PBXware replies with 401 Unauthorized.
It is important to emphasize that this is a normal response and it is not a root cause of any issue that a user might experience.
After that in the standard SIP negotiation after 401 Unauthorized response, the phone would send ACK (acknowledgment that the authentication is required) and then send another INVITE that contains the authentication. As per the next screenshot, we can see that there is an authentication header included in this INVITE.
The important part is to see which side sends BYE as BYE represents the call termination. In this particular example, BYE comes from the remote side (Trunk provider/end-user on the remote side):
This piece of information is relevant when we are analyzing dropped calls as CLIR will not provide this type of information.
Furthermore, if there is an issue with dropped calls, we may observe the RTP and the codecs that are exchanged. For example, if there is g729 codec sent/received and after that the call is dropped, we should check if that codec is installed on PBXware as that one does not come by default.
The same analysis comes for the audio issues as well - if RTP is missing from any end, we can see if it is actually sent or not and if it is missing from a certain end (not sent from the carrier, for example).
However, if there is an issue with the call quality and packet loss, it would be best to download the SIP trace and observe it in Wireshark.
The most common issue - Caller ID
In case a valid Caller ID is not sent from PBXware, the provider will reject the call. Depending on the remote side setup, the response will be 503 Service Unavailable or 486 Busy.
For example, below we can see that the Caller ID is sent as 'Unknown' and the remote side replies with '486 Busy Here'.
Important things to observe
1. Headers
From - Contains the Caller ID sent to the provider (in the leg from PBXware to the trunk provider)
To - Contains the number that is dialed and it shows the format in which the call is sent to the provider. For example, here we can see if there is any prefix added or something changed compared to the number that was dialed by the end user.
Remote-Party-ID - CallerID sent to the provider in the form of Remote-Party-ID
User-Agent - in the leg to the provider, this will show PBXware/Asterisk, but in the initial leg from the end user to PBXware, it will show the phone/app model/type that was used to make a call. E.g.
2. TLS
If the phone/app is registered on TLS, the traffic will not be shown in the SNGREP as TLS traffic is encrypted. On the PBXware Monitor page, we can check the protocol that is used for the registration and keep in mind that TLS leg will not be shown here. If we are troubleshooting gloCOM/Communicator application, we can switch the transport on the application briefly to TCP/UDP while testing and that traffic will be shown.
3. sipPROT
If a certain IP is blocked on sipPROT, there will be no attempt shown in SNGREP. If a phone is trying to register from a certain IP and we do not see that REGISTER in SNGREP at all, we should check sipPROT (if used) and confirm that the IP is not on the Deny list.