44 thoughts on - Voice “broken” During Calls

• Am 13.06.2020 um 08:28 schrieb Luca Bertoncello:

  Hi again!

  Just a detail: I tried an internal call (from my phone, to my wife’s phone) and it works wonderful, no broken, no delay, top quality. So the problem _MUST_ be in the settings of the communication with Deutsche Telekom and MessageNet (the providers I used).

  The settings for Deutsche Telekom are:

  [pbxluca]
  type=peer defaultuser=-0001
  secret=
  dtmfmode=rfc2833
  host=tel.t-online.de context=luca_incoming outboundproxy=tel.t-online.de port=5060
  fromuser=0351xxxxxxx fromdomain=tel.t-online.de usereqphone=yes canreinvite=yes insecure=port,invite nat=force_rport,comedia qualify=yes qualifyfreq=600
  disallow=all allow=alaw allow=ulaw

  and the settings for MessageNet are:

  [messagenet]
  type=peer defaultuser=
  secret=
  dtmfmode=rfc2833
  host=sip.messagenet.it context=messagenet_incoming outboundproxy=sip.messagenet.it port=5060
  fromuser=
  fromdomain=sip.messagenet.it usereqphone=yes canreinvite=yes insecure=invite qualify=yes qualifyfreq=60
  disallow=all allow=alaw allow=ulaw allow=gsm

  Any idea?

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

  —

• Am 13.06.2020 09:30, schrieb Luca Bertoncello:

  Hi again (again)

  I noticed right now another strange detail… I made a call using my mobile phone (connected to the Asterisk). The quality was top… Maybe is the problem in a codec used from our phones at homes?
  Could someone suggest me how to check the codec used by my mobile phone and the codec used by the phones at home?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• What does that mean? You’re making a mobile phone call over the GSM network to your Asterisk server, or you’re using a soft phone application on your smartphone, which is registered by SIP to your Asterisk server?

  Also, where did you make the call *to* ?

  Didn’t we already discuss this last year?

  http://lists.digium.com/pipermail/asterisk-users/2019-December/294446.html

  Look at the verbose log file and search for “transcoding”.

  Also, do a SIP packet trace at the start of the call and see which codecs are announced by each side and then what gets agreed on (I don’t think this gets logged by Asterisk, so you need to look at the SIP negotiation itself).

  Antony.

  —
  I’m not impossible, just highly implausible.

  Please reply to the list;
  please *don’t* CC me.

  —

• Try “sip show peer ” for a phone. Then “sip show channels” during an existing call. And “sip show channel ” for more info.

  Michael

  http://www.mksolutions.info

  —

