2015-03-30

I have a cunning plan

As usual, when BT make a change, we have to adapt.

At one point SFI was charged for "work done on end user equipment beyond the NTE", so we made sure no work was done.

Then they decided "a visual inspection of end user equipment" counted as work, making visits chargeable. That was some genius weaseling on their part! So we had end users actually hide their routers. They still had the cheek to charge!

SFI was an "optional extra service" which we refused to order, so they changed it to be "part of the fault repair process" hence us arguing that we should therefore only pay if we actually breached some term such as checking the equipment before reporting.

Now we have the latest that SFI2 is a product or service they offer and which checks the line to SIN349, and fixes (free) to that if it was not to SIN349, or maybe does other work if it does but is chargeable. So once again SFI2 is an optional service.

So the cunning plan...
  • We are have got a JDSU, which is the test kit BT engineers use to test a line to SIN349. We hope we will not have to use it that often to prove the point here.
  • When we get a fault near us, we will send someone (our staff) to test the line.
  • If the line fails SIN349, we report a PSTN fault and get fixed
  • If/when the line passes SIN349, we report the broadband fault
Now, at this point BT will, as always, offer an SFI2 engineer. However, we will have the justifiable reason to not take that offer as we will have tested the line to SIN349 already so do not need to pay for a service described as "The SFI2 visit simply checks whether a line is working within the specification of SIN 349". Job done, move on to next step in fixing fault!

However, we will have evidence in our line testing of a broadband fault and be well within our rights to insist BT fix the broadband fault, within the 40 hour SLG, and without using an SFI2 engineer.

If they refuse to fix the fault, county court claim.

We'll see how it goes, and what next crazy step BT come up with to stitch up ISPs after this one.

P.S. Same will apply to TalkTalk.

Update: The JDSU has a lot of useful tests which should help where we can use it, including ADSL and VDSL tests. Looking in detail at SIN349, which is literally a "Metallic path facility interface description" the tests are purely electrical characteristics, and most are tested by BT from their end for us. Indeed, we are not really able to test these without isolation and/or loop at the exchange end. We'll ask BT and TT how we can arrange open/loop at exchange end for independent testing and see what they say. Even so, the specification of SFI2 makes it very clear that it is simply not the appropriate "product" to consider as a means to address broadband faults so we will be back to "Not buying SFI2, are you refusing to fix the fault?" as before. Oh well.

Update: It seems that a SIN349 test needs an earth. If the end user does not allow use of power socket or other earth in premises a full SIN349 test cannot be done. If doing a SIN349 test is what we are paying for and the engineer cannot do that, well, then we won't have to pay, will we?! That could be another angle (assuming engineer does, as they usually do, go on to fix the problem).

