similar to: Faxes stopped working - AMI issue?

On 12/2/19 11:52 AM, Joshua C. Colp wrote: > So I know that AMI is listening and I can talk to it.  Here is the > main log" > > [Nov 27 06:16:00] VERBOSE[101155] asterisk.c: Remote UNIX connection > [Nov 27 06:16:00] VERBOSE[101245] asterisk.c: Remote UNIX connection > disconnected > [Nov 27 06:16:01] VERBOSE[101244] manager.c: Manager

On 12/3/19 3:04 PM, Joshua C. Colp wrote: > >     The AMI command, after the login, looks like this: > > > >     Action: Originate > >     Channel: SIP/outgoing/%%(destination)s > >     Context: LocalSets > >     CallerID: Vybe Consulting Inc Fax Service <5555551212> > >     Exten: sendfax > >   

I am having troubles with sending faxes. I hope someone can help me work out a better method. Basically we have a special address that our users can send to. It winds up on our Asterisk server which runs a Python script that parses the message for attachments and the phone number from the recipient address. The attachments are converted to TIFF and stored in a folder with various information

Hi list , someone on the list has seen this type of connection attempts in asterisk, fail2ban does not stop 2015-01-08 14:59:47] SECURITY[21515] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="1420750787-386840",Severity="Informational",Service="SIP",EventVersion="1",AccountID="sip:100 at

Hi list, I would like to now what is the sense of such type of entry in security.log [2019-09-27 15:12:24] SECURITY[26964] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2019-09-27T15:12:24.181+0200",Severity="Informational",Servic e="PJSIP",EventVersion="1",AccountID="<unknown>",

Le 30/09/2019 à 11:45, Joshua C. Colp a écrit : > On Fri, Sep 27, 2019, at 11:31 AM, Administrator TOOTAI wrote: >> Hi list, >> >> I would like to now what is the sense of such type of entry in security.log >> >> [2019-09-27 15:12:24] SECURITY[26964] res_security_log.c: >>

Hello; Did you remember to uncomment the dateformat in /etc/asterisk/logger.conf? That's necessary for fail2ban to work. Logger.conf [general] dateformat=%F %T Regards; John -----Original Message----- From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of ricky gutierrez Sent: Thursday, January 08, 2015 4:38 PM To: Asterisk

On 01/08/2015 11:37 PM, ricky gutierrez wrote: > Hi list , someone on the list has seen this type of connection > attempts in asterisk, fail2ban does not stop > > 2015-01-08 14:59:47] SECURITY[21515] res_security_log.c: >

I have an error sending to a specific fax number. It may be more than one but this is the one I investigated. It seems the delay for the SIP negotiation in T.38 was initiated after 6 seconds, however, our system sent the BYE after only 4 seconds, possibly cutting the call before all the communication necessary for the negotiation was completed. Here is the trace from our provider showing their

On 2017-04-18 02:42 AM, Pete Mundy wrote: > Try this: > > asterisk -r > core set verbose 10 > [get user to trigger fault] > [examine console output, and post to list if still unclear] > > If you don't solve it yourself, then we'll be able to help further once > we've seen the output. I can't see much more than at my previous debug level but here it is

I am running Asterisk 16.9 on FreeBSD 12.1-RELEASE-p1. I keep seeing lines like this in my logs. [Apr 1 13:30:33] NOTICE[101155][C-00004526] chan_sip.c: Call from '' (45.143.220.235:5356) to extension '2037' rejected because extension not found in context 'unauthenticated'. I have a script that checks for things like this and adds them to my packet filter (pf).

>>>>> D'Arcy Cain <darcy at VybeNetworks.com> writes: >> Ie after both sides select t38, until they agree on the t38 terms. > OK, so does that mean that setting it to 25000 should leave time for the > re-invite or does the timeout start after that. As I wrote above, after that. After the sip/sdp. -JimC -- James Cloos <cloos at jhcloos.com>

On 2/04/2020 6:35 AM, D'Arcy Cain wrote: > On 2020-04-01 16:28, Mark Boyce wrote: >> On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com >> <mailto:gdt at lexort.com>> wrote: >>> I think you need to use tcpdump and turn up firewall debugging. >> sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) > block drop in log quick on bge0

On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com> wrote: > > I think you need to use tcpdump and turn up firewall debugging. sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) Mark -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 2017-04-19 11:57 AM, J Montoya or A J Stiles wrote: > I fished this out of an old extensions.conf from a defunct project. It might > be relevant to your use case: > > exten => 1571,1,NoOp(Call to 1571: voicemail retrieval) > exten => 1571,n,AGI(lookup_caller_id.agi,${CALLERID(num)}) > exten => 1571,n,NoOp(CLID is ${clid}) > exten =>

On 2017-04-18 08:31 PM, Victor Villarreal wrote: > Maybe excecuting the following command at Asterisk console, will help you: > > asterisk> voicemail show users > > And you will get a list of all mailbox configured in your system. Search > for the user with problems. VoiceMail stocktrans2 Angelica Douglas 12 Definitely there. In fact, I generate all

On 2018-05-22 02:17 AM, Yves wrote: > you could > > - use "global variables" > - use the asterisk built in database Both of those seem difficult as the process is split between Asterisk and an external script. > - mv the file to temporary folder _before_ faxing (would be the most > easy solution as you already > know how to mv a file via asterisk...) True. This

On 2017-04-18 08:17 PM, Pete Mundy wrote: >> On 19/04/2017, at 7:58 am, D'Arcy Cain <darcy at VybeNetworks.com >> <mailto:darcy at VybeNetworks.com>> wrote: >> >> <snip> >> Everything looks the same as another one that works except for two >> things. The one that works doesn't have the "Probation passed" lines. >> I am

On 2017-04-19 02:39 AM, Pete Mundy wrote: > Hmm... Above my pay grade I'm afraid! Looking at your 'voicemail > show users' I can't see why the vm_authenticate function is > failing to read the username :( I can answer that one. It's because we can't enter 'stocktrans2' from a telephone so we just hang up. The question is, why does it ask for the

On 2017-04-20 05:14 AM, J Montoya or A J Stiles wrote: > This is just screaming "configuration mismatch" -- or, possibly, "latent bug > whereby things parsed in separate places should be treated the same, but are > actually getting treated differently". I really don't want to be the "my system isn't working so there must be a bug in Asterisk" guy