I’m currently experiencing some external calls dropping randomly (all at once) aswell as sporadic “All circuits are busy now” responses when trying to initiate an outbound call. Because of this, I believe there’s something misconfigured regarding my trunks or firewall.
I’m massively lacking experience troubleshooting voip and am desperately looking for help, guiding me in the right direction to find the reason for these problems. But please be patient with me, I’m trying my best, promised!
@Quafi Most VoIP issues tend to be networking issues. Please read over this wiki page and make sure your network and NAT settings are setup correctly.
I’ve checked my configuration against the provided documentation and everything was fine. I’ve added a manual NAT outbound rule with static ports in my firewall to adress the possibility of issues through port rewriting.
Will report back in a couple of days max. when I’m sure if the issue still persists.
@mbrooks Okay, so the problem still persists.
I’ve checked my Asterisk logfiles and have compared the ending of a dropped call to a normal call and, well, they’re exactly the same, with the exception of one additional line in the successfull call.
[2020-03-25 11:00:52] VERBOSE[C-00000025] app_macro.c: Spawn extension (macro-exten-vm, s, 26) exited non-zero on 'PJSIP/+49censorednumber-00000043' in macro 'exten-vm'
But this, at least afaik, shouldn’t have anything to do with my issue at all. Just wanted to mention it anyways.
But that’s it. How would I go about debugging from here on?
Out of curiosity, do you know if the dropped call always happen at the same interval? Like, do calls always drop after a certain amount of time? Or is it random?
It’s totally random (unfortunately), at least afaik. Sometimes calls are fine four hours, other times they drop after some time (which is also inconsistent). Sometimes you can dial out fine, sometimes you can’t. Time or day is also inconsistent. I just can’t find a valid reason.
Shouldn’t, if a call is dropped at any time, there be a log with at least to some degree, helpful information?
I’m monitoring my trunks constantly, right now in intervals of 1s for debugging reasons, and they’re shown as “registered” all the time. But that’s all I’m really monitoring, still new to Asterisk. I only feel comfortable in the FreePBX GUI, yet.
Hi @Quafi As soon you see “All Circuits are busy” error then immediately you can logic to your pbx and try to capture asterisk cli (asterisk -rvvvvv) logs and wireshark trace (https://wiki.freepbx.org/display/FPG/Wireshark+-+tcpdump+trace+on+PBX) . You may want to make new call again to capture just failure call log and tcpdump, this will give you some clue why failure is happening.
This is part of the log of a failed outbound call:
If you need more details, please let me know.
I also have a pcap file but found it hard to match log events to the correct time in the pcap file. I’d happily send both files uncensored to someone private but, for obvious reasons, wouldn’t want to post it here, accessible for everyone.
The same log/pcap should also contain an ongoing call getting dropped.
cause 21 means your carrier ‘rejected’ the call for some reason, you would only be able to get the specific ‘reason’ from your carrier.
I’ve made a reinstall of the PBX (for another reason than these failures) and have captured some syslogs.
At one point, all trunks went from “Registered” to “Rejected” with these messages:
Endpoint +49xxxxxxxxxxx is now Unreachable -- Contact +49xxxxxxxxxxx/sip:[email protected]:5060 is now Unreachable. RTT: 0.000 msec
These messages have appeared for all four trunks in a time span of 5 seconds.
[2020-04-03 16:36:19] WARNING: res_pjsip_outbound_registration.c:829 schedule_retry: No response received from ‘sip:tel.t-online.de:5060’ on registration attempt to ‘sip:[email protected]:5060’, retrying in ‘60’
Again, for all four trunks within 5 seconds.
Naturally, every call fails with the following message:
[2020-04-03 16:36:38] WARNING[C-0000000a]: app_dial.c:2576 dial_exec_full: Unable to create channel of type ‘PJSIP’ (cause 3 - No route to destination)
In case this should be helpful, any idea on what could be the cause?
The cause is easy, but not necessarily helpful. When you see UNREACHABLE, that is the PBX sending a SIP OPTIONS packet to the trunk peer, and not getting an OK back. There are many reasons why this might happen, but most commonly this is the router in front of the PBX. It is blocking or misdirecting the outbound OPTIONS, or blocking/misdirecting the inbound OK.
The PBX is running in a VM.
It is configured for IPv4 only. Inbound Firewall Roules are UDP Ports 5060/5061 & 10000-20000. Through NAT, obviously.
It has an OutboundNAT-Rule configured to use static ports instead of rewriting them. There are no Outbound Restrictions.
There’s no SipALG or anything like that active. I’m using pfSense as Firewall.
It’s configured exactly as stated in the documentation…
Just for the record, this is my configuration for the sip trunks.
I’ve posted this aswell in my provider’s forum and called them. Their answer on the phone was “Your phone line is working great, I can’t see any problems there”, whilst my PBX clearly stated a “Registration Rejected” on all trunks and wasn’t able to make any In-/Outbound calls.
[+49xxxxxxxxxx] type=aor qualify_frequency=60 contact=sip:[email protected]:5060
[+49xxxxxxxxxx] type=auth auth_type=userpass password=xxxxxxxx username=+49xxxxxxxxxx
[global] type=global user_agent=PBXAct-Appliance default_outbound_endpoint=dpma_endpoint endpoint_identifier_order=ip,username,header,auth_username,anonymous default_outbound_endpoint=dpma_endpoint
[+49xxxxxxxxxx] type=endpoint transport=0.0.0.0-udp context=from-pstn disallow=all allow=g722,alaw aors=+49xxxxxxxxxx send_connected_line=false language=de_DE outbound_auth=+49xxxxxxxxxx from_domain=tel.t-online.de from_user=0xxxxxxxxxx contact_user=0xxxxxxxxxx t38_udptl=no t38_udptl_ec=none fax_detect=no trust_id_inbound=no t38_udptl_nat=no direct_media=no rewrite_contact=yes rtp_symmetric=yes dtmf_mode=rfc4733 [dpma_endpoint] type=endpoint context=dpma-invalid context=dpma-invalid
[+49xxxxxxxxxx] type=identify endpoint=+49xxxxxxxxxx match=tel.t-online.de
[+49xxxxxxxxxx] type=registration transport=0.0.0.0-udp outbound_auth=+49xxxxxxxxxx retry_interval=15 fatal_retry_interval=0 forbidden_retry_interval=15 max_retries=0 expiration=480 line=yes endpoint=+49xxxxxxxxxx auth_rejection_permanent=no contact_user=0xxxxxxxxxx server_uri=sip:tel.t-online.de:5060 client_uri=sip:[email protected]:5060
[0.0.0.0-udp] type=transport protocol=udp bind=0.0.0.0:5060 external_media_address=xxx.xxx.xxx.xxx external_signaling_address=xxx.xxx.xxx.xxx allow_reload=no tos=cs3 cos=3 local_net=xxx.xxx.xxx.xxx/24
Some providers will shut down your connection if you get “overly chatty” with them (sending more options packets than they want or using options they don’t support). I’d suggest excerpting the /var/log/asterisk/full log section where they shut down your connection and send it to them in a trouble ticket.
If they come back and say “Yeah, we see you disconnecting but we’re not shutting you down” then the problem is likely in your local firewall/router. WHile it would be unusual, you could be dropping your NAT sessions to the outside world with some crazy short time-out in the firewall.
As Lorne said - the problem is that you are losing the connection. The likely culprits at that point are not the Asterisk or FreePBX processes - they are likely external (your provider or your network).
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.