23 comments:

  1. In an effort to save you a few grand - there are a couple of flaws I'm afraid.

    To test the line, you'd need to remove the NTE at which point BT would have a field day turning the tables on you. You wouldn't have a battery reference nor would you have the ability to loop the line at the exchange leaving you with basic measurements that can be done with a £10 multimeter.

    Any wideband measurements that indicate a fault are out of scope of SIN349 too.

    ReplyDelete
    Replies
    1. Interesting. But if we have no way to test the line is what BT say it is, how can they have the cheek to charge us for testing it for us? They have to allow us to carry out the tests?

      Delete
    2. Why do you need to remove the NTE? I've not had an SFI visit, but when the OR engineer installed my FTTC all the tests were done through the NTE (with the user-removable plate removed).

      Also, the NTE is part of OR's responsibility, so if the argument is that the tests aren't valid because the NTE could be broken, its still OR's responsibility to fix the busted NTE.

      WRT looping the line - is there no test number you can dial to trigger the exchange to do this?

      Delete
  2. "basic measurements that can be done with a £10 multimeter." (said bej).

    Whatever happened to Teradyne Celerity and suchlike that were being talked about a decade or more ago? For those that weren't there back then; BTO were at one time going to invest loadsamoney in exchange-based 21CN automatic test equipment **for broadband** which was going to lead OpenReach down the road to a land of milk and honey and cost-effective line maintenance. Or not, as the case may be.

    E.g.
    http://phx.corporate-ir.net/phoenix.zhtml?c=65320&p=irol-newsArticle&ID=519131 says
    ""Moving to a single system is a key to supporting BT's development of services carried over the copper access network, in that we will see greater flexibility and shorter time to market for test solutions," said Ray Clay, BT's Test and Diagnostic Program Manager. " (he was later Head of Test and Diagnostics for 21CN, dunno where he is now).

    Similar question applies to the Test Access Matrix kit, of which BT once said
    "The TAM can connect to the DSLAM, it can then emulate the Modem from the customer and Prove if the fault is at the customer end or in the exchange"
    from
    https://www.btwholesale.com/pages/downloads/broadband_community/Fault_Diagnostics_Best_Practice_Guide_Issue_1.pdf

    And here we are, ten years later, and the best available option still seems to be to send out a technician with a (smart) meter, and more importantly, charging the ISP for fixing the broken service?

    ReplyDelete
  3. Dont you have to have an active job reference etc to be able to get the line to connect to the test head in the exchange? I've had issues in the past where BT have booked an SFI on the wrong telephone line, when the engineer visited he was unable to continue the call as he explained that it wasnt possible to PQ any lines not listed on the job...

    ReplyDelete
    Replies
    1. We will find out. If BT refuse to allow us to independently verify that the service meets the spec they sell it to, that is a problem and may involve solicitors letters.

      Delete
  4. Surely if you've tested the line to compliance beyond the NTE/exchange looping point, that is a superset of the compliance demanded by SIN349? If you pass SIN349 testing at the end user socket then shouldn't it be a given testing beyond the NTE would pass?

    I have no knowledge of these matters or what SIN349 says but it seems like common sense?

    ReplyDelete
  5. Had a problem with one of the many lines at work. First guy came with a JDSU, mucked around for a while in the NTE and one of the on premises DPs. Told me all well then disappeared. Problem came back within an hour.

    Next engineer came with an old-school BT Hawk, job done in ten minutes - dodgy connection in the manhole outside. The guy had a JDSU in his toolkit but told me that the Hawk was better in his opinion?! Not had a problem with the line since.

    Could have been a fault in two places on the line I guess, but sounds improbable.

    ReplyDelete
    Replies
    1. And current BT policy would be to definitely charge for first engineer, and probably charge for second if jdsu said it was ok on arrival. Given that it was clearly an actual BT fault, such an arrangement is IMHO unacceptable.

      Delete
  6. "Similar question applies to the Test Access Matrix kit, of which BT once said
    "The TAM can connect to the DSLAM, it can then emulate the Modem from the customer and Prove if the fault is at the customer end or in the exchange""

    They have this and they use it - but it still isn't solving the issue. For example, we had a line where the pair had been stolen, and it was at someone else's premises, but they had plugged in a router - so there was sync - just no valid PPP. TAM test comes back "Yeah, all is good" - so you think OK that's odd.

    You've already done the PSTN tests and it tells you all is well (yeah, because the line is "good" - just not where it should be, so you assumed the fault is BB side.

    ...BT automated testing just keeps determining there is no fault - you get all faults logged for PSTN rejected because it passes test, you get all faults for BB rejected because there the fault is incorrect PPP details at your end, and a TAM test passes, and you have to play BT clue whack-a-mole to get them to actually READ the god damn notes.

    I've had this happen SEVERAL times at the SAME PREMISES - and I've lost track of how much of our time is wasted - none of which we can recover from customer or BT.

    Unfortunately JDSU tests are mostly useless without being able to connect to the test kit and set loops etc (and that requires a job number and your employment ID and passcode stuff IIRC), so that's a no go.

    Apparently it's down to us to pay Openreach" a distinct arm but not really and still part of the same BT plc" to fix the service that isn't working that I'm already paying for. There does need to be some test causes brought to court for this sort of shambles.

    I suspect the biggest reason they're ditching OR supplied modems for FTTC is that it opens up the SFI charging game - must be a nice little earner where people agree to it.

    Of course it's also a nice earner where we instead just order a new line when we get a major fault and have that provisioned because it's less expensive than SFI and they then fix it at provisioning time (and usually fix the original fault so we just pick the best line and drop the other immediately after).

    ReplyDelete
    Replies
    1. Very good points, and I agree with all. If, by some quirk of legal stupidity it was valid for BT to charge to fix faults it would be a matter of installing new lines instead - as way cheaper.

      Delete
    2. I wonder if an active NTE is the answer - you could have a tiny microprocessor in the NTE, powered by the line. The exchange could query it for an ID to make sure the line is connected to the right premises still, and could ask it to disconnect everything beyond the NTE and loop back the copper pair for a few seconds so the exchange can do end-to-end tests on the pair without it being affected by any CPE. Sounds like something that could be done for a few pence per NTE and would save a lot of headaches.

      Delete
    3. Definitely - BT could have got some manufacturer to make a faceplate ADSL/VDSL bridging modem with plug top power or PoE that would work with a "BT hub" generating PoE with no extra "boxes" but be an active endpoint of an Ethernet service. That is absolutely what they should have done from day 1.

      Delete
    4. Requiring anything, such as power, from the customer premises opens up a whole load of ways they can blame the customer (has the NTE failed, or did the customer just not plug it in?). Sticking a really simple line-powered diagnostics chip in the NTE would ensure all copper/NTE problems could definitely be pinned down to OR and never blamed on the customer.

      Also, the FTTC NTE5 faceplates are already big enough, I'm not sure people would want a VDSL modem stacked on top of that as well.

      Delete
    5. I'm sure I've seen proposals for a NTE mounted modem before now.

      Delete
    6. Re the JDSUs - every damned BTOR engineer who came out to my place saw no faults on the line, appeared very uninterested in my home-grown graphs showing CRC errors and packet loss, and refused to climb the pole to actually check the DP.

      I'm pretty sure the fault I was suffering from was very dependent on the impedance of the test kit / modem and filter. It was _worse_ with any of three SSFPs - I assume due to lower impedance. The JDSU apparently had a higher impedance when it was pretending to be a DSL modem, as it never logged any CRCs, despite three different modems of mine racking them up.

      In the end - as RevK knows - I switched to FTTC and the line has been rock solid. Feels like using a rather expensive hammer to crack a small nut, but it really does seem that BTOR engineers don't want to / aren't authorized to fix faults beyond a very low level of usability.

      Fortunately it looks like VDSL2 is much more tolerant of whatever minor issues there are on my line. I've lost 2 packets in the 2-3 weeks since I switched over! It's still scary though that what is now a pretty fundamental utility is provided over a physical facility that the owners apparently feel no obligation to maintain to a level where it will actually work reliably.

      I'm still hoping AA will one day run their own fibre, or that the local WiMAX ISP will extend its range. Monopolies suck.

      Delete
  7. Requiring an earth is a great point. An engineer who came out to look at my line failed to identify an earth contact fault because he'd clipped his JDSU's earth connection to a radiator... with plastic pipes. So no earth connection.

    He was very embarrassed when I pointed this out.

    ReplyDelete
  8. Would the situation be worse if one had gone for the AAISP "copper-pair only" product ? No dial-tone, so that can't be tested for.

    ReplyDelete
  9. Out of interest, RevK did you ever make any headway regarding testing the lines yourselves?

    ReplyDelete
  10. That's a nightmare, I'm sorry to hear that, does the JDSU ever get any use or is it not much help unless the celerity test system allows the line to be put into test mode?

    ReplyDelete
    Replies
    1. I think that was part of the problem.

      Delete
    2. It's a shame one of the bt wholesale tests can't be invoked to give your JDSU long enough to carry out some testing at least.

      Delete

Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

Fencing

Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...