• Am 13.06.2020 um 13:47 schrieb Michael Keuter:

  Hi

  So:

  mobile phone:
  bpi*CLI> sip show peer 0049177xxxxxxx

  * Name : 0049177xxxxxxx

  Description :

  Secret :

  MD5Secret :

  Remote Secret:

  Context : default

  Record On feature : automon

  Record Off feature : automon

  Subscr.Cont. :

  Language : de

  Tonezone :
  AMA flags : Unknown
  Transfer mode: open
  CallingPres : Presentation Allowed, Not Screened
  Callgroup : 1
  Pickupgroup : 1
  Named Callgr :
  Nam. Pickupgr:
  MOH Suggest :
  Mailbox :
  VM Extension : asterisk
  LastMsgsSent : 0/0
  Call limit : 2147483647
  Max forwards : 0
  Dynamic : Yes
  Callerid : “0049177xxxxxxx” <>
  MaxCallBR : 384 kbps
  Expire : -1
  Insecure : no
  Force rport : Yes
  Symmetric RTP: Yes
  ACL : No
  DirectMedACL : No
  T.38 support : Yes
  T.38 EC mode : FEC
  T.38 MaxDtgrm: 4294967295
  DirectMedia : No
  PromiscRedir : No
  User=Phone : No
  Video Support: No
  Text Support : No
  Ign SDP ver : No
  Trust RPID : No
  Send RPID : Yes
  Path support : No
  Path : N/A
  TrustIDOutbnd: Legacy
  Subscriptions: Yes
  Overlap dial : No
  DTMFmode : rfc2833
  Timer T1 : 500
  Timer B : 32000
  ToHost :
  Addr->IP : (null)
  Defaddr->IP : (null)
  Prim.Transp. : UDP
  Allowed.Trsp : UDP
  Def. Username:
  SIP Options : (none)
  Codecs :
  (alaw|ulaw|ilbc|g729|g723|gsm|amr|amrwb|g726|g726aal2|adpcm|slin|slin|slin|slin|slin|slin|slin|slin|slin|lpc10|speex|speex|speex|g722|siren7|siren14|testlaw|g719|opus|jpeg|png|h261|h263|h263p|h264|mpeg4|vp8|red|t140|silk|silk|silk|silk)
  Auto-Framing : No
  Status : UNKNOWN
  Useragent :
  Reg. Contact :
  Qualify Freq : 60000 ms
  Keepalive : 0 ms
  Sess-Timers : Refuse
  Sess-Refresh : uac
  Sess-Expires : 1800 secs
  Min-Sess : 90 secs
  RTP Engine : asterisk
  Parkinglot :
  Use Reason : No
  Encryption : No

  VoIP-phone (Thomson ST2022):
  bpi*CLI> sip show peer 0049351xxxxxxx

  * Name : 0049351xxxxxxx

  Description :

  Secret :

  MD5Secret :

  Remote Secret:

  Context : default

  Record On feature : automon

  Record Off feature : automon
  Subscr.Cont. :
  Language : de
  Tonezone :
  AMA flags : Unknown
  Transfer mode: open
  CallingPres : Presentation Allowed, Not Screened
  Callgroup : 1
  Pickupgroup : 1
  Named Callgr :
  Nam. Pickupgr:
  MOH Suggest :
  Mailbox :
  VM Extension : asterisk
  LastMsgsSent : 0/0
  Call limit : 2147483647
  Max forwards : 0
  Dynamic : Yes
  Callerid : “0049351xxxxxxx” <>
  MaxCallBR : 384 kbps
  Expire : 3111
  Insecure : no
  Force rport : Yes
  Symmetric RTP: Yes
  ACL : Yes
  DirectMedACL : No
  T.38 support : Yes
  T.38 EC mode : FEC
  T.38 MaxDtgrm: 4294967295
  DirectMedia : No
  PromiscRedir : No
  User=Phone : No
  Video Support: No
  Text Support : No
  Ign SDP ver : No
  Trust RPID : No
  Send RPID : Yes
  Path support : No
  Path : N/A
  TrustIDOutbnd: Legacy
  Subscriptions: Yes
  Overlap dial : No
  DTMFmode : rfc2833
  Timer T1 : 500
  Timer B : 32000
  ToHost :
  Addr->IP : 192.168.200.10:25572
  Defaddr->IP : (null)
  Prim.Transp. : UDP
  Allowed.Trsp : UDP
  Def. Username: 0049351xxxxxxx
  SIP Options : (none)
  Codecs : (alaw|ulaw|ilbc|g729|g723|gsm)
  Auto-Framing : No
  Status : OK (17 ms)
  Useragent : THOMSON ST2022 hw2 fw3.56 00-26-44-31-10-23
  Reg. Contact : sip:0049351xxxxxxx@192.168.200.10:25572;user=phone
  Qualify Freq : 60000 ms
  Keepalive : 0 ms
  Sess-Timers : Refuse
  Sess-Refresh : uac
  Sess-Expires : 1800 secs
  Min-Sess : 90 secs
  RTP Engine : asterisk
  Parkinglot :
  Use Reason : No
  Encryption : No

  Call from normal phone:
  bpi*CLI> sip show channels Peer User/ANR Call ID Format Hold
  Last Message Expiry Peer
  192.168.200.10 0049351xxxxxxx 9eff88f7-c0a801 (alaw) No
  Rx: ACK 0049351xxxxxxx
  217.0.27.53 03501xxxxxxx 453efbcb7a04f33 (alaw) No
  Tx: ACK pbxluca
  2 active SIP dialogs

  Call from mobile phone (via VoIP registered in Asterisk):

  bpi*CLI> sip show channels Peer User/ANR Call ID Format Hold
  Last Message Expiry Peer
  192.168.10.12 0049177xxxxxxx 11b86bd612b71ae (alaw) No
  Rx: INVITE 0049177xxxxxxx
  217.0.27.53 00493501xxxxxxx 5647efe41d746b4 (alaw) No
  Tx: INVITE pbxluca
  2 active SIP dialogs

  Call from normal phone:

  bpi*CLI> sip show channel 9eff88f7-c0a80101-0-22c911@192.168.200.10

  * SIP Call

  Curr. trans. direction: Incoming

  Call-ID: 9eff88f7-c0a80101-0-22c911@192.168.200.10

  Owner channel ID: SIP/0049351xxxxxxx-000000a7
  Our Codec Capability: (alaw|ulaw|ilbc|g729|g723|gsm)

  Non-Codec Capability (DTMF): 1

  Their Codec Capability: (ulaw|g723|alaw|g729)

  Joint Codec Capability: (alaw|ulaw|g729|g723)
  Format: (alaw)
  T.38 support No
  Video support No
  MaxCallBR: 384 kbps
  Theoretical Address: 192.168.200.10:25572
  Received Address: 192.168.200.10:25572
  SIP Transfer mode: open
  Force rport: Yes
  Audio IP: 192.168.200.1 (local)
  Our Tag: as12e44b1b
  Their Tag: c0a80101-d3c8cef7
  SIP User agent: THOMSON ST2022 hw2 fw3.56 00-26-44-31-10-23
  Username: 0049351xxxxxxx
  Peername: 0049351xxxxxxx
  Original uri: sip:0049351xxxxxxx@192.168.200.10:25572
  Caller-ID: 0049351xxxxxxx
  Need Destroy: No
  Last Message: Rx: ACK
  Promiscuous Redir: No
  Route:
  
  DTMF Mode: rfc2833
  SIP Options: replaces replace timer
  Session-Timer: Inactive
  Transport: UDP
  Media: RTP

  bpi*CLI> sip show channel 453efbcb7a04f33e1e0de7ef461f9b38@tel.t-online.de

  * SIP Call
  Curr. trans. direction: Outgoing
  Call-ID: 453efbcb7a04f33e1e0de7ef461f9b38@tel.t-online.de
  Owner channel ID: SIP/pbxluca-000000a8
  Our Codec Capability: (alaw|ulaw)
  Non-Codec Capability (DTMF): 1
  Their Codec Capability: (alaw)
  Joint Codec Capability: (alaw)
  Format: (alaw)
  T.38 support Yes
  Video support No
  MaxCallBR: 384 kbps
  Theoretical Address: 217.0.27.xx:5060
  Received Address: 217.0.27.xx:5060
  SIP Transfer mode: open
  Force rport: Yes
  Audio IP: 91.49.50.x (local)
  Our Tag: as29bbbfb6
  Their Tag:
  h7g4Esbg_p65551t1592060241m195254c7230720s1_1763914935-920913141
  SIP User agent:
  Username: 03501xxxxxxx
  Peername: pbxluca
  Original uri: sip:sgc_c@217.0.27.xx
  Need Destroy: No
  Last Message: Tx: ACK
  Promiscuous Redir: No
  Route:
  DTMF Mode: rfc2833
  SIP Options: (none)
  Session-Timer: Inactive
  Transport: UDP
  Media: RTP

  Call from mobile phone (via VoIP registered in Asterisk):

  bpi*CLI> sip show channel 11b86bd612b71ae0f06c62d53ecf08c6@192.168.10.12

  * SIP Call
  Curr. trans. direction: Incoming
  Call-ID: 11b86bd612b71ae0f06c62d53ecf08c6@192.168.10.12
  Owner channel ID: SIP/0049177xxxxxxx-000000a9
  Our Codec Capability:
  (alaw|ulaw|ilbc|g729|g723|gsm|amr|amrwb|g726|g726aal2|adpcm|slin|slin|slin|slin|slin|slin|slin|slin|slin|lpc10|speex|speex|speex|g722|siren7|siren14|testlaw|g719|opus|jpeg|png|h261|h263|h263p|h264|mpeg4|vp8|red|t140|silk|silk|silk|silk)
  Non-Codec Capability (DTMF): 1
  Their Codec Capability: (ulaw|gsm|alaw|amr)
  Joint Codec Capability: (alaw|ulaw|gsm|amr)
  Format: (alaw)
  T.38 support No
  Video support No
  MaxCallBR: 384 kbps
  Theoretical Address: 192.168.10.12:37210
  Received Address: 192.168.10.12:37210
  SIP Transfer mode: open
  Force rport: Yes
  Audio IP: 192.168.10.1 (local)
  Our Tag: as339b5367
  Their Tag: 1910565801
  SIP User agent:
  Peername: 0049177xxxxxxx
  Original uri: sip:0049177xxxxxxx@192.168.10.12:37210
  Caller-ID: 0049177xxxxxxx
  Need Destroy: No
  Last Message: Rx: ACK
  Promiscuous Redir: No
  Route:
  
  DTMF Mode: rfc2833
  SIP Options: (none)
  Session-Timer: Inactive
  Transport: UDP
  Media: RTP

  bpi*CLI> sip show channel 5647efe41d746b4d67ad5c576b67beba@tel.t-online.de

  * SIP Call
  Curr. trans. direction: Outgoing
  Call-ID: 5647efe41d746b4d67ad5c576b67beba@tel.t-online.de
  Owner channel ID: SIP/pbxluca-000000aa
  Our Codec Capability: (alaw|ulaw)
  Non-Codec Capability (DTMF): 1
  Their Codec Capability: (alaw)
  Joint Codec Capability: (alaw)
  Format: (alaw)
  T.38 support Yes
  Video support No
  MaxCallBR: 384 kbps
  Theoretical Address: 217.0.27.xx:5060
  Received Address: 217.0.27.xx:5060
  SIP Transfer mode: open
  Force rport: Yes
  Audio IP: 91.49.50.xx (local)
  Our Tag: as148b6300
  Their Tag:
  h7g4Esbg_p65551t1592060364m136229c7238384s1_1886856096-203650581
  SIP User agent:
  Username: 00493501xxxxxxx
  Peername: pbxluca
  Original uri: sip:sgc_c@217.0.27.xx
  Need Destroy: No
  Last Message: Tx: ACK
  Promiscuous Redir: No
  Route:
  DTMF Mode: rfc2833
  SIP Options: (none)
  Session-Timer: Inactive
  Transport: UDP
  Media: RTP

  So, I’d say, the codecs are the same… Do you see something strange that I should check/change?

  Thank you very very much for your help!
  Luca Bertoncello
  (lucabert@lucabert.de)

  —

