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.
>
> [...]
>>>> 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. I generally limit my voip packets to the IP addresses of any
pops that I connect to. 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.
>
> 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.
>
> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
