[asterisk-users] Voice "broken" during calls
Marek Greško
mgresko8 at gmail.com
Mon Jun 22 15:14:49 CDT 2020
Missing packet from DT could be caused by MTU issue.
Marek
2020-06-18 5:41 GMT+02:00, Jeff LaCoursiere <jeff at stratustalk.com>:
> 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>
>
>
>
More information about the asterisk-users
mailing list