[asterisk-users] Failed to authenticate device message

[Jerry Geis]

I am getting this message:
Failed to authenticate device ;tag=149853321 for INVITE,
code = -1

but it does not report the "connecting" address. Who is failing connecting ?
I either need to block someone or fix something - I'm thinking block - but
I dont know who.
How do I found out the connecting IP?

Jerry
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Failed to authenticate device message

[Jerry Geis]

>exten = i,1,Verbose(Incoming ANONYMOUS SIP call from ${CALLERID(name)}
>${CALLERID(num)} SRC IP ${CHANNEL(recvip)})


Thanks - its not an incoming call - its just a log on the CLI
There is nothing before it and nothing after - no incoming call.

Jerry
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Failed to authenticate device message

[Andrew Yager]

Did you check your security log?

There is usually a wealth of info there about who, what, where when and why.

Andrew


On Wed, 22 Jul 2020 at 11:22 pm, Jerry Geis  wrote:

> >exten = i,1,Verbose(Incoming ANONYMOUS SIP call from ${CALLERID(name)}
> >${CALLERID(num)} SRC IP ${CHANNEL(recvip)})
>
>
> Thanks - its not an incoming call - its just a log on the CLI
> There is nothing before it and nothing after - no incoming call.
>
> Jerry
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
--
*Andrew Yager, CEO* *(BCompSc, JNCIS-SP, MACS (Snr) CP)*
*business nbn™ advisor (advisor 01783150)*
Real World Technology Solutions - IT People you can trust
Voice | Data | IT Procurement | Managed IT
rwts.com.au | 1300 798 718


*Real World is a DellEMC Gold Partner*

This document should be read only by those persons to whom it is addressed
and its content is not intended for use by any other persons. If you have
received this message in error, please notify us immediately. Please also
destroy and delete the message from your computer. Any unauthorised form of
reproduction of this message is strictly prohibited. We are not liable for
the proper and complete transmission of the information contained in this
communication, nor for any delay in its receipt. Please consider the
environment before printing this e-mail.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Failed to authenticate device message

[Jerry Geis]

>Did you check your security log?

>There is usually a wealth of info there about who, what, where when and why


I also checked /var/log/asterisk/messages and it just has the same
line. Nothing additional.


Jerry
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] module cel error with bridge events

[Joshua C. Colp]

On Wed, Jul 22, 2020 at 12:44 PM Administrator  wrote:

> No one on this ?
>
> Le 10/07/2020 à 18:06, Administrator a écrit :
> > Hi,
> >
> > On Asterisk 16.11.1 when enabling cel I get error with BRIDGE_START
> > and BRIDGE_END events
> >
> > zone-s*CLI> module reload cel
> > The module 'cel' reported a reload failure
> > -- Reloading module 'cel' (CEL Engine)
> > [2020-07-10 17:57:01] ERROR[16163]: cel.c:428
> > ast_cel_str_to_event_type: Unknown event name 'BRIDGE_START'
> > [2020-07-10 17:57:01] ERROR[16163]: config_options.c:798
> > aco_process_var: Error parsing
> >
> events=APP_START,CHAN_START,CHAN_END,BRIDGE_START,BRIDGE_END,ANSWER,HANGUP
> > at line 72 of
> > [2020-07-10 17:57:01] ERROR[16163]: config_options.c:544
> > process_category: In cel.conf: Processing options for general failed
> > zone-s*CLI> module reload cel
> > The module 'cel' reported a reload failure
> > -- Reloading module 'cel' (CEL Engine)
> > [2020-07-10 17:57:31] ERROR[16163]: cel.c:428
> > ast_cel_str_to_event_type: Unknown event name 'BRIDGE_END'
> > [2020-07-10 17:57:31] ERROR[16163]: config_options.c:798
> > aco_process_var: Error parsing
> > events=APP_START,CHAN_START,CHAN_END,BRIDGE_END,ANSWER,HANGUP at line
> > 72 of
> > [2020-07-10 17:57:31] ERROR[16163]: config_options.c:544
> > process_category: In cel.conf: Processing options for general failed
> >
> > If I remove BRIDGE_START and BRIDGE_END error disappears.
> >
> >
> > zone-s*CLI> module reload cel
> > Module 'cel' reloaded successfully.
> > -- Reloading module 'cel' (CEL Engine)
> > -- CEL logging enabled.
> > zone-s*CLI>
> >
> > Are those 2 events removed from cel ?
> >
>
>
BRIDGE_END does not exist in current code. All the removed events were
noted in the UPGRADE.txt document:

 - CEL has undergone significant rework in Asterisk 12, and is now built on
