Fw: [Asterisk-Users] Digium FXO Interfaces don't support groundstart???
through or are blocked from double connection because the ground start recovers from the collision. It doesn't reduce the incidence of glare mathematically predicted. It justs copes with it by invoking an (unnecessary) 2nd trial. The very fact that the pre-seize test describe by the previsous contributor is used at all makes this evident. Think about it: Properly dimensoned, only three busy events will occur at all in the busy hour for a 24 server trunk group. Why is the pre-seize so vital? The problem is still there, it is beating the switchgear to death, but it is no longer causing subscriber complaints. 6. This is why I just can't believe the terrible incidence of glare described by the previous contributors. It either has to be a drastically under dimensioned trunk group, a colliding hunting order, or cockpit trouble in the hardware configuration of the trunks. 7. Analogously, it is better to avoid an accident than to drive recklessly and rely on air bags. Hope this helps. - Original Message - From: Bill Church [EMAIL PROTECTED] To: 'Frank Cofer' [EMAIL PROTECTED] Sent: Sunday, August 01, 2004 5:19 PM Subject: RE: [Asterisk-Users] Digium FXO Interfaces don't support groundstart??? I got a kick out of this. There is always an expert who thinks their 10 years of experience running cable has any relevance. -Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Cofer Sent: Sunday, August 01, 2004 3:23 PM To: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] Digium FXO Interfaces don't support groundstart??? He who knows not that he knows not, knows little; he who knows that he knows not, knows a lot. 1. Glare is the simultaneous seizure of a common facility using two separate independent universes whereby a decision at one end is not immediately know to the other. As mentioned previously, because any two points that are not the same in space are separated in distance, they are necessarily separated in time. The possibility of seizure of a given circuit from both ends simultaneously is minimized by careful design, but it is never reduced to zero. Thus the original statement, ...ground start eliminates glare... is simply false. You can tell it is false if you have any rudimentary knowledge of physics, which (currently) holds that the maximum speed any information can travel is the speed of light. Electrical circuits are much slower. Thus the means to communicate an independent decision made at one end, that is separated by a distance, is also necessarily separated by time to the other end. Due to this propagation delay, glare cannot be eliminated on any two-way circuit. This does not take craft credentials to recognize, it merely requires a modicum of logic and perception. 2. Without maligning your comparative lack of telephony experience of a scant ten years, it would be useful to bring up how the central office or the PBX know what the other end is doing. On older central offices that had line and cut off relays, ground start service was effected by simply removing the tip ground of a bifalor (two in hand) wound line relay. There was a line relay for every line in the central office. Doing this in effect preventing it from operating unless the ring conductor (the -48vdc power feed to the line) was grounded, closing the loop would no longer do. Until either the line relay or the cutoff relay (busy at central office) was operated, the central office was ignorant of the change of status of the distant end. So to operate a line relay if the ground was removed from it, the PBX had to place an earth ground on the ring side of the line for a short interval that would not only be safely more than the time to cause the line relay to operate, but also to hold it there until a circuit had been established and the associated cutoff relay operated by the central office to hold the connection. Typically this occurs in 20-80ms but, to be safe, the time for the PBX to ground the ring is set nominally to 150ms or so, or until ground is seen on the tip conductor at the PBX end. The latter is not seen until the call set up is nearly complete at the central office, since it is first extended from the inter- or intra-office trunk through the cut off relay. Since a subscriber line relay, modified as mentoned above for ground start, has only one half the ampere-turns of current to operate as loop start, its speed of operation is decreased greatly and the mark of busy to the central office (from the time the line is seized by the PBX at the distant end until such time the cut off relay operates) is markedly increased. From (1), above, it logically and inescapably follows that the time that the central office knows that the PBX has seized the line is increased over that of loop start because
Re: [Asterisk-Users] Digium FXO Interfaces don't support groundstart???
be extended to the equipment and through to the connecting circuits. And as soon as that is done, all of the circuits are exposed to longitudinal voltages to that earth ground from the transmission line. Believe me, this is a very bad idea. It is also unnecessary. 7. Digium is not alone in not offering ground start. Avaya, Nortel, and other major manufactures of key and PBX's have eliminated ground start other than accommodating diehards on some older equipment. You might argue that their reason is more value engineering rather than to get away from FEMF failures that are intrinsic to any such design. Or, you may argue that they did so because they no longer care about the benefit to the central office any more, or because they are no longer controlled by the Bell System and can do what's singly best for their customer. Or, you might argue that Bell Labs (Avaya) was unaware of the dangers of glare that are present when you don't have ground start as simply lacks the wisdom of your ten years experience. I don't know what there reasons were for abandoning ground start, but I think the reasons I have given above should certainly suffice. 8. How do you prevent (or minimize) glare on a two way circuit via fiber optic, since there is no earth ground? Your answer, if your head firmly is not implanted firmly in the sand, should make you come to terms that glare is independent of ground and, indeed, is independent of any supervision method. It is merely a function of time. No amount of signaling schemes can eliminate it for two-way circuits. One can only reduce it by speeding up the communication of the state at each end to the other end or lessening the probability that the event will occur by changing the hunt order. Even ISDN PRI using common channel signaling is still susceptible to glare on 2-way circuits and still employs inverse hunt order to minimize glare. 9. I have a hard time correlating anything but an overloaded or misconfigured trunk group that would be responsible for the severe problems given as horror examples you and the previous writer have related, since any glare interval is relatively short if the system is properly configured (inverse hunting sequence) and the probability that a circuit would be simultaneously seized would be relatively infrequent unless it is severely underdimensioned. How large was the trunk group you had, what was the traffic carried and what was the engineered grade of service? Did you check the time of disconnect of the associated central office trunk? What was the guard interval employed? Did you have immediate ring from the central office? Did you use change of state for an incoming call with loop supervison? Did you have reverse battery disconnect supervison from the CO? Finally, there are two times one should mention their credentials: shortly before they're hired and shortly before they should be fired. Lawyers argue credentials, scientists argue verifiable facts. Those that mention their credentials to persuade, don't even believe themselves. Tone down your rhetoric, forget your credentials, and think. - Original Message - From: Bruce Ferrell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 31, 2004 1:27 PM Subject: Re: [Asterisk-Users] Digium FXO Interfaces don't support groundstart??? First of all I use this in humor: Frank you ignorant slut! I have to disagree on your analysis. I worked in telephone COs (DMS250, Stromberg/Carlson) and with PBXes for over a decade. Glare can and is controlled by ground start signaling. It does so because the ground is tested for (or supposed to be) prior to dialing. It's called the pre-seize condition. On a T1 using robbed bit signaling, tip and ring conditions are converted into A/B signaling states in the channel modules of a channel bank. Ground start was the prefered signaling system for what was called Feature Group D trunks between Other Common Carriers and the RBOCs. Before FGD was available, we used loop start. We had incoming and outgoing trunk groups, hence no glare... Needless to say expensive. Because FGD had ground start, to cut interconnect costs, we went there as soon as it was made available. The 150ms pulse you described is called wink start, which was funky. I most commonly say it on systems using EM signaling. Gawd I hated those! YA know, the asterisk list has been for a lot of walks down memory lane :) Frank Cofer wrote: Glare cannot be prevented on two way trunks (it is physically impossible because the two ends are separated in distance and therefore separated in time and any independent decision to use it at one end is never seen instantly at the other end). Ground start does not decrease glare at all (it actually increases it) and use of ground start to eliminate glare is a common myth. This is because use of ground start (which uses only one side of the pair to earth ground to start a request
Re: [Asterisk-Users] Digium FXO Interfaces don't support groundstart???
Glare cannot be prevented on two way trunks (it is physically impossible because the two ends are separated in distance and therefore separated in time and any independent decision to use it at one end is never seen instantly at the other end). Ground start does not decrease glare at all (it actually increases it) and use of ground start to eliminate glare is a common myth. This is because use of ground start (which uses only one side of the pair to earth ground to start a request for service) increases the time to mark a central office line busy when it is seized from the Customer Premise Equipment (CPE), owing to its clunky signaling (150ms earth ground on the ring of the line) and the fact that it uses only one half of the current to start the line as loop start. Since it increases the time to signal the distant end, it increases glare. Its only benefit is to the central office because it stops a second seizure to the central office when a call disconnects from the central office end first, which would otherwise find a request (loop) as soon as the disconnect was effected. This is why ground start was introduced by the Bell System (when they owned both the PBX and the CO) since it would reduce the attempt load on the central office from large business users by 25% or more saving a lot of central office gear for a relatively small expenditure on the PBX end. Ground start has some ugly drawbacks, since it reduces signaling range, requires the normally isolated floating pair to be referenced to earth ground (which exposes the circuit to longitudinal spikes, noise and lightning) and requires the circuit to be muted during the imbalanced condition that occurs when the ring conductor is momentarily grounded to draw dial tone. Digium is right to leave it out. Most other informed, modern manufacturers do likewise. Ground start signaling referred to in T1 (which is an absurd label since there is no ground placed on a T1) is really after the Grey Code (only one signaling bit transitions at a time) and has nothing to do with glare or ground start signaling and is just a carry over label. Glare can be reduced by changing the hunt order from either end and to employ faster signaling. The former method decreases the likelihood that both ends will compete for the circuit at the same time and the latter reduces the window that a commitment has been made at one end and is still not known by the other end. Typically, the CO is set to hunt ascending and the CPE descending and this is still employed even in ISDN circuits. This is a terminal hunt and NOT a round robin hunting sequence. If you want to absolutely eliminate glare, use one way (incoming/outgoing only) circuits. I believe asterisk has a feature to set the hunt order preference. The disconnect problems you experienced with your Agilent PBX may be more likely related to the guard interval that a circuit is left alone at your end after it is used. Though ground start will appear to fix it, there are some issues of CO message rate three way calling that have caused grief (the CO interprets the next call as a flash for a three way call and holds the circuit rather than disconnecting it). This phenomena may have been misdiagnosed as glare, since the message unit 3-way calling was imposed as a default feature in certain jurisdictions. Increasing the guard interval to 2 or 3 seconds will suffice, or specify to the carrier that the 3-way calling is to be denied for your lines. Hope this helps. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 08, 2004 4:55 AM Subject: [Asterisk-Users] Digium FXO Interfaces don't support groundstart??? Hi All, I was surprised to be told by a Digium support person today that Digium's FXO interfaces (X100P, TDM400P FXO modules) don't support groundstart signalling. This surprises me because as far as I know in a typical PBX configuration with analog trunk lines, groundstart signalling is the only way to prevent Glare. I just purchased two TDM400P's for a system I'm building to replace our office PBX (Altigen). Since there are no statements anywhere on Digium's website about lack of groundstart support (Actually, to the contrary they boast about all the signalling support in their sales slick), I now need to decide if I want to return the products and switch to a T1 / channel bank configuration. I remember when we setup our current Altigen PBX, we had problems with glare and disconnect detection and so I went through the process of figuring out what was going on and learning about groundstart. After we switched to groundstart everything worked great. In a high use system, it's highly likely that a trunk will experience glare, which is annoying for incoming callers and system users. I'm just a bit baffled as to why Digium wouldn't support groundstart on cards designed to be PBX trunk lines. Someone please tell me I'm missing something.
[Asterisk-Users] Red alarm on T1 PRI but not on zttool
SYNOPSIS Erratic red alarm T1 PRI on asterisk, but zttool running concurrently during alarm shows no errors, irq misses, or alarms, on any span. Using asterisk and quad Digium T405P, configured as follows: Span 1 connects to ISDN PRI (fractional 8 B channels, D channel 24). Span 2 connects to T1 Mux and analog stations. Span 3 connects to ISDN PRI Nortel BCM hybrid key system digital trunk. Span 4 is not configured. Host system is Athlon 1.8GHz, 512MB running Gentoo Linux 2.4.20 vanilla kernel, RAID 1 (software Linux), 2 x IDE 80GB. T1 card shares no interrupt. After 12 hours to several days, asterisk detects a red alarm on the configured channels 1 through 8 of span 1 (ISDN PRI.) Concurrently run zttool shows no alarms, no irq misses, and no errors on any span. When the alarm is first detected, it bounces several times, then quits for 6 hours or so, then recurs. Suspecting a timing problem, the configuration has been repeatedly checked for proper clocking (to CO span 1) and this is also verified by zttool which shows sync source as Card 0, span1 on all configured spans. The original Digium TE410P Quad card was replaced with a Digium T405P with no improvement. Telco has replaced both Adtran HDSL2 smartjack and repeater cards. Problem is independent of traffic and occurs late night, early morning, weekends or during load. Simulated load of CPU does not produce any failure and CPU load is otherwise negligible. The utility zttest has been run on the new T405P card with no errors. Zttool shows red alarm if a span is disconnected, LB when under loopback test, but otherwise shows no errors on any span. Span 1 connects to telco Adtran HDSL2-R. Numerous loop around tests and 30m span pattern tests were performed over several days, and the span tested clear in both directions through to CSU with no errors. Span 2 connects to a Zhone T1 mux and shows no alarms or errors, either from asterisk console or messages (zap channels 25 -48). Span 3 connects to Nortel BCM PRI (fractional 8 channels, plus D on 24(channels 9-23 are deprovisioned); it likewise shows no errors. Span 4 is not connected and not configured. It has been swapped with Span 1 on occasion with no improvement. Upon occurrence of an red alarm condition on Span 1, all calls are dropped. Successive call attempts during the red alarm condition encounter 120IPM congestion tone. However, calls can still be made between BMC (Span 3) and the T1 (Span 2) when the red alarm is reported by the asterisk console on Span 1. Specifically, during a red alarm, only service through Span 1 is affected. Here is an example from the messages log (grepped for channel 1: Red): Jun 10 04:02:29 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 12 21:02:17 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 12 21:05:12 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 12 21:08:23 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 12 21:47:01 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 12 21:58:15 WARNING[163851]: Detected alarm on channel 1: Red Alarm ... the alarm continues bouncing, then eventually abates... Jun 13 01:44:57 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 13 01:52:19 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 13 12:15:15 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 13 12:20:32 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 13 12:25:45 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 13 12:40:02 WARNING[163851]: Detected alarm on channel 1: Red Alarm Jun 13 12:57:49 WARNING[163851]: Detected alarm on channel 1: Red Alarm .. it then subsides for several hours, e.g., none further as of Sun Jun 13 17:39:39 EDT 200. Debug output is apparently is suppressed during alarm. (This has been reported on bug report separately). Configuration (/etc/zapata.conf) span=1,1,3,esf,b8zs span=2,0,0,esf,b8zs span=3,0,0,esf,b8zs #span=4,1,3,esf,b8zs NOTES All cables, protectors, and the like, have been verified, reterminated or swapped. However, these types of errors should have been discovered via a short-term error test. The server and all connected telephony equipment is powered by two separate UPS's, and report no downtime during the red alarm events. Except during artificial load tests, the server's CPU usage has never risen above 1%. Error #500 errors occur sporadically, but without any clear relationship to the red alarms. UDMA was reduced from UDMA 5 to UDMA 3, but this failed to correct the error #500 problem. Debug and warning message logs have been retained. Inexplicably, the red alarms appear to occur with no external stimulus. QUESTIONS 1. How can the asterisk messages log show a red alarm, yet the zttool utility (running concurrently and watched during alarm transition) shows no red alarm? 2. What are the conditions that asterisk uses to declare red alarms? How does this
