When calling one of the inbound routes, it states that the number you have dialed is not in service. But when you call it again immediately, it connects to the IVR. I connected to the asterisk when this happened, and it said “Rejecting unknown SIP connection from” then sends the no service message. Although it says it’s rejecting the connection, call again and the call goes through.
@ally_4321 - That is definitely a strange as the results should be consistent. Since you are getting different results then first we need to review the input to see if the actual messages are the same. This means from the same source IP and the same contents. My assumption is we would find a difference there which would explain this behaviour.
To do this simply take a pcap on the system using the command below and then compare the two calls using wireshark.
Command: tcpdump -i any -s 0 -w sip-trace.pcap
To compare the calls in wireshark to go to Telephony->Voip Calls to see the call flow and compare the source IP/port and compare the body of the SIP layer.
What is most likely occurring is the ITSP is sending the call from a different IP sometimes and you need to define a second trunk with this IP. That way when the call hits the PBX it is not treated as being from an unknown IP.
Do NOT enable “Allow Anonymous Inbound SIP Calls”, as this is a security risk. It may make things work, but it will allow calls from any IP to be processed.
1 Like
This should not be necessary with chan_pjsip. You should just make sure that the match / permit settings cover all the addresses from which the provider can send. One trunk should cover all inbound and outbound calls via the provider.
@david55 - You are right in general of course. I am referring to the setup below.
-
Trunk#1 → Private IP #1 → Router → ISP #1 Public IP #1 → SIP Trunk #1
-
Trunk#2 → Private IP #2 → Router → ISP #2 Public IP #2 → SIP Trunk #2
The concept is with our Sangoma SBC you use Trunk #1 to go over ISP#1, and Trunk #2 to go over ISP#2. This way the SBC decides which internet connection to use, and the router just locks IP#1 to ISP#1 and IP#2 to ISP#2.
This avoids dynamic configuration which can be problematic and allows for a static configuration, but dynamic routing.
Let me know if that clears things up. If not, I can try to draw up a quick diagram to explain it better as we don’t have a white paper or KB article for this.
Thank you for the suggestion, not too familiar with wireshark, so can you give me an idea of what I’m looking for?
Hello @ally_4321 - I made a quick video to show how to find the calls in Wireshark, and then how to click on the INVITE and view its contents. Then in the picture you can see the parts you need to compare.
So you need to compare the working one with the not working one. As mentioned I think the source IP and port will be different based on your description, so check this first. In my example the source IP is 10.0.0.17 as this is just a local IP of a lab system. In your trace this will be the public IP of your ITSP since they are the ones sending you the call.
If you need help beyond this then I would recommend purchasing support and opening up a case with Sangoma (https://help.sangoma.com/) as this stuff is best explained live during a meeting.
The video is up on my google drive at Screen Recording 2025-03-25 at 9.30.03 AM.mov - Google Drive .
3 Likes
This helped me get to the root of my problem hence I’m marking it as the solution.
My ISP gave two IP addresses that the calls ought to go through and indicated that one or both of the IP addresses could be used, and we were using both. When comparing the two .pcap files, I noticed that when it goes through one of the routes specifically it works, and when going through the other one it fails. So I removed one of the routes and only kept the working one and so far so good. Thank you!
2 Likes
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.