asterisk users - Jun 2020 - Voice broken during calls (again...)

Am 23.06.2020 um 21:08 schrieb Michael Maier:
> On 23.06.20 at 08:05 Luca Bertoncello wrote:
>> Am 23.06.2020 07:27, schrieb Luca Bertoncello:
>>
>> I again
>>
>>>> Do not change MTU. Probably there will be another problem. I
expect
>>>> packet size 1466 would pass and higher will have the same
result. It
> 
> RTP-VoIP-packets never reach this size. Size is about 214 bytes.
OK, so it must be something other...

But I really don't have any idea what... :(

Thanks
Luca

On 23.06.20 at 21:10 Luca Bertoncello wrote:
> Am 23.06.2020 um 21:08 schrieb Michael Maier:
>> On 23.06.20 at 08:05 Luca Bertoncello wrote:
>>> Am 23.06.2020 07:27, schrieb Luca Bertoncello:
>>>
>>> I again
>>>
>>>>> Do not change MTU. Probably there will be another problem.
I expect
>>>>> packet size 1466 would pass and higher will have the same
result. It
>>
>> RTP-VoIP-packets never reach this size. Size is about 214 bytes.
> 
> OK, so it must be something other...
> 
> But I really don't have any idea what... :(
Your basic architecture looks good to me - now you have to start the analysis of
the problem with pcapsipdump and wireshark as I wrote before to get an idea what
actually happens at
all. You most probably won't come any further without doing any analyzing.
You have to learn it. It will take some, or even more, time. You can't do it
in just few hours or maybe
even days or weeks. It is work or even hard work to learn and to do it.

That's my problem: It's impossible for me to assist because I can't
see any effort on your side to learn. I won't fix your problem. You have to
fix it yourself. All I can do, is, to
show you a way to *find* your problem (I can't know your problem) and may be
to give some hints how to fix it (once you've found it). Finding /
localizing problems and fixing them
are two completely different things. But before you fix a problem, you have to
know the problem. Therefore: go and find your problem by starting the analysis.
That's the first thing
to do.


Regards
Michael

Am 24.06.2020 05:05, schrieb Michael Maier:

Hi
> Your basic architecture looks good to me - now you have to start the
Nice to hear it...
> analysis of the problem with pcapsipdump and wireshark as I wrote
> before to get an idea what actually happens at
> all. You most probably won't come any further without doing any
> analyzing. You have to learn it. It will take some, or even more,
> time. You can't do it in just few hours or maybe
> even days or weeks. It is work or even hard work to learn and to do it.
Well, that's the very problem...
I don't know *how* to analyze it... Or, better, how to read the data...
I know, I can use tcpdump, sngrep and many other tools, but I don't know 
what I have to expect and how to decide, that a paket is wrong...
Can someone help me to learn it?
> That's my problem: It's impossible for me to assist because I
can't
> see any effort on your side to learn. I won't fix your problem. You
> have to fix it yourself. All I can do, is, to
> show you a way to *find* your problem (I can't know your problem) and
> may be to give some hints how to fix it (once you've found it).
> Finding / localizing problems and fixing them
> are two completely different things. But before you fix a problem, you
> have to know the problem. Therefore: go and find your problem by
> starting the analysis. That's the first thing
> to do.
Of course, the first thing to do is to locate the problem...

I think, the problem can *not* be:

1) by Deutsche Telekom (since I have the problem even on local tests)
2) on the devices (since I tested many devices)

so the problem can be:

1) in the Firewall configuration
2) in the Asterisk configuration
3) in the BananaPI

I think I can exclude my switch, since I checked right now and no port 
has errors...

Now the question: can someone help me to understand/learn how to check 
the involved parts and search for the problem?

Thanks
Luca Bertoncello
(lucabert at lucabert.de)