• So the call used Alaw as Codec.

  Michael

  http://www.mksolutions.info

  —

• …which should be excellent quality.

  PS: Michael: thanks for the tips regarding “sip show channels” and “sip show channel ” – I was aware of these for some details, but hadn’t realised they showed the codecs as well. Very useful 🙂

  Antony.

  —
  Your work is both good and original. Unfortunately the parts that are good aren’t original, and the parts that are original aren’t good.

  – Samuel Johnson

  Please reply to the list;
  please *don’t* CC me.

  —

• That strikes me as somewhat unlikely.

  That looks a little more standard.

  Regards,

  Antony.

  —
  I just got a new mobile phone, and I called it Titanic. It’s already syncing.

  Please reply to the list;
  please *don’t* CC me.

  —

• Am 13.06.2020 um 18:20 schrieb Antony Stone:

  Hi

  Too much things, isn’t it?

  The questions are:

  1) why the mobile phone, with “too many things” has a better quality
  2) where can I change these settings?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 13.06.2020 um 18:06 schrieb Michael Keuter:

  Yes, so seems it to be… It should has the better quality… But the calls done using my mobile phone in VoIP with the Asterisk have better quality as the calls done using the normal VoIP-telefon…

  I’m really puzzled…

  Luca Bertoncello
  (lucabert@lucabert.de)

  —

• You are *assuming* that it’s the codec causing the difference.

  We don’t know that.

  Let me get this clear, to make sure I understand (differences emphasised):

  1. You use *a VoIP softphone app* on your mobile, which is registered by SIP, to your Asterisk server, over your home *wireless network*, to place a call to some external number, you have a conversation and *the quality is excellent*.

  2. You use your *Thomson ST2022*, which is also registered by SIP, to your home Asterisk server, over your home *cabled* network, to place a call to some
  (the same???) external number, you have a conversation and the quality is *not excellent*.

  Is that an accurate summary of your situation?

  Antony.

  —
  Just when you think you’re done, a cat floats by with buttered toast strapped to its back.

  – Steve Krug, “Don’t make me think”

  Please reply to the list;
  please *don’t* CC me.

  —

