I get this message printed to the console and sent to our syslog server for every call that is setup on a TA908e. Is there a way to turn this specific notification off, or to configure it to identify the call 'properly'; that is, to know it is not an emergency call?
Robert,
Thanks for posting! Emergency call detection is determined by the dial plan entries that contain "always-permitted". Therefore, my guess is that you have a matching dial-plan entry with this classification. You may want to try to remove those entries or mark them with "local", "long-distance", etc. Let me know if this doesn't resolve the issue.
Thanks!
David
Robert,
Thanks for posting! Emergency call detection is determined by the dial plan entries that contain "always-permitted". Therefore, my guess is that you have a matching dial-plan entry with this classification. You may want to try to remove those entries or mark them with "local", "long-distance", etc. Let me know if this doesn't resolve the issue.
Thanks!
David
Thanks David! That makes perfect since. I've used always-permitted for each of my dial plan's. I don't need the 900
I recently replaced a bad TA924 and started to receive the same message (see below) but cannot identify where to set 911 to local or long distance. The previous Adtran did not send out these notifications.
2017.04.28 12:55:14 SB.CALL Detected Emergency Call 65 Setting processing Emergency Call
Also, I am not seeing any 911 calls at any time from this device or in my phone system indicating that an Emergency Call was placed. Perhaps I have something miss configured with my dial plan?
Current dial plan
voice grouped-trunk TOPBX
trunk T01
accept 911 cost 0
accept 0 cost 0
accept *XX cost 0
accept MXX cost 0
accept MXXX cost 0
accept NXX-NXX-XXXX cost 0
accept 1-NXX-NXX-XXXX cost 0
accept 91-NXX-NXX-XXXX cost 0
accept $ cost 0
reject NXX-976-XXXX
reject 1-900-NXX-XXXX
reject 1-976-NXX-XXXX
I do see a 911 template configured that is labeled as "Always Permitted" but I don't recall adding this template manually as there is no way to delete it. If this alert was not triggered by a 911 call what other types of calls could trigger it?
Thanks,
Blake
Bumping to see if some additional clarification can be provided on this alert when running R11.10.4.E (see my previous response above). Also, I noticed another alert from the SB.Call application that seems to be related but is different. Are these alerts also controlled by the always-permitted dial plan entries?
Alerts seen:
MAIN_ADTRAN924_5: ADTRAN, Inc. OS version R11.10.4.E
Platform: Total Access 924 (2nd Gen), Part Number 4212924L1, Serial Number CFGXXXXXXX
2017.06.16 14:31:23 SB.CALL 451 Breaking call from (XXXX) to (XXXX) for emergency call
MAIN_ADTRAN924_5: ADTRAN, Inc. OS version R11.10.4.E
Platform: Total Access 924 (2nd Gen), Part Number 4212924L1, Serial Number CFGXXXXXXX
2017.06.15 18:48:49 SB.CALL Detected Emergency Call 436 Setting processing Emergency Call
Thanks,
Blake
Blake,
The command is hidden, if you do the following you will see it in verbose:
ADTRAN#show run verbose | include always
voice dial-plan 0 always-permitted 911 none
it is not recommended to remove that command if in the US. You want all 911 calls to have priority.
If you can attach your config, I can look at it to see what could be causing that message.
-Mark
Thanks for the quick response.
MAIN_ADTRAN924_5#show run verbose | include always
voice dial-plan 0 always-permitted 911 none
Attached are the config file (minus passwords and users) and the current event log, I left one voice user in the config as an example.
Thanks,
Blake
Blake,
First off you have a wiring issue on port 9 which if you don’t address could destroy your FXS port and/or eventually the whole FXS block. See this for more info:
https://supportforums.adtran.com/message/21932#21932
What exactly is your config? Are you taking a SIP trunk from your SIP PBX and handing off FXS ports?
Can you please send me all the users configuration please.
I don’t see right off what could be causing the Emergency Call logs. Whole config with all users will help me see everything.
Are you able to duplicate this? Anyway to have some debug running?
Really need a debug if you can
Run these:
Debug sip stack mes
Debug voice verbose
Debug sip cldu
-Mark
One other thing,
In your voice group-trunk you have a *XX the * is not a match symbol in AOS unlike regular expressions.
What are you trying to match with the *XX?
voice grouped-trunk TOPBX
trunk T01
accept 911 cost 0
accept 0 cost 0
accept *XX cost 0
-Mark
Thanks! The wiring issue for port 9 has been corrected.
· Asterisk PBX (SIP Extension via a SIP Trunk on the TA924) --> TA924 (FXS)
· The remainder of the voice users are identical to the user 205 except for the user’s name and which FXS port its connected to. But see the attached config for all users.
· Have not been able to duplicate this failure to date
I will try to make some test calls this week and turn on the debugging items you listed.
Thanks,
Blake
We are using the *XX for feature code dialing (i.e. *72, *73, *69, etc.). Is there a different method that should be used for this function in the AOS dial plan?
Is your Asterisk doing all the call permissions before sending calls to the PSTN?
If so then the easiest thing to do is just make your group trunk look like this. No point doing call permission on ADTRAN and then again on your Asterisk. You already have the $ which accepts all calls so remove everything else.
voice grouped-trunk TOPBX
trunk T01
accept $ cost 0
Another thing you can do since you have email server configured you could get an email sent to you when someone tries to place a 911 call so at least you will know that
Configure this sender field is who is going to be sending email, and address field is who the email is going to.
voice email-list emergency
sender mark@mark.com
address mark@mark.com
-Mark
I will modify the trunk and test it out this weekend when no one is here. My PBX notifies me if a 911 call is placed but it would also be a good backup from the Adtran’s just in case. Thanks for the tip!
Blake,
Couple other options you can do to catch debug of the problem:
Option 1:
Set up persistent debugging to let it run during week to catch the problem.
https://supportforums.adtran.com/docs/DOC-2870
Option 2:
New feature in AOS 12.3 is send debugging to syslog server
Upgrade firmware to 12.3 then run these commands:
Logging forwarding
Logging forwarding priority-level debug
Logging forwarding debug sip stack messages
Logging forwarding debug voice verbose
Logging forwarding debug sip cldu
-Mark
Thanks again for the information. I have made the above changes, upgraded to 12.4 .0 and have not seen these messages return to date. However it has been slow here over the summer so I will continue to monitor.