Bruce, They use different cables depending on the technology being used.
DS3: Coax cables OC-3, OC-48 & OC-192: fiber cables. The cables are usually being fed into the building with the normal copper cables. Stephan Monette Unlimitel Inc. Tel.: (877) 464-6638 Fax: (613) 482-1077 On 2011-02-18, at 3:53 PM, Bruce N wrote: > Thanks for the input again. I am assuming the cables do not travel much in > the outside world and the data-centers for your equipment and Bell CO is > either close by or maybe even the same building? Just wondering how they keep > those lines out of the hands of the lousy techs if any is making their ways > into the street boxes. > > Regards, > Bruce > > CC: [email protected]; [email protected]; [email protected] > From: [email protected] > Subject: Re: [on-asterisk] Noise on PRI link that is hearable - Really?! What > does that mean technically? (Thought it's not possible) > Date: Fri, 18 Feb 2011 15:49:13 -0500 > To: [email protected] > > Bruce, > > When you get several PRI-T1 into one location, Bell would look at bringing > either a single DS3 circuit (28 T1) or a full OC-3 (84 T1) circuit depending > on quantities. > > Bell delivers our PRI-T1 onto OC-48 and OC-192 to our datacenter and they > bring it down to OC-3 to our cage in the same data centre. > > Thanks, > > Stephan Monette > Unlimitel Inc. > Tel.: (877) 464-6638 > Fax: (613) 482-1077 > > On 2011-02-18, at 3:42 PM, Bruce N wrote: > > Andrew, > I doubt there is ANYHING in the boxes that run close to 130V (I am not sure > about the sealed secluded DSL red box). Techs on daily basis cut and displace > the cables all over the box. You'd be surprised the sort of really really > messy boxes I have seen. Heck they probably knock off a cable or two as they > do a bad job at least 10-20% of the time. 130V probably would shock 10-20% of > Bell's stuff on daily basis :-) **I really wish the tech who knocked the pair > thought of it as 130V line and not go anywhere close to it. > > But yeah the red label just says "Do Not Disconnect" like Stephan mentioned > and it's also done for Dry Loop DSL. > > Stephan, > I would be interested to know what Bell uses for more than 1 or 2 T1 if not > copper wire? And wondering if that sort of service ends up in the pedestal > boxes on the streets at all because again I don't see much of good service > level to that. And thanks for your input. > > Dave, > I just got off the phone with the testing center lady tech and she checked > all the channels found nothing abnormal. She had to wait long time until she > got access to system ; Apparently they share a monitoring system and they > have to take turns. It's nice to know how they work :-). But she had no clue > what sort of tester they use and only thing should could tell me was along > the lines of that the test is placed at DSX Panel before the Pair Gain before > the PRI card....something like that. So, yeah it is at CO side. However, she > doesn't know what the tester looks and what kind of a noise it emits. The > reason she can see the problem is maybe because when she turns on her > listening tool the monitoring tool switches off like exactly when a channel > connects..... > > **To clarify, I am recording idle channel. "ztmonitor" tool when using Zaptel > or "dahdi_monitor" when using dahdi allows for this. The tool is very neat. I > am not sure if it's from Asterisk or Sangoma but allows for visual and for > recording of idle and non-idle channel. And yes, once the channel is up the > test is gone because now I don't hear the ear screeching noise but when > channel is down then the recording shows the Rx. I always use this tool to > tune analogue lines to milliwatt testers. Very easy and handy to almost > perfect the echo setting using this. > > Problem is that this noise level should not exists on an idle channel. Indeed > PRI is to be 0/0 for Rx/Tx and analogue line is to NOT be at any time due to > known reasons. > > Sample of readings: > > Channel 4: root@pbx $ ztmonitor 4 -vv > Rx: 12 ( 12) Tx: 0 ( 0) > > Channel 6: root@pbx $ ztmonitor 6 -vv > Rx: 0 ( 0) Tx: 0 ( 0) > > Channel 5: root@pbx $ ztmonitor 5 -vv > ( # = Audio Level * = Max Audio Hit ) > <----------------(RX <----------------(TX > #* > Rx: 228 ( 228) Tx: 0 ( 0) > > So, I just recorded the Rx (pre-echo) and (post echo) on Channel 5 and sent > you. That has the highest level of noise right now and it indeed shows the # > sign which is volume VS like channel 4 that show (12 Rx) but really audio is > too low to qualify for even 1 # sign. Though it is still noise. This wasn't > there previously. All other channels are CLEAR CLEAR like they should always > be when there is no call. > > Oh, and yeah of course they deny fault noting when our tech arrived > everything was fine but he reconnected as good measure :-) > > Regards, > Bruce > > > > > Date: Fri, 18 Feb 2011 14:39:57 -0500 > > From: [email protected] > > To: [email protected] > > Subject: Re: [on-asterisk] Noise on PRI link that is hearable - Really?! > > What does that mean technically? (Thought it's not possible) > > > > On Fri, Feb 18, 2011 at 2:04 PM, Bruce N <[email protected]> wrote: > > > > > I have sent you the file I recorded from the Tx stream and converted it to > > > a format that can play on VLC Media Player. > > > > > > > > Interesting. It's a sawtooth wave, not a sine wave. Not that it matters I > > guess but I would have bet on a square wave. > > > > The pitch variation only shows up when you play it in VLC. If you play it > > in Audacity, there's no pitch change. That solves one of the mysteries of > > "why would a Milliwatt have frequency drift". > > > > I can still see the reason for Milliwatt tests. Even though you've got a > > digital circuit, you could be putting that into a channel bank and > > terminating on analog circuits. I agree thought, I can't think of much use > > for it in testing a PRI. It's TDM, if your timing is ok, your frames are > > arriving intact and your signalling is setup right, you should have good > > voice quality. At least that's how I see it. > > > > I'd be interested to know how it works out. If I had to make a prediction, > > it would be that you tell Bell about the problem, the problem goes away and > > they deny changing anything on your circuit. > > > > One thing I'm not clear on is this: You say the problem goes away when the > > call is connected. Does the user hear this sound at all or are you > > recording idle channels? (I wouldn't have thought to try that or even though > > it was possible) > > > > Dave > >
