39 thoughts on - Voice Broken During Calls (again…)

• I don’t know if there was a prior email with more details, but….

  Latency is as important as speed. Have you checked latency between your device and pop? What about QoS at your location, and does your ITSP support/respect QoS?

  Could problem be inside your network? Have you tested/optimized internal?

  —–Original Message—–
  From: asterisk-users [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Luca Bertoncello Sent: Monday, June 22, 2020 10:49 AM
  To: Asterisk Users
  Subject: [asterisk-users] Voice broken during calls (again…)

  Hi list!

  So, now I have a business contract and a technician was here to check the DSL… Nothing found, except that for 50Mbps I need now vectoring. Really nice… A couple of years ago I could get 50Mbps without vectoring. Of course, Deutsche Telekom said nothing about this change…

  Well, I got it working, and now I have 48Mbps down and 10Mbps up. I _REALLY CAN’T_ believe, that this is not enough…

  The problem with many little disruptions during calls is always here.

  I tried changing the codecs and changing some settings in the SIP configuration of the peers. No changes…

  On the Gateway (Banana PI), where the Asterisk server also runs, the load is about 0.50 during calls and it has a Gbps LAN. I can’t believe, the problem is here…

  @all german users using Telekom: how did you configured your Asterisk?
  @all: thank you for all your suggestion, I really don’t know anymore what I can do…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 22.06.2020 um 17:01 schrieb Telium Technical Support:

  That’s a very good idea… Could you suggest me how can I check it?
  The Gateway is a Linux with Debian 9.

  Really difficult to believe… If I call another VoIP-phone in my network (using the “internal number”) the quality is excellent.

  If I call my wife using the “external number”, the quality is very bad…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Hello,

  try pinging your sip peer ip address following way:

  ping -n -M do -s 1300 -i 0.1 -c 100 ${ipaddress}

  Post several lines and the statistics.

  Were you also thinking about MTU problems? Not very probable, but one never knows.

  Marek

  2020-06-22 17:18 GMT+02:00, Luca Bertoncello :

  —

• You could also use the ‘mtr’ command under Linux.

  Michael

  http://www.mksolutions.info

  —

• Still lots of detail missing, but….likely causes include:
  1. Egress latency (does your router/firewall support QoS, are you leaving headroom )
  2. Ingress latency – does your ITSP support it
  3. Router/firewall latency – can it keep up with the traffic and packet size. Do you have way too many iptables rules in your Debian box?

  Between ping and traceroute you can probably get some basic stats. Some speed test websites even report latency, other sites will should tracert/ping from outside in to you.

  How about putting a phone on the DSL/cable modem directly and calling out…same problem?

  —–Original Message—–
  From: asterisk-users [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Luca Bertoncello Sent: Monday, June 22, 2020 11:19 AM
  To: Asterisk Users Mailing List – Non-Commercial Discussion
  Subject: Re: [asterisk-users] Voice broken during calls (again…)

  Am 22.06.2020 um 17:01 schrieb Telium Technical Support:

  That’s a very good idea… Could you suggest me how can I check it?
  The Gateway is a Linux with Debian 9.

  Really difficult to believe… If I call another VoIP-phone in my network (using the “internal number”) the quality is excellent.

  If I call my wife using the “external number”, the quality is very bad…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 22.06.2020 um 17:41 schrieb Marek Greško:

  Hi

  root@bpi:/etc/asterisk# ping -n -M do -s 1300 -i 0.1 -c 100 tel.t-online.de PING tel.t-online.de (217.0.128.133) 1300(1328) bytes of data.
  1308 bytes from 217.0.128.133: icmp_seq=1 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=2 ttl=57 time=17.9 ms
  1308 bytes from 217.0.128.133: icmp_seq=3 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=4 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=5 ttl=57 time=18.1 ms
  1308 bytes from 217.0.128.133: icmp_seq=6 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=7 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=8 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=9 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=10 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=11 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=12 ttl=57 time=17.7 ms
  1308 bytes from 217.0.128.133: icmp_seq=13 ttl=57 time=17.8 ms
  1308 bytes from 217.0.128.133: icmp_seq=14 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=15 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=16 ttl=57 time=17.9 ms
  1308 bytes from 217.0.128.133: icmp_seq=17 ttl=57 time=18.2 ms
  1308 bytes from 217.0.128.133: icmp_seq=18 ttl=57 time=17.9 ms
  1308 bytes from 217.0.128.133: icmp_seq=19 ttl=57 time=18.4 ms
  1308 bytes from 217.0.128.133: icmp_seq=20 ttl=57 time=17.9 ms
  1308 bytes from 217.0.128.133: icmp_seq=21 ttl=57 time=18.2 ms
  1308 bytes from 217.0.128.133: icmp_seq=22 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=23 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=24 ttl=57 time=17.8 ms
  1308 bytes from 217.0.128.133: icmp_seq=25 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=26 ttl=57 time=18.1 ms
  1308 bytes from 217.0.128.133: icmp_seq=27 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=28 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=29 ttl=57 time=18.1 ms
  1308 bytes from 217.0.128.133: icmp_seq=30 ttl=57 time=17.9 ms
  1308 bytes from 217.0.128.133: icmp_seq=31 ttl=57 time=18.3 ms
  1308 bytes from 217.0.128.133: icmp_seq=32 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=33 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=34 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=35 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=36 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=37 ttl=57 time=18.1 ms
  1308 bytes from 217.0.128.133: icmp_seq=38 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=39 ttl=57 time=18.0 ms
  1308 bytes from 217.0.128.133: icmp_seq=40 ttl=57 time=17.9 ms
  1308 bytes from 217.0.128.133: icmp_seq=41 ttl=57 time=17.9 ms
  1308 bytes from 217.0.128.133: icmp_seq=42 ttl=57 time=18.1 ms
  1308 bytes from 217.0.128.133: icmp_seq=43 ttl=57 time=18.1 ms
  1308 bytes from 217.0.128.133: icmp_seq=44 ttl=57 time=18.1 ms
  1308 bytes from 217.0.128.133: icmp_seq=45 ttl=57 time=17.9 ms
  1308 bytes from 217.0.128.133: icmp_seq=46 ttl=57 time=18.1 ms
  ^C
  — tel.t-online.de ping statistics —
  46 packets transmitted, 46 received, 0% packet loss, time 4527ms rtt min/avg/max/mdev = 17.784/18.058/18.454/0.190 ms, pipe 2

  But now I made a test with a friend of mine, and I think the results are very interesting…

  So, we configured his mobile phone (Android) to use my Asterisk as peer. We created also a VoIP account on the phone. The phone was *NOT* in my WLAN.

  The friend called my phone (Thomson ST2022 in local LAN). This was a VoIP call inside Asterisk (two peers speaking together). Deutsche Telekom was *NOT* used now!
  I can hear very good the friend, without “broken voice”, but *he* just hear “like a robot with sore throat” and can’t understand any word… The same if I call ihm from my phone (via VoIP).

  I tried to call my wife’s phone from my phone (both in the LAN, both Thomson ST2022). Excellent quality in both direction.

  Last test: I configured my Android phone and added a VoIP-account on my Asterisk, so now I have my Android as peer in my Asterisk. Then I called my friend’s phone (also logged in my Asterisk). First test was with my mobile phone in my WLAN and his phone via LTE. Terrible quality on his side (he hear me very bad), good quality on my side (I hear ihm good). Second test with *both my phone and my friend’s phone* via LTE:
  excellent quality in both directions.

  Conclusion (maybe!): it can *not* be a problem in the DSL connection and
  *maybe* it is not a problem in the communication with the Server of Deutsche Telekom, since I have many problems to communicate between two peers in local Asterisk if one is over LTE and the other in local LAN
  (but curiously *not* if both peers are in local LAN or both via LTE).

  Ergo: this *must* be a problem in my Asterisk…

  So the questions:

  1) can someone confirm or contradict my conclusions?
  2) assuming are my conclusions correct, can someone suggest me where can I search the problem?

  Thanks a lot Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 22.06.20 um 16:48 schrieb Luca Bertoncello:

  This is enough if you’re doing it correctly. But that’s your job to do it correctly – not Telekom’s one.

  Not surprising. That’s most probably not a problem of the provider. VoIP of Deutsche Telekom mostly is pretty perfect regarding voice quality and availability.

  Not surprising.

  Did you check to prevent transcoding?

  What’s running on this device on parallel? What about other network traffic – not necessarily to the internet interface?

  That’s irrelevant. You have to ensure, that the driver doesn’t have any problems. Reducing the queue sizes of the interface may help.

  – At first, you have to trace down the problem and analyze those traces when the problem occurred. This could be done with pcapsipdump[1] on both sides (internal and external). Example:

  pcapsipdump -i ppp0 -p -d /tmp/pcapsipdump &

  will trace the connection to Telekom. You have to add another process to another device to trace the internal call. Use Wireshark to analyze the dumps. Wireshark understands VoIP. (I assume you are using SIP / RTP on all legs.) Now you can see on which side the problem happens and how it looks like.
  – Are you using NAT or is asterisk running on the device which runs the ppp-interface?
  – What’s the modem you are using? What about the wiring between APL and modem? Is it done correctly? [2]
  – Did you configure prioritization for the up-stream regarding RTP and SIP? This is done with the tc tool.
  – Did you correctly configure tos? For Deutsche Telekom you may use tos=0xb8 (pjsip). You have to verify it with Wireshark with your traces. You have to set it to the same value as the packages which are received from their server.
  – You have to use the DNS of Deutsche Telekom which they provide during the ppp-login because they usually provide optimal sip servers for you (regarding distance). You’re RTT of ping (18 ms) is pretty bad. I’m having here 5 ms to the primary server (Telekom provides 3). See

  dig +noall +answer _sip._udp.tel.t-online.de SRV

  e.g. (don’t know the hostname for the business infrastructure)

  Regards, Michael

  [1] https://sourceforge.net/projects/pcapsipdump/
  [2] https://telekomhilft.telekom.de/t5/Telefonie-Internet/Das-richtige-Kabel-zwischen-APL-und-TAE-Dose/ta-p/3499089

  —

