acc-name: nralphwp status: comatose name: Ralph Warren Pearson company-phone: 408-xxx-xxxx company-address: 1031 Third St. #B Santa Cruz, CA 95060 company-fax: 408-xxx-xxxx technical-contact: Ralph Pearson technical-email: ralph@netcom.com technical-phone: 408-556-3372 technical-fax: 408-551-2241 technical-address: 849 Almar Ave, STE C-450 Santa Cruz, CA 95060 marketing-contact: (contact doesn't like marketing) type: ISDN@128k (CENTREX damn it!) circuit-id: 80IBDC109488-000 customer-router-type: Livingston Office Router -- ISDN (OR-U) customer-router-serno: 1H01071 isdn-bandwidth: 128kbps (CENTREX) isdn-vendor: Pacific Hell isdn-switchtype: 5ess Cust-SPID1: 0147139980 (dn=408-471-3998) Cust-SPID2: 0147139990 (dn=408-471-3999) Netcom-SPID1: 0147139960 (dn=408-471-3996) Netcom-SPID2: 0147139970 (dn=408-471-3997) pop: scz-ca port1: scz-ca-pm20:s0 port2: scz-ca-pm20:s1 remote-ip: 199.233.217.1 login: muthascratchie password: nunnayodambidniz protocol: multicast network: 199.233.217.0/24 network: 207.95.176.0/24 network: 207.93.179.240/28 network: 192.187.130.0/24 domain-name: mola.org netcom-ic: install-date: primary-ns: ns1.noc.netcom.net (204.31.1.1) secondary-ns: ns2.noc.netcom.net (204.31.1.2) updated: 1/6/97rwp add misc information down here 11Mar97 Customer called in and opened ticket 183957, harassing the administrators he came into contact with. He is demanding some sort of compensation for having to live in Santa Cruz. I forwarded his complaints to nododge@ix.netcom.com. -jrn The scz-ca end was not ready when the customer's end was brought up and he was pissed; in fact there were no records in the dbfile about CIDs, SPIDs, DNs or any special Centrex codes he needs to dial, and the POP file still shows the original planned redesign of BRI#10. This guy's a fucking jerk so if at all possible, just leave him voicemail at x3372 or send email to ralph@netcom.com, but whatever you do, don't call him at home. His brother-in-law has runs a construction company, and has been threatening to take out our mae-west link with a back-hoe if we bug him. NOC refuses to deal with him altogether. As a workaround, the customer is dialing out from BRI#10 (s28 and s29 on scz-ca-pm15), but we have yet to sort out the details regarding the other half of the Centrex connection. For some reason, the customer was unable to dial up to BRI#10, but dialing out from it works. Buh. 10-10-96: Ralph should be ready to go and s0 & s1 are his permanante isdn - msh 10-21-96: Customer reports that since the turn-up of this circuit, he has *never* been able to dial out, and has been establishing a connection by dialing out from pm15 or pm20. Pacific Bell has been totally unresponsive in trying to resolve this problem, and someone needs to talk to Alice Cody about getting a credit for the whopper of a bill that will be coming to us due to the dialout charges. 10-23-96: Customer just found out that no Centrex circuit was ordered for the scz-ca side of the link, so having the customer's side as Centrex is totally pointless, and there's no way to avoid the usage charges; when he found out, he openly stated that the only reason he's not cancelling and going with UUNet is that this is an employee comp-link. He even suggested that the connect-time charges for the past month come out of the paycheck of the person responsible for ordering the circuit improperly. What an asshole. On a lighter note, a Pac Bell tech dispatched to the customer's site to investigate why he can't dial out, had a $5000.00 TPI isdn test set *stolen*, and had to sit in his truck for 4.5 hours (contemplating the error of his ways) while another tech was dispatched with a replacement. Upon arrival of the replacement, the problem obstructing dial-out was found! Due to a problem with the switch (load related?) there is a 4-6 second delay between dialing "9" (to escape the Centrex group) and the new external "dialtone". This is not something that normally occurs with ISDN circuits, so consequently, the Livingston OR-U at the customer's site offers no workaround option (e.g. delaying the dialing with commas doesn't work). The sad irony here is that if the circuit had been ordered properly, the customer wouldn't have to dial "9" in the first place! That being the case, the circuit will *not* be redesigned with the "assume 9" option; instead the original plan of redesigning BRI#10 in the NC ISDN huntgroup is being pursued by the customer himself. He refuses to deal with IC or even NETCOM in this matter, and is quoted as saying that if he had the option, he wouldn't deal with Pac Bell either. Police investigation is currently underway regarding the stolen TPI, and, needless to say, the customer is a prime suspect. 12-18-96: As the saga unfolds, there is much enlightenment. The four second delay dialing 9 was finally explained by the first competent PB tech I've spoken to yet in this caper (Paul Pickering). Apparently, sending a "9" to the switch on a Centrex ISDN link tells the switch that you aren't dialing normally, and it waits for further instructions (for 4 seconds) before providing an outbound data circuit (i.e. if it has a choice of providing voice or data, it needs to be told which at this time). Sending a "#" after the "9" will tell the switch that you are done giving it alternative instructions, and need an outbound data circuit pronto. I'm not sure the Livingston OR-U will send a "#" character, but the question is moot, since dialing "9" implies that the connection is outside of the Centrex group, and therefore will be subject to usage charges. Further irony can be found in the fact that the four-digit Centrex number for the lines in the scz-ca huntgroup is the last four digits of the main dialin number (459-9851). That's right, <<<<9>>>>851. What this means is that four digit dialing into the scz-ca ISDN huntgroup (Alice's preferred plan) will *NEVER* work; the switch won't see it as a four digit Centrex number, it will see a "9" as an instruction to escape the Centrex group, and then three meaningless numbers. At any rate, the current plan is to bring two new B-channels into the scz-ca POP: 471-3996 and 471-3997. There will be no modifications to the scz-ca ISDN huntgroup. Alice Cody has committed to having the new BRI available by the end of December. Mike Haley has reiterated his commitment to get a refund for any and all usage charges incurred on this link since it was turned up. Ralph Pearson has been admitted to a rehabilitation facility, but should be available by the end of the month. 01-05-97 Alice Cody has fallen short of her commitment to have this circuit up and running by the end of '96. Instead of redesigning BRI#10 on pm15 (the original plan back in July '96), PB brought in a new pair, terminated on a block that had nothing on it and called it a day. The customer spent an afternoon with PB at our POP sorting out where the new circuit would connect. In the course of these machinations, it was determined that relocating the new circuit to one of the BRIs on pm15 would be a bad idea based on some problems with software compatibility experienced upon earlier attempts (the version that will allow multilink for Ralph's connection won't function with netcruiser dialups). The new pair was instead punched down to pm30:s0,s1. This renders useless the B-channels that were previously wired to those posts (469-7961, 469-7962 which need to be cancelled). Also, BRI#5 on pm30 is not working, and PB tests good to their demarc, so we will have to re-cable and/or swap that pm before BRI#5 can be used for a customer link. Naturally, both pm15 and pm30 have 1mb RAM instead of the minimum 4mb, so that will have to be fixed as well. So, all told, PB has now started from scratch by bringing in a whole new circuit, and guess what...IT STILL DOESN'T WORK! The new circuit is not picking up incoming calls from Ralph's end, and in contrast with every other BRI at the POP, is also unable to dial out to Ralph's side -- one step forward, two steps back. Ralph opened yet another trouble ticket with a request to dispatch a tech with a TPI ASAP. They gave him a commitment of 5pm tomorrow to have the circuit functioning. Funny. 01-06-97: AAAAAAAAAAAAAAAAAAARRRRRRRRGGGGGGGGGGHHHHHHHHH!!!!!!!!!! Ken(PB) and Jim Rose(PB field tech) worked on this today and discovered that 3996 and 3997 are out of service (i.e. not plugged into our router). Apparently, Jim Keller (PB field tech) with whom Ralph worked last Thursday accidently relocated the pair that wasn't making it to the router (BRI#5) to the posts that are supposed to have 3996 and 3997 on them. Ken(PB) figured this out when Ralph had him dial each BRI on pm20 including the disconnected one (469-7961,7962 -- which was out of service from his perspective, as it should be), and noticed that when he dialed 469-4360,4627, he picked up that the far end was configured for 471-3996,3997. In other words, the pair that used to go to s8/s9 is now connecting to s0/s1 which is where 471-3996,3997 are supposed to be. Ken has paged a field tech, and just in case this becomes a vendor-meet situation (Ken, upon insinuating that inside wiring is NETCOM's responsibility was promptly torn a new asshole by the customer), NETCOM is dispatching Novadyne. At the very least, they can investigate why the fucking air-conditioner isn't working (POP is 100 deg F). If they are able to locate a new ISDN portmaster (with 4mb even!), then we could kill a few birds with one stone. Speaking of killing, it is now 17:01pt, so Pac Bell has blown it again by missing yet another commitment time. 01-06-97: Neal Bahu (King of the Wild Frontier) has saved the day. Working with PB and the customer in a conference call, he was able to locate and rewire each port on pm20 (no more flakey high-density jack which accounted for the previous death of BRI#5). A detailed description of what goes where has been added to the scz-ca POP file in case PB goes back there and relables everything just to fuck with the customer (not altogether unlikely at this point). Once the punch-down locations were all verified, the router ports were configured appropriately and, in an historic, and long awaited moment of victory, the customer established his first CENTREX call FROM HIS SIDE, thus ending an eight month holocaust of stupidity and miscommunication. There are a couple of loose ends though, like the fact that pm20 (and pm15!) has only 1mb RAM, and the fact that the old BRI#1(469-7691,7962) needs to be cancelled, and the fact that there is a four-figure refund due NETCOM by PacBell, and the fact that the airconditioner in scz-ca is out of freon... That's all folks!!! 09-23-97: ...but wait! There's more. Our Telco group (notably Janet Monroe, and Charlie Greer) were able to explain to PacBell the error of their ways, and just received a check in the amount of $1200 to account for the usage charges billed to NETCOM for this line since its installation. Woohoo!!!