the
   Stasis message bus. Please see the specification for CEL on the Asterisk
   wiki at https://wiki.asterisk.org/wiki/x/4ICLAQ for more detailed
   information. A summary of the affected events is below:
   - BRIDGE_START, BRIDGE_END, BRIDGE_UPDATE, 3WAY_START, 3WAY_END,
CONF_ENTER,
 CONF_EXIT, CONF_START, and CONF_END events have all been removed. These
 events have been replaced by BRIDGE_ENTER/BRIDGE_EXIT.
   - BLINDTRANSFER/ATTENDEDTRANSFER events now report the peer as NULL and
 additional information in the extra string field.

This occurred as of Asterisk 12.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Failed to authenticate device message

[Telium Technical Support]

You didn’t post the Asterisk version, but if this is an OLD asterisk version 
then the source IP may be missing from messages/logs.

 

If you have low traffic in general then using something like Wireshark may help 
you examine any suspicious SIP packet on the PBX.  For higher volumes it’s like 
drinking from a fire hydrant, so not suitable.

 

If this is a small PBX, have a look at the SecAst product 
(https://teium.io/secast).  It’s free for small installations.  It’s an 
Asterisk security product that monitors network traffic at a the adapter level 
so it can sniff the source.  It also talks to Asterisk through the AMI so it 
can get more details of the connection/session that way.  If this is for a 
larger PBX then you would have to move the discussion to the biz list for more 
info on SecAst.  (Or email me off list)

 

 

From: asterisk-users [mailto:asterisk-users-boun...@lists.digium.com] On Behalf 
Of Jerry Geis
Sent: Wednesday, July 22, 2020 11:37 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion 

Subject: Re: [asterisk-users] Failed to authenticate device message

 

>Did you check your security log?
 
>There is usually a wealth of info there about who, what, where when and why
 
I also checked /var/log/asterisk/messages and it just has the same line. 
Nothing additional.
 
Jerry
 
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Failed to authenticate device message

[Administrator]

Hi Jerry

Le 22/07/2020 à 14:54, Jerry Geis a écrit :

I am getting this message:
Failed to authenticate device ;tag=149853321 for 
INVITE, code = -1


but it does not report the "connecting" address. Who is failing 
connecting ?
I either need to block someone or fix something - I'm thinking block - 
but I dont know who.

How do I found out the connecting IP?

Jerry


You should get it with recvip

exten = i,1,Verbose(Incoming ANONYMOUS SIP call from ${CALLERID(name)} 
${CALLERID(num)} SRC IP ${CHANNEL(recvip)})


--
Daniel

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] module cel error with bridge events

[Administrator]

No one on this ?

Le 10/07/2020 à 18:06, Administrator a écrit :

Hi,

On Asterisk 16.11.1 when enabling cel I get error with BRIDGE_START 
and BRIDGE_END events


zone-s*CLI> module reload cel
The module 'cel' reported a reload failure
    -- Reloading module 'cel' (CEL Engine)
[2020-07-10 17:57:01] ERROR[16163]: cel.c:428 
ast_cel_str_to_event_type: Unknown event name 'BRIDGE_START'
[2020-07-10 17:57:01] ERROR[16163]: config_options.c:798 
aco_process_var: Error parsing 
events=APP_START,CHAN_START,CHAN_END,BRIDGE_START,BRIDGE_END,ANSWER,HANGUP 
at line 72 of
[2020-07-10 17:57:01] ERROR[16163]: config_options.c:544 
process_category: In cel.conf: Processing options for general failed

zone-s*CLI> module reload cel
The module 'cel' reported a reload failure
    -- Reloading module 'cel' (CEL Engine)
[2020-07-10 17:57:31] ERROR[16163]: cel.c:428 
ast_cel_str_to_event_type: Unknown event name 'BRIDGE_END'
[2020-07-10 17:57:31] ERROR[16163]: config_options.c:798 
aco_process_var: Error parsing 
events=APP_START,CHAN_START,CHAN_END,BRIDGE_END,ANSWER,HANGUP at line

72 of
[2020-07-10 17:57:31] ERROR[16163]: config_options.c:544 
process_category: In cel.conf: Processing options for general failed


If I remove BRIDGE_START and BRIDGE_END error disappears.


zone-s*CLI> module reload cel
Module 'cel' reloaded successfully.
    -- Reloading module 'cel' (CEL Engine)
    -- CEL logging enabled.
zone-s*CLI>

Are those 2 events removed from cel ?


