Speaking of the PAP2T -- the current Cisco (they own Linksys) documentation for it is total crap. For the unlocked version, one needs the "Administrator's Guide", and the Cisco version is rather generic, covering several of their products under a single title.

But I did eventually locate a copy of the original Linksys PAP2(T) admin guide, and that's just so much better! Between it and wikipedia, I can now figure out what all of the settings are used for.

Mind you, it practically worked without a hitch straight from the box, after I entered the SIP user/passwd and turned on NAT traversal. But the extra fun stuff just tends to draw one in..

Cheers

Can I ask which provider you are using ?

Thanks
Mark

I just used my Nokia N800 to make a PSTN call

Denise setup a local Asterisk SIP server using Sein's gear and connected it to the PSTN line a couple of weeks back. We've been using headsets on the PC and normal analogue phones with a PAP2T.

It was fun having extensions and setting up local voicemail to be stored on the IMAP server.

Cool!

Glad you're having fun with it.

Sure, I use VOIPTalk I have an incoming freephone number with them.

Cheers

Cris.

Thank you.

Progress report.

The Bell telephone line got disconnected this past Monday, and as a result our "dry DSL" loop showed an immediate improvement in S/N characteristics. It's been quite rock solid since then.

Which bodes well for our VoIP telephone service that relies on the DSL now.

We've got E911 set up on the account now (painless), so recurring charges tally in at US$3/month + calling fees, plus the CDN$9.10/month for the dry loop itself. Internet access is CDN$34/month w/static IP.

The Siemens DECT/IP sets are not yet widely available over here, so I've gone and added three handsets (total of five now) to our existing conventional DECT 6.0 Vtech system. Really, it could hardly be any better suited. It has dedicated voice-mail access buttons and indicators, and no local answering machine. Perfect for use with voip.ms!

Cheers

Mark, what ISP are you with? And what are your down/up published rates and monthly bandwidth allowance?

I just hooked my parents up with TekSavvy for both a line and DSL. Didn't go voip, so it's a full-blown line. I'd love to save them some money, but I'm not sure if I can rely on voip for them.

We get internet from ncf.ca (National Capital Freenet), who resell Teksavvy at pretty much the same rates as Teksavvy themselves. So, really, we're with Teksavvy, just indirectly. No complaints whatsoever there. Bandwidth allowance is 200GB monthly, with explicit permission to host servers and share the connection with neighbours.

Data rates are for up to 5mb/s down and 800kb/s up. But we are a very long way from the C.O. (5.4km, I believe), so we're lucky to have DSL at all really. Our line is currently configured with a 2496/640 profile (2.4mb/s down, 640kb/s up), interleaved.

This has worked very well for us, with a sync loss once or thrice a day over the past few years (S/N ratio of 6dB or so). But when the Bell line got removed on Monday, the dry loop suddenly became a lot more stable (S/N ratio is now 13dB). It could easily do fast-mode 3mb/s down now, but perhaps with the odd sync loss here and there again. I'm trying to decide whether to ask for a slightly faster line profile, or to leave it alone in its new rock-solid state.

We're also thinking of setting up voip.ms for the mother-in-law in Toronto, perhaps. She already has Teksavvy DSL (and excellent line quality, 5.5mb/sec), but would need a new dry DSL loop installed. Then have the DSL service moved to that from the Bell "wet loop" currently in use, transfer the DID, and disconnect the Bell loop finally.

Trickiest bit would be getting her Bell DID transfered over.. it's a nice number, and she'd like to keep it. Piece of cake if we actually lived in Toronto, where we could just handle it all for her. But from Ottawa.. dunno.

EDIT: Oh, wait. She also has a telephone-based alarm system there. Have to check if it has a dedicated line, or if it shared the house telephone line.

Cheers

One cool trick I discovered today, was a setting in the PAP2T unit to have it use euro-style ETSI FSK signalling for the CID functions on the handsets.

Normally over here, CID info gets sent to the handset between the first and second rings, but with the ETSI method it is sent immediately before the first ring. Much better for screening calls that way. The DECT sets have no issues with it (as expected), and neither does another CID-capable handset we were using.

-ml

