Our users are experiencing some unacceptable delay when trying to have a conversation. The delay is so noticeable that they keep stepping on each others words and resort to calling the customers via cell phone. Here is the setup SDSL Connection (PPPoA) Speedtouch 610 SDSL Modem 3Com 2224PWR Plus Switch (phones on separate VLAN) 8 Cisco 796 Phones All connecting to a remote Asterisk Server. We found that the MTU for the SDSL modem was set to 1500 and I have since changed it to 1458 which is the ISP's recommended setting. Can this MTU difference cause the delay my users are experiencing? All the voice packets would become fragmented so it sounds logical. And simply changing the MTU on the modem, will that fix it, I can't find a way to change it at the Cisco phone level. Thanks, Geoff Manning
> Our users are experiencing some unacceptable delay when trying to have a > conversation. The delay is so noticeable that they keep stepping on each > others words and resort to calling the customers via cell phone. > > Here is the setup > > SDSL Connection (PPPoA) > Speedtouch 610 SDSL Modem > 3Com 2224PWR Plus Switch (phones on separate VLAN) > 8 Cisco 796 Phones > > All connecting to a remote Asterisk Server. > > We found that the MTU for the SDSL modem was set to 1500 and I have since > changed it to 1458 which is the ISP's recommended setting. > > Can this MTU difference cause the delay my users are experiencing? All the > voice packets would become fragmented so it sounds logical.Absolutely not. The MTU is the Maximum Transmission Unit, and sip packets are about 214 bytes in size (including all pkt headers). Way smaller then the MTU.> And simply changing the MTU on the modem, will that fix it, I can't find a > way to change it at the Cisco phone level.There will be a delay associated with any sip-to-sip call, but it should not be all that noticable unless both the talker and listener are in the same room. Are you sure this is a delay problem, or might it be a half-duplex problem? If any of the hardware mentioned is operating in half-duplex-only mode, it is entirely possible to create what might be construed as a delay.
How far (physically) is the Asterisk server location from the location of the phones? Have you tried pinging the Asterisk server from the network to which the phones are connected? As a rule of thumb, If the two sites are within 2500 miles of each other and the network connection between them is working properly, the round trip time for a 64 byte ping should be less than 100 ms, the round trip time should not vary from one ping to another by more than 2-5 ms (typical), and there should be virtually no dropped packets (well under 0.1%). If your network does not meet these standards, then it may well be the cause of your problems. In that case, if you e-mail me a traceroute from the phone location to the Asterisk location as well as the output of a ping from the phone location to the Asterisk location (preferably including at least 100 repetitions), I will take a look at it and let you know what I think. If your network seems fine by the above standards, then you/we will have to pursue other Asterisk/SIP/RTP-related avenues of troubleshooting. Regards, Rusty On 1/9/06, Geoff Manning <gmanning@zoom.com> wrote:> > Our users are experiencing some unacceptable delay when trying to have a > conversation. The delay is so noticeable that they keep stepping on each > others words and resort to calling the customers via cell phone. > > Here is the setup > > SDSL Connection (PPPoA) > Speedtouch 610 SDSL Modem > 3Com 2224PWR Plus Switch (phones on separate VLAN) > 8 Cisco 796 Phones > > All connecting to a remote Asterisk Server. > > We found that the MTU for the SDSL modem was set to 1500 and I have since > changed it to 1458 which is the ISP's recommended setting. > > Can this MTU difference cause the delay my users are experiencing? All the > voice packets would become fragmented so it sounds logical. > > And simply changing the MTU on the modem, will that fix it, I can't find a > way to change it at the Cisco phone level. > > Thanks, > Geoff Manning > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060109/c1056fb1/attachment.htm
Geoff Manning wrote:> Our users are experiencing some unacceptable delay when trying to have a > conversation. The delay is so noticeable that they keep stepping on each > others words and resort to calling the customers via cell phone.We've had some pretty bad delay in the past when customers have been using file sharing (p2p) and saturating bandwidth etc. Check if they are, and if so, get them to change their settings to not use 500% of their connection (yes some do this). -- Cheers, Matt Riddell _______________________________________________ http://www.sineapps.com/news.php (Daily Asterisk News - html) http://freevoip.gedameurope.com (Free Asterisk Voip Community) http://www.sineapps.com/rssfeed.php (Daily Asterisk News - rss)
Rich Adamson wrote:> There will be a delay associated with any sip-to-sip call, but it > should not be all that noticable unless both the talker and listener > are in the same room. > > Are you sure this is a delay problem, or might it be a half-duplex > problem? > > If any of the hardware mentioned is operating in half-duplex-only > mode, > it is entirely possible to create what might be construed as a delay. >I will look at all the equipment to see if anything is in half duplex mode. The equipment is remote from me so I will need to poke around a little. A cursory glance indicates this is not the case, but I'll make sure. Thanks, Geoff
Matt Riddell (IT) wrote:> Geoff Manning wrote: >> Our users are experiencing some unacceptable delay when trying to >> have a conversation. The delay is so noticeable that they keep >> stepping on each others words and resort to calling the customers >> via cell phone. > > We've had some pretty bad delay in the past when customers have been > using file sharing (p2p) and saturating bandwidth etc. > > Check if they are, and if so, get them to change their settings to not > use 500% of their connection (yes some do this).The only devices on this VLAN are the 8 Cisco 7960 phones. Thanks, Geoff
Rich Adamson wrote:> Be carefull with vlan assumptions. If two or more vlans exist across > multiple switches, how do you know if another vlan hasn't consumed all > available resources leaving little (or none) for your phone vlan? > > Hint: look for "discarded packets in or out" on the physical ports of > those switches in the path. >There are two VLANS: 1st VLAN has port 1 going to SDSL modem, ports 2-9 are connected to the phones 2nd VLAN has port 10 going to PIX (then to ADSL modem) and the rest of the ports to the desktop. Unfortunately the reporting and statistics on the #com switch 2226 PWR plus is somewhat limited. I can't find any discarded packets. I can plug one of the phones directly into the back of the SDSL modem to see if the problem goes away for that one user. That would take the switch out of the equation. Thanks, Geoff
Rusty Dekema wrote:> How far (physically) is the Asterisk server location from the > location of the phones? Have you tried pinging the Asterisk server > from the network to which the phones are connected? > > As a rule of thumb, If the two sites are within 2500 miles of each > other and the network connection between them is working properly, > the round trip time for a 64 byte ping should be less than 100 ms, > the round trip time should not vary from one ping to another by more > than 2-5 ms (typical), and there should be virtually no dropped > packets (well under 0.1%).The two locations are in Greater London Here is a traceroute from the Modem to the Asterisk Server (64byte packets) ttl=1 82.152.192.1 10 ms |<10 ms |<10 ms ttl=2 81.5.191.177 |<10 ms |<10 ms |<10 ms ttl=3 212.187.151.157 |<10 ms |<10 ms |<10 ms ttl=4 212.113.3.25 |<10 ms 40 ms |<10 ms ttl=5 212.187.131.161 |<10 ms |<10 ms |<10 ms ttl=6 212.187.128.46 10 ms ttl=6 4.68.128.110 |<10 ms ttl=6 212.187.128.46 10 ms ttl=7 212.187.129.165 |<10 ms ttl=7 212.187.129.197 |<10 ms ttl=7 212.187.129.181 |<10 ms ttl=8 195.50.117.134 10 ms |<10 ms |<10 ms ttl=9 69.64.163.17 |<10 ms |<10 ms |<10 ms Here is the ping output (64byte packets): Where useconds = ms * 1000 (I think) 72 bytes from 69.64.163.17: icmp_seq=0 time=9249 us 72 bytes from 69.64.163.17: icmp_seq=1 time=8772 us 72 bytes from 69.64.163.17: icmp_seq=2 time=8102 us 72 bytes from 69.64.163.17: icmp_seq=3 time=8214 us 72 bytes from 69.64.163.17: icmp_seq=4 time=8143 us 72 bytes from 69.64.163.17: icmp_seq=5 time=8090 us 72 bytes from 69.64.163.17: icmp_seq=6 time=8241 us 72 bytes from 69.64.163.17: icmp_seq=7 time=8187 us 72 bytes from 69.64.163.17: icmp_seq=8 time=8730 us 72 bytes from 69.64.163.17: icmp_seq=9 time=8018 us 72 bytes from 69.64.163.17: icmp_seq=10 time=8559 us 72 bytes from 69.64.163.17: icmp_seq=11 time=7906 us 72 bytes from 69.64.163.17: icmp_seq=12 time=8036 us 72 bytes from 69.64.163.17: icmp_seq=13 time=9195 us 72 bytes from 69.64.163.17: icmp_seq=14 time=9145 us 72 bytes from 69.64.163.17: icmp_seq=15 time=10200 us 72 bytes from 69.64.163.17: icmp_seq=16 time=7975 us 72 bytes from 69.64.163.17: icmp_seq=17 time=8138 us 72 bytes from 69.64.163.17: icmp_seq=18 time=8357 us 72 bytes from 69.64.163.17: icmp_seq=19 time=8733 us 72 bytes from 69.64.163.17: icmp_seq=20 time=8445 us 72 bytes from 69.64.163.17: icmp_seq=21 time=9225 us 72 bytes from 69.64.163.17: icmp_seq=22 time=8879 us 72 bytes from 69.64.163.17: icmp_seq=23 time=9121 us 72 bytes from 69.64.163.17: icmp_seq=24 time=9292 us 72 bytes from 69.64.163.17: icmp_seq=25 time=8195 us 72 bytes from 69.64.163.17: icmp_seq=26 time=8545 us 72 bytes from 69.64.163.17: icmp_seq=27 time=8403 us 72 bytes from 69.64.163.17: icmp_seq=28 time=8591 us 72 bytes from 69.64.163.17: icmp_seq=29 time=9554 us 72 bytes from 69.64.163.17: icmp_seq=30 time=7852 us 72 bytes from 69.64.163.17: icmp_seq=31 time=8398 us 72 bytes from 69.64.163.17: icmp_seq=32 time=10150 us 72 bytes from 69.64.163.17: icmp_seq=33 time=7954 us 72 bytes from 69.64.163.17: icmp_seq=34 time=8309 us 72 bytes from 69.64.163.17: icmp_seq=35 time=8888 us 72 bytes from 69.64.163.17: icmp_seq=36 time=8208 us 72 bytes from 69.64.163.17: icmp_seq=37 time=9043 us 72 bytes from 69.64.163.17: icmp_seq=38 time=10129 us 72 bytes from 69.64.163.17: icmp_seq=39 time=8095 us 72 bytes from 69.64.163.17: icmp_seq=40 time=9500 us 72 bytes from 69.64.163.17: icmp_seq=41 time=8626 us 72 bytes from 69.64.163.17: icmp_seq=42 time=8975 us 72 bytes from 69.64.163.17: icmp_seq=43 time=8883 us 72 bytes from 69.64.163.17: icmp_seq=44 time=9045 us 72 bytes from 69.64.163.17: icmp_seq=45 time=8145 us 72 bytes from 69.64.163.17: icmp_seq=46 time=8707 us 72 bytes from 69.64.163.17: icmp_seq=47 time=8186 us 72 bytes from 69.64.163.17: icmp_seq=48 time=11648 us 72 bytes from 69.64.163.17: icmp_seq=49 time=11705 us 72 bytes from 69.64.163.17: icmp_seq=50 time=8200 us 72 bytes from 69.64.163.17: icmp_seq=51 time=8763 us 72 bytes from 69.64.163.17: icmp_seq=52 time=11047 us 72 bytes from 69.64.163.17: icmp_seq=53 time=8319 us 72 bytes from 69.64.163.17: icmp_seq=54 time=8228 us 72 bytes from 69.64.163.17: icmp_seq=55 time=8173 us 72 bytes from 69.64.163.17: icmp_seq=56 time=8960 us 72 bytes from 69.64.163.17: icmp_seq=57 time=7969 us 72 bytes from 69.64.163.17: icmp_seq=58 time=8594 us 72 bytes from 69.64.163.17: icmp_seq=59 time=8117 us 72 bytes from 69.64.163.17: icmp_seq=60 time=8897 us 72 bytes from 69.64.163.17: icmp_seq=61 time=8242 us 72 bytes from 69.64.163.17: icmp_seq=62 time=8224 us 72 bytes from 69.64.163.17: icmp_seq=63 time=8361 us 72 bytes from 69.64.163.17: icmp_seq=64 time=8515 us 72 bytes from 69.64.163.17: icmp_seq=65 time=8251 us 72 bytes from 69.64.163.17: icmp_seq=66 time=7826 us 72 bytes from 69.64.163.17: icmp_seq=67 time=8936 us 72 bytes from 69.64.163.17: icmp_seq=68 time=8249 us 72 bytes from 69.64.163.17: icmp_seq=69 time=8821 us 72 bytes from 69.64.163.17: icmp_seq=70 time=8134 us 72 bytes from 69.64.163.17: icmp_seq=71 time=8781 us 72 bytes from 69.64.163.17: icmp_seq=72 time=8299 us 72 bytes from 69.64.163.17: icmp_seq=73 time=8028 us 72 bytes from 69.64.163.17: icmp_seq=74 time=10186 us 72 bytes from 69.64.163.17: icmp_seq=75 time=8137 us 72 bytes from 69.64.163.17: icmp_seq=76 time=9527 us 72 bytes from 69.64.163.17: icmp_seq=77 time=8446 us 72 bytes from 69.64.163.17: icmp_seq=78 time=8379 us 72 bytes from 69.64.163.17: icmp_seq=79 time=9164 us 72 bytes from 69.64.163.17: icmp_seq=80 time=8285 us 72 bytes from 69.64.163.17: icmp_seq=81 time=14911 us 72 bytes from 69.64.163.17: icmp_seq=82 time=9286 us 72 bytes from 69.64.163.17: icmp_seq=83 time=8393 us 72 bytes from 69.64.163.17: icmp_seq=84 time=9171 us 72 bytes from 69.64.163.17: icmp_seq=85 time=8279 us 72 bytes from 69.64.163.17: icmp_seq=86 time=7796 us 72 bytes from 69.64.163.17: icmp_seq=87 time=8519 us 72 bytes from 69.64.163.17: icmp_seq=88 time=9483 us 72 bytes from 69.64.163.17: icmp_seq=89 time=8608 us 72 bytes from 69.64.163.17: icmp_seq=90 time=7914 us 72 bytes from 69.64.163.17: icmp_seq=91 time=10575 us 72 bytes from 69.64.163.17: icmp_seq=92 time=7842 us 72 bytes from 69.64.163.17: icmp_seq=93 time=8591 us 72 bytes from 69.64.163.17: icmp_seq=94 time=8321 us 72 bytes from 69.64.163.17: icmp_seq=95 time=8269 us 72 bytes from 69.64.163.17: icmp_seq=96 time=8012 us 72 bytes from 69.64.163.17: icmp_seq=97 time=12541 us 72 bytes from 69.64.163.17: icmp_seq=98 time=10270 us 72 bytes from 69.64.163.17: icmp_seq=99 time=12235 us 72 bytes from 69.64.163.17: icmp_seq=100 time=9665 us 72 bytes from 69.64.163.17: icmp_seq=101 time=8358 us 72 bytes from 69.64.163.17: icmp_seq=102 time=9679 us 72 bytes from 69.64.163.17: icmp_seq=103 time=8185 us 72 bytes from 69.64.163.17: icmp_seq=104 time=8533 us 72 bytes from 69.64.163.17: icmp_seq=105 time=8082 us 72 bytes from 69.64.163.17: icmp_seq=106 time=8409 us 72 bytes from 69.64.163.17: icmp_seq=107 time=8556 us 72 bytes from 69.64.163.17: icmp_seq=108 time=9487 us 72 bytes from 69.64.163.17: icmp_seq=109 time=8231 us 72 bytes from 69.64.163.17: icmp_seq=110 time=7994 us 72 bytes from 69.64.163.17: icmp_seq=111 time=8508 us 72 bytes from 69.64.163.17: icmp_seq=112 time=8295 us 72 bytes from 69.64.163.17: icmp_seq=113 time=8178 us 72 bytes from 69.64.163.17: icmp_seq=114 time=9436 us 72 bytes from 69.64.163.17: icmp_seq=115 time=8941 us 72 bytes from 69.64.163.17: icmp_seq=116 time=8452 us 72 bytes from 69.64.163.17: icmp_seq=117 time=8592 us 72 bytes from 69.64.163.17: icmp_seq=118 time=8321 us 72 bytes from 69.64.163.17: icmp_seq=119 time=9515 us 72 bytes from 69.64.163.17: icmp_seq=120 time=7990 us 72 bytes from 69.64.163.17: icmp_seq=121 time=9213 us 72 bytes from 69.64.163.17: icmp_seq=122 time=7914 us 72 bytes from 69.64.163.17: icmp_seq=123 time=8258 us 72 bytes from 69.64.163.17: icmp_seq=124 time=7998 us 72 bytes from 69.64.163.17: icmp_seq=125 time=8165 us 72 bytes from 69.64.163.17: icmp_seq=126 time=7912 us 72 bytes from 69.64.163.17: icmp_seq=127 time=8236 us 72 bytes from 69.64.163.17: icmp_seq=128 time=8380 us 72 bytes from 69.64.163.17: icmp_seq=129 time=9493 us 72 bytes from 69.64.163.17: icmp_seq=130 time=8316 us 72 bytes from 69.64.163.17: icmp_seq=131 time=8048 us 72 bytes from 69.64.163.17: icmp_seq=132 time=8013 us 72 bytes from 69.64.163.17: icmp_seq=133 time=8983 us 72 bytes from 69.64.163.17: icmp_seq=134 time=8143 us 72 bytes from 69.64.163.17: icmp_seq=135 time=8507 us 72 bytes from 69.64.163.17: icmp_seq=136 time=8240 us 72 bytes from 69.64.163.17: icmp_seq=137 time=9031 us 72 bytes from 69.64.163.17: icmp_seq=138 time=8343 us 72 bytes from 69.64.163.17: icmp_seq=139 time=8335 us 72 bytes from 69.64.163.17: icmp_seq=140 time=8443 us 72 bytes from 69.64.163.17: icmp_seq=141 time=8080 us 72 bytes from 69.64.163.17: icmp_seq=142 time=8242 us 72 bytes from 69.64.163.17: icmp_seq=143 time=8156 us 72 bytes from 69.64.163.17: icmp_seq=144 time=8010 us 72 bytes from 69.64.163.17: icmp_seq=145 time=8170 us 72 bytes from 69.64.163.17: icmp_seq=146 time=7856 us 72 bytes from 69.64.163.17: icmp_seq=147 time=7995 us 72 bytes from 69.64.163.17: icmp_seq=148 time=8520 us 72 bytes from 69.64.163.17: icmp_seq=149 time=8969 us 72 bytes from 69.64.163.17: icmp_seq=150 time=7870 us 72 bytes from 69.64.163.17: icmp_seq=151 time=8089 us 72 bytes from 69.64.163.17: icmp_seq=152 time=8186 us 72 bytes from 69.64.163.17: icmp_seq=153 time=8627 us 72 bytes from 69.64.163.17: icmp_seq=154 time=8334 us 72 bytes from 69.64.163.17: icmp_seq=155 time=8433 us 72 bytes from 69.64.163.17: icmp_seq=156 time=8007 us 72 bytes from 69.64.163.17: icmp_seq=157 time=8155 us 72 bytes from 69.64.163.17: icmp_seq=158 time=8465 us 72 bytes from 69.64.163.17: icmp_seq=159 time=8249 us 72 bytes from 69.64.163.17: icmp_seq=160 time=7986 us 72 bytes from 69.64.163.17: icmp_seq=161 time=8538 us 72 bytes from 69.64.163.17: icmp_seq=162 time=8276 us 72 bytes from 69.64.163.17: icmp_seq=163 time=9040 us 72 bytes from 69.64.163.17: icmp_seq=164 time=8161 us 72 bytes from 69.64.163.17: icmp_seq=165 time=9332 us 72 bytes from 69.64.163.17: icmp_seq=166 time=8056 us 72 bytes from 69.64.163.17: icmp_seq=167 time=8393 us 72 bytes from 69.64.163.17: icmp_seq=168 time=8592 us 72 bytes from 69.64.163.17: icmp_seq=169 time=8766 us 72 bytes from 69.64.163.17: icmp_seq=170 time=8478 us 72 bytes from 69.64.163.17: icmp_seq=171 time=9046 us 72 bytes from 69.64.163.17: icmp_seq=172 time=8163 us 72 bytes from 69.64.163.17: icmp_seq=173 time=7953 us 72 bytes from 69.64.163.17: icmp_seq=174 time=8053 us 72 bytes from 69.64.163.17: icmp_seq=175 time=8448 us 72 bytes from 69.64.163.17: icmp_seq=176 time=8218 us 72 bytes from 69.64.163.17: icmp_seq=177 time=8616 us 72 bytes from 69.64.163.17: icmp_seq=178 time=8048 us 72 bytes from 69.64.163.17: icmp_seq=179 time=7792 us 72 bytes from 69.64.163.17: icmp_seq=180 time=8137 us 72 bytes from 69.64.163.17: icmp_seq=181 time=7875 us 72 bytes from 69.64.163.17: icmp_seq=182 time=9696 us 72 bytes from 69.64.163.17: icmp_seq=183 time=7990 us 72 bytes from 69.64.163.17: icmp_seq=184 time=8138 us 72 bytes from 69.64.163.17: icmp_seq=185 time=7878 us 72 bytes from 69.64.163.17: icmp_seq=186 time=8228 us 72 bytes from 69.64.163.17: icmp_seq=187 time=7766 us 72 bytes from 69.64.163.17: icmp_seq=188 time=8699 us 72 bytes from 69.64.163.17: icmp_seq=189 time=8258 us 72 bytes from 69.64.163.17: icmp_seq=190 time=9333 us 72 bytes from 69.64.163.17: icmp_seq=191 time=10335 us 72 bytes from 69.64.163.17: icmp_seq=192 time=7852 us 72 bytes from 69.64.163.17: icmp_seq=193 time=7792 us 72 bytes from 69.64.163.17: icmp_seq=194 time=8536 us 72 bytes from 69.64.163.17: icmp_seq=195 time=7866 us 72 bytes from 69.64.163.17: icmp_seq=196 time=8633 us 72 bytes from 69.64.163.17: icmp_seq=197 time=8528 us 72 bytes from 69.64.163.17: icmp_seq=198 time=8476 us 72 bytes from 69.64.163.17: icmp_seq=199 time=8426 us 72 bytes from 69.64.163.17: icmp_seq=200 time=7953 us 72 bytes from 69.64.163.17: icmp_seq=201 time=8531 us 72 bytes from 69.64.163.17: icmp_seq=202 time=8294 us 72 bytes from 69.64.163.17: icmp_seq=203 time=7887 us 72 bytes from 69.64.163.17: icmp_seq=204 time=8212 us 72 bytes from 69.64.163.17: icmp_seq=205 time=9620 us 72 bytes from 69.64.163.17: icmp_seq=206 time=8036 us 72 bytes from 69.64.163.17: icmp_seq=207 time=7990 us 72 bytes from 69.64.163.17: icmp_seq=208 time=8532 us 72 bytes from 69.64.163.17: icmp_seq=209 time=8716 us 72 bytes from 69.64.163.17: icmp_seq=210 time=8422 us 72 bytes from 69.64.163.17: icmp_seq=211 time=9156 us 72 bytes from 69.64.163.17: icmp_seq=212 time=8264 us 72 bytes from 69.64.163.17: icmp_seq=213 time=7754 us 72 bytes from 69.64.163.17: icmp_seq=214 time=8078 us 72 bytes from 69.64.163.17: icmp_seq=215 time=8449 us 72 bytes from 69.64.163.17: icmp_seq=216 time=8470 us 72 bytes from 69.64.163.17: icmp_seq=217 time=8463 us 72 bytes from 69.64.163.17: icmp_seq=218 time=8560 us 72 bytes from 69.64.163.17: icmp_seq=219 time=9057 us 72 bytes from 69.64.163.17: icmp_seq=220 time=12960 us 72 bytes from 69.64.163.17: icmp_seq=221 time=8532 us 72 bytes from 69.64.163.17: icmp_seq=222 time=8411 us 72 bytes from 69.64.163.17: icmp_seq=223 time=7938 us 72 bytes from 69.64.163.17: icmp_seq=224 time=8320 us 72 bytes from 69.64.163.17: icmp_seq=225 time=8039 us 72 bytes from 69.64.163.17: icmp_seq=226 time=8192 us 72 bytes from 69.64.163.17: icmp_seq=227 time=8766 us 72 bytes from 69.64.163.17: icmp_seq=228 time=8277 us 72 bytes from 69.64.163.17: icmp_seq=229 time=8223 us 72 bytes from 69.64.163.17: icmp_seq=230 time=8064 us 72 bytes from 69.64.163.17: icmp_seq=231 time=8338 us 72 bytes from 69.64.163.17: icmp_seq=232 time=9572 us 72 bytes from 69.64.163.17: icmp_seq=233 time=9077 us 72 bytes from 69.64.163.17: icmp_seq=234 time=8361 us 72 bytes from 69.64.163.17: icmp_seq=235 time=8066 us 72 bytes from 69.64.163.17: icmp_seq=236 time=9243 us 72 bytes from 69.64.163.17: icmp_seq=237 time=8156 us 72 bytes from 69.64.163.17: icmp_seq=238 time=8294 us 72 bytes from 69.64.163.17: icmp_seq=239 time=8681 us 72 bytes from 69.64.163.17: icmp_seq=240 time=8191 us 72 bytes from 69.64.163.17: icmp_seq=241 time=8332 us 72 bytes from 69.64.163.17: icmp_seq=242 time=8083 us 72 bytes from 69.64.163.17: icmp_seq=243 time=8227 us 72 bytes from 69.64.163.17: icmp_seq=244 time=8318 us 72 bytes from 69.64.163.17: icmp_seq=245 time=8277 us 72 bytes from 69.64.163.17: icmp_seq=246 time=8201 us 72 bytes from 69.64.163.17: icmp_seq=247 time=11682 us 72 bytes from 69.64.163.17: icmp_seq=248 time=8303 us 72 bytes from 69.64.163.17: icmp_seq=249 time=7857 us 72 bytes from 69.64.163.17: icmp_seq=250 time=8003 us 72 bytes from 69.64.163.17: icmp_seq=251 time=8139 us 72 bytes from 69.64.163.17: icmp_seq=252 time=8511 us 72 bytes from 69.64.163.17: icmp_seq=253 time=8641 us 72 bytes from 69.64.163.17: icmp_seq=254 time=8329 us 72 bytes from 69.64.163.17: icmp_seq=255 time=8277 us 72 bytes from 69.64.163.17: icmp_seq=256 time=8218 us 72 bytes from 69.64.163.17: icmp_seq=257 time=8151 us 72 bytes from 69.64.163.17: icmp_seq=258 time=8510 us 72 bytes from 69.64.163.17: icmp_seq=259 time=7839 us 72 bytes from 69.64.163.17: icmp_seq=260 time=8975 us 72 bytes from 69.64.163.17: icmp_seq=261 time=8404 us 72 bytes from 69.64.163.17: icmp_seq=262 time=8905 us 72 bytes from 69.64.163.17: icmp_seq=263 time=8785 us 72 bytes from 69.64.163.17: icmp_seq=264 time=7838 us 72 bytes from 69.64.163.17: icmp_seq=265 time=8600 us 72 bytes from 69.64.163.17: icmp_seq=266 time=7924 us 72 bytes from 69.64.163.17: icmp_seq=267 time=8342 us 72 bytes from 69.64.163.17: icmp_seq=268 time=9071 us 72 bytes from 69.64.163.17: icmp_seq=269 time=8187 us 72 bytes from 69.64.163.17: icmp_seq=270 time=8319 us 72 bytes from 69.64.163.17: icmp_seq=271 time=8268 us 72 bytes from 69.64.163.17: icmp_seq=272 time=8206 us 72 bytes from 69.64.163.17: icmp_seq=273 time=8585 us 72 bytes from 69.64.163.17: icmp_seq=274 time=8124 us 72 bytes from 69.64.163.17: icmp_seq=275 time=8266 us 72 bytes from 69.64.163.17: icmp_seq=276 time=8608 us 72 bytes from 69.64.163.17: icmp_seq=277 time=8981 us 72 bytes from 69.64.163.17: icmp_seq=278 time=8597 us 72 bytes from 69.64.163.17: icmp_seq=279 time=10618 us 72 bytes from 69.64.163.17: icmp_seq=280 time=8504 us 72 bytes from 69.64.163.17: icmp_seq=281 time=7992 us 72 bytes from 69.64.163.17: icmp_seq=282 time=7957 us 72 bytes from 69.64.163.17: icmp_seq=283 time=8360 us 72 bytes from 69.64.163.17: icmp_seq=284 time=8112 us 72 bytes from 69.64.163.17: icmp_seq=285 time=8840 us 72 bytes from 69.64.163.17: icmp_seq=286 time=7957 us 72 bytes from 69.64.163.17: icmp_seq=287 time=8496 us 72 bytes from 69.64.163.17: icmp_seq=288 time=9092 us 72 bytes from 69.64.163.17: icmp_seq=289 time=9246 us 72 bytes from 69.64.163.17: icmp_seq=290 time=8364 us 72 bytes from 69.64.163.17: icmp_seq=291 time=8928 us 72 bytes from 69.64.163.17: icmp_seq=292 time=8285 us 72 bytes from 69.64.163.17: icmp_seq=293 time=8425 us 72 bytes from 69.64.163.17: icmp_seq=294 time=9052 us 72 bytes from 69.64.163.17: icmp_seq=295 time=8513 us 72 bytes from 69.64.163.17: icmp_seq=296 time=8464 us 72 bytes from 69.64.163.17: icmp_seq=297 time=8631 us 72 bytes from 69.64.163.17: icmp_seq=298 time=8048 us 72 bytes from 69.64.163.17: icmp_seq=299 time=8853 us
Rich Adamson wrote:> Absolutely not. The MTU is the Maximum Transmission Unit, and sip > packets are about 214 bytes in size (including all pkt headers). Way > smaller then the MTU. >If the only thing on my network are these Cisco Phones, would lowering the MTU encourage more efficient transfer of data as per here: http://www.voiptroubleshooter.com/problems/mtu.html http://www.opalsoft.net/qos/VoIP.htm Here is the breakdown of packets on the port that has the SDSL modem: SDSL Router Amount % of Whole 64 BytePkts 0 0% 65-127 BytePkts 20257 1% 128-255 BytePkts 3623518 91% 256-511 BytePkts 237087 6% 512-1023 BytePkts 112900 3% 1024-1522 BytePkts 48 0% Total 3993810 100% The larger packets I'm sure are the bootloader stuff and config file downloads, etc. I do feel like I am reaching for straws here! Just as an update, the users used to be on two 2mb down/512 up ADSL lines (PPPoE) (4 users on each) and they never reported a problem. Now that they are on one SDSL (PPPoA) line (2mb) is when they report the issues.
Rich Adamson wrote:> No. The reason is that "if" the phones are the only thing on this, the > size of the sip packets will never be greater then 214 bytes.> Given your table below, there "are" other devices on your network and > 6% of those are sending packets of in the 512 to 1023 byte range.Actually these are the only devices, honestly. Looking at a packet capture from the SDSL network shows plenty of larger packets. The SIP Invite packets are 769 bytes, SIP Notify at 516 bytes, SIP Option packets at 481, Register packets between 430-609 bytes, Status 200 at 725 packets. They are minimal in number compared to the RTP packets though.> > Have you tried the previous suggestion relative to two simultaneous > ftp sessions?Unfortunately not, I have no access to the remote site inside the LAN. The onsite tech is out of the office and it is difficult to walk others through this process.> > What city/state are you located in? >The phones and the asterisk server are in London.
Andrew Kohlsmith wrote:> My suspect is the SDSL modem; what is it? We use ADC Megabit modems > here and they work fairly well. We've had some issue with the old > Flowpoint 5250s.It is a Speedtouch 610s. Seems like a pretty robust small biz class modem but it could be the issue. We are just trying to determine what has changed since we moved from ADSL to SDSL (which is when the issue started) Here is what has changed 1) Contention on the internal network doubled to 8 users (used to be 4 users on 2 slower ADSL lines 1a) There used to be 3 VLANs, 2 for voice, 1 for data; now there is 1 for voice, one for data. 2) The modem is new with the SDSL line 3) We are using PPPoA vs. PPPoE Thanks, Geoff
Pete Barnwell wrote:> Are you sure about that? Most ADSL in the UK is on PPPoA (BT supplied > - it may be different for LLU providers), not PPPoE so I wouldn't > think this has actually changed. >Correction, you are right. The old ADSL we were running was indeed PPPoA. That has not changed. Thanks, Geoff
As an update and back to the original response from Rich re: duplexing The topology looks like this: 8 Cisco IP Phones | | 3COM 226 PWR-Plus | | Speedtouch 610s | | SHDSL Line When I used to have the ADSL modem plugged into port 1 of the 3COM switch, the port would auto-sense to 100 Full, with Flow Control Enabled. With the SDSL modem plugged into port 1 it auto-senses to 100 Full but with Flow Control Disabled. Here are the results of playing with the setting between the 3COM and Speedtouch: Speedtouch set to 100Full - 3COM set to Auto 3COM port configures at 100Half; Flow Control Enabled Speedtouch set to 100Half - 3COM set to Auto 3COM port configures at 100Half; Flow Control Enabled Speedtouch set to 10Full - 3COM set to Auto 3COM port configures at 10Half; Flow Control Enabled Speedtouch set to 10Half - 3COM set to Auto 3COM port configures at 10Half; Flow Control Enabled ------------- 3COM set to 100Full - Speedtouch set to Auto Speedtouch configures at 100Half; 3COM Flow Control Disabled 3COM set to 100Half - Speedtouch set to Auto Speedtouch configures at 100Half; 3COM Flow Control Enabled 3COM set to 10Full - Speedtouch set to Auto Speedtouch configures at 10Half; 3COM Flow Control Disabled 3COM set to 10Half - Speedtouch set to Auto Speedtouch configures at 10Half; 3COM Flow Control Enabled* * (This test is inconclusive since I crashed the web interface of the modem. The modem is located on the other side of the Atlantic so I'll need to wait until they power cycle it in the AM.) So if I leave it as is (both set to Auto) then Flow Control is Disabled on the 3COM switch If I configure it so the Flow Control is Enabled then the 3COM defaults to Half Duplex.
Rich Adamson wrote:>> So if I leave it as is (both set to Auto) then Flow Control is >> Disabled on the 3COM switch >> >> If I configure it so the Flow Control is Enabled then the 3COM >> defaults to Half Duplex. > > Is there a way for you to use ethereal to "see" what's coming through > the dsl circuit? > > What happens if you set the 3com AND Speedtouch to "full duplex"? > > Flow control is not necessary for what you're doing; disable it if > you can.I will attempt to set both to 100Full after hours UK time today. As for ethereal, I have several captures, what in particular would you recommend I look for? Thanks, Geoff
Rich Adamson wrote:> What happens if you set the 3com AND Speedtouch to "full duplex"? >Setting both to Full Duplex (10 or 100) shuts the port on the 3COM switch down!
> > Geoff Manning wrote: > > Rich Adamson wrote: > > > >> What happens if you set the 3com AND Speedtouch to "full duplex"? > >> > > > > Setting both to Full Duplex (10 or 100) shuts the port on the 3COM > switch > > down! > > Sounds like you're getting closer to the root cause. Now try using a > different switch to see if the issue follows the switch or theSpeedtouch.>The 'Speedtouch' modem isn't made by Alcatel is it? I remember a while back an issue with a certain Alcatel modem where it would just freak out under certain circumstances if you tried to send large (eg >1000 bytes from memory) packets at it. Only when connected to certain hardware though (netgear?) It could be worked around by placing a switch between the two devices. Google doesn't tell me anything useful about the 'Speedtouch 610' though so this probably isn't your problem. James