search for: vybe

...[Nov 27 06:16:01] VERBOSE[101244] manager.c: Manager 'asterisk' logged > on from 127.0.0.1 > > 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 > Priority: 1 > Timeout: 30000 > Variable: faxfile=%%(faxfile)s > Variable: uid=%%(uid)s > Variable: destination=%%(destination)s > Variable: sender_name=Vybe Consulting Inc Fax Service &...

...VERBOSE[101245] asterisk.c: Remote UNIX connection disconnected [Nov 27 06:16:01] VERBOSE[101244] manager.c: Manager 'asterisk' logged on from 127.0.0.1 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 Priority: 1 Timeout: 30000 Variable: faxfile=%%(faxfile)s Variable: uid=%%(uid)s Variable: destination=%%(destination)s Variable: sender_name=Vybe Consulting Inc Fax Service Variable: sender_num=5555551212 Those "%%" strings ge...

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 > >     Priority: 1 > >     Timeout: 30000 > >     Variable: faxfile=%%(faxfile)s > >     Variable: uid=%%(uid)s > >     Variable: destination=%%(destination)s >...

...n a folder with various information encoded into the file name such as phone number and retry information. That all works fine. A separate process picks up the files and sends them using an AMI script like this: Action: Originate Channel: SIP/provider/%(destination)s Context: LocalSets CallerID: Vybe Consulting Inc Fax Service <6475551212> Exten: sendfax Priority: 1 Timeout: 30000 Variable: faxfile=%(faxfile)s Variable: uid=%(uid)s Variable: destination=%(destination)s Variable: sender_name=Vybe Consulting Inc Fax Service Variable: sender_num=6475551212 It then renames the file encoding...

...Detected CEDPR modem tone Universal Media Gateway MGW02-EDTMTDS 2018-06-01 08:34:20.692 - Incoming SIP message received : BYE From: 5555551111 at tor.trk.tprm.ca To: 5555552222 at 206.80.250.100 5555552222 at 209.197.130.80:5060 ********** MetaSphere CFS Distributel-Western-CFS 555-555-1111: Vybe Networks Inc. 98.158.139.74 SUCCESS: 2018-06-01 08:30:56.959 - Detected CED modem tone *********** Universal Media Gateway MGW02-EDTMTDS 2018-06-01 08:30:57.388 - Detected CEDPR modem tone Universal Media Gateway MGW02-EDTMTDS 2018-06-01 08:31:03.187 - Detected V.21 flag fax tone ********* U...

...bstitutions which is what makes this so baffling. Every extension is built exactly the same way. Here are two voicemail entries, the failing one and mine that works. The only sanitation I did was for the password. stocktrans2 => 9999,Angelica Douglas,stocktrans2 at Vex.Net darcy => 9999,Vybe Networks - D'Arcy,darcy at Vex.Net Here is the full dialplan for stocktrans2. exten => stocktrans2,1,Verbose(0,Entering extension stocktrans2) same => n,Goto(DialCell) same => n,GotoIf($["x" = "x"]?DialAlt) same => n(DialAll),Verbose(0,${CALLERI...

...trying to deal with the situation where someone calls themselves from another phone (internal or external) to pick up their messages. In every other case it asks for their password (which is always numeric) and goes into the VM. This one extension asks for a mailbox. -- D'Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/ IM:darcy at Vex.Net VoIP: sip:darcy at VybeNetworks.com

...system. Search > for the user with problems. VoiceMail stocktrans2 Angelica Douglas 12 Definitely there. In fact, I generate all the configs from a database with a script so I would be very surprised if one user was different from another. -- D'Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/ IM:darcy at Vex.Net VoIP: sip:darcy at VybeNetworks.com

...me process to move it back if it is still there after an hour or so in case something went wrong. The same sort of thing would be needed for John's solution as well. It sure would be nice if I could query Asterisk to see if the fax process was still running. Thanks. -- D'Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/ IM:darcy at Vex.Net VoIP: sip:darcy at VybeNetworks.com

>>>>> 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 -- Jame...

...which point of > that process it's failing. But I'm no good at coding in that > language, so will have to defer to others to help. I guess that's my next stop. Luckily I have kept my C skills somewhat active as the chief maintainer for PyGreSQL. :-) -- D'Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/ IM:darcy at Vex.Net VoIP: sip:darcy at VybeNetworks.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 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 not sure if...

...clear that the IP address is not being faked somehow. I also tried doing "pfctl -k 45.143.220.235" but that says that no connections were dropped. It looks like pf is convinced that the connection is gone. So, can anyone suggest why the attack keeps happening? -- D'Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation - Propelling Business Forward http://www.VybeNetworks.com/ IM:darcy at VybeNetworks.com VoIP: sip:darcy at VybeNetworks.com

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-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

>>>>> "DC" == D'Arcy Cain <darcy at VybeNetworks.com> writes: DC> Perhaps someone can explain what t38timeout is supposed to do A 'git grep t38timeout' on the src leads one to res/res_fax.c, where one case see that it is the number of miliseconds to permit for t38 negotiation to complete once it starts. Ie after both side...

...understanding pf? I thought that that would block TCP, UDP, ICMP and anything else trying to get through. Since I started looking at this closer I did find that only some connections have this problem. Most get blocked as soon as the IP is passed to the AUTOBLOCK table. -- D'Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation - Propelling Business Forward http://www.VybeNetworks.com/ IM:darcy at VybeNetworks.com VoIP: sip:darcy at VybeNetworks.com

...e office makes a mistake I don't want them blocked. Same for other friends. I haven't seen the issue today. One thing that I did was to move the anti spoof line further up. I thought that anti-spoof would block wherever it was. Could the location be important? -- D'Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation - Propelling Business Forward http://www.VybeNetworks.com/ IM:darcy at VybeNetworks.com VoIP: sip:darcy at VybeNetworks.com

On 2020-04-01 15:12, Greg Troxel wrote: > D'Arcy Cain <darcy at VybeNetworks.com> writes: > But yet, new packets from that IP address reach asterisk. It seems > almost entirely clear to me that you have a firewall problem, not an > asterisk problem. This could well be but Asterisk is the only thing that continues to communicate. > I would test thi...