[asterisk-users] Voice "broken" during calls

Wed Jun 17 22:41:39 CDT 2020

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 at 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 at 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 at 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 at 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 at 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 at 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

On 6/15/20 3:27 PM, Luca Bertoncello wrote:
> Am 15.06.2020 um 21:50 schrieb Luca Bertoncello:
>
>> 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.
> 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 at lucabert.de)
>

-- 

	*Jeff LaCoursiere*
STRATUSTALK, INC. / CTO

Phone: 	*+1 703.496.4990 x108*
Mobile: 	*+1 815.546.6599*
Email: 	*jeff at stratustalk.com* <mailto:jeff at stratustalk.com>
Website: 	*https://www.stratustalk.com*
Address: 	*One Freedom Square
13th Floor
Reston, VA 20190*

<https://www.facebook.com/jeff.lacoursiere> 
<https://linkedin.com/in/jeff-lacoursiere-884361> 
<https://www.twitter.com/stratustalk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200617/50f290ed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic1.png
Type: image/png
Size: 15375 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200617/50f290ed/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic2.png
Type: image/png
Size: 15773 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200617/50f290ed/attachment-0001.png>