• Am 13.06.2020 um 22:09 schrieb Antony Stone:

  Hi Antony

  Well, I really don’t know what I can think, now…

  Not really…

  1) I have an Android phone, using the integrated Android VoIP-subsystem, connected to my Asterisk at home, over LTE or other network *outside my home network*. Today I called my mother using this method (I was in the home network of my parents in law, about 20km von my home network, so definitly *not* in my wireless…). The quality was excellent and it was confirmed from my father in law, too…
  2) I have a Thomson ST2022 connected to my Asterisk over Ethernet
  (cabled network). If I call for example my mother or my parents in law, the conversation is “broken”, eg: both partner can hear little
  “interruption”, about 1/10 seconds in the conversation…

  This is the situation…

  I tried to connect the Thomson ST2022 directly to the server of Deutsche Telekom via VoIP (excluding the Asterisk, but of couse using NAT, since the phone does not have a public IP but just an IP in my internal network) and then I called my father in law. Same problem… 🙁
  I didn’t get my Android phone connected to the server of Deutsche Telekom to check how it works *outside my home network*… Not sure why it doesn’t work…

  Some other information:

  1) Asterisk runs on a Linux-Box (on a BananaPI) with Debian 10. Asterisk was installed from Debian repositories.
  2) The Linux-Box is directly connected to the Internet (no NAT) with a DSL-Modem and PPPoE. Public IPv4 and IPv6 addresses are configured in a network interface of the Linux-Box.
  3) I use iptables+tc to manage a traffic shaping, privileging the VoIP
  connection. If you want, I have no problem to send the traffic-shaping-script to the list.
  4) The DSL connection has a speed of 50Mbps down and 10Mbps up, and I
  really think, it should be enough…
  5) The phones are connected with Gbps-Ethernet to the Linux-Box.
  6) On my Asterisk I configured a second VoIP-Provider (MessageNet, in Italy), but just to *receive* calls. My contract with MessageNet does not allow me the call someone using this connection. If someone calls my number by MessageNet, I have the same problem I have with Deutsche Telekom, altought not so strong, eg. the “interruptions” are not so frequent as by calls via Deutsche Telekom… Btw: by MessageNet I must use *gsm* as Codec, otherwise a connection will be extablished, but no Voice can be heared…

  I really appreciate any idea. Of course, it could be possible that there is a problem on Telekom-side, but it does not explain why I have the same problems, altought not often as by Telekom, by MessageNet, too…

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

  —

• sip.conf

  Look for lines such as

  disallow=all allow=ulaw allow=alaw allow=h263

  They may be in the [general] section, or they may be in the client (Android /
  Thomson) specific sections.

  Regards,

  Antony.

  —
  The lottery is a tax for people who can’t do maths.

  Please reply to the list;
  please *don’t* CC me.

  —

• Am 13.06.2020 um 22:56 schrieb Antony Stone:

  Hi Antony,

  OK

  Today was the quality not so excellent as yesterday… Both I and my father in law could hear “interruptions”, but so so much as if I call with the Thomson phone…

  This was the same as always… More little “broken voice” on both parts…

  It was a little bit better. I didn’t hear any “interruptions”, but my father in law does. Not many, but somes…

  Right now I don’t have the possibility to do that… 🙁

  I did another test, today: I called my leased line number using my mobile phone (over GSM, not VoIP) and wait for the answering maschine. So, as a normal call from outside if I’m not at home. Result: the quality is *excellent*. I didn’t hear any “interruptions” in the message of the answering maschine and, as I played the message I
  spoked there were no “interruptions”, too…

  So, the module voicemail in Asterisk does *not* have the same problems as the other phones. And the Thomson VoIP-phone has more problems than my Android connected to the Asterisk…

  Maybe helps this behaviour to find the problem?

  The quality is terrible. It is not possible to understand any word… BUT: if I call my wife using the Thomson (she uses a Thomsons, same model, too!) the quality is excellent…

  In my [general] section I have:

  disallow=all allow=alaw allow=ulaw allow=ilbc allow=g729
  allow=g723
  allow=gsm ; Messagenet need gsm…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• So, you don’t get “consistently good quality” in any situation, but it seems like the Thomson phone being involved makes things worse.

  And is her Thomson connected on the same network to the same Asterisk server, or is it somewhere else altogether?

  Why do you have:

  in sip.conf?

  Antony.

  —
  The words “e pluribus unum” on the Great Seal of the United States are from a poem by Virgil entitled “Moretum”, which is about cheese and garlic salad dressing.

  Please reply to the list;
  please *don’t* CC me.

  —

• Am 14.06.2020 um 10:49 schrieb Antony Stone:

  Correct

  Yes, both telefons are in the same VLAN and Asterisk, too.

  I can’t really remember why I added it… I try to remove it now and call my father in law. No changes…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 13.06.2020 um 22:56 schrieb Antony Stone:

  Hi again,

  I tried it on the network of a friend. Not possible to establish a connection at all… I *suppose* Deutsche Telekom just allow a logon on their servers from the IP of the user, who tries to log on (with other words: my VoIP login can just log on from my current IP)…

  This would explain why I didn’t got my mobile phone connecting to the Telekom’s server and establish a call…

  I also tried to stop Asterisk and all other network services on my Linux-Box Firewall/Gateway, including the traffic shaper (in the case, this was the problem), then connect my Thomson phone to the Telekom’s server and call my father in law. Always the same problem…

  So, tomorrow I’ll get another VoIP phone from a colleque (Elmeg IP 290). I’ll connect it to my network and my Asterisk and will try to call my father in law for a test.

  I really do *not* expect any change in the situation… I think, the problem should be somewhere by Deutsche Telekom…

  What is your opinion?

  Btw: I did all tests with my father in law, since he had time for me today, but the problem exists an almost all calls, incoming or outgoing, no matter from/to which network provider…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Hi Luca,

  the standard Deutsche Telekom SIP-account (former ISDN Mehrgeräteanschluß PTMP with 3-10 numbers) is always tied to your DSL account.

  There is a special “DeutschlandLAN SIP-Trunk Pure” where it does not depend on your DSL account (as it is standard with most other VoIP providers).

  Michael

  http://www.mksolutions.info

  —