• Am 22.06.2020 um 21:30 schrieb Michael Maier:

  could you explain what do you mean and how to check it?

  On the BananaPI? Nothing other PPP, Bind, NTP, Firewall (iptables) and Asterisk.

  I don’t understand what you mean…

  Asterisk runs on PPP interface

  Zyxel VMG1312B30A. It works correctly and using the Internet (upload and download) is not a problem

  Yes

  I use SIP, not PJSIP… Do I have to do that, too? Which value?

  I have a forwarding to the DNS servers of Telekom configured in my bind, since the Gateway has to manage the internal domains, too…

  Regarding the ping time: wich line do you have? I have a DSL 50Mbps. Maybe your times are better due to a faster line?

  What is your opinion about the tests I did today with the friend and his phone as VoIP-peer?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• A thing I forgot to report… My Asterisk listen on an high port (*not* 5060), since I had many problems in the past with someone trying to use my Asterisk with brute force attack…

  I really don’t think, this can be the problem, but better to report all…

  Regards Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Would you mind repeating the test with canreinvite=no set for all you phones and mobile phones?

  What is your upload bitrate? Is it guaranteed?

  I would try also to test the PMTU:

  Try:

  ping -M do -s 2000 ${ip address of the sip server}

  You should receive icmp asking for lowering the packet size.

  The LTE phones could have lower MTU and thus overcome PMTU problem.

  Marek

  2020-06-22 21:48 GMT+02:00, Luca Bertoncello :

  —

• Am 22.06.2020 um 22:12 schrieb Marek Greško:

  Hi Marek

  All my peers have already canreinvite=no… I only have canreinvite=yes on the SIP configuration on the Telekom part:

  [pbxluca]
  type=peer defaultuser=111111111@t-online.de secret= xxxxxxxxxx dtmfmode=rfc2833
  host=tel.t-online.de context=luca_incoming outboundproxy=tel.t-online.de port=5060
  fromuser=03511111111
  fromdomain=tel.t-online.de usereqphone=yes canreinvite=yes insecure=port,invite nat=no qualify=yes qualifyfreq=600
  disallow=all allow=alaw allow=ulaw

  Should I change canreinvite=no there?

  Currently 12Mbps. Guaranteed should be about 10Mbps…

  root@bpi:/etc/asterisk# ping -M do -s 2000 tel.t-online.de PING tel.t-online.de (217.0.128.133) 2000(2028) bytes of data. ping: local error: Message too long, mtu=1492
  ping: local error: Message too long, mtu=1492
  ping: local error: Message too long, mtu=1492
  ping: local error: Message too long, mtu=1492
  ping: local error: Message too long, mtu=1492
  ping: local error: Message too long, mtu=1492
  ^C
  — tel.t-online.de ping statistics —
  6 packets transmitted, 0 received, +6 errors, 100% packet loss, time 5103ms

  Mmmm… it seems not good, isn’t it?

  For information, here the output of ifconfig:

  dsl0: flags=4305 mtu 1492
  inet 93.241.x.y netmask 255.255.255.255 destination 62.156.z.k
  inet6 fe80::9565:3024:4deb:ebc7 prefixlen 10 scopeid 0x20 ppp txqueuelen 3 (Point-to-Point Protocol)
  RX packets 852397 bytes 480197087 (457.9 MiB)
  RX errors 0 dropped 0 overruns 0 frame 0
  TX packets 967912 bytes 170822532 (162.9 MiB)
  TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

  Should I reduce the MTU?!?
  Maybe I didn’t understood what you mean…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Hello,

  there is no need to change canreinvite for provider configuration.

  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 would be interesting to make the same test from the outside towards your asterisk with size 2 bytes larger the highest you are able to ping.

  Marek

  2020-06-22 22:26 GMT+02:00, Luca Bertoncello :

  —

