Thread View: demon.service.isdn
3 messages
3 total messages
Started by tfb+google
Mon, 12 Jul 2004 11:29
Demon G5 ISDN, again
Author: tfb+google
Date: Mon, 12 Jul 2004 11:29
Date: Mon, 12 Jul 2004 11:29
45 lines
3159 bytes
3159 bytes
Apologies if this is a near duplicate of an earlier message of mine, I'm just about to whine furiously at demon / bt and I want to know who I should whine at if possible. I'm living in an ADSL-free area, so I'm using ISDN, or rather the BT home highway thingy. I used to use the BT USB thing, but it never worked very well and was also Windows-specific, so I'm now using a Netopia 3100 router. I have the `vanilla' BT surftime offering, which means I should be able to dial the G5 number (0844 041 6672) off-peak and have no call charges. I've set up various timed-connect things in the router to do this automatically. In particular it's set up to dial up at around 18:30 and keep the line up most of the night, which is slightly excessive but allows me do to things like have other machines establish ssh connections to me to sync files and so on. This has worked in the past (with the same router and the same firmware in it). It may even work, occasionally, now. What happens most of the time though is that the call to the G5 number fails - it seems to get a connection but this is then terminated by the far end. The G4 number (0844 099 6662) works fine, but isn't free, of course. The end result is that I'm paying BT some monthly fee for something that doesn't work: I don't actually get free evening and weekend ISDN access. I'm fed up with doing this. What I want to know is whose fault this is: when I asked Demon about it some months ago, they were fairly clear that they were not even seeing the dialup attempts. But of course BT say that it's Demon's fault, and superficially it does look like it must be. What I don't understand, I think, is what happens when I attempt to make an ISDN connection: is it like an analogue connection, where BT just provide a circuit to Demon, or is it more complicated than that (I'm sure it is). If it's like (or approximately like) an analogue connection, then it has to be Demon's fault, doesn't it - I can get the circuit, but then something at Demon's end is screwing up. But if BT have a larger role to play, then it could easily be their fault. I have no idea how to diagnose this unfortunately, and I know nothing about ISDN really. Can anyone describe what the process is, and give any hints as to how I could find out what is breaking? I need to know whose head to jump on! Thanks --tim
Re: Demon G5 ISDN, again
Author: Bob Evans
Date: Mon, 12 Jul 2004 17:59
Date: Mon, 12 Jul 2004 17:59
37 lines
2532 bytes
2532 bytes
In article <cctslu$hi1@odbk17.prod.google.com>, "tfb+google@tfeb.org" <tfb+google@tfeb.org> wrote [of problems with Demon access via the g5 ISDN number] >Can anyone describe what the process is, and give any hints as to how I >could find out what is breaking? I need to know whose head to jump on! The best reference is Denis McMahon's Surftime troubleshooting pages, now available at <http://www.dsl.co.uk/surftime/>. There you will find details of the BT-Thus interconnect and the formal procedure for fault resolution. Some miscellaneous points: 1. Demon have stated that from their point of view (and subject to routeing within the BT network), calls to the g5, g4 and Purple ROMP 0845 numbers all terminate on the same equipment. 2. When you (as a BT customer) initiate a call, your "contract" to have that call delivered correctly to the destination number is with BT. In the event that that the cause of a particular fault lies outside of the BT network then (as is explained at the URL referenced above) it is nevertheless BT's responsibility to follow the documented procedure to achieve a resolution of the problem. 3. From my observation, Demon/Surftime access faults have, in the main, tended to fall into one of two categories: either (a) due to a datafill error, a particular BT exchange has (temporarily) no idea how to correctly route calls to 0844 041 6662/6672 to their destination and so connection is not possible; or (b) call routeing takes place correctly but data synchronisation issues (often occurring at the interface between BT's network and that of another operator) then result in connections that perform poorly or drop the call after a brief period. HTH, -- Bob Evans
Re: Demon G5 ISDN, again
Author: Brian {Hamilton Kelly}
Date: Mon, 12 Jul 2004 23:00
Date: Mon, 12 Jul 2004 23:00
22 lines
1982 bytes
1982 bytes
On 12 Jul, in article <cctslu$hi1@odbk17.prod.google.com>
tfb+google@tfeb.org "tfb+google@tfeb.org" wrote:
> Can anyone describe what the process is, and give any hints as to how I
> could find out what is breaking? I need to know whose head to jump on!
> Thanks
See <http://www.dsl.co.uk/surftime> and the pages that lead off from
there. This was a website originally constructed by Denis McMahon, who
graciously allowed me to copy it when he ceased to have any interest in
SurfTime (and/or Demon); so there are out-of-date things there, like the
actual prices, and also links to non-existent pages that used to be
elsewhere in Denis' own site.
However, I think it provides the answers to your questions (and perhaps a
strategy for testing and reporting your fault situation).
--
fix (vb.): 1. to paper over, obscure, hide from public view; 2. to
work around, in a way that produces unintended consequences that are
worse than the original problem. Usage: "Windows ME fixes many of the
shortcomings of Windows 98 SE".
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads