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
errors.
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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