• Am 22.06.2020 um 22:42 schrieb Marek Greško:

  Hi Marek,

  OK, so I leave it…

  root@bpi:~# ping -M do -s 1466 tel.t-online.de PING tel.t-online.de (217.0.128.133) 1466(1494) bytes of data. ping: local error: Message too long, mtu=1492
  ping: local error: Message too long, mtu=1492

  ping: local error: Message too long, mtu=1492

  ping: local error: Message too long, mtu=1492

  ^C

  — tel.t-online.de ping statistics —

  4 packets transmitted, 0 received, +4 errors, 100% packet loss, time
  3077ms

  Do I have a problem?

  I don’t understand what you mean, could you explain?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 23.06.2020 07:27, schrieb Luca Bertoncello:

  I again

  I checked it, and I see, that the maximum I can use is a paket size of
  1464 with all hosts via IPv4. Via IPv6 I can use higher MTU, but I really can’t explain why…

  Can someone explain me what does it mean, if this is a problem for VoIP
  and how I can solve it?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 22.06.2020 20:09, schrieb Luca Bertoncello:

  A couple of other ideas…

  I think, the problem with bad quality and broken voice just happens if the peers are in different LANs, since if I call my wife’s phone (VLAN
  “phone”) using my mobile phone via SIP (in VLAN “intlan”) the quality is bad, but if I call her using my phone in VLAN “phone” or if both peers use SIP via LTE the quality is very good…

  Could you suggest me something to restrict the problem?
  Currently, I think the problem can be:

  1) on Asterisk
  2) on my Gateway/Firewall

  At home I have many VLANs, that normally *not* communicate together
  (some exceptions are of course implemented). The phones don’t reach the Internet via NAT (VLAN “phone” has no routing in Internet). The mobile phones are in VLAN “intlan”, with routing in Internet.

  Any idea?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 23.06.2020 08:43, schrieb Luca Bertoncello:

  And another thing, I discovered right now…

  A couple of years ago I added this entry in my firewall:

  /sbin/iptables -A FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS
  –clamp-mss-to-pmtu

  since I had the problem downloading data from an Internet site using my tablet. I found this site explaining that:

  https://lartc.org/howto/lartc.cookbook.mtu-mss.html

  I really forgot this entry, but now I checked all entries in my Firewall, and I see it, with my remark… Now, the last line of the HowTo:

  ——————————–
  # iptables -A FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –set-mss
  128

  This sets the MSS of passing SYN packets to 128. Use this if you have VoIP with tiny packets, and huge http packets which are causing chopping in your voice calls.
  ——————————–

  Could it be the problem? Right now I’m not at home, so I cannot test it, but maybe I can add an entry like:

  iptables -A FORWARD -p tcp -m multiport –ports 5060, –tcp-flags SYN,RST SYN -j TCPMSS –set-mss 128

  and change the previous entry like:

  iptables -A FORWARD -p tcp -i intlan0 –tcp-flags SYN,RST SYN -j TCPMSS
  –clamp-mss-to-pmtu

  to limit the behaviour on the internal LAN…

  Your opinion?

  Thanks a lot!
  Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Hello

  Le 23/06/2020 à 09:06, Luca Bertoncello a écrit :
  Audio has nothing to do with SIP signaling 5060 port. Look at your rtp.conf

  —
  Daniel

  —

