[CentOS] Centos 7: UPD packet checksum verification?

Wed Jan 29 23:26:12 UTC 2020
hw <hw at gc-24.de>

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

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

How would the packets being blocked explain asterisk showing replay errors and 
authentication failures?  Packets that aren't there can hardly cause such 

BTW, the VOIP provider is fixing or has fixed the problem now.  It turned out 
that they need or needed to update the firmware of some network adapters 
because the old firmware has been causing issues.  A test call showed no 
errors on both sides for over 45 minutes.