*Hello Darryl:* You are welcome. To advise, we can go back and forth and talk about possibilities etc. and never solve or come to the bottom of the issue.
Configure your QoS/Routers to give equal priority to your laptop/desktop and do the Speed Test, Latency Test, and VoIP test through the links I've provided to you. *Do at speed and VoIP quality check on the following: 1) http://myvoipspeed.visualware.com/servers/yul.html 2) http://myspeed.visualware.com/servers/yul.html and share with us your stats. >From the summary section, we would like to know your: a) Connection Jiitter in ms b) Packet Loss c) MOS * Please share the above stats/numbers with us. It will help us all understand, and will help us to help you. But from what you have just shared with us - it obviously appears you have congestion somewhere. Are you 100% sure the congestion is not within your own network or QoS improperly configured? Bell has upgraded their infrastructure in many places to support their fiber. I highly doubt that your uplink from dslam to provider network is fully overbooked in your area (though a remote possibility). Based on extensive experience over 5+ years we have **never** come to a situation where a problem could not be resolved. I've had locations where bell dropped a fresh new copper pair and problems resolved. We've had clients where they simply changed routers and/or modem and problems resolved. At extreme cases where client insisted to stick to Bell and the measures taken did not rectify the problem, they converted to Rogers high speed and has not regretted their decision. Life's too short! Don't waste it behind packet tests and analysis. Simple common sense tests and alternatives solved over 99% issues our customers have faced. *Good luck! Reza.* -- Toronto based VoIP / Asterisk Trainer, I.T. Consultant and Hosted PBX Solutions Provider. +1-647-476-2067. http://www.linkedin.com/in/seminar On Mon, Apr 12, 2010 at 3:15 PM, Darryl Moore <[email protected]> wrote: > Thanks patrick, > > DSLAM may well be layer 2 devices, but I've read in many places how many > of them still support QoS > > > http://www.ciscosistemas.com/en/US/tech/tk175/tk176/technologies_tech_note09186a0080128caf.shtml > > Just not the ones Bell uses. :-( > > > Yes, I realize that ISPs are best effort and to get anything with > service guarantees requires prohibitively expensive service level > agreements. > > That is sort of why I am asking about VOIP providers in the first place. > There being little I can depend on with my ISP, can I make up for it in > any way by my choice in VOIP provider? Knowing how their buffers work > and my ability to adjust them if necessary I think would be fairly > central to that. > > Another thought I had was what if I had MLPPP service? Could I arrange > to have my second DSL on a separate DSLAM? Would there be any way to > explicitly control which DSL line is used to send data, and to identify > which DSL line would get my packets out the soonest at any given moment. > > > On Mon, 2010-04-12 at 14:42 -0400, Patrick Song wrote: > > Hi Darry > > > > I assume the dsl service you have is in the residential area based on > > what you said "the quality gets worse in the evening". is this > > correct? it is because the traffic flow pattern for business > > environment is high during the day and is less at night. > > > > one of the reasons you have worse quality is that the uplink from > > dslam to provider network is fully overbooked in your area. > > > > also, the TOS value you set in the IP packets is ignored by the dslam > > because dslam is a layer 2 device and it looks at MAC address only > > > > by the way, Internet is best effort service for most service providers > > and no guaranteed speed, delay and jitter (NO SLA) > > > > thank you > > > > On Mon, Apr 12, 2010 at 2:17 PM, Philip Mullis <[email protected]> > > wrote: > > Darryl, might say Unmonitored because your missing qualify=yes > > in that providers sip profile. > > > > Phil > > > > > > > > > > Darryl Moore wrote: > > Thanks Reza. > > > > That is interesting. > > > > One of the VOIP providers yields: > > Status : OK (37 ms) > > > > The other one says: > > Status : Unmonitored > > > > I wonder why one says unmonitored. > > > > As I said, it doesn't get noisy until the evening. I > > expect my upstream > > data is bottle necked at the DSLAM, I use the QoS bits > > in the IP packet, > > but I'd be very surprised if Ma Bell actually looks at > > these. Especially > > at the DSLAM. > > > > I built a little Perl script to monitor the line which > > you can see at > > http://moores.ca/qosplot.pl. This generally tells my > > if the latency is > > due to the VOIP provider or the DSL. What I can't > > reliably figure out > > from this, is if the latency is on the ATM network or > > the ISP network, > > but I would certainly say it does not appear to be on > > the VOIP. > > > > Note the data is collected by a different machine on > > my network from the > > asterisk server. The asterisk server always has a > > higher priority, so > > when my network gets busy (as it did this morning) > > VOIP generally does > > not suffer, but my monitor will. I need to move it to > > run on the > > asterisk box itself to be more accurate. > > > > cheers, > > darryl > > > > > > On Mon, 2010-04-12 at 13:56 -0400, Reza - Asterisk > > Consultant wrote: > > > > *Darryl:* > > > > Please do a "sip show peer > > _your_trunk_provider" and let us know what > > your > > latency is. 200ms is nothing in terms of a > > delay/lag between two human > > voice conversations. I have people > > connecting to our platform from > > overseas at 350ms+ latency **without** any > > jitter buffer enabled and quality > > of connection is excellent. Their 350ms+ > > though seems to be huge (in > > Toronto standards) - the connection we have > > between here and overseas office > > is strong and stable (without congestion). > > > > I am happy to give you a test account and DID > > on our server to help you > > identify whether its a problem at your side, > > or whether the problem > > magically goes away when you are connected > > with us. > > > > " *Jitter is generally caused by congestion in > > the IP network. The > > congestion can occur either at the router > > interfaces or in a provider or > > carrier network if the circuit has not been > > provisioned correctly. *" -- > > so the trick here is to determine where the > > congestion is taking place. > > > > Do at speed and VoIP quality check on the > > following: > > 1) > > > http://myvoipspeed.visualware.com/servers/yul.html > > 2) > > http://myspeed.visualware.com/servers/yul.html > > and share with us your stats. > > > > >From the summary section, we would like to > > know your: > > a) Connection Jiitter in ms > > b) Packet Loss > > c) MOS > > > > We would also like to know your > > upload/download speed (of course). Along > > with this, please copy and paste (except your > > password & userid) - your > > entry you made in the sip.conf file in order > > to connect to your provider. > > Kindly also share with us your DSL or Cable > > internet provider name. > > > > The answers to the above will help determine > > where the fault is. Either > > way - these issues are 100% solvable, assuming > > your carrier or ISP is > > cooperative **if** we determine the problem is > > at their end. > > > > *Best, > > Reza.* > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > -- > > Thank you > > > > Patrick Song > > Thinking globally, Networking locally > > CCVP, CCNP, M.Eng in Telecommunications > > Cell:1-647-868-2950 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