• Am 23.06.2020 09:19, schrieb Administrator:

  Hi Daniel

  You’re right… I have to restrict to the ports I configured in rtp.conf… So like:

  iptables -A FORWARD -p tcp -m multiport –ports -ports 10000:15100
  –tcp-flags SYN,RST SYN -j TCPMSS –set-mss 128

  ?

  Or I just have to use:

  iptables -A FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –set-mss
  128

  instead of:

  iptables -A FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS
  –clamp-mss-to-pmtu

  ?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Hello,

  if you need clampmss then it is highly probable there is a PMTU
  discovery problem. The clampmss does not work for UDP.

  I probably counted the size incorrectly. So you are able to ping with size 1464 and not with 1466. How about trying same ping sizes from the internet towards your site? I mean trying to ping from sites with higher MTU than yours without lower MTU links in the path.

  You know MTU is a size of l2 frame, so using ipv6 you are able to use higher payload sizes because of ip header size.

  Marek

  2020-06-23 9:06 GMT+02:00, Luca Bertoncello :

  —

• Am 23.06.2020 09:28, schrieb Marek Greško:

  Hi

  Is there a way to check if I have this problem?

  lucabert@ns:~$ ping -4 -M do -s 1465 bpi.d.lucabert.com PING bpi.d.lucabert.com (93.241.91.232) 1465(1493) bytes of data. From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set
  (mtu = 1492)
  ping: local error: Message too long, mtu=1492
  ping: local error: Message too long, mtu=1492
  ping: local error: Message too long, mtu=1492
  ^C
  — bpi.d.lucabert.com ping statistics —
  4 packets transmitted, 0 received, +4 errors, 100% packet loss, time
  3965ms pipe 2

  With paket size of 1464 it works…

  OK, thanks!
  Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Hello,

  this is a correct response:

  From 62.156.246.57 (62.156.246.57) icmp_seq=1 Frag needed and DF set
  (mtu = 1492)

  So PMTU discovery is working. No problem here. You got correct message to lower the packet size from 62.156.246.57. This is probably the last hop before your site.

  Marek

  2020-06-23 9:40 GMT+02:00, Luca Bertoncello :

  —

