Thus spake Aaron Nabil
Gee, thanks. Nice to know that "I'm closer than Garlic Whatziname", and that I haven't managed to make any major blunders in my first sentence.
I don't know why you'd say "assuming D4 of course" as RBS occurs at the same rate in both D4 and ESF.
Yeah...my apologies...mostly it was terminology thing. Of course the RBS occurs at the same rate in SF and ESF...didn't mean to imply otherwise. :) Just that it would occur at the 6th, 12th, 18th, and 24th frame in ESF since ESF has 24 frames compared to SF's 12. Same diff really...mostly a terminology thing.
Are you talking about CCITT mu-law encoding? Sure, CCITT mu-law enforces ones-density IN A SINGLE PCM CHANNEL. But when you stack mulitple channels together into a T1, how is one PCM channel supposed to know what's in the next channel? Well, it doesn't, and it's trivial to violate ones density with something like +127 in the DS0 1 (1000 0000) and -126 (0000 0010) in DS0 2, as they are simply catenated together in the T1 frame. 1000 0000 0000 0010 has a run of 13 zeros.
Uhm...ones-density requires no more than 15 consecutive zero's, so your run of 13 is fine. It also requires an minimum average of 12.5% of ones (I don't know the period over which this average applies), which is where the one in eight idea comes from I believe.
It only "eats" that bit in DATA. In voice (modems), that bit is still there, it's just noisy.
True...the bit is still interpretted in voice applications...so its not eaten per se...effectively, however, the bit is unuseable for practical purposes...that's all I was trying to say there.
Yeah, I was simplifying. In the context of the original message, I didn't see any value in driving home and looking up the exact substitution value in a reference book or on the web. Obviously you did. Good for you.
Actually I waited until I got back to work since all my reference material was at work...I didn't wait just so I could put the B8ZS pattern though...I wanted to confirm a few other things. :)
Your definition of ZCS (Zero code _supression_) would best be forgotten.
Dang...got that one wrong...my apologies...right idea...wrong acronym expansion. ZCS is almost never used any more...but it is something to be aware of...as I said...I ran into some trunks that had it configured and were causing considerable problems.
You are simply wrong. You are again confusing ones density in a single PCM channel with ones density in the T1 frame.
Sorry...I'm well aware of the possibilities of interactions between different DS0's in a frame...I am still correct though...mu-law encoding will enforce ones-density (up to 15 consecutive zeros) on its own, with no need for B8ZS (or the sucky ZCS).
Jeff, it's simply marvellous that you are able to use a search engine and come up with these "answers". In fact, it's a skill that I've wished would be more commonplace on a majority of mailing lists (especially inet-access). But in future, note that there is a difference between "knowing where to find something" and "knowing something". Both very useful, but in this case you are in the former category, not the latter.
Hey...I don't claim to be an expert on this...and I'll acknowledge that I didn't communicate well here (and got at least one detail wrong)...but I do have a fairly decent understanding of common T1 technologies. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.