SB.CALL Detected Emergency Call 24 Setting processing Emergency Call

[ftwrobert]

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?

[Anonymous · Accepted solution]

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

[ftwrobert]

Thanks David! That makes perfect since. I've used always-permitted for each of my dial plan's. I don't need the 900's to distinguish between any calls. I'll test this shortly and get back to you.

[mhccphoneguy]

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

[mhccphoneguy]

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

[Anonymous]

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

[mhccphoneguy]

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

[Anonymous]

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

[Anonymous]

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

[mhccphoneguy]

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

[mhccphoneguy]

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?

[Anonymous]

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

[mhccphoneguy]

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!

[Anonymous]

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

[mhccphoneguy]

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.