• Am 23.06.2020 10:07, schrieb Marek Greško:

  Hi

  No, the last hop is 62.156.246.65:

  lucabert@ns:~$ mtr -4nr bpi.d.lucabert.com Start: Tue Jun 23 10:10:16 2020
  HOST: ns.lucabert.de Loss% Snt Last Avg Best Wrst StDev
  1.|– 185.242.112.1 0.0% 10 0.4 1.1 0.3 4.4
  1.2
  2.|– 84.200.230.82 0.0% 10 0.8 0.7 0.5 0.8
  0.0
  3.|– 87.190.233.113 0.0% 10 1.6 1.7 1.4 2.5
  0.0
  4.|– 217.5.82.94 0.0% 10 7.9 7.6 7.4 7.9
  0.0
  5.|– 217.5.82.94 0.0% 10 7.7 7.5 7.2 7.7
  0.0
  6.|– 62.156.246.49 0.0% 10 7.4 7.4 7.3 7.4
  0.0
  7.|– 62.156.246.65 0.0% 10 7.6 7.6 7.4 7.8
  0.0
  8.|– 93.241.91.232 0.0% 10 21.4 21.9 21.4 24.3
  0.7

  Don’t know where this 62.156.246.57 comes… 🙁

  Everyway: you think, my network works as expected? At least the part using DSL?
  Any idea, where could be the problem?

  Thanks a lot Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Hello,

  this could be ip address of the different interface on the same box. I
  think it works like expected. The only exception would be if the sip peer ignores the icmp packet unreachable. But I doubt this is the case. Anyway you get problems also when calling to LTE phone without using sip provider.

  Let first concentrate on these calls LTE to LAN. Are you sure you do not block incoming icmp unreachables? At least verify type 3 subtype 4
  is enabled. If it is, I have no clue what is going on.

  Marek

  Marek

  2020-06-23 10:11 GMT+02:00, Luca Bertoncello :

  —

• Am 23.06.2020 14:49, schrieb Marek Greško:

  Hi Marek,

  Do you mean “my Linux-Box ignores ICMP packet unreachable” or “Deutsche Telekom ignores them”?

  I have problem calling someone outside my networks and I have problem if the peers are in different networks…

  Well, I limit incoming ICMP packets and I block some hosts (known crackers)… If you think, I can send you the script I use (with iptables) to manage my firewall, so you can check it… The only entries I have, having something to do with ICMP, are:

  ———————————-
  /bin/echo -n “Disable ICMP Redirect acceptance…”
  for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
  /bin/echo 0 > $f done
  /bin/echo “done.”
  /sbin/iptables -A INPUT -i dsl0 -p icmp –icmp-type echo-request -m limit –limit 6/m –limit-burst 5 -j ACCEPT
  /sbin/iptables -A FORWARD -o dsl0 -p icmp -j ACCEPT
  ———————————-

  and of course other rules to allow ICMP pakets in the internal networks…

  Thanks a lot Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Hi Luca,

  I may have missed this originally – are you saying you have trouble when internal phones call each other, if they are on different VLAN’s? 
  That’s a pretty big deal.

  I didn’t see my post with the graphs of inter-packet latency make it to the list (moderator?), I think the images were too large.  Recall that clearly showed half of the packets coming inbound from DT were
  *missing*, which confirms your audio experience.  I don’t think that fact has been addressed properly – it is the only smoking gun you have so far.  If that is also happening inter-VLAN, something is seriously wrong on the Pi.

  If you can reproduce this can you send me a few more packet traces, from each of the VLAN interfaces involved?

  Always looking for real-world data to improve our tools 🙂

  Cheers,

