On Thursday, January 30, 2020 2:01:28 AM CET Nataraj wrote: > On 1/29/20 3:26 PM, hw wrote: > > On Wednesday, January 29, 2020 6:52:50 PM CET Nataraj wrote: > > [...] > > > >> By burst, I mean that you don't have a bandwidth commitment with an SLA > >> from your provider. A bandwidth commitment means that you are paying a > >> provider to guarantee you so many MB or GB of bandwidth and this is > >> guaranteed to you. This means it is allocated to you in their network > >> allotments and you can use it at any time. > > > > Isn't that called more like "guarantied bandwith" than "burst"? > > burstable bandwidth is the opposite of guaranteed bandwidth. How does creating a burst help when you don't have enough bandwidth to begin with? You can burst all you want and the packets will be dropped when there is not enough bandwidth to transmit them. In theory, you could fill packet buffers along the line. In practise, chances are that the buffers are already full because you don't have enough bandwidth --- and even if they aren't, creating a burst is not exactly useful because people on phones aren't going to talk extremely fast every time when a burst could be transmitted and then talk extremely slowly until the burst was transmitted and then fast again, and so on. People also do not want their conversations interrupted by having to wait for packet buffers to eventually become empty, and VOIP related packets are usually not the only ones underway. > > [...] > > > >>>> Well it sounds like you know where your problem is then. If your > >>>> current provider can't solve the problems to your satisfaction then you > >>>> probably need to find a different provider. > >>> > >>> Well, I don't know, I can only be like 99% sure that the problem is with > >>> the VOIP provider. Changing the VOIP provider would be very difficult > >>> because there aren't many left to begin with, and even fewer allow > >>> encrypted connections. And try to find one that has a useful support > >>> ... > >>> I might end up with not having a phone anymore, and that would make > >>> things extremely difficult. > >> > >> I can't really speak for the situation in your country. One more thing > >> comes to mind. I don't remember if anyone has mentioned that the 1 way > >> voice problem can be caused by an issue with the stateful packet filter > >> in your firewall. I.E. your firewall has become confused and thinks > >> the UDP connection (we'll not really a connection) is no longer active, > >> so it blocks the packets, creating the one way voice scenario. Most > >> phone switch software and VOIP phones have things that can be configured > >> to send extra packets to fool the stateful packet filter into allowing > >> necessary packets to flow. I've never set this up in asterisk, but I > >> suggest you look into it. > > > > How does a firewall allow the desireable SRTP packets to traverse it in > > the > > first place? > > My firewall is CentOS running iptables, so you would use something like > > iptables -A INPUT -p udp -m state [OTHER MATCH OPTIONS] --state > ESTABLISHED -j ACCEPT > > You would similarly code an OUTPUT rule. You obviously need to permit > whatever packets/ports your voice thisapplications requires i.e. SIPS > srtp etc. Well, yes, I used firewall-cmd when I needed to open ports on the server for SRTP/RTP so that local phones will work --- which is a bad solution and makes me wonder if there isn't a better one. But there are no ports open in the firewall on the router and it just works, even through NAT. I've always been wondering how that works. > I generally limit my voip packets to the IP addresses of any > pops that I connect to. You mean in a firewall? What if the address changes? > There are hackers out there that will connect > to your phone switch if you allow voip packets from any source. > > Most commercial firewalls have options to enable VOIP services. Well, I don't want to open any ports to the outside for VOIP just like that. If I ever need to do that, I might have to look at OpenSIPS maybe ... > > How would the packets being blocked explain asterisk showing replay errors > > and authentication failures? Packets that aren't there can hardly cause > > such errors. > > I don't know. Maybe the 1 way voice problem is different than the replay > errors. I'm just throwing out ideas, you'll have to determine if they > apply to your situation or not. Yes, it is entirely different.