--
Daniel

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] module cel error with bridge events

[Administrator]

Le 22/07/2020 à 17:47, Joshua C. Colp a écrit :
On Wed, Jul 22, 2020 at 12:44 PM Administrator > wrote:


No one on this ?

Le 10/07/2020 à 18:06, Administrator a écrit :
> Hi,
>
> On Asterisk 16.11.1 when enabling cel I get error with BRIDGE_START
> and BRIDGE_END events
>
> zone-s*CLI> module reload cel
> The module 'cel' reported a reload failure
>     -- Reloading module 'cel' (CEL Engine)
> [2020-07-10 17:57:01] ERROR[16163]: cel.c:428
> ast_cel_str_to_event_type: Unknown event name 'BRIDGE_START'
> [2020-07-10 17:57:01] ERROR[16163]: config_options.c:798
> aco_process_var: Error parsing
>
events=APP_START,CHAN_START,CHAN_END,BRIDGE_START,BRIDGE_END,ANSWER,HANGUP

> at line 72 of
> [2020-07-10 17:57:01] ERROR[16163]: config_options.c:544
> process_category: In cel.conf: Processing options for general failed
> zone-s*CLI> module reload cel
> The module 'cel' reported a reload failure
>     -- Reloading module 'cel' (CEL Engine)
> [2020-07-10 17:57:31] ERROR[16163]: cel.c:428
> ast_cel_str_to_event_type: Unknown event name 'BRIDGE_END'
> [2020-07-10 17:57:31] ERROR[16163]: config_options.c:798
> aco_process_var: Error parsing
> events=APP_START,CHAN_START,CHAN_END,BRIDGE_END,ANSWER,HANGUP at
line
> 72 of
> [2020-07-10 17:57:31] ERROR[16163]: config_options.c:544
> process_category: In cel.conf: Processing options for general failed
>
> If I remove BRIDGE_START and BRIDGE_END error disappears.
>
>
> zone-s*CLI> module reload cel
> Module 'cel' reloaded successfully.
>     -- Reloading module 'cel' (CEL Engine)
>     -- CEL logging enabled.
> zone-s*CLI>
>
> Are those 2 events removed from cel ?
>


BRIDGE_END does not exist in current code. All the removed events were 
noted in the UPGRADE.txt document:


 - CEL has undergone significant rework in Asterisk 12, and is now 
built on the
   Stasis message bus. Please see the specification for CEL on the 
Asterisk

   wiki at https://wiki.asterisk.org/wiki/x/4ICLAQ for more detailed
   information. A summary of the affected events is below:
   - BRIDGE_START, BRIDGE_END, BRIDGE_UPDATE, 3WAY_START, 3WAY_END, 
CONF_ENTER,
     CONF_EXIT, CONF_START, and CONF_END events have all been removed. 
These

     events have been replaced by BRIDGE_ENTER/BRIDGE_EXIT.
   - BLINDTRANSFER/ATTENDEDTRANSFER events now report the peer as NULL and
     additional information in the extra string field.

This occurred as of Asterisk 12.


My doc bases is still voip-info.org (aside of the wiki) which seems 
outdated. Sorry, for the noise, thanks for having pointed that point


Regards

--
Daniel

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Fwd: blf problems after dialplan reload

[Israel Gottlieb]

Hi Guys
we have a system that uses a lot of custom hints based on the extension
the extensions use the format of ext-system for example 200-pbx01
when starting asterisk the "core show hints" show the correct hints and blf
works as expected

in the extensions.conf we have _.,hint,Custom:${exten}

when running dialplan reload all the hints lose the dashes (-) they become
200pbx01
of course blf doesnt work anymore

does anyone know a way to debug this as i think this is a asterisk bug and
would like to file a bug report
thanks,
israel
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Fwd: blf problems after dialplan reload

[Joshua C. Colp]

On Wed, Jul 22, 2020 at 6:24 PM Israel Gottlieb  wrote:

>
>
>
> Hi Guys
> we have a system that uses a lot of custom hints based on the extension
> the extensions use the format of ext-system for example 200-pbx01
> when starting asterisk the "core show hints" show the correct hints and
> blf works as expected
>
> in the extensions.conf we have _.,hint,Custom:${exten}
>
> when running dialplan reload all the hints lose the dashes (-) they become
> 200pbx01
> of course blf doesnt work anymore
>
> does anyone know a way to debug this as i think this is a asterisk bug and
> would like to file a bug report
> thanks,
> israel
>

An issue report[1] already exists for this problem.

[1] https://issues.asterisk.org/jira/browse/ASTERISK-28040

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Exceptionally long queue length queuing

[Patrick Wakano]

Hello list,
Hope you are all doing well!

Sorry for the long email but I tried to explain all I've seen regarding
this issue I am going to open a ticket for this issue but I found it
useful to already explain it here.

I've also recently faced this "Exceptionally long queue length queuing"
error in some servers running 16.8.0 and after A LOT of investigation, I've
discovered what is causing it in my case (not sure if is the same case as
initially reported by Dovid)
So, what I discovered is that in case the diaplan has a Wait() and during
this wait period many "deferrable frames" are received, the final piece of
the Wait function (ast_safe_sleep_conditional) can throw the "Exceptionally
long queue length queuing" error message.
It is not really common to get a lot of "deferrable frames" (see
ast_is_deferrable_frame) but we can have that by simply putting on hold and
off hold while the channel is on "wait".
My production case is a little more complex and happens while on Wait and
with the AST_CONTROL_SRCCHANGE event. This happens when an old Asterisk
13.13.0 receives a hold REINVITE and starts a new RTP stream (with
different SSRC) towards some other victim Asterisk with the Music on Hold
while still sending the original caller RTP (so at this point 2 RTP streams
with different SSRCs are sent to the destination that happens to be a
channel currently on Wait). I could not find any ticket for such bug, but
version 16.8.0 does not have this problem and instead seems to inject the
Music on Hold in the existing RTP stream so there aren't 2 streams at the
same time to the same destination. The problem with 2 streams is that each
RTP package of the new stream generates a source change frame
(AST_CONTROL_SRCCHANGE), and at 50pps this builds up a lot of events fast
and so if the Wait is high the issue pops up (I agree having a channel on
Wait for too long is not a good practice but noone is perfect...). Also if
multiple channels are facing this situation then the problem just escalates
very bad.
When the "Exceptionally long queue length queuing" is happening all AMI
commands seem to fail, BYE messages seem to be missed/delayed, internal
timeouts expire and all sort of weird things happen to all channels in the
server, apparently the whole Asterisk process gets locked in this loop
affecting everything else... and this is what makes this issue really bad
because Asterisk can become completely unresponsive while the error message
is happening... if it only could throw the error and keep working fine I
guess it would be reasonable leaving it up to the dialplan logic to avoid a
long Wait()
Anyway, to replicate the issue is enough a simple dialplan like this:
exten => ,1,Answer()
same => n,Wait(30)
same => n,NoOp(After wait)
same => n,Playback(goodbye)
same => n,Hangup()
After calling in and while in the Wait(30), repeatedly press Hold/Unhold in
the telephone (with Linphone just press the hold once and then press and
hold the spacebar which will repeatedly do the hold and unhold several
times). After Wait is finished the "Exceptionally long queue length
queuing" will show up but gets resolved very fast just because I think
there weren't enough frames queued to really freeze Asterisk for too long.

Thank you,
Kind regards,
Patrick Wakano

On Fri, 3 Jul 2020 at 19:29, Joshua C. Colp  wrote:

> On Fri, Jul 3, 2020 at 3:32 AM Dovid Bender  wrote:
>
>>
>>
>> On Mon, Jun 29, 2020 at 6:46 AM Joshua C. Colp  wrote:
>>
>>> On Sun, Jun 28, 2020 at 2:26 PM Dovid Bender 
>>> wrote:
>>>
 Hi,

 We have a box up and we are starting to see a lot of "Exceptionally
 long queue length queuing" in the logs. From all the research so far it
 seems like this leads to their systems crashing and being unreachable. In
 our case the box remains up and takes calls. We are running Asterisk
 16.6.1. We are using MusicOnHold to play online music streams via ffmpeg.
 Any idea on how to troubleshoot this further to see why this is happening?

>>>
>>> The message occurs when either a channel is deadlocked or the processing
>>> time to handle what a channel is doing is substantial, and things build up.
>>> Getting a backtrace[1] at the time it occurs will show what the system is
>>> actually doing and can provide insight into what is causing it.
>>>
>>> [1]
>>> https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-Runningast_coredumperfordeadlocks,taskprocessorbackups,etc
>>> .
>>>
>>> --
>>>
>> I ended up re-writing my code to use less Local channels and most of the
>> errors went away. I also noticed that my load average and CPU usage is way
>> down. I will open a ticket since it seems  that it may be a bug that others
>> are experiencing.
>>
>
> A backtrace would still be needed for the issue, otherwise there is no way
> to know what exactly is going on our where things are getting held up.
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at