• Am 23.06.2020 15:15, schrieb Jeff LaCoursiere:

  Hi Jeff,

  There were the results of my yesterday’s tests… If both mobile phones using SIP via LTE or both phones are in the same VLAN, the quality is excellent, otherwise it’s bad to very bad…

  But the very problem is, that all other communication between the VLANs don’t have any problem?!?
  I can transfer GB and don’t have any issue…

  I’m really confused…

  Well, probabilly not on the PI, since, as I sayd, communication with both peers in the same interface work correct, but maybe my firewall script…

  Of course, I can do that!
  Maybe I get it this evening.

  Regards Luca Bertoncello
  (lucabert@lucabert.de)

  —

• 2020-06-23 15:02 GMT+02:00, Luca Bertoncello :

  I meant DT, but this was a speculation. I did not say they do. I
  consider it highly improbable. Then I was asking whether you do. As per configuration you sent you are not blocking icmp type 3 so this should not be an issue.

  —

• Am 23.06.2020 15:43, schrieb Marek Greško:

  Hi

  OK, so this should not be the problem… What can we check now?
  If you want, I can send my iptables-script. It is possible, that I have there an error causing this behaviour…

  Maybe someone in the list is an expert with iptables and can check it?
  I know this program, but I’m not really an expert…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• It seems your problems lie in something other. Most probably it is not mtu problem. All my suspections are contradicted. If it is true you have inter vlan voice quality problems, it is definitely something different. Formerly I assumed you were trying only LTE vs LAN using internet.

  Marek

  2020-06-23 15:50 GMT+02:00, Luca Bertoncello :

  —

• Am 23.06.2020 16:22, schrieb Marek Greško:

  I’m not sure what you mean with the last sentence… I tried to connect to my Asterisk via LAN or via DSL (either via LTE or other DSL). Then I noticed that if I call another peer in same network (= both peers via DSL or both peers in the same VLAN), the quality is very good, otherwise is very poor.

  But why should Asterisk have problem if the peers are in different networks it’s for me a really big mistery…

  This evening I’ll try to capture the pakets in a call between two peers connected to Asterisk via LTE, two peers connected in the same LAN and a peer connected via LTE and the other in LAN, then maybe it’s possible to find the problem…

  But if you have any other idea, I’m very happy to hear it! 😉

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• I interchanged LAN and LTE in the sentence.

  Do you have some kind of NAT in fron of asterisk? Or is your asterisk having public IP? Could you share sip.conf (without passwords)? One LAN client, one LTE and general section.

  Marek

  2020-06-23 16:29 GMT+02:00, Luca Bertoncello :

  —