• Am 14.06.2020 um 16:48 schrieb Michael Keuter:

  Hi Michael,

  I supposed it…

  OK, I really don’t think I want to subscribe this option just to check if the problem is in my account… 😀

  Any other suggestion how to find *where* the problem is?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Wait a moment…

  You mean that the Thomson phone is registering to Deutsche Telekom?

  I thought it was registering to your Asterisk server.

  Maybe it would be a good idea to tell *exactly* what your network setup is, because I’d certainly assumed something that’s clearly not true; maybe others here have as well.

  Basically, what SIP phones (hardware or software) are you using, what are they registering to, and what role is Asterisk playing in all of this? How do calls to/from the public phone network get routed from/to your telephones?

  Antony.

  —
  In science, one tries to tell people in such a way as to be understood by everyone something that no-one ever knew before.

  In poetry, it is the exact opposite.

  – Paul Dirac

  Please reply to the list;
  please *don’t* CC me.

  —

• Am 14.06.2020 um 17:05 schrieb Antony Stone:

  Hi Antony,

  Sorry, I didn’t read correctly your test 2b… Normally my Thomson phone is registering to my Asterisk server.

  I tried to register the Thomson phone directly to Telekom’s server, to check if the problem could be in my Asterisk…

  Well, I’ll try:

  – DSL-Modem, connected to a BananaPI with Debian 9
  – On the BananaPI, PPPoE to connect to the Internet, iptables and some scripts to manage the Gateway and Firewall
  – Many VLANs, some of them can use the Internet via NAT
  – The phones are in an own VLAN without any routing to the Internet
  (exception for my phone was temporarily made to allow the tests)
  – In the phone’s VLAN there is the Asterisk server, running on the same BananaPI the act as Gateway/Firewall
  – Mobile phone connected via WLAN in the same VLAN used from the PCs, and with routing to the Internet via NAT

  We have two phones Thomson ST2022, registering to the Asterisk server. The Asterisk server registers to Deutsche Telekom and MessageNet. All calls are normally routed by Asterisk to Deutsche Telekom. Some
  *incoming* calls to an italian number arrives via MessageNet and will be directed to my Thomson phone.

  What I tried connecting the phone directly to the Internet and the servers of Deutsche Telekom was just a test, not the normal situation.

  Do I have explained my current situation?
  Of course I can send extract of configurations, if needed…

  What I’ll do tomorrow with a test phone is:

  1) connecting it to my Asterisk and try to make a call
  2) connecting it directly to the servers of Deutsche Telekom (using my network) and try to make a call

  Thanks a lot for your help Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 14.06.2020 um 17:33 schrieb Luca Bertoncello:

  Hi

  So, I got a phone (Elmeg IP290) from a collegue and tested it…

  Absolutly *no changes* on the behaviour compared with my Thomsons…

  I try to summarize:

  1) Phones are not the problem, since 3 phones of 2 different companies/model have the same issue.
  2) Asterisk seems not to be the problem, too, since I have the same behaviour if I connect to phone directly to the server of Deutsche Telekom.
  3) Traffic shaping seems not to be the problem, too, since I tried to deactivate it.
  4) The problem happens *only* on active call, not by voicemail.
  4a) To test it I read a text and my partner just listen it, and then he read a text and I listen it. *No* simulaneously speak!
  5) A *single call* (since I couldn’t reproduce it anymore), made using my Android phone as SIP-client connected to my Asterisk, had not the problem. Any other try to call someone using my mobile phone via SIP had the problem.

  I could *not* test connecting to the server of Deutsche Telekom using the Internet connection of someone other, since Telekom bounds my VoIP-login to my IP.

  I really think, the problem should be by Deutsche Telekom…

  What is your opinion? Do you see some other tests I should try?

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

  —

• Hi,

  We are working on a product to analyze pcap files of VoIP calls. So far it does a reasonable job of analyzing the frequency distribution of packets in both directions, pointing out which direction packet loss /
  bad jitter occurs.  If you can trap the traffic on the outside and the inside of your Banana Pi and send me the pcap files, I would be happy to run it through our analyzer as further information for you.  If it shows DTK isn’t sending packets when it should, that will be obvious, and you can send to them as solid evidence of their guilt 🙂

  Beyond that, are you certain you aren’t taxing the Banana Pi?  It really
  *should* be able to handle a single call while handling your LAN’s routing/firewall tasks, but you are probably skating the edge.  The results of the above might point out that the Pi isn’t *sending* packets it should be, or sending them way late, in which case the issue is actually your hardware.

  Cheers,

  *Jeff LaCoursiere*
  STRATUSTALK, INC. / CTO

  Phone: *+1 703.496.4990 x108*
  Mobile: *+1 815.546.6599*
  Email: *jeff@stratustalk.com*
  Website: *https://www.stratustalk.com*
  Address: *

• I have a Banana Pi R1 (the version with 5 ethernet ports, actually VLANned off a single physical interface), and all my Internet traffic goes through it, including SIP to NetCologne, who is my local telephony and connectivity provider here.

  My only major difference from Luca’s situation is that I don’t run Asterisk on this machine (although I do run it on a Raspberry Pi inside my network).

  I don’t experience any of the problems Luca reports – the worst I get from time to time is some briefly reduced call quality if someone happens to do a large file download while I’m on the phone (the download speed here is ‘only’
  25Mbps, so it’s easy enough to saturate for a short time with a browser).

  I certainly agree with the idea of doing a packet analysis on both sides of the Banana, though, to see whether DT is causing the problem, or whether the hardware’s just not up to the job.

  Regards,

  Antony

  —
  The truth is rarely pure, and never simple.

  – Oscar Wilde

  Please reply to the list;
  please *don’t* CC me.

  —

