Here is the test results, and yes the jitter is quite high, and that would probably explain why the audio sounds the way it does
Speed test statistics --------------------- Download speed: 4384 kbps Upload speed: 893 kbps Download consistency of service: 51 % Upload consistency of service: -- % Download test type: socket Upload test type: POST Maximum TCP delay: 719 ms Average download pause: 8 ms Minimum round trip time to server: 1 ms Average round trip time to server: 1 ms Estimated download bandwidth: 11779 kbps Route concurrency: 2.6869798 Download TCP forced idle: 0 % Maximum route speed: 524280 kbps VoIP test statistics -------------------- Jitter: you --> server: 208.5 ms Jitter: server --> you: 10.6 ms Packet loss: you --> server: 0.0 % Packet loss: server --> you: 0.0 % Packet discards: 87.0 % Packets out of order: 0.0 % Estimated MOS score: 1.0 The jitter inbound is good, that explains why inbound audio is good but the outbound jitter sucks, so I guess there it is. On Tue, Dec 30, 2014 at 12:43 AM, Chuck Hast <wch...@gmail.com> wrote: > Went to Firefox, the site is requesting a Java permission, not sure > why Chrome is just tossing the missing plugin FireFox is asking for > permission to use Java... > > > On Tue, Dec 30, 2014 at 12:39 AM, Chuck Hast <wch...@gmail.com> wrote: > >> I went to the 8 x 8 sight and got a 'plugin not supported on >> Chrome, that is the second speed test site that gives me that >> error. >> >> >> On Tue, Dec 30, 2014 at 12:37 AM, Chuck Hast <wch...@gmail.com> wrote: >> >>> Actually it is quite interesting, I also have Vonage, it did not work at >>> all >>> well when we first move here, voice in both directions was terrrible, and >>> Vonage said that they knew it would not work, so we were expecting >>> that, we did not use the Vonage service to the point that I was going >>> to ship back all but one device and keep it for grins on the cheapest >>> rate, but now the Vonage phones work just fine, so I am really flum- >>> moxed. >>> >>> I was looking a where to change the codec for the cellular side, but >>> I do not see where to do it for the cellular side of the phone. >>> >>> The uCell just acts like a mini base station, the phone registers with >>> it and carries on just as though it was talking to the big ones out on >>> the towers and other structures. There are NO knobs on the uCell, >>> indeed when I was talking to the AT&T CSR, I told him that it sure >>> would be nice to have a small web server where you could at least >>> link to the thing and watch as it did whatever it does on re-start. Mine >>> is in a higher part of the house so I can not see the indicators on the >>> front (well now I can I put a IP camera up looking at it so when i am >>> asked to tell them what I see I do not have to go running up there I >>> just bring up the video) when I am down in front of the computer. >>> >>> The testing I have done are with some numbers that you dial as it >>> is from a cell phone and i am testing the cellular stream not the >>> VoIP stream from a app to stream over WiFi. >>> >>> I was looking at the BW going through my router, when I have a call >>> running it is about 27Kb. It is not much, when I am not home the >>> modem will show maybe 100KB of data flow during the day from >>> my wife using the phones, so they do not pull too much. >>> >>> >>> >>> On Tue, Dec 30, 2014 at 12:23 AM, Mike C. <mconno...@gmail.com> wrote: >>> >>>> > >>>> > >>>> > Message: 2 >>>> > Date: Mon, 29 Dec 2014 15:31:38 -0800 >>>> > From: Chuck Hast <wch...@gmail.com> >>>> > Subject: Re: [PLUG] O.T.VoIP and Satellite >>>> > To: "Portland Linux/Unix Group" <plug@lists.pdxlinux.org> >>>> > Message-ID: >>>> > <CADNfBV-E-CAKZTq3tkYm5hxi4xCS7ZQ0a0635kt1j3KnD= >>>> > a...@mail.gmail.com> >>>> > Content-Type: text/plain; charset=UTF-8 >>>> > >>>> > MIke >>>> > Thank you for the observations. I did test the connection, since I am >>>> using >>>> > cellular, I found several phone numbers to test against, and all of >>>> them >>>> > provide >>>> > good inbound audio but my outbound audio is just all corrupted. >>>> > >>>> >>>> Call quality or lack thereof, as it relates to the network, is mostly a >>>> function of packet loss, delay and jitter. Jitter is variance in delay. >>>> 150 >>>> ms 1-way delay is the standard measurement for "toll quality voice." >>>> That >>>> is, the voice quality is good enough to charge for. >>>> >>>> > >>>> > I do not think that the DHCP assignment caused the problem, but I am >>>> trying >>>> > to figure out if something else was changed on the network at the same >>>> > time. >>>> > i.e. different routing. >>>> > >>>> > I know that normally ip addresses are not geo based, but it was >>>> always of >>>> > note that in the past any search or application that took me to a map >>>> would >>>> > always take me to a map of the area I live in, now since I am one >>>> > HughesNet, I see >>>> > that I am now taken to sites that are no where near where I am, and I >>>> > figured that it was probably where the gateway to the uplink to the >>>> > satellites was >>>> > located. I know that they have several of them, so I thought that >>>> might be >>>> > the issue. >>>> > >>>> >>>> You're correct in that a new DHCP ip address assignment could change the >>>> gateway and the routing to and from the satellite. It's also possible >>>> that >>>> only the outbound route is problematic. You would want to run at least >>>> some >>>> extended basic ping tests to the default gateway. >>>> >>>> What would be really useful at this point is to get some relevant >>>> network >>>> connectivity data. >>>> >>>> Can you go here - http://voiptest.8x8.com/ and run a few tests and >>>> post the >>>> results? I would run the test for 69 secs and run it for both G.729 and >>>> G.711 codecs. The reason being is that your internet connection might >>>> support the lower quality G.729 codec and you might be able to set that >>>> in >>>> your microcell or in your smartphone voip app. >>>> >>>> When the test is complete please click on the advanced tab and copy and >>>> paste all the statistics reported. >>>> >>>> Also, if you go to the "summary tab" and click on "result analysis" of >>>> "voip test" that would be useful info too. >>>> >>>> > >>>> > >>>> >>>> > Typical internet is asymmetric - when somebody is watching a movie >>>> > on netflix or surfing the web, they are receiving a firehose of >>>> > bits and sending out a trickle of ACK packets. >>>> > >>>> > VOIP usage is symmetric, moderate bandwidth data streams in both >>>> > directions. >>>> > >>>> > Satellites are also asymmetric - they have a limited number of >>>> > transponders with limited bandwidth, which they will allocate to >>>> > maximize overall customer retention, which means catering to the >>>> > majority. Which isn't thee and me. >>>> > >>>> > The satellite provider probably recently reallocated a customer >>>> > uplink transponder as a customer downlink transponder, to better >>>> > serve the netflix users. There might be an FCC or ITU document >>>> > or ruling about this. Do you know which particular satellite >>>> > you are talking to? One of the ANIKs? >>>> > >>>> > >>>> This is really getting off into the weeds. What matters with VOIP call >>>> quality is consistency. Consistency of packet loss, delay and jitter. >>>> Jitter is variance in delay. 3 Mbs of bandwidth in each direction >>>> should be >>>> sufficient to provide okay call quality. Call distortion is caused >>>> mostly >>>> by packet loss, delay and jitter. At the simplest level, 150 ms one way >>>> delay is the standard measurement to provide what's called "toll quality >>>> voice." That is, it's good enough to charge for. >>>> >>>> A g.729 call requires 32 kbps. The average satellite link bandwidth is >>>> approx 400 kbps. If you're just making a voip call, there shouldn't be >>>> any >>>> call quality problems due to "asymmetric, moderate bandwidth streams in >>>> both directions." >>>> >>>> However, asymmetric routing in which the outbound and inbound calls take >>>> different routes with different packet loss, delay and jitter is a real >>>> problem. >>>> _______________________________________________ >>>> PLUG mailing list >>>> PLUG@lists.pdxlinux.org >>>> http://lists.pdxlinux.org/mailman/listinfo/plug >>>> >>> >>> >>> >>> -- >>> >>> Chuck Hast -- KP4DJT -- >>> Glass, five thousand years of history and getting better. >>> The only container material that the USDA gives blanket approval on. >>> >>> >>> >> >> >> -- >> >> Chuck Hast -- KP4DJT -- >> Glass, five thousand years of history and getting better. >> The only container material that the USDA gives blanket approval on. >> >> >> > > > -- > > Chuck Hast -- KP4DJT -- > Glass, five thousand years of history and getting better. > The only container material that the USDA gives blanket approval on. > > > -- Chuck Hast -- KP4DJT -- Glass, five thousand years of history and getting better. The only container material that the USDA gives blanket approval on. _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