I think you are quite brave going for a dry loop. This isn't something widely available yet here, but it could be just around the corner.

In the UK I wouldn't recommend that to anyone, retain dial tone on your line. I know the state of our network in the UK inside out, and with pairs at a premium the last thing you want is to not have dial tone. Before you know it "someone" will pinch it away as engineering techniques in general haven't moved on for 50 years and most don't think to check for a digital signal before assuming it's a spare.

Of course this is against company policy, but what would you do yourself? I bet a high percentage wouldn't be following the company line!

I hope practices in Canada are a little more advanced than here.

Cheers

Cris.

They have been doing it in Australia for maybe 6 or 12 months now. It's called "Naked ADSL" here. I've not heard of anything like what you're suggesting Cris where your pair would get taken away from you.

It is a similar system though I'd guess and the original issue was always you had to have a POTS service before you could get ADSL so that the line stayed allocated.

In my case to actually go to the naked service it would actually cost me more and get me less since I have a pretty good deal already. Plus the phone call rates I get are quite reasonable for the odd local or international call (international ones are very good actually I think).

We had an SDSL line put in years ago, and when the engineer was looking for a spare pair on our trunk to put it on he inadvertently pulled a KiloStream to a branch office out because he couldn't hear a dial tone on the line. Needless to say, our IT director tore strips out of his manager.

We've had "dry DSL" (as opposed to "wet DSL") offered locally for at least the past 2.5 years. Should have switched to it sooner, but I think waiting helped a bit while things stabilized around the engineering/deployment side of it.

Cheers

Yep, that is exactly what I am talking about. Openreach's (BT) continued under investment in it's staff training and lack of discipline within the engineering community will only make this worse over time. The worst part of it is that it really doesn't matter which SP you go with as they all have to use the Openreach Network for delivery.

There is another side to this in the UK. If it truly is a "dry" line, ie missing even the 50v DC wetting then on the network in the UK that isn't going to last too long fault free.

I think my point really only applies to the UK, as our network is so old and over stretched, along with very unhappy engineers, short cuts are always taken to deliver new service.

I can say all of this of course now I'm not part of that problem anymore. I would point out that I was never a "pair pincher"

Cheers

Cris.

Heh, hardly! It's a real eye-opener touring around the world, and discovering that backwoods Canada really is backwoods in so many many ways.

The installer guy shows up, with a belt hung line test unit. If he wants to find an unused pair, he selects a likely candidate from the bundle, and checks for existing signals with the line test unit. Thankfully, it will see DSL as well as voice equipment, so things should be safe enough. Time will tell.

You are one step ahead of us here then!

The equipment currently widely in use here pre dates the digital era, whilst most engineers will carry a a test unit capable of detecting a digital signal (they are the blue ones you see) most, myself included, used to hide the old yellow equipment come inspection time as they are a whole lot better to use. I used to use an amplifier that held up to the pair would detect the digital signal before I broke the pair down. Now try showing that to someone who has always waded in and cut a pair down to test it.

I must admit, the company bought me £1200 worth of digital tester for finding faults, but it was so poor to use I ended up using my old trusty £50 needle multimeter. f you know what to look for you can even get distance to fault off one of those things, and experience tells you what a DSL DSLAM looks like on an analogue scale. And again most engineers don't have the training backup to use the equipment so it just sits in the back of the van will the batteries leaking all over the place. Management are only interested in the quickest solution to the problem in hand. So hence my advice, for the UK at least, to keep your dialtone even if it's out going calls barred or something.

Ah them were the days.

Cheers

Cris.

I remember the days when the test units didn't detect DSL, and lots of DSL customers were getting disconnected because a tech thought he'd found a free pair he could use...

No, back in those days the DSL lines also always had voice service. So the tech probably just didn't check at all.

A customer of mine lost their DSL connection while I happened to be onsite recently. I noticed that a BT engineer was working in the building's cabinet and I mentioned to him that the downstairs company had lost their broadband. He insisted that nothing he was doing could be responsible and offered to show me his test meter thingamajig as proof!
Suffice it to say that when my client's broadband was restored a few days later upstairs lost theirs (or their fax -- they lost *something BT wise). I sortof *knew* they were stealing pairs and I now feel vindicated that you guys (Chris and Andy) are confirming that!