• Am 15.06.2020 um 20:15 schrieb Jeff LaCoursiere:

  Hi Jeff,

  Thank you for your offer. Could you say me which options I should pass to tcpdump to get all information you need?

  But I’m not really sure, that Asterisk could be the problem, since, as I
  said, the problem happens even if I connect the phone direct to the server of Telekom…

  Well, during the calls, the BananaPI has a load of max 1, and it have 2
  cores… The LAN interface is Gbps, and my DSL is only 50Mbps, so it is not possible to get it full of band…

  And during the test as I connected the phone to the Telekom servers the load of the BananaPI was lower as 1.

  Last but not least: I tried calls via Skype and WhatsApp (with my phone in my WLAN). No problem and very good quality, so the BananaPI does not have any problem to manage the data transfer, isn’t it?

  Regards Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Okay, I’m glad we can rule out the specific make / model of phone – that would have been bizarre.

  Good (if you see what I mean).

  Is that also via the Banana, or with the phone directly on a DSL modem?

  Good test / check.

  So, only when there are two SIP clients active on each side of the Asterisk server…

  But, what were the results – each of you could hear the other perfectly well?

  This sounds interesting – more ideas below.

  You seem to have the problem in general, so a single (or small number of)
  instances of no problem doesn’t mean there isn’t something to be resolved.

  Right.

  Especially since you say you do not get the problem when you have calls in via Messagenet for your Italian calls.

  Yes.

  I’m intrigued by the “only one party speaking at a time” test you did.

  What happens if:

  a) you call someone external, speak for about 30 seconds without them making any sound, then they start speaking *at the same time as you*, then you stop talking and they carry on.

  b) exactly the same, except this time they call you, so it’s an inbound call.

  Do you get good quality while only one person speaks, and bad while both do?
  Does the quality return to good when one person stops speaking?

  Regards,

  Antony.

  —
  f u cn rd ths, u cn gt a gd jb n nx prgrmmng

  Please reply to the list;
  please *don’t* CC me.

  —

• I think that is significant, even if the routing is still going through the Banana.

  Multi-core CPUs are only a benefit if you can run separate applications (or at least separate threads of an application) on the separate cores.

  I’m not sure Asterisk can do this for a single call.

  Can you get the full 50Mbps through the Banana when you’re doing a download of something biggish?

  The big difference there, though, is that Asterisk (running on the Banana) is not handling the call, so you have the traffic being routed through the Banana, but Asterisk is not being asked to do anything with it in the middle.

  Antony.

  —
  “When you talk about Linux versus Windows, you’re talking about which operating system is the best value for money and fit for purpose. That’s a very basic decision customers can make if they have the information available to them. Quite frankly if we lose to Linux because our customers say it’s better value for money, tough luck for us.”

  – Steve Vamos, MD of Microsoft Australia

  Please reply to the list;
  please *don’t* CC me.

  —

• Am 15.06.2020 um 21:24 schrieb Antony Stone:

  Yes, I really didn’t believe, it could be the problem, but know is better than believe… 😉

  Always via the BananaPI
  I cannot connect the phone directly to a DSL modem, since the phone does not have any program to establish a PPPoE

  Yes, you can say it, too… I think, this is the same with other words…

  No! Maybe I didn’t explained well… All the tests I done with my father in law, during that we experienced the “interruptions” were made as I described, one of us spoke, the other counts the “interruptions”.

  Yes, this is a general problem, happening using the phone of my wife, too, btw…

  Sometimes I experienced problem with MessageNet, too, but not so frequently as with Deutsche Telekom…

  Are these 30 seconds of “silence” important? If not, it happens very frequently that both partners speak at the same time. In this case, the quality is a little bit less than normal, but very very little!, and I
  hear “interruptions” in this case, too…

  I experienced these “interruptions” if I call even if I receive the call, if this was your question…

  Actually I don’t get a good quality at all, expect for some isolated calls…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 15.06.2020 um 21:28 schrieb Antony Stone:

  What do you mean? In which sense this is “significant”?

  Yes, of course.

  But of course the BananaPI can handle that Asterisk uses a core and reserve the rest (or part of it) to manage the PPPoE connection…

  What do you mean now? If I can use the full available band or if I can download exactly 50Mbs?
  The answer to the first question is: YES! That’s why I use a traffic shaper… 😉
  The answer to the second question is: NO. I made a speedtest right now and I get only ~18Mbps download.

  Yes, and the voice quality is excellent, but *just* if I’m *not* using DT… As soon as I use DT (configuring the phone to connect directly to the server) both partners can hear the “interruptions”…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 15.06.2020 um 21:50 schrieb Luca Bertoncello:

  And some other information, too.

  I checked the xDSL-statistics of my DSL-Modem (which use the BananaPI to establish the PPPoE connection):

  adsl: ADSL driver and PHY status Status: Showtime Last Retrain Reason: 2
  Last initialization procedure status: 0
  Max: Upstream rate = 1709 Kbps, Downstream rate = 19888 Kbps Bearer: 0, Upstream rate = 1626 Kbps, Downstream rate = 20113 Kbps Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps

  So it seems, that my connection is about the half of the theorical one…

  I think, I must call Deutsche Telekom, but since I’ll change my contract at 18.06., I’ll wait some days. Then I’ll have a “business” contract, and I hope I don’t must speak with someone that can just say “you have to reboot your Fritzbox. What? You don’t have a Fritzbox? That’s not possible. Please check your Fritbox, I can’t reach it”… 😉

  Bye Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Because if/when the Thomson is registered directly to DT, then Asterisk is not doing anything on the Banana.

  The fact that you get the problem with the Thomson registered directly to DT, but with the traffic still going through the Banana, indicates to me that
  “Asterisk running on the Banana” is not the problem.

  I don’t see the difference – I’m asking whether the Banana can manage to route
  50Mbps of traffic.

  So, you’re saying that your Banana Pi *can* provide the full 50Mbps throughput if you don’t enable the traffic shaper?

  So, is it the traffic shaper which is imposing this limit?

  Right.

  I’m very much agreeing with you here, that DT appears to be the problem, and I
  think Jeff’s suggestion / offer to capture the audio data and do an analysis on it would likely show that.

  Just one suggestion regarding that: I recommend doing two packet captures; one with Asterisk registered to DT and the Thomson registered to Asterisk, and the other with the Thomson registered to DT but the traffic still going through the Banana.

  Regards,

  Antony.

  —
  Someone has stolen all the toilets from New Scotland Yard. Police say they have absolutely nothing to go on.

  Please reply to the list;
  please *don’t* CC me.

  —

