Hi Sackboy, I don't feel its fair to directly compare your case with the one of the original poster's as the issues are not exactly the same and have different circumstances.
You certainly did have serious intermittency which did take a considerably longer amount of time to deal with than it should have, thankfully the intermittency was eventually resolved. That left the issue that you have been having connecting to a 3rd party service on port 993 which was totally different problem. Zen most certainly do not block port 993, if someone had advised you that we do they were certainly mistaken. Leo is not in for me to ask him what was meant by not supporting 993, I would guess he was trying to explain that he could not comprehensively support a service provided by a 3rd party.
Both Zen and BT were unable to reproduce the SSL problem. Due to the large number of BT engineers booked and stating they could find nothing wrong or not getting access (even though we both know you were in at the time),the case went to the BT complex faults team and they could not find anything or reproduce the problem either. We would not deliberately block the booking of an engineer however in this case we did have to ask what would engineer number 9 find that the ones that had attended didn't find.
With BT's engineer charge policy there is the risk of BT charging you nearly £200 per engineer visit if they felt the issue was nothing to do with BT. If they apply a charge these would need to be disputed on a visit by visit basis. From the way I read the case notes it was as much about protecting you from needless charges as it was about trying to get to the bottom of the issue.
Certain basic diagnostics had not been performed or at least not clearly noted if you had done them. Such things for example as testing alternate MTU values from your computers and router to ensure that youíre not suffering packet fragmentation (which would cause such problems with SSL). The kind of diagnostics that we could present proving that the issue was not at your end would be invaluable in ensuring you did not get charged for all of those visits.
I fully understand your frustration with the issue its one of the strangest cases that I've read through, and while I was not directly involved in any part of your case I offer my apologies for the frustration this must have caused you.
As much as we wish it was not so the fact remains that some hardware does not work as well on 21CN as it does on 20CN and vice versa. Day in day out we see example of this and if we did not mention or investigate such possibility as hardware being part of a problem we could be ignoring a possible cause of a fault and expose our customers to the risk of engineer charges.
This would then lead to the point of why donít Zen just stick to 20CN. Eventually the plan for 20CN is to be decommissioned anyone still on it would have no service. BT require the 21CN network to keep developing Internet access, without the 21CN network there would be no FTTC and FTTP (at least not in its current forms). With ISP backhaul on 20CN bandwidth costs are higher, moving to 21CN allows for higher usage limits. It would just not be commercially viable to not adopt 21CN and deal with the small percentage of issue that come along with it.
are recruiting! Click here
to view the opportunities available.
Edited by drefsab (Thu 28-Apr-11 16:46:57)