On 1/29/20 4:48 AM, hw wrote:
> On Wednesday, January 29, 2020 10:10:48 AM CET Nataraj wrote:
>> On 1/28/20 12:39 PM, hw wrote:
>>> On Tuesday, January 28, 2020 9:00:22 AM CET Nataraj wrote:
>>>> On 1/26/20 5:44 PM, hw wrote:
>>>>> On Sunday, January 26, 2020 11:18:36 PM CET Pete Biggs wrote:
>>>>>> First of all - disclaimer - I'm no network specialist, I just read and
>>>>>> am interested in it. I may get things wrong!!
>>>>>>
>>>>>>> Both physical interfaces show the same. But does this mean it's on as
>>>>>>> in
>>>>>>> "rx- checksumming: on" or off as in "tx-checksum-ipv4: off [fixed]"?
>>>>>> As far as I understand it rx-checksum is the underlying wire
>>>>>> checksumming - and from what I've read about it, disabling that
>>>>>> disables the UDP checksums.
>>>>> You mean layer 1 checksumming? Is there such a thing with ethernet? I
>>>>> think I read something about encoding, when I was trying to understand
>>>>> what "bandwidth" actually means, being involved in signal transmissions;
>>>>> and I seem to remember that there was no checksumming involved and it
>>>>> had
>>>>> to do with identifying signals as a requirement for the very possibility
>>>>> to transmit something before anything could be transmitted at all.
>>>>>
>>>>>>> Assuming that I do not receive packets with invalid UPD checksums,
>>>>>>> then
>>>>>>> the
>>>>>>> packages must be somehow altered and their UPD checksums recalculated
>>>>>>> to
>>>>>>> arrive here. Does bad hardware etc. do that? Why would the UDP
>>>>>>> checksums
>>>>>>> just happen to get recalculated correctly but like randomly without
>>>>>>> intent?
>>>>>> I'm not sure I understand what you are asking.
>>>>> It is about VOIP calls via SRTP being interrupted at irregular
>>>>> intervals.
>>>>> The intervals appear to depend on the time of day: Such phone calls can
>>>>> last for a duration of about 5--25 minutes during the day to up to 1.5
>>>>> hours at around 3am before being interrupted.
>>>> My sense is you may be starting at too low of a level in trying to debug
>>>> this.
>>> One of the reasons I have to look into it is that it is usually good to
>>> know more/better.
>>>
>>>> I have seen the same kind of problems with my voip service when
>>>> there is a problem with my Internet connection. When this happens I
>>>> also see high retransmission rates for tcp connections and other signs
>>>> of network problem.
>>> How do you monitor such retransmissions to be able to see if and when they
>>> occur?
>> netstat -s | grep -i retrans
> Cool, that gives a lot of information. Retransmissions are at ~0.012/~0.029
> percent on the server/workstation, and the UPD statistics look good.
>
>>>> If I check the modem for my Internet connection
>>>> there are issues with the signal levels and high error rates reported by
>>>> the modem. If you believe your Internet connection is reliable, then if
>>>> you run managed switches, check your switch logs for any reported errors.
>>>>
>>>> You could try tools like iperf to check for problems on your internal
>>>> network. You could run some of the basic tools for testing voip
>>>> performance of your Inetnet connection and if necessary run iperf to a
>>>> cloud hosted system.
>>> Can you suggest useful tools to analyze VOIP performance, and how do you
>>> define VOIP performance?
>> Well there used to be a number of speedtest like sites that use to
>> report more accurately , latency, jitter and packet loss. It seems most
>> of them have now scaled down their output, but you could use ping. mean
>> deviation is basically jitter.
>>
>> I think a few of the tests listed on this site, still work.
>>
>> https://getvoip.com/blog/2014/05/12/20-best-voip-speed-test-tools/
> Most seem to be test for bandwidth, and none of the VOIP related sites work.
> Besides, ping times to the US are usually around 200ms, so if there were any
> results to be abtained, they might be questionable.
>
>> There used to be sites that did a calculation for something called MOS
>> score, which is a measure of expected voice quality based on the
>> performance of a connection. Don't know if anyone does that anymore.
>> In the VOIP industry there is fancy/expensive equipment for measuring
>> end to end performance, but in practice simple ping output with regular
>> sampling from something like a cron job can tell you alot.
> VOIP performance comes down to what you might call the human experience.
> Tools only trying to measure how well data is being transferred aren't going
> to measure that. The human experience is also subjective and not easy to
> measure.
>
> For example, the network can be perfectly fine, and yet the VOIP performance
> is total shit when you use a cell phone because their audio output sucks no
> matter what. What can you expect from a tiny speaker built into a cell phone?
>
>> Basically, what you want is that if your phone system relies on your
>> Internet connection, the pop that your connecting too needs to be
>> relatively close and have minimal packet loss and similar latency/jitter
>> characteristics on both the up/down stream. Generally that is not too
>> hard to find these days, but if the Internet connectivity to your voip
>> pop takes a route half way across the country over the Internet, that's
>> not it.
> In this country, you can be glad if you can get an internet connection at all,
> no matter how bad it is. Even some businesses can't get a connection at all,
> except maybe mobile connections which are so expensive and with only minimal
> volumes data to transfer that they are useless.
>
>> I have one of the lowest cost voip providers, voip.ms, and I find the
>> voip quality to be excellent and call drop rate to be low except when I
>> have problems with my Internet provider.
> In this country, you can be glad if you can find a VOIP provider at all.
>
>>> The performance is kinda acceptable as long as the calls are not
>>> interrupted. It's still worlds apart from what it used to be 25 years
>>> ago, before VOIP was used. Back then, you never had to worry that calls
>>> could be interrupted or that you couldn't hear someone or that you
>>> couldn't have a conversation because the latency makes it impossible.
>>> You could just talk to someone on a phone, like it should be. Nowadays,
>>> we get to pay 10 times as much and more, plus all the expensive hardware,
>>> and it still doesn't work right and doesn't even come close.
>> Well if your relying on the Internet, you are essentially relying on the
>> availability of burst bandwidth.
> In this country, there is no other way to do phone calls anymore than over the
> internet. Why burst? The VOIP audio streams are continuous.
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.
>
>> If you application needs higher
>> reliability then I would be looking at purchasing some kind of commited
>> bandwidth to a voip provider. I don't follow the voip industry much
>> lately, but I'm guessing that people still provision dedicated bandwidth
>> into a voip provider with a nationwide backbone.
> See above, you can be glad if you can get an internet connection at all.
>
>>>> I think it is highly unlikely that you are only having issues with srtp
>>>> packets and I would look at the broader picture first to try to isolate
>>>> some other problem in your network or Internet connection.
>>> See it this way: It is highly likely that I don't have any issues with
>>> SRTP at all. Calls over the LAN work fine. The only issue is with the
>>> VOIP provider. What I have learned about SRTP so far tells me that, like
>>> everything else does.
>>>
>>> How would you explain that the same problem occurs at two entirely
>>> unrelated physical locations each having their own asterisk
>>> installations, using entirely different hardware and entirely different
>>> internet connections from entirely different ISPs, with the only thing in
>>> common being the VOIP provider?
>>>
>>> If it was only my internet connection which is affected, I'd be talking to
>>> my ISP (probably useless) instead of the VOIP provider (who will probably
>>> do something about it).
>> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
