Re: [PLUG] O.T.VoIP and Satellite
Here is another I just pulled, it is bad, the downlink has higher jitter too, so it must be loading. Also note the speeds have dropped. Speed test statistics - Download speed: 2655 kbps Upload speed: 743 kbps Download consistency of service: 19 % Upload consistency of service: -- % Download test type: socket Upload test type: POST Maximum TCP delay: 990 ms Average download pause: 12 ms Minimum round trip time to server: 1 ms Average round trip time to server: 1 ms Estimated download bandwidth: 11177 kbps Route concurrency: 4.2097044 Download TCP forced idle: 0 % Maximum route speed: 524280 kbps VoIP test statistics Jitter: you --> server: 173.5 ms Jitter: server --> you: 23.0 ms Packet loss: you --> server: 0.0 % Packet loss: server --> you: 0.0 % Packet discards: 74.2 % Packets out of order: 0.0 % Estimated MOS score: 1.1 General information --- IP address: 72.168.141.72 Local time: Dec 30, 2014 6:16:44 PM Test server: http://voiptest.8x8.com:82/ On Tue, Dec 30, 2014 at 2:56 PM, Mike C. wrote: > > > > Here is another test of the link the jitter has dropped down quite a > > bit still not good enough for VoIP, but better. > > > > > > Speed test statistics > > - > > Download speed: 3864 kbps > > Upload speed: 894 kbps > > Download consistency of service: 55 % > > Upload consistency of service: -- % > > Download test type: socket > > Upload test type: POST > > Maximum TCP delay: 933 ms > > Average download pause: 7 ms > > Minimum round trip time to server: 1 ms > > Average round trip time to server: 1 ms > > Estimated download bandwidth: 13010 kbps > > Route concurrency: 3.3666103 > > Download TCP forced idle: 0 % > > Maximum route speed: 524280 kbps > > > > VoIP test statistics > > > > Jitter: you --> server: 166.8 ms > > Jitter: server --> you: 3.1 ms > > Packet loss: you --> server: 0.0 % > > Packet loss: server --> you: 0.0 % > > Packet discards: 73.0 % > > Packets out of order: 0.0 % > > Estimated MOS score: 1.1 > > > > > > General information > > --- > > IP address: 72.168.141.72 > > Local time: Dec 30, 2014 11:19:37 AM > > Test server: http://voiptest.8x8.com:82/ > > > > Here it is with a 729 codec simulation: > > > > > > Speed test statistics > > - > > Download speed: 3557 kbps > > Upload speed: 896 kbps > > Download consistency of service: 21 % > > Upload consistency of service: -- % > > Download test type: socket > > Upload test type: POST > > Maximum TCP delay: 1242 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: 4777 kbps > > Route concurrency: 1.3429916 > > Download TCP forced idle: 0 % > > Maximum route speed: 524280 kbps > > > > VoIP test statistics > > > > Jitter: you --> server: 106.9 ms > > Jitter: server --> you: 2.9 ms > > Packet loss: you --> server: 0.0 % > > Packet loss: server --> you: 0.0 % > > Packet discards: 65.8 % > > Packets out of order: 0.0 % > > Estimated MOS score: 1.4 > > > > > > General information > > --- > > > > Note that the Jitter has dropped, not sure if that is going from 711 to > 729 > > but I will do more testing. > > > This is good information and a good start. Yes, the jitter did drop and I'd > expect it to for g.729 since it requires less bandwidth. Even though at 90 > Kbps, it's using approx. 10% of the available bandwidth. > > The bigger concern for me though is "packet discards = 65.8%" The VOIP > server will discard packets it receives too late and that it can't use. > This indicates the delay is too high between you and the VOIP server. > > It's too bad that only max and not avg tcp delay is provided. As it is, max > tcp delay of 1242 ms is way out of tolerance for VOIP. > > You could provide this data to HughesNet and see what they can do. Maybe > there is some way they can clean up the sat-link? > > I'd be curious to see test results from say midnight or after. If there's > congestion on the Sat uplink side, that could delay the packets enough for > the VOIP server to discard them. > ___ > 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. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] O.T.VoIP and Satellite
> > Here is another test of the link the jitter has dropped down quite a > bit still not good enough for VoIP, but better. > > > Speed test statistics > - > Download speed: 3864 kbps > Upload speed: 894 kbps > Download consistency of service: 55 % > Upload consistency of service: -- % > Download test type: socket > Upload test type: POST > Maximum TCP delay: 933 ms > Average download pause: 7 ms > Minimum round trip time to server: 1 ms > Average round trip time to server: 1 ms > Estimated download bandwidth: 13010 kbps > Route concurrency: 3.3666103 > Download TCP forced idle: 0 % > Maximum route speed: 524280 kbps > > VoIP test statistics > > Jitter: you --> server: 166.8 ms > Jitter: server --> you: 3.1 ms > Packet loss: you --> server: 0.0 % > Packet loss: server --> you: 0.0 % > Packet discards: 73.0 % > Packets out of order: 0.0 % > Estimated MOS score: 1.1 > > > General information > --- > IP address: 72.168.141.72 > Local time: Dec 30, 2014 11:19:37 AM > Test server: http://voiptest.8x8.com:82/ > > Here it is with a 729 codec simulation: > > > Speed test statistics > - > Download speed: 3557 kbps > Upload speed: 896 kbps > Download consistency of service: 21 % > Upload consistency of service: -- % > Download test type: socket > Upload test type: POST > Maximum TCP delay: 1242 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: 4777 kbps > Route concurrency: 1.3429916 > Download TCP forced idle: 0 % > Maximum route speed: 524280 kbps > > VoIP test statistics > > Jitter: you --> server: 106.9 ms > Jitter: server --> you: 2.9 ms > Packet loss: you --> server: 0.0 % > Packet loss: server --> you: 0.0 % > Packet discards: 65.8 % > Packets out of order: 0.0 % > Estimated MOS score: 1.4 > > > General information > --- > > Note that the Jitter has dropped, not sure if that is going from 711 to 729 > but I will do more testing. This is good information and a good start. Yes, the jitter did drop and I'd expect it to for g.729 since it requires less bandwidth. Even though at 90 Kbps, it's using approx. 10% of the available bandwidth. The bigger concern for me though is "packet discards = 65.8%" The VOIP server will discard packets it receives too late and that it can't use. This indicates the delay is too high between you and the VOIP server. It's too bad that only max and not avg tcp delay is provided. As it is, max tcp delay of 1242 ms is way out of tolerance for VOIP. You could provide this data to HughesNet and see what they can do. Maybe there is some way they can clean up the sat-link? I'd be curious to see test results from say midnight or after. If there's congestion on the Sat uplink side, that could delay the packets enough for the VOIP server to discard them. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] O.T.VoIP and Satellite
Here is another test of the link the jitter has dropped down quite a bit still not good enough for VoIP, but better. Speed test statistics - Download speed: 3864 kbps Upload speed: 894 kbps Download consistency of service: 55 % Upload consistency of service: -- % Download test type: socket Upload test type: POST Maximum TCP delay: 933 ms Average download pause: 7 ms Minimum round trip time to server: 1 ms Average round trip time to server: 1 ms Estimated download bandwidth: 13010 kbps Route concurrency: 3.3666103 Download TCP forced idle: 0 % Maximum route speed: 524280 kbps VoIP test statistics Jitter: you --> server: 166.8 ms Jitter: server --> you: 3.1 ms Packet loss: you --> server: 0.0 % Packet loss: server --> you: 0.0 % Packet discards: 73.0 % Packets out of order: 0.0 % Estimated MOS score: 1.1 General information --- IP address: 72.168.141.72 Local time: Dec 30, 2014 11:19:37 AM Test server: http://voiptest.8x8.com:82/ Here it is with a 729 codec simulation: Speed test statistics - Download speed: 3557 kbps Upload speed: 896 kbps Download consistency of service: 21 % Upload consistency of service: -- % Download test type: socket Upload test type: POST Maximum TCP delay: 1242 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: 4777 kbps Route concurrency: 1.3429916 Download TCP forced idle: 0 % Maximum route speed: 524280 kbps VoIP test statistics Jitter: you --> server: 106.9 ms Jitter: server --> you: 2.9 ms Packet loss: you --> server: 0.0 % Packet loss: server --> you: 0.0 % Packet discards: 65.8 % Packets out of order: 0.0 % Estimated MOS score: 1.4 General information --- Note that the Jitter has dropped, not sure if that is going from 711 to 729 but I will do more testing. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] O.T.VoIP and Satellite
On Tue, Dec 30, 2014 at 8:27 AM, Mike C. wrote: > > > > > That's an interesting twist.. > Well when I last talked to Vonage they told me that the product did not work over satellite links, but that they were working on a solution, I am assuming that they may have pushed it out. There is a little bit of judder on the audio at times but it is not enough to normally cause issues. > > > > > If there's no software menu for either the mCell or the phones then there > won't be a way to change the voip codec. I thought you were using a > cellular smartphone running a VOIP over wifi app. > No, I am not using a VoIP app, just the cellular data flow. My wife does a lot of calling to Costa Rica and we have the plan that lets us do inter- national for $0.01/minute, so it is quite worth it to us, to keep our plan. I also do some international work and everywhere I go is GSM so that means either AT&T or T-Mobile as far as the provider, T-Mobile does not have the coverage that AT&T does so that is where I am. > > > > > 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. > > > > > > I ran into the same problem. Iceweasel browser with the IcedTea web > plugin > will do the trick. Firefox worked just fine, I had to jump through the java security hoops, but once done it runs just fine. Not sure what is with Chrome, but that is a pain not running those java apps. I looked to see if something was turned off but nothing like that. > -- 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
Re: [PLUG] O.T.VoIP and Satellite
> > > 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. > > That's an interesting twist.. > 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. > If there's no software menu for either the mCell or the phones then there won't be a way to change the voip codec. I thought you were using a cellular smartphone running a VOIP over wifi app. > > 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. > As I would expect. > > > > 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. > > > I ran into the same problem. Iceweasel browser with the IcedTea web plugin will do the trick. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] O.T.VoIP and Satellite
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 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 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 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. wrote: >>> >>>> > >>>> > >>>> > Message: 2 >>>> > Date: Mon, 29 Dec 2014 15:31:38 -0800 >>>> > From: Chuck Hast >>>> > Subject: Re: [PLUG] O.T.VoIP and Satellite >>>> > To: "Portland Linux/Unix Group" >>>> > Message-ID: >>>> > >>> > 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 >
Re: [PLUG] O.T.VoIP and Satellite
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 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 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. wrote: >> >>> > >>> > >>> > Message: 2 >>> > Date: Mon, 29 Dec 2014 15:31:38 -0800 >>> > From: Chuck Hast >>> > Subject: Re: [PLUG] O.T.VoIP and Satellite >>> > To: "Portland Linux/Unix Group" >>> > Message-ID: >>> > >> > 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 >>
Re: [PLUG] O.T.VoIP and Satellite
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 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. wrote: > >> > >> > >> > Message: 2 >> > Date: Mon, 29 Dec 2014 15:31:38 -0800 >> > From: Chuck Hast >> > Subject: Re: [PLUG] O.T.VoIP and Satellite >> > To: "Portland Linux/Unix Group" >> > Message-ID: >> > > > 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 pleas
Re: [PLUG] O.T.VoIP and Satellite
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. wrote: > > > > > > Message: 2 > > Date: Mon, 29 Dec 2014 15:31:38 -0800 > > From: Chuck Hast > > Subject: Re: [PLUG] O.T.VoIP and Satellite > > To: "Portland Linux/Unix Group" > > Message-ID: > > > 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 asymmetri
[PLUG] O.T.VoIP and Satellite
> > > Message: 2 > Date: Mon, 29 Dec 2014 15:31:38 -0800 > From: Chuck Hast > Subject: Re: [PLUG] O.T.VoIP and Satellite > To: "Portland Linux/Unix Group" > Message-ID: > 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
Re: [PLUG] O.T.VoIP and Satellite
As to the satellite loading and that could well be what has happened. But you have to shell out the bucks if you want to watch much stream- ing, as they take you to the cleaners. As to the dish moving, I watch the signal level on it and it is about the same as it was when they came out and adjusted it after I first moved in. It will run from 100 units to about 110 units, which I am told is good signal level, indeed I have a RasPI that I have running with both the router load screen on one tab and the modem radio data on a second tab. I watch it while I am setting here doing other things and it seems to set always about 100. On Mon, Dec 29, 2014 at 5:12 PM, Bill Barry wrote: > On Mon, Dec 29, 2014 at 6:04 PM, Keith Lofstrom > wrote: > > On Sun, Dec 28, 2014 at 11:05:21PM -0800, Chuck Hast wrote: > >> Does anyone on the list have any experience with this sort of thing. > >> I am going to see if I can get a hub on between the microcell and > >> the rest of the network and try to sniff where it is talking to, then > see > >> if I > >> do a traceroute to see what manner of delays I see on the link. > > > > 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. > > > > Which points to another possibility. Maybe the dish has moved slightly > out of alignment. Is your signal strength the same as it was before > Dec 15th? > > Bill > ___ > 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. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] O.T.VoIP and Satellite
By way I tried that URL you gave me but my browsers keep on coming up saying that there is a missing plugin, but can not figure out what it is. On Mon, Dec 29, 2014 at 3:31 PM, Chuck Hast wrote: > 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. > > 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. > > I need to get on a wired internet connection and put the uCell on it and > make > sure I do not have something going on with the outbound side of the device. > Inbound audio is so good, and it was working so well prior to the failure > that > I am left wondering. > > On Mon, Dec 29, 2014 at 2:14 PM, Mike C. wrote: > >> > >> > ------ >> > >> > Message: 8 >> > Date: Sun, 28 Dec 2014 23:05:21 -0800 >> > From: Chuck Hast >> > Subject: [PLUG] O.T.VoIP and Satellite >> > To: "Portland Linux/Unix Group" >> > Message-ID: >> > < >> > cadnfbv8dmg_x4oqrl8edtq1mz1z8cmonhqghmuhqnaayfvd...@mail.gmail.com> >> > Content-Type: text/plain; charset=UTF-8 >> > >> > Folks, >> > This is a issue that I have been trying to figure out, and I have been >> > talking to the two parties involved. >> > >> > I am a HughesNet user (that is all we have out in the woods here) >> > I have been using a AT&T microcell on the satellite link since July. >> > >> > When I moved here I was told that the microcell would probably not >> > work, or at best with a lot of latency, well it did quite well, I always >> > told people at the start of a call that I was on a satellite link and >> that >> > there would be some delay, no issues. >> > >> > Then on the 15th of Dec the outbound audio went to trash. I can >> > hear anything on the far end just fine, voice quality is good nothing >> > missing. But the outbound sounds totally distorted if there is any- >> > thing at all. >> > >> > AT&T has been working with me on it, so far they do not see any- >> > thing wrong with the microcell, HughesNet totally washes their >> > hands, the thing that I have observed is that this whole thing took >> > a dump after there was a DHCP assignment change ( Hughesnet >> > seems to change them all the time) the other thing that I had noticed >> > was that prior to that change, applications that tried to map your IP >> > address to your location usualy showed me as being somewhere >> > near Kansas City. Now they think I am near Chicago. >> > >> > Does anyone on the list have any experience with this sort of thing. >> > I am going to see if I can get a hub on between the microcell and >> > the rest of the network and try to sniff where it is talking to, then >> see >> > if I do a traceroute to see what manner of delays I see on the link. >> > >> > In my miserable experience with VoIP, if there was a issue it always >> > seemed like it showed up on both paths, but in this case it is only the >> > outbound, so I am assuming that something is causing a delay there >> > somewhere. >> > >> > The microcell comes on line and appears to be happy, but no joy >> > with the outbound audio. >> > >> > >> > >> > >> Hey Chuck - I'd start by going to this website and testing you VOIP >> connection and hopefully get some useful data. >> http://www.voipqualitytest.com/ >> >> With many years of Network Engineering work experience, I'd say it's >> highly >> unlikely this problem is caused by a DHCP assignment change. Especially if >> the only change in your internet connection is outbound voip call quality. >> >> I also wouldn't put too much into geo-ip mapping ei
Re: [PLUG] O.T.VoIP and Satellite
On Mon, Dec 29, 2014 at 6:04 PM, Keith Lofstrom wrote: > On Sun, Dec 28, 2014 at 11:05:21PM -0800, Chuck Hast wrote: >> Does anyone on the list have any experience with this sort of thing. >> I am going to see if I can get a hub on between the microcell and >> the rest of the network and try to sniff where it is talking to, then see >> if I >> do a traceroute to see what manner of delays I see on the link. > > 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. > Which points to another possibility. Maybe the dish has moved slightly out of alignment. Is your signal strength the same as it was before Dec 15th? Bill ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] O.T.VoIP and Satellite
On Sun, Dec 28, 2014 at 11:05:21PM -0800, Chuck Hast wrote: > Does anyone on the list have any experience with this sort of thing. > I am going to see if I can get a hub on between the microcell and > the rest of the network and try to sniff where it is talking to, then see > if I > do a traceroute to see what manner of delays I see on the link. 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 may also affect other satellite-linked services; long haul trucking, remote gas stations and ATMs. Look for other disgruntled customers. Keith -- Keith Lofstrom kei...@keithl.com ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] O.T.VoIP and Satellite
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. 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. I need to get on a wired internet connection and put the uCell on it and make sure I do not have something going on with the outbound side of the device. Inbound audio is so good, and it was working so well prior to the failure that I am left wondering. On Mon, Dec 29, 2014 at 2:14 PM, Mike C. wrote: > > > > -- > > > > Message: 8 > > Date: Sun, 28 Dec 2014 23:05:21 -0800 > > From: Chuck Hast > > Subject: [PLUG] O.T.VoIP and Satellite > > To: "Portland Linux/Unix Group" > > Message-ID: > > < > > cadnfbv8dmg_x4oqrl8edtq1mz1z8cmonhqghmuhqnaayfvd...@mail.gmail.com> > > Content-Type: text/plain; charset=UTF-8 > > > > Folks, > > This is a issue that I have been trying to figure out, and I have been > > talking to the two parties involved. > > > > I am a HughesNet user (that is all we have out in the woods here) > > I have been using a AT&T microcell on the satellite link since July. > > > > When I moved here I was told that the microcell would probably not > > work, or at best with a lot of latency, well it did quite well, I always > > told people at the start of a call that I was on a satellite link and > that > > there would be some delay, no issues. > > > > Then on the 15th of Dec the outbound audio went to trash. I can > > hear anything on the far end just fine, voice quality is good nothing > > missing. But the outbound sounds totally distorted if there is any- > > thing at all. > > > > AT&T has been working with me on it, so far they do not see any- > > thing wrong with the microcell, HughesNet totally washes their > > hands, the thing that I have observed is that this whole thing took > > a dump after there was a DHCP assignment change ( Hughesnet > > seems to change them all the time) the other thing that I had noticed > > was that prior to that change, applications that tried to map your IP > > address to your location usualy showed me as being somewhere > > near Kansas City. Now they think I am near Chicago. > > > > Does anyone on the list have any experience with this sort of thing. > > I am going to see if I can get a hub on between the microcell and > > the rest of the network and try to sniff where it is talking to, then see > > if I do a traceroute to see what manner of delays I see on the link. > > > > In my miserable experience with VoIP, if there was a issue it always > > seemed like it showed up on both paths, but in this case it is only the > > outbound, so I am assuming that something is causing a delay there > > somewhere. > > > > The microcell comes on line and appears to be happy, but no joy > > with the outbound audio. > > > > > > > > > Hey Chuck - I'd start by going to this website and testing you VOIP > connection and hopefully get some useful data. > http://www.voipqualitytest.com/ > > With many years of Network Engineering work experience, I'd say it's highly > unlikely this problem is caused by a DHCP assignment change. Especially if > the only change in your internet connection is outbound voip call quality. > > I also wouldn't put too much into geo-ip mapping either. ISPs are assigned > blocks of ip addresses from IANA and those assignments are not > geographically based. Geo-ip location takes extra logic, such as Google's > My Location service which requires a browser that supports W3C's Geolcation > API. Google also makes use of it by getting your web browser to provide > information an wifi access points nearby. > > Cheers, > > Mike > ___ > 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. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] O.T.VoIP and Satellite
> > -- > > Message: 8 > Date: Sun, 28 Dec 2014 23:05:21 -0800 > From: Chuck Hast > Subject: [PLUG] O.T.VoIP and Satellite > To: "Portland Linux/Unix Group" > Message-ID: > < > cadnfbv8dmg_x4oqrl8edtq1mz1z8cmonhqghmuhqnaayfvd...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Folks, > This is a issue that I have been trying to figure out, and I have been > talking to the two parties involved. > > I am a HughesNet user (that is all we have out in the woods here) > I have been using a AT&T microcell on the satellite link since July. > > When I moved here I was told that the microcell would probably not > work, or at best with a lot of latency, well it did quite well, I always > told people at the start of a call that I was on a satellite link and that > there would be some delay, no issues. > > Then on the 15th of Dec the outbound audio went to trash. I can > hear anything on the far end just fine, voice quality is good nothing > missing. But the outbound sounds totally distorted if there is any- > thing at all. > > AT&T has been working with me on it, so far they do not see any- > thing wrong with the microcell, HughesNet totally washes their > hands, the thing that I have observed is that this whole thing took > a dump after there was a DHCP assignment change ( Hughesnet > seems to change them all the time) the other thing that I had noticed > was that prior to that change, applications that tried to map your IP > address to your location usualy showed me as being somewhere > near Kansas City. Now they think I am near Chicago. > > Does anyone on the list have any experience with this sort of thing. > I am going to see if I can get a hub on between the microcell and > the rest of the network and try to sniff where it is talking to, then see > if I do a traceroute to see what manner of delays I see on the link. > > In my miserable experience with VoIP, if there was a issue it always > seemed like it showed up on both paths, but in this case it is only the > outbound, so I am assuming that something is causing a delay there > somewhere. > > The microcell comes on line and appears to be happy, but no joy > with the outbound audio. > > > > Hey Chuck - I'd start by going to this website and testing you VOIP connection and hopefully get some useful data. http://www.voipqualitytest.com/ With many years of Network Engineering work experience, I'd say it's highly unlikely this problem is caused by a DHCP assignment change. Especially if the only change in your internet connection is outbound voip call quality. I also wouldn't put too much into geo-ip mapping either. ISPs are assigned blocks of ip addresses from IANA and those assignments are not geographically based. Geo-ip location takes extra logic, such as Google's My Location service which requires a browser that supports W3C's Geolcation API. Google also makes use of it by getting your web browser to provide information an wifi access points nearby. Cheers, Mike ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] O.T.VoIP and Satellite
Folks, This is a issue that I have been trying to figure out, and I have been talking to the two parties involved. I am a HughesNet user (that is all we have out in the woods here) I have been using a AT&T microcell on the satellite link since July. When I moved here I was told that the microcell would probably not work, or at best with a lot of latency, well it did quite well, I always told people at the start of a call that I was on a satellite link and that there would be some delay, no issues. Then on the 15th of Dec the outbound audio went to trash. I can hear anything on the far end just fine, voice quality is good nothing missing. But the outbound sounds totally distorted if there is any- thing at all. AT&T has been working with me on it, so far they do not see any- thing wrong with the microcell, HughesNet totally washes their hands, the thing that I have observed is that this whole thing took a dump after there was a DHCP assignment change ( Hughesnet seems to change them all the time) the other thing that I had noticed was that prior to that change, applications that tried to map your IP address to your location usualy showed me as being somewhere near Kansas City. Now they think I am near Chicago. Does anyone on the list have any experience with this sort of thing. I am going to see if I can get a hub on between the microcell and the rest of the network and try to sniff where it is talking to, then see if I do a traceroute to see what manner of delays I see on the link. In my miserable experience with VoIP, if there was a issue it always seemed like it showed up on both paths, but in this case it is only the outbound, so I am assuming that something is causing a delay there somewhere. The microcell comes on line and appears to be happy, but no joy with the outbound audio. -- 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