Another thing while I'm thinking about BT... I see a lot of cases that go like this, the fault is: DSL present on line (according to router) but no Internet, no "bad logon" reported by router:
1. Customer reports fault to their IT provider (my company)
2. We we report problem to BT reseller
3. They check for DSL logins etc
4. We check (and sometimes replace) router
5. Reseller reports fault to BT and BT supposedly test the line as NFF
6. BT threaten a fee for a wasted site visit if we make them attend
7. BT attends site, line NFF
8. Customer's DSL starts working
9. No charge.

It's happening more and more these days. So much so that we're starting to 'pretend' we've replaced the router etc. until BT have been to site. I know that's wrong but over 95% of the time we get a NFF and the DSL starts working again.

Purely OOC, any idea what's actually going on behind the scenes here?

That sounds kind of like what I'm going through with my Dad's ADSL line at the moment. It still has sync but appears to be failing to authenticate. The ISP (Plusnet) also can't authenticate with his details on their test line and yet BT have still been sitting on the fault seemingly doing nothing for the last three days.

I doesn't help that I couldn't talk my Dad through using the BT test login. I don't suppose there is a router out there with a web page that has a simple "switch to BT test login and then switch back to my login" option ?

I suppose I should defend slightly what the guys are doing, I would say in the vast majority of times the engineer is not cutting off one customer to feed another, at least not in his eyes. He sees that as a spare and uses it, quite often his system will be telling him it is spare but the records are wrong. This doesn't excuse poor engineering practices of course.

Sounds like your common problem is the card locking in the exchange, the very fact that they remote test it will likely free it up again and bingo it starts working. Do you find it happens on the same brand of router you are using? If so it could be some kind of conflict with certain cards, and that is what is causing the locks? That is the sort of thing we used to see back in the early days where people didn't like using the BT supplied router and put their own on there.

Cheers

Cris.

Thanks for the explanation Chris.


We mostly use Zyxel routers such as the Zyxel P-660H model so by default, the problems we see are pretty much all with one brand of router. I must admit I hadn't given any thought to the possibility of bugs/lockups etc. Do BT publish details of 3rd party routers known to have compatibility problems etc. that you are aware of?

Zyxel have totally stupid default settings on their routers. SNMP, telnet, FTP and web to the router are all set to be allowed from the outside.

Not that I have any experience of this but with Zyxel routers you can configure them by issuing command lines over telnet. I suppose a clever person could script something to automate the switch over.

Alternatively, you could post him a cheap (2nd user?) router pre-configured with the BT test login.

I actually used to use a script just like that to switch my Efficient Networks (BT supplied) router to the BT login and back at 6am every morning. In the early days of BT ADSL it was the only way to ensure a reliable line. Thankfully things have improved at lot since.

Unfortunately while my Dad's Zyxel router has telnet access it is telnet access into a menu system, making it pretty much non scriptable.



Hmmm, good point. I have two old BT EN5861 routers sat here doing nothing. Though of course you play russian roulette every time you power cycle them, their fragile PSUs only last so long.

However I fear that having my Dad unplug one router and then plug another in could well end up with him not having everything plugged together correctly afterwards.

I know they used to, at least internally. But I think they stopped doing this a long time ago once ADSL routers flooded in from all sorts of places. My knowledge of routers that caused problems used to be pretty good, but it is getting less and less relevant now.

I would suggest that next time you have a problems like this, preferably one that repeats, to replace the router with a different brand before reporting to BT and see if the problem goes away. If it does it could be likely that you have an incompatibility going on.

As for the old BT routers blowing up all the time, that kept me fed and watered and in good overtime for a couple of years, loved those jobs

Cheers

Cris.

Over here, where the loops are long and heavily attenuated, we swear by Thomson SpeedTouch xDSL gear. The cheap/simple ST516 in particular is rather legendary for its performance.

Cheers

Yeah, I used expect for my previous script. It would however be a nightmare doing it for the menu based ui on my dads router. I'd be much better off swapping it with one with a simple web ui.