• Am 23.06.2020 um 17:04 schrieb Marek Greško:

  OK…

  No, Asterisk has a public IP. No NAT in front of Asterisk…

  Of course:

  my outgoing configuration:
  [pbxluca]
  type=peer defaultuser=
  secret=
  dtmfmode=rfc2833
  host=tel.t-online.de context=luca_incoming outboundproxy=tel.t-online.de port=5060
  fromuser=03511111111
  fromdomain=tel.t-online.de usereqphone=yes canreinvite=yes insecure=port,invite nat=no qualify=yes qualifyfreq=600
  disallow=all allow=alaw allow=ulaw

  my phone configuration:
  ; Lucas Telefon
  [00493511111111]
  fullname = 00493511111111
  secret =
  hassip = yes hasiax = no hash323 = no hasmanager = no callwaiting = no context = default host = dynamic dtmfmode=rfc2833
  canreinvite=no sendrpid=pai type=friend nat=force_rport,comedia qualify=yes qualifyfreq=60
  avpf=no force_avp=no icesupport=no encryption=no callgroup=1
  pickupgroup=1
  deny=0.0.0.0/0.0.0.0
  permit=192.168.200.0/255.255.255.0
  dial=SIP/00493511111111

  my mobile phone:
  ; Lucas Handy
  [00491772222222]
  fullname = 00491772222222
  secret =
  hassip = yes hasiax = no hash323 = no hasmanager = no callwaiting = no context = default host = dynamic dtmfmode=rfc2833
  canreinvite=no sendrpid=pai type=friend nat=force_rport,comedia qualify=yes qualifyfreq=60
  avpf=no force_avp=no icesupport=no encryption=no callgroup=1
  pickupgroup=1
  dial=SIP/00491772222222
  allow = all

  sip.conf:
  [general]
  context=default allowoverlap=no udpbindaddr=0.0.0.0:25572
  tcpenable=yes tcpbindaddr=0.0.0.0:25572
  tlsenable=no tlsbindaddr=0.0.0.0:25573
  transport=udp srvlookup=no minexpiry=480
  defaultexpiry=480
  disallow=all allow=alaw allow=ulaw allow=ilbc allow=g729
  allow=g723
  allow=gsm language=de alwaysauthreject = yes tlscertfile=/etc/asterisk/ssl/asterisk.pem tlscafile=/etc/asterisk/ssl/ca.crt tlscipher=ALL
  tlsclientmethod=tlsv1
  callcounter = yes t38pt_udptl = yes faxdetect = no register =>
  03511111111:xxxxxxxx:333333333333-0001@t-online.de@pbxluca/00493511111111
  register =>
  03511111112:xxxxxxxx:333333333333-0001@t-online.de@pbxfax/00493511111112
  register =>
  03511111113:xxxxxxxx:333333333333-0001@t-online.de@pbxanika/00493511111113
  register => 555555555:xxxxxxxx@messagenet/555555555
  register => lucabertoncello:xxxxxxxxx@rebvoice/lucabertoncello jbenable = no jbmaxsize = 200
  jbresyncthreshold = 1000
  jbimpl = fixed

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• RTP-VoIP-packets never reach this size. Size is about 214 bytes.

  Regards Michael

  —

• Am 23.06.2020 um 21:08 schrieb Michael Maier:

  OK, so it must be something other…

  But I really don’t have any idea what… 🙁

  Thanks Luca

  —

• 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

  Nice to hear 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?

  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@lucabert.de)

  —

• Am 24.06.20 um 08:10 schrieb Luca Bertoncello:
  Google is your friend as usual. Try *for example* those search patterns as *entry point*:
  wireshark rtp stream analysis wireshark voip mitschneiden

  https://support.yeastar.com/hc/en-us/articles/360007606533-How-to-Analyze-SIP-Calls-in-Wireshark https://www.innosoft.at/news/169/voip-grundlagen-wireshark-analyse-von-sip-telefonie https://sharkfestus.wireshark.org/sharkfest.12/presentations/BI-7_VoIP_Analysis_Fundamentals.pdf

  Regards Michael

  —

• Hi list!

  Am 22.06.2020 um 16:48 schrieb Luca Bertoncello:

  So, now I know what was the problem and I solved it…

  The problem was: the Banana PI… 🙁

  I checked it with mtr and I see really bad times to communicate with other devices im same networks (~2 – 380 ms!!). Many tries with other Switch ports and so on didn’t solved the problem.

  So I bought a mini PC and I configured it as Firewall with Asterisk. mtr give now really good times (~0.2 – 0.4 ms). And Asterisk works very good…

  I tried right now with my father in law and the communication was excellent, without any disruptions.

  So, I really thank you for the idea, that my Banana PI can be the problem. It was! 😉

  Have a nice weekend!
  Luca Bertoncello
  (lucabert@lucabert.de)

  —

• […]

  Glad you could find and solve the problem.

  Yeah, that’s what I already thought for myself. VoIP is (based on its realtime nature) extremely picky about network interfaces (or even complete hardware of the system) and their drivers and the corresponding configuration. But most of the people can’t / won’t believe it.

  Many of them (NICs) are pretty broken (sometimes the nic hardware, sometimes both hard- and software). Even APU 1 or 2 devices don’t work reliably for VoIP with the standard in kernel drivers or with default configuration here. I always had / have to use other drivers / kernels / configurations to get a proper and reliable rtp stream – even over hours.

  Regards Michael

  —