search for: sngrep

On Wed, 31 May 2017, Barry Flanagan wrote: > sngrep? Isn't sngrep a great tool? Since discovering it my use of tcpdump/wireshark has cratered. Being able to compare an INVITE that worked with one that didn't (with color highlighting) rocks. -- Thanks in advance, -------------------------------------------------------------------------...

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: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200401/d5366a6b/attachment.html>

...hangup, but the asterisk one. BYE is sent, received and confirmed. I don't know how I could investigate the reason for this BYE. Em 21/09/2020 17:12, Dovid Bender escreveu: > Is there anything in the Asterisk logs? Which side sends the BYE? Were > you able to capture the traffic with sngrep/wireshark to see if any > side stopped sending/getting RTP? What did the other side see? > > > On Mon, Sep 21, 2020 at 3:22 PM Roberto > <roberto.medola at gasparimsantos.com.br > <mailto:roberto.medola at gasparimsantos.com.br>> wrote: > > Hello >...

ok, solved the firewall issue. A first test call worked fine. Another one now still gets disconnected after 32s. But in FW there are no blocked packets anymore?! And I don't understand why the registration to the same IP and same Port is working, but not later transmission of further SIP packets? that doesn't sound logical to me. What do you think? regards, andre

I want to capture all SIP messages. I have about 30 hosts in about 6 colos. My first thought was dumpcap, but the output file name format bugs me. What do you use for long term SIP capture? -- Thanks in advance, ------------------------------------------------------------------------- Steve Edwards sedwards at sedwards.com Voice: +1-760-468-3867 PST

Roberto Check your router if ALG or similar feature is enabled. Disable and test. Also, on SNGREP check if both parties are getting ACK correctly after RTP starts. *--* *Atenciosamente,* *Luciano Moreira**(85)99974-2750* *__Logic Telecom* *0800-085-7799 | (85)4042-7799 | **(11)4210-7799* Em ter., 22 de set. de 2020 às 13:35, Roberto < roberto.medola at gasparimsantos.com.br> escrev...

...ake some, or even more, > time. You can't do it in just few hours or maybe > even days or weeks. It is work or even hard work to learn and to do it. Well, that's the very problem... I don't know *how* to analyze it... Or, better, how to read the data... I know, I can use tcpdump, sngrep and many other tools, but I don't know what I have to expect and how to decide, that a paket is wrong... Can someone help me to learn it? > That's my problem: It's impossible for me to assist because I can't > see any effort on your side to learn. I won't fix your proble...

Is there a way to configure the old SIP channel to stay in sip set debug all the time, without human intervention and also at boot time, by default? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20181205/d0ee9297/attachment.html>

Hello I have an asterisk 16.2.1 on an ubuntu on AWS, which is experiencing a drop in call. It does not have a certain time, it is random. The audio is flowing normally and the call is dropped. Has anyone ever experienced this? My settings changed below: allowoverlap = no udpbindaddr = 0.0.0.0 tcpenable = no tcpbindaddr = 0.0.0.0 transport = udp, ws, wss srvlookup = yes directmedia = no

...ables -A INPUT -p icmp --icmp-type 8 -m state --state NEW -j ACCEPT # Log then drop any packets that are not allowed. You will probably want to turn off the logging # /sbin/iptables -A INPUT -j LOG /sbin/iptables -A INPUT -j REJECT -------------------------------------------------- Then one day, sngrep was running in the background, and I noticed lots of these... OPTIONS sip:50901 at 46.101.X.X SIP/2.0 163.172.210.65:5089 46.101.X.X:5060 ?Via: SIP/2.0/UDP 127.0.1.1:5089;branch=z9hG4bK-786048925;rport ???????????????????? ?????????????????????Content-Leng...

...o that? I may get on> of those callers to work with us on testing. I would start with something like: # tshark -i any -f "port 5060" -w "sip.debug.pcap" and then afterwards look at the pcap file with tshark (tshark -r "sip.debug.pcap -V") or some SIP tool such as sngrep. Antony. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20190228/50224160/attachment.html>

On 2/04/2020 5:28 AM, 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 :-) > > Mark Or the stateful entry still exists when the table entry is updated. Does your script also issue a command to kill existing states from that host after it has updated the table, e.g.  pfctl -k 45.143.220.235 Larry. -------...

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 from <AUTOBLOCK> to any block drop out log quick on bge0 from any to <AUTOBLOCK> Am I misunderstanding pf? I thought that that would block TCP, UDP, ICMP and anything else trying to get through...

Is there anything in the Asterisk logs? Which side sends the BYE? Were you able to capture the traffic with sngrep/wireshark to see if any side stopped sending/getting RTP? What did the other side see? On Mon, Sep 21, 2020 at 3:22 PM Roberto < roberto.medola at gasparimsantos.com.br> wrote: > Hello > I have an asterisk 16.2.1 on an ubuntu on AWS, which is experiencing a > drop in call. It does...

Hello, This is not technical post, just looking for suggestions on what to check.I have asterisk for long time, no updates, just maintain OS updates. I use SPA504G phones Very rarely and randomly when we pickup a phone - other side does not hear us. Call them back and all works. Now I have couple people I'm talking to and it seems like very call like this. Someone can't hear someone.

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 this out with a remote

Another nice sip packet is sngrep Shows realtime the sip flows But i think you have to chk the asterisk answer in the dialplan logic to chk what context its hitting etc. ?????? 6 ????? 2016 10:05 PM,? "Steve Edwards" <asterisk.org at sedwards.com> ???: > On Wed, 6 Jul 2016, Victor Villarreal wrote: > > If...

Am 23.06.2020 um 21:08 schrieb Michael Maier: > On 23.06.20 at 08:05 Luca Bertoncello wrote: >> Am 23.06.2020 07:27, schrieb Luca Bertoncello: >> >> I again >> >>>> Do not change MTU. Probably there will be another problem. I expect >>>> packet size 1466 would pass and higher will have the same result. It > > RTP-VoIP-packets never reach

Hi Thufir, The analysis of a SIP Debug depends on what the problem to be solved. If you experience problems with inbound calls from a SIP trunk or provider, you can type in Asterisk cli 'core set debug 3' and then 'sip set debug ip xxx.xxx.xxx.xxx' where xxx is the IP of your SIP provider or from where it is supposed to come call. Then you make a test call, and look in full log

I have a SIP trunk - calls going out work fine. Trying to setup an incoming call with a DNIS When I dial the number - I see nothing on the CLI. The person says the server is returning 401 How do I debug that. Using asterisk 18.8.0 Thanks Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: