Hey there,
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.
https://wiki.freepbx.org/display/FPG/NAT+Configuration+FreePBX+12
1 Like
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[5122][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.
thanks.
1 Like
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.
Followed by
[2020-04-03 16:36:19] WARNING[18879]: 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[30515][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.
Ok then.
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.
pjsip.aor.conf
[+49xxxxxxxxxx]
type=aor
qualify_frequency=60
contact=sip:[email protected]:5060
pjsip.auth.conf
[+49xxxxxxxxxx]
type=auth
auth_type=userpass
password=xxxxxxxx
username=+49xxxxxxxxxx
pjsip.conf
[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
pjsip.endpoint.conf
[+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
pjsip.identify.conf
[+49xxxxxxxxxx]
type=identify
endpoint=+49xxxxxxxxxx
match=tel.t-online.de
pjsip.registration.conf
[+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
pjsip.transports.conf
[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).
1 Like
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.