• Oh!

  Right.

  Hehe 🙂

  Good luck,

  Antony.

  —
  “A person lives in the UK, but commutes to France daily for work. He belongs in the UK.”

  – From UK Revenue & Customs notice 741, page 13, paragraph 3.5.1
  – http://tinyurl.com/o7gnm4

  Please reply to the list;
  please *don’t* CC me.

  —

• Am 15.06.2020 um 22:30 schrieb Antony Stone:

  Yes, I think it too

  I think, it should be possible… the BananaPI has a Gbit ethernet…

  If I try to transfer a big file between two devices in different VLANs
  (through the BananaPI as Gateway), there is no problem. I don’t really measured it, but it’s bigger than 50Mbps…

  No, I tried the test disabling the traffic shaper, too… no changes…

  OK!

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Yes, sure, please use (replace with correct interface names):

  sudo tcpdump -i eth0 -s 0 -w /tmp/test0.pcap &
  sudo tcpdump -i eth1 -s 0 -w /tmp/test1.pcap &

  Try to limit the traffic to just your phone call tests (to reduce the size of the capture files).  Make all your tests, then:

  sudo killall tcpdump
  tar cvzf /tmp/tests.tgz /tmp/test?.pcap

  Send /tmp/tests.tgz to me by email, or leave somewhere I can download. 
  I’ll run the analysis tonight and send the results to the list.

  Cheers,

• Am 15.06.2020 um 23:15 schrieb Jeff LaCoursiere:

  Hi

  OK, I’ll do it this evening (german time), since now I must go to the office…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 15.06.2020 23:15, schrieb Jeff LaCoursiere:

  Hi again,

  just a question, to be sure…

  eth0 is my DSL interface and eth1 my phone interface?

  Well, assuming eth0 is the DSL interface and eth1 the phone interface, I
  can so that:

  tcpdump -i dsl0 -s 0 -w /tmp/test0.pcap host tel.t-online.de &
  tcpdump -i phone0 -s 0 -w /tmp/test1.pcap host 192.168.200.xx (IP of my phone) &

  is it correct?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Well, one is internal (phone) and the other is external (DT), doesn’t matter which way round.

  Looks like you name your Banana interfaces very similarly to mine 🙂

  However, I would be careful with that first one, containing “host tel.t-
  online.de”. I don’t use DT, so I can’t be sure, but I guess this is the SIP
  server to which you register with the account credentials…

  It *may not* be the same machine as handles the RTP packets – that is negotiated separately between Asterisk (or the Thomson, when it’s connected directly to DT) as part of the SIP INVITE / Acknowledge.

  So, you *could* find that you capture all of the SIP traffic and none of the RTP
  traffic. On the other hand, you might get everything.

  You can be pretty sure it’s worked if you do the above and then find that the two packet capture files are approximately the same size. If the DT one is significantly smaller (by which I mean a factor of at least ten different), then omit the “host” parameter on that capture and try again…

  Antony.

  —
  A few words to be cautious of between American and English:
  – momentarily
  – suspenders
  – chips
  – pants
  – jelly
  – pavement
  – vest
  – pint (and gallon)
  – pissed

  Please reply to the list;
  please *don’t* CC me.

  —

• Am 16.06.2020 10:48, schrieb Antony Stone:

  This was what I meant…

  I think, we are not alone… 😀

  OK, I’ll check it…

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Sure, that’s fine.  We will figure out which one is north/south in the analysis.

  Perfect.

  Cheers,

  j

  —

• Hi Luca,

  Am Samstag, den 13.06.2020, 08:28 +0200 schrieb Luca Bertoncello:

  The product is “All-IP” and not the SIP trunk, right?
  The call starts normally and after about 15 minutes the quality is disturbed?

  Try to set “session-timers = refuse” in the sip.conf in the global section. I have observed that when updating the session this error occurs.

  Best regards,

  Karsten

  —

• Am 17.06.2020 14:37, schrieb Karsten Wemheuer:

  Hi Karsten!

  No, current we have Magenta Zuhause. Tomorrow we’ll change to DeutschlandLAN IP (business contract). The quality is disturbed from the first second…

  I had the problem, that the connection will be *dropped* after 15
  minutes, and I solved it with “session-timers = refuse”

  Bye Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Hi Luca,

  I suspect the problem is either the line quality, aggregation or some other factor. I can see you allow alaw and ulaw codecs for DT and alaw, ulaw and gsm for the second provider. This could be the difference why you observe problems mainly on DT. The alaw and ulaw codec require 64 kbps stream, but gsm requires only 13 kbps. If this is true, your problems will most probably be gone right after switching to the business contract. So happy tomorow.

  Marek

  2020-06-17 15:07 GMT+02:00, Luca Bertoncello :

  —

• Hello Luca,

  We are still playing with visualization of your data, but I didn’t want you to wait any longer for some results.  I think I blame both DT and the Pi 🙂

  First, a look at the phone side of your Banana Pi.  The first thing we noticed is there were a LOT more packets in one direction (north towards DT) than the other (towards the phone):

  jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ tcpdump -nr
  testPhone.pcap src 192.168.200.10 | wc -l
  reading from file testPhone.pcap, link-type EN10MB (Ethernet)
  7951
  jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ tcpdump -nr
  testPhone.pcap dst 192.168.200.10 | wc -l
  reading from file testPhone.pcap, link-type EN10MB (Ethernet)
  3981

  Note there are almost twice as many packets headed out.  Our tool takes a shot at it:

  jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ wotinder -I
  testPhone.pcap
  input: testPhone.pcap
  2020/06/16 10:47:16.047401 INVITE 192.168.200.10:25572 (Luca) ->
  192.168.200.1:25572 (sip:035014649215)-(81b17560-c0a80101-0-1798,10000)
  2020/06/16 10:47:16.112866 DUPINVITE 192.168.200.10:25572 (Luca) ->
  192.168.200.1:25572 (sip:035014649215)-(81b17560-c0a80101-0-1798,10000)
  2020/06/16 10:48:43.690647 BYE 192.168.200.1:25572(sip:035014649215)
  -> 192.168.200.10:25572(Luca)
      Session: 81b17560-c0a80101-0-1798
      RTP 10000 -> 10030
      Source total pkts: 7899 (avg err 15934.774414)
      Dest total pkts: 3943 (avg err 8307.511719)

  The “average error” is the average departure from exactly 50hz, in microseconds.  Basically we are wanting to see a packet every 20,000us, and if it arrives early (because the last one was late) or late, then the absolute value of how far off it was is accumulated, and in the end averaged.  Its a bit misleading in this case, because there has clearly been packet loss in one direction, and I am still wrapping my head around why the error isn’t much higher (some kind of bug in our packet loss penalties).

  It does show that from the BPi’s perspective, the stream from the phone is NOT very steady.  The *average* error was almost a full packet length late (16,000us).  Now our tool spits out the raw data (time between packets in us) and we can quickly graph it.  I lined up the two legs, but of course you are only seeing half of the second one, and it makes an interesting visual:

  What on earth is causing the very regular spikes?  Roughly every second there seems to be a delay introduced, EVEN FROM THE PHONE ON THE LAN! 
  This worries me that we have asked the Pi to do too much. Perhaps capturing the data and writing it while also running asterisk is causing something to back up regularly.  We do prefer to do this kind of analysis from a span port on a switch…

  But that doesn’t explain the missing packets from DT.

  Similar results on that side:

  jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ tcpdump -nr
  testDSL.pcap src 91.49.58.181 | wc -l
  reading from file testDSL.pcap, link-type LINUX_SLL (Linux cooked)
  8048
  jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ tcpdump -nr
  testDSL.pcap dst 91.49.58.181 | wc -l
  reading from file testDSL.pcap, link-type LINUX_SLL (Linux cooked)
  4076

  I’m making an assumption that 91.49.58.181 is your side of the DSL, and the packets towards you seem to be missing a lot!  I can’t explain that as a Pi issue *unless* something funny is happening on the kernel handling inbound public traffic.  You mention you are traffic shaping –
  that could easily be causing something like this. Running our tool on that trace:

  jeff@jasper:~/Personal/StratusTalk/wotinder/Luca/tmp$ wotinder -I
  DSL.pcap
  input: DSL.pcap
  2020/06/16 10:47:16.196746 INVITE 91.49.58.181:25572
  (00493514977290) -> 217.0.27.53:5060
  (sip:035014649215)-(765cb6164b1c122a3b9c8303600ea367,10036)
  2020/06/16 10:47:16.296309 DUPINVITE 91.49.58.181:25572
  (00493514977290) -> 217.0.27.53:5060
  (sip:035014649215)-(765cb6164b1c122a3b9c8303600ea367,10036)
  2020/06/16 10:47:16.357971 DUPINVITE 91.49.58.181:25572
  (00493514977290) -> 217.0.27.53:5060
  (sip:035014649215)-(765cb6164b1c122a3b9c8303600ea367,10036)
  2020/06/16 10:47:16.457280 DUPINVITE 91.49.58.181:25572
  (00493514977290) -> 217.0.27.53:5060
  (sip:035014649215)-(765cb6164b1c122a3b9c8303600ea367,10036)
  2020/06/16 10:48:43.680671 BYE 217.0.27.53:5060(sip:035014649215) ->
  91.49.58.181:25572(00493514977290)
      Session: 765cb6164b1c122a3b9c8303600ea367
      RTP 10036 -> 6300
      Source total pkts: 7898 (avg err 15771.558594)
      Dest total pkts: 3943 (avg err 6995.069824)

  The DUPINVITE packets I think are probably negotiations.  I didn’t dive into a SIP analysis, but it may be good to look at the SDP and confirm codec selection, etc.

  Funny enough, a visual of THAT side looks exactly the same:

  This really is telling I think about the Pi’s ability to keep up with everything you are asking it to do, when looked at from the
  *microsecond* perspective.

  Still doesn’t explain the lack of traffic from DT… I would call them, send them the trace you sent me, and this message.

  Good luck!

  Cheers,

  j

• Missing packet from DT could be caused by MTU issue.

  Marek

  2020-06-18 5:41 GMT+02:00, Jeff LaCoursiere :
  —