Re: [asterisk-dev] Rate limiting traffic to address potential DoS issues?
Kevin P. Fleming wrote: I'm sorry it took me so long to get back to this thread... there have been many good points raised and I'm happy to see that the general sense in the community is along the same lines as my original thinking :-) The issue that started this discussion is NOT an extreme volume of proper/valid signaling; instead, it is properly-formatted but otherwise bogus signaling that Asterisk has to respond to because the RFCs require it (in general). There is some evidence that if you send enough of this stuff at Asterisk, it will start to drop calls and otherwise behave badly. While we can do some work to try to make this have less drastic side effects, there are always going to be limits to how much traffic we can handle before falling over. If we can improve the code to handle 100 packets per second, is that really an improvement since the attacker can just send 200 packets per second instead? It seems that maybe the best proposal at this time is to just provide a method for counting the number of improper/bogus signaling packets received in a given time frame (per second, per minute, etc.) and then dropping (without response) any signaling that is not known to be valid beyond that limit. Would it be a large load on the system to "count the number of improper/bogus signaling packets received in a given time frame" by souce IP address, and then dropping (without response) any signaling. Notice I inserted "by source IP address" into your statement. Its not a lot different then what some firewalls do. Even if someone tried a DDoS, the above would catch it and reduce the load on the asterisk box. I'd suggest making two important tunable parameters accessible from some conf file though; 1. number of improper/bogus signaling packet threshold 2. amount of time before clearing the able Something like... after 10 bogus attempts, add the IP address in the table and stop responding. Then after 60 seconds, clear that IP address from the table (and start over). Obviously, it would be nice to see some sort of log entry that indicated the above action was taken. Rich ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Tuning Software Echo Cancellers
Inline... general comments I am working on trying to track down and eliminate echo on a PRI. I'm using Gen 2 TE-405P cards, w/ the MG2 echo canceller. I cannot enabnle AGGRESSIVE_SUPPRESSION because that causes dropouts in the speech that are unacceptable to my customers needs. I am awaiting the RMA of a pair of TE-405s for upgrade to Gen 3 so that I can put the VPM-450 hardware echo can card on them, but in the meantime, I am trying to tune the software echo cancelling routines to lessen the impact of the echo to specific local central offices where the Telcos just do not have any edge supression going on. I am using MG2 w/ the following settings in zapata.conf echocancel=256 echotraining=800 rxgain=+0.21 txgain=-0.0 The echotraining parameter was originally created for analog pstn lines, adding a delay (in the above example, 800 milliseconds) to allow analog central office equipment to settle down before the s/w echo can routines pulsed the line. The reflective energy from the pulse was then used to preload the echo can routines. Doubtful this parameter should be anything other then =yes on a PRI. The rxgain and txgain values need only be expressed in units; the numbers after the decimal point have no practical value. The rxgain was set using a local milliwatt number (line side). Exactly how did you measure that? (What type of transmission test set and what did you attach the test set to?) I'm still having trouble getting a long enough tone from the local C/O to do the txgain, hence the 0.0 setting. Apparently, X/O has their DMS 100 set to only provide 6 seconds of Millwat before it ends. No one seems to be able to figure out how to extend it on the local switch. The above statements don't make any sense. When you dial into a CO milliwatt generator, it generates a 1k tone allowing you to measure the level of that tone at your site. You then adjust rxgain. Since this happens to be a PRI, there is no pstn loss and therefore no reason to try and compensate for a pstn loss. How did you jump to a conclusion that you could use a CO milliwatt generator to set txgain? Using a value of 256 should give me a 64ms echo tail (from what I have read), but it does not seem to be enough to qwell the echo coming back from the particular trouble CO, which appears to have a 189 ms echo. Highly unlikely that "the particular trouble CO" involves 189 ms echo, unless that CO is half way around the world or is accessed via satellite facilities. I'd suggest going back to 128 and compare echo with 256 to the exact same distant tel number. Suspicion is you can't tell the difference and 128 is just fine. The sangoma folks created a utility that could be used to measure the echo and plot it in an excel graph. I've not used it since roughly 12 months ago and don't actually remember the utility's name. (Hopefully someone else on the list will remember and post it.) Think I'd start with parameters like these: echocancel=yes echotraining=yes rxgain=0 txgain=-3 and adjust txgain downward (more negative) by two or three units (eg, -3, -6, -9) to see if that impacts echo. If one of those values is better then another, then adjust by units around that point (forget the decimal point). Be sure to call the same pstn tel number for each test (and not a cell phone), and restart asterisk after each parameter change (don't use reload). ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] option for timestamps in log messages
Russell Bryant wrote: On Fri, 2006-07-28 at 05:30 -0200, Kaloyan Kovachev wrote: In 1.2 timstamps option in asterisk.conf have added timestamps not just in logs (actually changes the way they appear), but also to the cli for all actions including dialplan messages and devices registration. In trunk it does nothing - with or without it, timestamps are included only for the log messages, not for the dialplan actions. I guess the initial idea of timestamps option was for the cli, not for the log files and i am definitely missing it in trunk Sure enough. I did see the code that looked like it was intended to add timestamps the CLI verbose output, but I figured it never worked. In fact, it is correct in the 1.2 branch and was broken at some point in the trunk. In that case, I suppose I would propose keeping the option, but only having it apply to the CLI verbose output, and always having the timestamp in the logs. FWIW, I'd vote +10 for that approach. R. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] How to rotate between Stable and Trunk versions
Obelix wrote: I want to run a trunk version of Asterisk with the ability to switch back to a stable version. Because they will be running with the same .conf files and call management database, I want to be able to switch between them just my running a simple script - either by copying them to and from their storage locations or by the use of file links, and changing some of the paths in asterisk.conf Besides the bin and lib directories are there any other folders whose contents need to be checked? I don't expect to change any configuration files or scripts unless they contain configuration options that are version specific. Are there any such samples out there? If the stable and trunk versions are relatively close, then... mv /usr/lib/asterisk/modules /usr/lib/asterisk/modules-stable mv /usr/lib/asterisk/modules-trunk /usr/lib/asterisk/modules and restart asterisk. Lots of assumptions in the above including zaptel, libpri, and any addons are compatible with both trunk and stable, etc. R. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Corydon76 Issue Deleted: 0006925, 04-28-06 17:49 Corydon76 Issue Deleted: 0006920
I need two things -- strict policy, and info about what patch would be commited, if some issues would fixes, and what patch would not be commited, and I doesn't need to spend my time for supporting this patches. There is no answer to that question before the patch exists. We can certainly tell you whether your idea seems like a good one and is likely to be something we would accept, but until the actual patch appears nobody can make any decisions about merging. I probably shouldn't be getting in the middle of this, but it appears the underlying root issue here is actually "closing/deleting an issue without comments", and not necessarily the quality of a patch. Since the arbitrary closing/deleting without comment issue has been around for at least a couple of years, maybe that should be addressed by the advisory council in the form of a policy or whatever. Seems like most folks are fine with discussing the quality of a patch via the irc channel, but that's not a substitute for arbitrary closings. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] FXO with Call Forwarding
We are using Asterisk 1.2 and have a TDM 400P installed with 2 FXO ports – each of these is plugged into a separate PSTN line with its own phone number. We have everything configured pretty well, but one strange issue is occurring which I’m hoping you can shed some light on. We use call forwarding from the PSTN provider (Verizon) when we are going to be away. In order to turn on call forwarding, we grab an outside line and dial *72 and then the # we want to forward to. To disable call forwarding we dial *73. After we have forwarded our calls through Verizon, when a call rings at the forwarded line, we get a single ring in Asterisk before the call is forwarded. This behavior is expected as it happened with the old phone system. However, Asterisk doesn’t seem to drop that channel after that call rings in and it will remain in the “Off Hook” state until pulling out the phone line and plugging it back in to Asterisk. Is there a reason for this? Asterisk (and the associated TDM400 drivers) will not answer that ringing line unless you have something in your config that tells it to answer. That could range from having an "answer" statement in your dialplan to an improperly configured ivr, and possibly incorrect zapata.conf parameters. Without knowing what those sections of zapata.conf and extensions.conf look like, its anybodies guess what might be wrong. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Dropping incompatible frame....
Joseph Rothstein wrote: I have already posted this several times on the users list, and have never gotten a response. http://lists.digium.com/pipermail/asterisk-users/2006-January/135205.html http://lists.digium.com/pipermail/asterisk-users/2006-January/136122.html Other people seem to be having the same problems with different phones: http://lists.digium.com/pipermail/asterisk-users/2006-March/143926.html I am getting these messages on an asterisk server located at a customer: Mar 23 10:59:35 NOTICE[17891] channel.c: Dropping incompatible voice frame on Local/[EMAIL PROTECTED],2 of format slin since our native format has changed to g729 Mar 23 10:59:35 NOTICE[17891] channel.c: Dropping incompatible voice frame on Local/[EMAIL PROTECTED],2 of format slin since our native format has changed to g729 Mar 23 10:59:35 NOTICE[17891] channel.c: Dropping incompatible voice frame on Local/[EMAIL PROTECTED],2 of format slin since our native format has changed to g729 Mar 23 10:59:35 NOTICE[17891] channel.c: Dropping incompatible voice frame on Local/[EMAIL PROTECTED],2 of format slin since our native format has changed to g729 This message repreats itslef for up to ten seconds during which time a call is impossible. We were having this exact same problem in the past when we had their phones (both SNOM and Cisco 79XX) running on a server located in house. Now we are getting this same error message on the server that has been moved to their location, and is running g729 over IAX to our main External GW. Any help would be appreciated as this seriously effects this customer as they are very telephone intensive business. I'm running 7960's behind multiple inexpensive firewalls with g729 and svn trunk asterisk, and haven't seen those messages. What version of * are you running? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Bug marshal
> Olle suggested that I email this list with respect to offering my > services as a bug marshal. I currently know my way around chan_zap and > some of the zaptel code as a result of maintaining the history buffer > patches over the last year or so. > > If there's any area that needs urgent attention I don't mind seeing if I > can get into it. My main programming skills include C, shell-scripting, > PHP, MySQL and some assembler (68k/x86). Other skills include > networking (TCP/IP, Cisco routers/switches, Linux), network security > (mainly firewalls) and web development (on LAMP). > > I can use my kit at home for testing outside of working hours - I have a > TDM01B and an X100P clone, a Cisco ATA-186 (SIP) and both IAX and SIP > connections to providers. Given the cards you have available, might want to take a look at trying to identify why the TDM and X100p cards inject a transmission loss into the audio stream. Have a look at the old bugs 2022 and 2023. I'm in the middle of documenting specifically the transmission loss associated with the TDM vs Sangoma card. For example, if rxgain and txgain are set to 0, and one dials a milliwatt generator (or uses a direct attached tone generator), there is a significant transmission loss. If you have an interest in this, please contact me off list. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] multithreaded IAX
> > that'll surely increase scalability, when the bugs are ironed out. well > > done, mark ! > > Bugs? We've been beating it up for like 3 hours now and it seems to be > dealing with things quite nicely. Is the impact of this change primarily oriented toward the registration process, or will it also have an impact on established sessions when multiple iax links are involved? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: Repost: Re: [asterisk-dev] How does RFC2833 get indicated to the SIP peer
> > > Back in Asterisk 1.0.5, when we sent our SDP packet to the distant end, > > > we sent > > > m=audio RTP/AVP 101 > > > where the 101 which indicated that we wanted to get RFC2833 DTMF from our > > > other end. > > > > > > Now it's missing, and my peer (level3) is sending me inband DTMF. > > > > > > It's not obvious to me from reading channels/chan_sip.c (in either the > > > old 1.0.5 or the current 1.2.4) how this 101 gets on the end of my Media > > > Description line or how else the peer is supposed to know that I need > > > rfc2833 DTMF. > > > > > > Can somebody please explain? > > Do you have dtmfmode=rfc2833 in sip.conf for this peer? If so, let's > get a sip debug and open a bug on bugs.digium.com. Might also do another update as that was removed by Olle about a week ago, and then restored a few hours later. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] gr303
> I have a siemens ewsd switch, it supports gr303 links. What i want to do is > have one asterisk server connected to > the switch(gr-303) passing calls . Then use asterisk servers at customer > locations to handle voice and data either > over a data t1 or voice and data t1. Can asterisk be used as a concentrator? > If so how is best used? Using data > t1s and everything go into the asterisk server as voip and get passed to > gr303 then to the switch, or channelizing a > t1 using some for data, some for voice into the asterisk back out the gr303? > I've been researching the exact same thing in the last several months. Asterisk has gr303 support, but only enough to support its interaction with a remote concentrator/channel bank via a T1. One of the digium employees set up a configuration recently to loop two T1's together using gr303; one as a concentrator and one port as a network switch. He was able to complete calls through the loop mechanism, however that test does _not_ suggest there is a sufficient amount of gr303 actually implemented to allow it to be connected to an ewsd central office switch. There is no doubt the maintenance channel that normally exists between the ewsd switch and the remote concentrator does not exist in any form within asterisk, but maybe its not required either. That implies someone would need to configure asterisk separately from the ewsd, mapping entries one-for-one on both ends of the T1. We're getting close to attempting our first T1 connection between asterisk and the ewsd switch and hope it actually works. Everything is currently in place, but no attempt has been made to communicate as yet. For those that aren't familiar with gr303, it is a standards-based protocol for central office switches to interface to remote line units. It is supported by a large number of manufacturers in the central office switching enironment, but has basically gone unnoticed in asterisk (with the exception of Mark implementing base functionality for show/booth demonstrations). The protocol supports up to something like 1024 logical connections, but is obviously limited to 24 simultanous g711 conversations per T1 at any moment in time. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: SRTP with keymanagement, SIP over TCP
> >- ensure that you are testing against inexpensive equipment (Sipura > > is an SRTP device which is cheap...) > > Did Sipura ever release enough information for folks to make their own > "mini-certificates"? P.17 - P.19 of 841AdminGuide1105.pdf has some > good hints, but I haven't been able to make enough sense of it to > generate one from openssl. I have not worked with the 841, but have done some research involving the spa3000 and its use of certificates for updating config's remotely, etc. Since Sipura products seem to share a large amount of source code, etc, between various products, I'd guess the certificate mechanism for the 841 is the same as the spa products. If you have access to their support web site, there were some documents that explain how to generate a certificate. However, once the certificate is generated (which I did on a FC3 stock box), one needed to send the certificate to Sipura for signing. When I asked where to send it, I was told to contact sales. I have not done that yet, but apparently there must be a charge to have that done since the support folks were referring me to sales. (It also could be part of their merging of products and support into the Cisco/Linksys group; really don't know for sure.) The Sipura support seems to have dropped somewhat after the announced Cisco purchase/merger. ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] current cvs-head seg fault while compiling
fc3, current cvs-head from 1:25pm today... make[1]: Leaving directory `/usr/src/asterisk/stdtime' gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declaration s -g -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i686 -DZAPTE L_OPTIMIZATIONS -fomit-frame-pointer-c -o io.o io.c gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declaration s -g -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i686 -DZAPTE L_OPTIMIZATIONS -fomit-frame-pointer-c -o sched.o sched.c gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declaration s -g -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i686 -DZAPTE L_OPTIMIZATIONS -fomit-frame-pointer-c -o logger.o logger.c logger.c: In function `ast_queue_log': logger.c:369: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla> for instructions. The bug is not reproducible, so it is likely a hardware or OS problem. gcc: Internal error: Segmentation fault (program as) Please submit a full bug report. See http://bugzilla.redhat.com/bugzilla> for instructions. make: *** [logger.o] Error 1 ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Stable change log suggestion?
> > I'm interested as well, haven't seen anything on -cvs or in the UPDATE > > file about this, any more clues? :) > > The only things that go into UPDATE are non-backwards-compatible > changes; if we tried to list every new feature there it would be an > enormous list. How difficult (or time consuming) would it be to create a one-line entry into a README-Changes type text file when a bug gets applied to Stable? Something like Date, Bug Number, and Short Description maybe auto- exported from the cvs system when its applied? I understand not all fixes actually come through a bug entry, but it appears the majority do and that certainly would help folks understand what is/isn't applied. Example: 9/1/05 #4567 xyz doesn't work Stable v1.06 released 7/1/05 #3456 zap channel doesn't hang up Just a thought. Rich ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Questions
The way that I read it is the drivers (etc) required for the cards are being jointly developed (doesn't say anything about "who" is selling them), and it doesn't say that Intel (or whoever) can't sell their cards with drivers bundled. If you wanted to buy their package and apply it to your cvs-head-compiled stuff, its up to you to support that installation/config assuming they sell them individually. (Not a lot different then buying competing T1 cards.) Developing the stuff under ABE and bundling the card(s) with ABE is just another way to sell the cards & software. There's nothing in that announcement that precludes either or both approaches. I'd be fairly certain the approach will be governed by a "marketing" plan, not a "sales" plan, and certainly not be a "technical" plan. > If I read this right this is ABE only and locks anyone wanting to use > Asterisk with Dialogic cards would have to buy an ABE license. This also > takes away the freedom of being able to really make a flexible solution > based on Asterisk because you don't get the source code that ABE is compiled > with thus you're stuck. > > /b > > On 9/21/05 3:20 PM, "Greg Boehnlein" <[EMAIL PROTECTED]> wrote: > > >> It brings ABE to a larger market that's it. I have no problem with that at > >> all but it makes me question their commitments to Open Source. > > > > How? > > > ___ > Asterisk-Dev mailing list > Asterisk-Dev@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-dev > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > ---End of Original Message- ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] SIP presence notification updated (#3644)
> After months in the bug tracker, we've finally committed a lot of > changes to the SIP Subscribe subsystem in Asterisk cvs head. > > * It now works even if you reload the dial plan > * It does not accept subscriptions to extensions without hints > * It will terminate subscriptions if the hint does not exist > after a dialplan reload > > To get this to work properly, you > * Configure incominglimit for the device > * Add a hint to the dialplan for the extension > > Now, you will see if the device is online, if it is > occupied in a call or just available for a call. This is confirmed > to work with Polycom phones, SNOM phones and Eye-Beam. > > A big thank you to everyone that have been assisting me working with > this patch and to Kevin that solved the reload problem. Olle, For those of us that can't read code and have not been following the sip changes, any chance you could provide a real example of how to make this work properly? Rich ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] wait_for_sysfs issue?
> Rich Adamson wrote: > > > Are the messages anything that I should be concerned about, or, should > > I open a bug on this? > > Neither; as the message clearly suggests, upgrade udev. Version 039 is > very old at this point, I believe version 062 is current right now, and > the entire wait_for_sysfs cruft has been removed. Thanks Kevin, guess that means I'll have to head towards upgrading the FC3 kernel, etc. I had been dragging my feet in that area since the systems have been running just fine. Rich ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] wait_for_sysfs issue?
FC3, cvs-head from 10:20pm Aug 6th (current) Just did a complete checkout and build, and /var/log/messages now contain the following messages: Aug 6 22:14:52 phoenix kernel: Found a Wildcard TDM: Wildcard TDM400P REV H (4 modules) Aug 6 22:14:52 phoenix kernel: Registered tone zone 0 (United States / North Am erica) Aug 6 22:14:52 phoenix kernel: usbcore: registered new driver wcusb Aug 6 22:14:52 phoenix kernel: Wildcard USB FXS Interface driver registered Aug 6 22:14:39 phoenix kernel: usbcore: deregistering driver wcusb Aug 6 22:14:39 phoenix kernel: Freed a Wildcard Aug 6 22:14:39 phoenix kernel: Unregistered Tormenta2 Aug 6 22:14:39 phoenix kernel: Zapata Telephony Interface Unloaded Aug 6 22:14:39 phoenix zaptel: Removing zaptel module: succeeded Aug 6 22:14:44 phoenix kernel: Zapata Telephony Interface Registered on major 1 96 Aug 6 22:14:44 phoenix zaptel: Loading zaptel framework: succeeded Aug 6 22:14:49 phoenix wait_for_sysfs[18113]: either wait_for_sysfs (udev 039) needs an update to handle the device '/class/zaptel/zaptimer' properly (no devic e symlink) or the sysfs-support of your device's driver needs to be fixed, pleas e report to <[EMAIL PROTECTED]> Aug 6 22:14:49 phoenix wait_for_sysfs[18115]: either wait_for_sysfs (udev 039) needs an update to handle the device '/class/zaptel/zapchannel' properly (no dev ice symlink) or the sysfs-support of your device's driver needs to be fixed, ple ase report to <[EMAIL PROTECTED]> Aug 6 22:14:49 phoenix wait_for_sysfs[18117]: either wait_for_sysfs (udev 039) needs an update to handle the device '/class/zaptel/zappseudo' properly (no devi ce symlink) or the sysfs-support of your device's driver needs to be fixed, plea se report to <[EMAIL PROTECTED]> The messages have been around for a while (prior to July 14th cvs-head) but don't seem to be impacting the operation. Are the messages anything that I should be concerned about, or, should I open a bug on this? Thoughts? Rich ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] current cvs-head issue?
Did a 'make update' from cvs-head this morning followed by 'make' and get: asterisk.o(.text+0x54): In function `ast_register_file_version': /usr/src/asterisk/asterisk.c:171: undefined reference to `ast_strip' collect2: ld returned 1 exit status make: *** [asterisk] Error 1 Anyone else getting this or do I need to do a complete checkout? Rich ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] End of * compile msg?
Would someone hit me with that clue-bat please? What's the meaning of the message following * compile? Your Asterisk modules directory, located at /usr/lib/asterisk/modules contains modules that were not installed by this version of Asterisk. Please ensure that these modules are compatible with this version before attempting to run Asterisk. app_adsiprog.so app_alarmreceiver.so app_authenticate.so app_cdr.so (etc) The literal translation would suggest that a bunch of stuff was existing in the modules directory, but when I check all modules have the correct timestamps. Am I really missing something? Rich ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Re: [Asterisk-Users] Alternatives to SpanDSP??
Cross posting on purpose to transition the thread to -dev The issue in this thread is the frame transfer rate for the TDM analog card almost always exceeds the 1.000 seconds expected by the design. The frame transfer rate seldem impacts voice (the missed frames aren't noticed), but seriously impact code such as spandsp. > From: Andrew Kohlsmith <[EMAIL PROTECTED]> > On April 27, 2005 09:04 am, Rich Adamson wrote: > > I would sort of disagree with the spiking thingie (now). If you modify > > the zttest app to provide timing output in terms of seconds and > > microseconds, you don't see the spiking impacting those measurements. > > Rather, you see 8,192 bytes arriving in something greater then 1.000 > > seconds on a very consistent basis. > > Do you have a copy of this patch? I'd like to work on this problem with you > (in my ample spare time, ha!). No I don't. I just inserted printf's in the 80+ line app to inspect the actual timing values (as opposed to viewing that mostly meaningless percentage number). > > The design of the card (and asterisk) is 100% oriented around receiving > > 8,192 bytes from the card every 1. seconds exactly. Any significant > > variation from 1.000 seconds will result in a missed frame (1024 bytes) > > sooner or later. > > *nod* > > > What I've not been able to figure out is "why" the delay. I'm 95% sure > > it has more to do with asterisk code (including drivers) then it does > > with other system interrupt handlers, interrupt latency, etc. Those > > _other_ things certainly can impact it, but there is definitely > > something within asterisk that is directly related to the TDM card > > and its drivers. (Its almost consistent enough to look closer at the > > clocking on the TDM itself. That assumes a clock on the TDM card is > > responsible for raising the interrupt to the O/S via the pci bus.) > > Well the clock on the TDM400P is the same as what is used in the T100P, X100P > (or is it X101P?) and TE110P. It's just a cheap crystal oscillator within > the TJ320 so at least in theory the same problem should exist with those > cards if it were an oscillator issue. That crystal oscillator is supposedly a standalone component that drives whatever other chips (on the card) the designer wants to use if for. Presumably, it is driving the 3050 (I didn't check). But, through some mechanism, the 3050 is serially sending pcm data bytes to the TJ320, and it appears _it_ buffers up that data and raises the pci interrupt to the O/S. So, any component associated with that process is including in my definition of "clocking" the interrupts (not just the crystal). > Even cheap oscillators are more accurate than this though. :-) I'm curious > though if the CPU spiking in the wctdm driver has something to do with it > (causing the time to stretch), especially since this isn't seen on the other > cards, only within that driver, and it's only that card that seems to have > it. If one includes a couple of printf's to watch the seconds and microseconds used in the zttest calculation, then execute 'zttest -v', the reported times will consistently be something like 1.021234 seconds. Even though vmstat shows the spiking, it does not show up in the time reported for the zttest to receive 8,192 bytes of data. That would suggest the spiking isn't the root cause for the TDM card's missed frames. Since the vmstat spiking occurs roughly every ten seconds, one would expect it to have an impact on at least some of the zttest output. But, I've not seen that happen as yet. Opinion: the TDM analog card is subject to a number of system level issues, but underlying those issues seems to be an asterisk-code problem (including drivers) that does not support receiving the expected 8,192 bytes from the TDM card in 1. seconds. (According to Steve Underwood, that was not a problem about six to nine months ago, but it is now.) > (I'll reply to your original post about the zttest stuff in -dev and we can > continue this there.) I'll modify the zttest.c app and post the mod's on the -dev list, and maybe we can narrow down the root cause for the TDM issues. Direct eamil for those that want is fine ([EMAIL PROTECTED]). I'll be out of the office for the remainder of today, but will continue with this later today or tomorrow morning. Rich ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] TDM-fxo card and zttest logic issues?
> On April 23, 2005 11:49 am, Rich Adamson wrote: > > I posted this to the -user list earlier and no responses as yet. > > > > Is there anyone on the -dev list that would have an interest in > > working with me to identify bus throughput issues with the digium > > TDM04b (analog fxo) card? > > Me. I have no phone lines at my house but could set up a test system at > work. > I have FXS lines at home and work and they both have trouble with passing > faxes to a real, honest fax machine. I'm working from a soho with cvs-head, single TDM card with four pstn lines coming from two central offices, multiple iax links, all on registered IP's. Anyone that cares to work with us can be given access to the system easily. The TDM card was just RMA'ed by digium and is the latest version with x101 fxo modules (as of two weeks ago). Rich ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Dialplan 'i' and DIALSTATUS bugs
> > ast-one dial(IAX2/)'s ast-two. Both are CVS HEAD within a week of today. > > > > ast-two's context for ast-one's type=user is somecontext. > > > > [somecontext] > > exten => 100,1,NoOp(One) > > exten => 100,2,Hangup > > > > exten => 200,1,NoOp(Two) > > exten => 200,2,Hangup > > > > exten => i,1,Wait(1) > > exten => i,2,Playback(tt-somethingwrong) > > exten => i,3,Hangup > > > > Now, when ast-one Dial(IAX2/[EMAIL PROTECTED]/300) I get an immediate > > failure > > with DIALSTATUS set to NOANSWER. > > > > This is bad. Why? Because I cannot tell the difference between dialing a > > valid extension that does not answer, and dialing an invalid extension, and > > thus it is impossible to provide a failover scenario. Further, extension > > 'i' > > is not being triggered even though it should. > > > > Similarly, I have a PRI and DIDs from 555-0001 thorugh 555-0030 inclusive. > > My > > 23 Zap channels dump into the pri context: > > > > [pri] > > exten => 555-0001,1,NoOp(0001) > > exten => 555-0001,2,Hangup > > > > exten => 555-0002,1,NoOp(0002) > > exten => 555-0002,2,Hangup > > > > exten => i,1,Wait(1) > > exten => i,2,Playback(tt-somethingwrong) > > exten => i,3,Hangup > > > > Now when someone calls 555-0003 the call gets routed to be. However, the > > 'i' > > extension again does not get triggered, Asterisk refuses the call and the > > Telco sends back a "number not in service" message. > > > > If I did NOT have 'i' in there I would agree with this behaviour. However, > > since the extension is invalid, I should be triggering 'i'. > > > > Can anyone refute this logic? I want to get everyone's opinion before I > > start > > an attempt to fix this. > > Next time try to use ACTUAL stuff from your dialplan. 555-1212 is NOT > correct unless your telco is REALLY REALLY WEIRD. The telco will send > 5551212 Telephone numbers do not contain non-numbers. Look a little closer... he didn't say a thing about 555-1212. (more coffee?) ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] BOUNTY: app_hangup from exten => h
> >>On April 15, 2005 08:06 am, Rich Adamson wrote: > >> > >>>; This section is the Last and handles 'no valid extension' > >>>[no-match] > >>>exten => _.,1,Answer > >>>exten => _.,2,Playback(invalid,skip) > >>>exten => _.,3,Hangup > >> > >>>where none of the includes have a _. except for the "no-match" > >>>catch all? That catch all is simply there to say "hey dummy, > >>>there is no match in the dialplan. Try again." > >> > >>As I suggested: > >> > >>[no-match] > >>exten => i,1,Answer > >>exten => i,2,Playback(invalid,skip) > >>exten => i,3,Hangup > >> > >>Am I missing something, or does the _. catchall catch an invalid extension > >>better than i? > > > > > > Tried that, doesn't work. So far the only thing that can catch > > an invalid extension is _. as shown above. > > You mean you can only catch ONE DIGIT invalid extensions with _. You > can catch all numeric extensions with _X. No, I meant the "i" extension doesn't work. The _. works fine as as catch-all no-match kind of thing for the entire dialplan. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] iax2 debug display problem?
> From: Steve Kann <[EMAIL PROTECTED]>
> Rich Adamson wrote:
>
> >Thanks Steve. How about just adding a new-line at the end of that
> >string so it doesn't mess up the remainder of the debug stuff?
> >
> >
> Each character is printed when a frame is pulled out of the
> jitterbuffer. So, the strings are each one character long. So, you
> could add a newline before each of the regular IAX2 debug things, but it
> would be easier to just make it possible to enable/disable these things
> separately..
Okay, can you take care of that some time or do you want me to enter
a bug on it?
Rich
> >
> >
> >
> >>Those letters are monitoring for the jitterbuffer. They've been
> >>described before.
> >>
> >>It could be made into an option to iax2 debug; i.e. iax2 debug
> >>jitterbuffer and iax2 no debug jitterbuffer or something..
> >>
> >>-SteveK
> >>
> >>
> >>Rich Adamson wrote:
> >>
> >>
> >>
> >>>RHv9 system, CVS-HEAD-04/07/05
> >>>
> >>>When "iax2 debug" is executed to observe an incoming iax call, cli shows:
> >>>
> >>>
> >>>Rx-Frame Retry[ No] -- OSeqno: 008 ISeqno: 012 Type: IAX Subclass:
> >>>LAGRP
> >>> Timestamp: 20010ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >>>Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 009 Type: IAX Subclass: ACK
> >>> Timestamp: 20010ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >>>LvvRx-Frame Retry[ No] -- OSeqno: 009 ISeqno: 012
> >>>Type: DTMF
> >>> Subclass: 3
> >>> Timestamp: 20563ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >>>Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 010 Type: IAX Subclass: ACK
> >>> Timestamp: 20563ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >>>vvovLvRx-Frame Retry[ No] -- OSeqno:
> >>>010 ISe
> >>>qno: 012 Type: DTMFSubclass: 0
> >>> Timestamp: 21363ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >>>Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 011 Type: IAX Subclass: ACK
> >>> Timestamp: 21363ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >>>vovLvvvRx-Frame Retry[ No] -- OSeqno: 011 ISeqno:
> >>>012 Ty
> >>>pe: DTMFSubclass: 0
> >>> Timestamp: 21963ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >>>Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 012 Type: IAX Subclass: ACK
> >>> Timestamp: 21963ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >>>vovvLvvRx-Frame Retry[ No] -- OSeqno: 012
> >>>ISeqno: 01
> >>>2 Type: DTMFSubclass: 0
> >>> Timestamp: 22623ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >>>Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 013 Type: IAX Subclass: ACK
> >>> Timestamp: 22623ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >>>ov == CDR updated on IAX2/[EMAIL PROTECTED]:4569-1
> >>> -- Executing Dial("IAX2/[EMAIL PROTECTED]:4569-1", "SIP/3000|15") in
> >>>new stack
> >>> -- Called 3000
> >>>v-- SIP/3000-2eaf is ringing
> >>>Tx-Frame Retry[000] -- OSeqno: 012 ISeqno: 013 Type: CONTROL Subclass:
> >>>RINGING
> >>> Timestamp: 23006ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >>>vRx-Frame Retry[ No] -- OSeqno: 013 ISeqno: 013 Type: IAX
> >>>Subclass: ACK
> >>>
> >>> Timestamp: 23006ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >>>
> >>>vvLv
> >>>LvvvLvvv
> >>>vLv--
> >>>SIP/3000-2eaf answ
> >>>ered IAX2/[EMAIL PROTECTED]:4569-1
> >>>Tx-Frame Retry[000] -- OSeqno: 013 ISeqno: 013 Type: CONTROL Subclass:
> >>>(255?)
> >>> Timestamp: 29016ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >>>
> >>>
> >>>Should I open a bug report for the above?
> >>>
> >>>Rich
> >>>
> &g
Re: [Asterisk-Dev] iax2 debug display problem?
Thanks Steve. How about just adding a new-line at the end of that
string so it doesn't mess up the remainder of the debug stuff?
> Those letters are monitoring for the jitterbuffer. They've been
> described before.
>
> It could be made into an option to iax2 debug; i.e. iax2 debug
> jitterbuffer and iax2 no debug jitterbuffer or something..
>
> -SteveK
>
>
> Rich Adamson wrote:
>
> >RHv9 system, CVS-HEAD-04/07/05
> >
> >When "iax2 debug" is executed to observe an incoming iax call, cli shows:
> >
> >
> >Rx-Frame Retry[ No] -- OSeqno: 008 ISeqno: 012 Type: IAX Subclass: LAGRP
> > Timestamp: 20010ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 009 Type: IAX Subclass: ACK
> > Timestamp: 20010ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >LvvRx-Frame Retry[ No] -- OSeqno: 009 ISeqno: 012 Type:
> >DTMF
> >Subclass: 3
> > Timestamp: 20563ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 010 Type: IAX Subclass: ACK
> > Timestamp: 20563ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >vvovLvRx-Frame Retry[ No] -- OSeqno: 010
> >ISe
> >qno: 012 Type: DTMFSubclass: 0
> > Timestamp: 21363ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 011 Type: IAX Subclass: ACK
> > Timestamp: 21363ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >vovLvvvRx-Frame Retry[ No] -- OSeqno: 011 ISeqno:
> >012 Ty
> >pe: DTMFSubclass: 0
> > Timestamp: 21963ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 012 Type: IAX Subclass: ACK
> > Timestamp: 21963ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >vovvLvvRx-Frame Retry[ No] -- OSeqno: 012
> >ISeqno: 01
> >2 Type: DTMFSubclass: 0
> > Timestamp: 22623ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 013 Type: IAX Subclass: ACK
> > Timestamp: 22623ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >ov == CDR updated on IAX2/[EMAIL PROTECTED]:4569-1
> >-- Executing Dial("IAX2/[EMAIL PROTECTED]:4569-1", "SIP/3000|15") in
> >new stack
> >-- Called 3000
> >v-- SIP/3000-2eaf is ringing
> >Tx-Frame Retry[000] -- OSeqno: 012 ISeqno: 013 Type: CONTROL Subclass:
> >RINGING
> > Timestamp: 23006ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >vRx-Frame Retry[ No] -- OSeqno: 013 ISeqno: 013 Type: IAX Subclass:
> >ACK
> >
> > Timestamp: 23006ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
> >
> >vvLv
> >LvvvLvvv
> >vLv-- SIP/3000-2eaf
> >answ
> >ered IAX2/[EMAIL PROTECTED]:4569-1
> >Tx-Frame Retry[000] -- OSeqno: 013 ISeqno: 013 Type: CONTROL Subclass: (255?)
> > Timestamp: 29016ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
> >
> >
> >Should I open a bug report for the above?
> >
> >Rich
> >
> >
> >___
> >Asterisk-Dev mailing list
> >Asterisk-Dev@lists.digium.com
> >http://lists.digium.com/mailman/listinfo/asterisk-dev
> >To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> >
> >
>
> ___
> Asterisk-Dev mailing list
> Asterisk-Dev@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
---End of Original Message-
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] iax2 debug display problem?
RHv9 system, CVS-HEAD-04/07/05
When "iax2 debug" is executed to observe an incoming iax call, cli shows:
Rx-Frame Retry[ No] -- OSeqno: 008 ISeqno: 012 Type: IAX Subclass: LAGRP
Timestamp: 20010ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 009 Type: IAX Subclass: ACK
Timestamp: 20010ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
LvvRx-Frame Retry[ No] -- OSeqno: 009 ISeqno: 012 Type: DTMF
Subclass: 3
Timestamp: 20563ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 010 Type: IAX Subclass: ACK
Timestamp: 20563ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
vvovLvRx-Frame Retry[ No] -- OSeqno: 010 ISe
qno: 012 Type: DTMFSubclass: 0
Timestamp: 21363ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 011 Type: IAX Subclass: ACK
Timestamp: 21363ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
vovLvvvRx-Frame Retry[ No] -- OSeqno: 011 ISeqno: 012 Ty
pe: DTMFSubclass: 0
Timestamp: 21963ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 012 Type: IAX Subclass: ACK
Timestamp: 21963ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
vovvLvvRx-Frame Retry[ No] -- OSeqno: 012 ISeqno: 01
2 Type: DTMFSubclass: 0
Timestamp: 22623ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno: 013 Type: IAX Subclass: ACK
Timestamp: 22623ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
ov == CDR updated on IAX2/[EMAIL PROTECTED]:4569-1
-- Executing Dial("IAX2/[EMAIL PROTECTED]:4569-1", "SIP/3000|15") in
new stack
-- Called 3000
v-- SIP/3000-2eaf is ringing
Tx-Frame Retry[000] -- OSeqno: 012 ISeqno: 013 Type: CONTROL Subclass: RINGING
Timestamp: 23006ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
vRx-Frame Retry[ No] -- OSeqno: 013 ISeqno: 013 Type: IAX Subclass: ACK
Timestamp: 23006ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
vvLv
LvvvLvvv
vLv-- SIP/3000-2eaf answ
ered IAX2/[EMAIL PROTECTED]:4569-1
Tx-Frame Retry[000] -- OSeqno: 013 ISeqno: 013 Type: CONTROL Subclass: (255?)
Timestamp: 29016ms SCall: 1 DCall: 00119 [217.160.244.186:4569]
Should I open a bug report for the above?
Rich
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] [OT] Freshmaker - END of Thread
> > I just chated with someone on the asterisk documentation > > channel, and they explained to me that the wctdm stuff > > is propiotary to Digium. > > > > This is something I did not know. > > > > So I am not going to persue trying to figure out that code anymore. > > > I'm not sure what you mean by proprietary. wctdm.c does seem to have > normal GPL type license headers. Can anyone else comment on this? I'd have to guess the person on the doc channel was actually saying the TDM card was designed/manufactured by digium, and the drivers for the card are specific for that card. In other words, its a proprietary card and disecting the drivers have no value other then to understand the code for that proprietary card. I don't think they were suggesting the code was non-GPL. Obviously, the comments at the top of wctdm say it is GPL. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] VoIP Call Sniffer
Yes, some. Switches forward packets at layer two (mac address), and learn the location of each mac address by listening to packets. Once it has learned the switch ports associated with the mac address, the switch will _not_ forward sip or rtp traffic to other ports not associated with the sip/rtp session. Example: one * with 100 sip phones on a corporate net with canreinvite=yes. All established phone-to-phone rtp conversations happen directly between the two sip phones. If this corporate net uses switches, you could not monitor the rtp traffic unless you had access to one of the switches in the rtp path, and set up a port mirror to watch it. Good security relies on multiple layers; the use of switches qualifies as a very simple example of one layer. UserID & passwords are another layer, while encryption is yet another, etc, etc. > So if I use switches does that offer any basic easedroping protection. > > -Original Message- > From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > To: Asterisk Developers Mailing List > Sent: Sat Jan 08 15:06:21 2005 > Subject: Re: [Asterisk-Dev] VoIP Call Sniffer > > > >>The Bad News: > > >> > > >>| VoIPong is a utility which detects all Voice Over IP calls on a > > >>| pipeline, and for those which are G711 encoded, dumps actual > > >>| conversation to seperate wave files. It supports SIP, H323, Cisco's > > >>| Skinny Client Protocol, RTP and RTCP. > > > > > > > > > This actually sounds very much like an Ethereal rip-off. Which has had > > > this functionality for at least two years. > > > > > > > Has anyone on the list actually gotten it to work? > > > > I installed it at several places on my network, just to play around. > > And even it situations where I'm pretty certain Ethereal sees the calls > > just fine, nothing gets reported by this program. > > If you are using ethernet switches, it won't see the rtp traffic. > > ___ > Asterisk-Dev mailing list > Asterisk-Dev@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-dev > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev ---End of Original Message- ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] VoIP Call Sniffer
> >>The Bad News: > >> > >>| VoIPong is a utility which detects all Voice Over IP calls on a > >>| pipeline, and for those which are G711 encoded, dumps actual > >>| conversation to seperate wave files. It supports SIP, H323, Cisco's > >>| Skinny Client Protocol, RTP and RTCP. > > > > > > This actually sounds very much like an Ethereal rip-off. Which has had > > this functionality for at least two years. > > > > Has anyone on the list actually gotten it to work? > > I installed it at several places on my network, just to play around. > And even it situations where I'm pretty certain Ethereal sees the calls > just fine, nothing gets reported by this program. If you are using ethernet switches, it won't see the rtp traffic. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] RFC: Moderating the Asterisk Mailing Lists
> > So the purpose should be clearly deliniated, and then an eval of how it is > > not > > being accomplished, or is being threatend can be done. > > > > The concern I have is that people are aware of and even if they disagree or > > are too lazy, they KNOW the rules of the list. > > Perhaps you are on to something. Maybe an actual moderation process > isn't required, just a link which clearly lists the rules and > "regulations" of the list. The link could be placed in the footer. > > > So I think that ensuring their awareness of the list rules is the thing to > > pursue. I think ensuring the rules are in plain view to be read before > > subscribing and sending a message after subscribing of the rules is enough. Why moderate when one can automate? What if - each new list member is emailed a somewhat abbreviated list of do's and don'ts and references (to how-to, faq, wiki, etc) as the initial result of successfully subscribing. - automate the list server to send an email back to the poster if html is detected - and maybe some sort of automated reply to the first x postings from new subscribers again reminding them of available references, resources and examples. - a monthly reminder (like many many other lists) to all list members as to how to unsubscribe, new references, etc. Just a thought ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] ZAP Channel Maxout.
Since a lot of folks seem to be sensitive to that 4800 number, keep in mind the primary issue that is significantly more important is 'how many simultanous channels in use'. E.g., if zero channels in use, why is 4800 a problem? (I'm not the original poster but just somebody that is rather sensitive to 'actual traffic' and not some meaningless max appearances / definitions. :) > As i still didnt do any load testing on TDMoE on asterisk, i can't > really tell for sure but i'm pretty sure it will blow up in your face if > you try to handle 4800 simultaneous channels. > > I also dont think the 20 pri / machine is a very good idea at least > not on an out of the box asterisk. > > > Zoa. > > > Kevin P. Fleming wrote: > > > [EMAIL PROTECTED] wrote: > > > >> Don't forget Lucent TNT and APX. TNT handles 680 DS0s, APX >4000 in 8U > >> chassis, transcoding to all codecs and SIP/H323/MGCP control. And > >> they are > >> order of magnitude cheaper than all of the above. [and particularly, > >> APX solution will be even cheaper than similar T400P-based solution] > > > > > > Yeah, the APX 8100 is very nice. Pricing on the secondary market looks > > pretty good too (under $40K for 64 DS1). It would cost over $20K just > > for the TE410P cards for that configuration, without any servers to > > put them in, hot-swappability, management overhead, etc. This is not > > even a close race :-) > > ___ > > Asterisk-Dev mailing list > > [EMAIL PROTECTED] > > http://lists.digium.com/mailman/listinfo/asterisk-dev > > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-dev > > > ___ > Asterisk-Dev mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-dev > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev ---End of Original Message- ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Voicemail sound level threads?
> Are there any threads anyone can dig up (and bump) on the > voicemail-too-quiet issue? And yes, Steve, I DTFG and didn't find > anything on it, and could not find anything immediately obvious in the > archives. Greg, There have been several on asterisk-users since about July 12th when bugs 2022 and 2023 were submitted. However, since the Subject line did not necessarily include those keywords, finding them via google is almost impossible. Before opening those two bugs, I had conducted several tests. Today, I summarized those tests at: http://www.routers.com/asteriskprob/asterisk-config.htm As sort of a short summary, I tested both the x100p and tdm04b cards with multiple pstn analog lines. Both exhibit the low voicemail volume problem. SIP or IAX users have not incurred the same problem. In addition, Frank has opened a case with digium support based on the same low voicemail problem using a digium TE405 T1 card. He has been working with John Bigelow (support) to document/diagnose the problem, however Frank's system is not Internet exposed. As of last week, I volunteered to contact John and allow him to use our * system to diagnose the problem since I can make our system Internet accessible and both of us have the same problem. I've not heard back from John as yet (Thanksgiving?). In an email/irc discussion with Mark relative to the problem, he asked if I would document the test config so that a digium employee (specifically James) could "lab" it and recreate the problem. I did that on August 27th and have never heard from anyone again. Around August 29th, Mark and Russell Bryant added the app_test routines to help diagnose the problem. Mark's comment of "I can definitely measure a surprising mismatch between FXS -> FXO and FXO -> FXS paths..." in 2023 indicates an issue was observed (but not yet diagnosed/fixed) involving a T1 card, but that app apparently is not usable by those of us with digium fxo (non-T1) cards. There has been some suggestions from bkw and others this could be a hardware/motherboard issue. I don't have a clue whether it is or isn't, but I don't think anything has formally or informally been ruled out at this time. Could it be something involving dropping a significant bit, word alignment, or some other weird thing? Don't know, but it certainly suggests there are some unknown x100p/tdm motherboard/system dependencies impacting these digium cards that are unknown at this time. (For those that haven't bothered to read bug 2022 and 2023, we've all tried the tip/ring reversal, rx/tx gain adjustments, different vm recording formats, no shared interrupts, zttest = 99.987793%, no GUI, latest cvs head several times since July 2004, etc. I believe I can say our * systems have been stable otherwise. I have not tried the "raw" vm recording format as I didn't know it even existed.) I can make our * system available to anyone with the skills to diagnose the problem, including three pstn numbers to access the system, sip acct, etc. I'm a non-programmer and really don't have a clue how to get closer to the problem at this point. Any thoughts? Rich Adamson ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [Asterisk-Dev] UK Caller ID patch and new CVS
> Rich Adamson [EMAIL PROTECTED] wrote: > > Its also fairly common knowledge the x100p was not designed/built by > > digium, but rather they choose to use an existing modem card that had > > the chipsets (etc) that could be used for entry-level systems at a > > very low cost, and those cards _were_ being manufactured in hugh > > volumes making the cost per card very reasonable. (Compare that > > cost to what you'd pay Nortel for the equivalent as one example.) > > Its certainly not difficult to understand the economics of that and > > its certain that most understand modem sales (worldwide) have > > dropped very significantly. That suggests the x100p-type (and the > > follow on x101p) cards will become more extinct over the next > > months/years. > > > The X100P cards seem to fall into two camps: "genuine Digium" or > "clones". That would seem to contradict your statement, although I > believe that you are correct. Perhaps someone could clarify this for > future reference. Think the digium vs clone thing has been beat to death over the last eight months or so. In support of the objective, I stuck with the genuine directly from digium. Regardless of the source, I wish I could contribute more in the area of tweeking the code associated with the various pstn interfaces (including echo cancellation) but my linux & C programming skills are very sub-elementary at best. Given my 20+ years as a technical telco engineer (including transmission engineering, central office engineering, etc), I understand the telephony piece vary well, have access to some central offices, but don't have a clue how to apply those skills to debug C code in linux. If someone could jump-start those skills in the form on helping me understand how to monitor variable values in the linux environment, etc, I think I could contribute towards improvemnet in some of these areas. I've been using Visual Studio for a fair number of windows projects, and can write/debug code in that environment. Can someone point me to an article or provide maybe a valid example of how one would montior the zaptel.c variable "chan->echolastupdate" (as an example only)? I'm assuming I'd have to insert some sort of printf statement and direct that output to my telnet session, but I don't have a clue how to do that. Or, maybe that's the wrong approach and I'm should use the linux debugger (never used it) instead. Can someone help me as a clueless beginner with an old Comp Sci degree? (pretty please) Rich ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [Asterisk-Dev] Problems with ring debounce on TDM400P FXO channel
I've not seen the disconnect supervision impact this, however simply picking up a bridged analog phone for a second or two is usually enough to cause asterisk to ring the appropriate dialplan entry. The ring detection / processing happens immediately after the analog phone hangup (not seconds later). I'd have to guess and say this happens about one of three calls handled by the bridged analog phone. Not very consistent. Applying the patch (changing 32 to 64 in wcfxs.c) seems to have a positive impact on it. Rich > I an still observing and know nothing about the platform yet, but an > analog trunk disconnect supervision signal (momentary reversal or open > cct) from the telco delivered about 6 seconds after hangup may be > interpreted as AC ring? As this event does not follow a hangup from > asterisk it will not be expecting that disconnect supervision signal. As > there are parallel device on the line how about the possibility of > capacitor discharge high enough to trigger ring detection? What > parameters does asterisk use to evaluate a ring is legitimate? > > Regards, > > Gerald Short > -Original Message- > Has anyone decided to experiment on this problem by varying the line's > signal impedance level? > > This sounds more like an impedance problem. > > Kris > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Courtnage > Sent: June 11, 2004 10:48 AM > To: [EMAIL PROTECTED] > Subject: Re: [Asterisk-Dev] Problems with ring debounce on TDM400P FXO > channel > > On 10-Jun-04, at 10:24 PM, Ron Frederick wrote: > > > I also have some other devices directly connected to that same phone > > line, > > in parallel with the TDM11B. I immediately noticed a problem in this > > configuration when one of the other devices went back on-hook after > > using > > the line. The wcfxs driver for the card recognized this as a "ring" > > event. > > I have the exact same problem, both at home, and at my customer's site. > > > I'm not sure if it would be safe to roll this change into the main > > tree, or > > if the longer debounce time might cause problems in some other cases. > > I would also like to hear some opinions on this. > > Thanks, > .. > Ryan Courtnage ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [Asterisk-Dev] Problems with ring debounce on TDM400P FXO channel
I spent a fair amount of time about three or four weeks ago trying the different options using the Silicon Labs tech sheet. I was attempting to verify whether the different settings had any impact on echo, and by simply listening (no instrumentation) I could not detect any impact. (3 active pstn lines from two central offices, all with the same identical issues.) I'm waiting on a 965DST transmission test set to help with the process, but it had to be sent to the manufacturer for repairs. Hopefully within the next week or so it should be here and I can spend some time trying to isolate the issues. I had not attempted to judge the impact of the ring debounce issue. Rich > Has anyone decided to experiment on this problem by varying the line's > signal impedance level? > > This sounds more like an impedance problem. > > Kris > > -Original Message- > On 10-Jun-04, at 10:24 PM, Ron Frederick wrote: > > > I also have some other devices directly connected to that same phone > > line, > > in parallel with the TDM11B. I immediately noticed a problem in this > > configuration when one of the other devices went back on-hook after > > using > > the line. The wcfxs driver for the card recognized this as a "ring" > > event. > > I have the exact same problem, both at home, and at my customer's site. > > > I'm not sure if it would be safe to roll this change into the main > > tree, or > > if the longer debounce time might cause problems in some other cases. > > I would also like to hear some opinions on this. > > Thanks, > .. > Ryan Courtnage > Coalescent Systems Inc > 403.244.8089 > www.voxbox.ca ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Problems with ring debounce on TDM400P FXO channel
> On 10-Jun-04, at 10:24 PM, Ron Frederick wrote: > > > I also have some other devices directly connected to that same phone > > line, > > in parallel with the TDM11B. I immediately noticed a problem in this > > configuration when one of the other devices went back on-hook after > > using > > the line. The wcfxs driver for the card recognized this as a "ring" > > event. > > I have the exact same problem, both at home, and at my customer's site. > > > I'm not sure if it would be safe to roll this change into the main > > tree, or > > if the longer debounce time might cause problems in some other cases. > > I would also like to hear some opinions on this. I've had the same issues since installing the tdm about a month ago. Just guessing and reading between the lines, the chipsets on the tdm card have a significant number of features/options/functions that do not appear to be implemented/used in the current * implementation. There are only a limited number of people that have the cards and the understanding to advance those functions, and Mark is one of them. His time is probably very limited in terms of extending the functionality. Since I too have the ring event problem, I just implemented the suggested patch to eval the impact. In the last hour, it seems to have addressed the problem without causing any other noticeable issues. (I don't have the x100p's in the system right now.) The primary tdm issues that I think need to be resolved over time include: - spurious ring events (pstn line disturbances as noted above) - callerid is less reliable then with x100p's - echo when using sip phones - unusual linux system events when using "service zaptel stop" & start (probably just a tweak or two on the script, but I'm not a programmer.) Rich ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Time to lock down v1.1?
Isn't it about time to lock down added functionality to v1.1 and fix the remaining bugs? There has been a significant amount of traffic on the cvs list, the irc and other channels with folks spending time adding new functionality to Head. Think its time to lock it down, fix the bugs that have been introduced, and get to "something" that the _majority_ can agree to call v1.1 Stable in real production terms. It's a known fact that bugs are not being fixed in Stable, and even Mark has suggested no one should be running Stable in a production environment. There has been a number of postings in the last few days relative to bugs in sip, iax2, zaptel, codecs, etc. The add-on folks are obviously also having problems keeping up with modifying patches to a constantly moving target, and applying those to Stable is fruitless. I'd even suggest that no v1.2 Head be created until such time as the majority of bugs are fixed, and that souce _then_ copied to whatever the next version is going to be called. All in favor? ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] OMG THE SKY IS FALLING!! NOT!!!
> Sadly, the article reads as more bogus than it really is. SIP really is > weak. RTP stream are almost universally unencrypted right now. Listening > in to a VoIP within your company is generally much easier than snooping > on a traditional call. I wonder how long it will take before encryption, > solid authentication, and other good stuff becomes widely deployed for VoIP? I don't disagree with the above at all, however as one person that does security assessments, I've got to wonder how many sip/iax/h323/xxx implementations are actually exposed to the Internet with unreasonable configuration settings. I'd have to guess that something on the order of 70% of the exposed implementations (or more) are left after the person 'finally got something to work', and few have a clue how to secure those exposures. (I know, has nothing to do with encryption, etc.) It wouldn't take a lot of effort to scan IP addresses looking for two specific udp port numbers (and a little password guessing in some cases) to find open machines to make long distance calls from. Its my opinion (for whatever that might be worth) that some additional focus (and documentation) should be completed that would help newbies and others secure there existing exposures way before worrying about encryption, DoS, conversation monitoring, etc. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: 802.11b a contraindication?
> > I agree that a more specific understanding of interactions between > > 802.11[b,a,g] and SIP RTP sessions would be worthwhile if it could be > > found or generated and posted to this list. Additionally, what would be > > more worthwhile would be a similar IAX2 study. I'll put this on my > > long and un-cheery list of "things to be tested", right beside satellite > > latency effects on IAX2... > > Some AP's claim they prioritize voice - I don't know how. Symbol have said > that for a long time, and they supported H.323 in their equipment. There's > a new QoS standard for 802.11, but I don't know how that works with various > protocols or equipments. Check 802.11e. There are only two common ways that network hardware supports QoS. One method has been to watch for the specific IP ports used by sip or h323, looking inside those packets to watch for rtp port negotiation, and then prioritize the traffic seen on those ports. The cisco pix firewall does something like that with their "fixup" statements for allowing access (not QoS). The second common way is to watch the TOS (Type of Service) bits in the IP header, and prioritize the traffic based on specific bit patterns. That's one typical way to handle QoS in cisco routers as an example. I'm with Olle in that I don't know what Symbol or others have actually implemented, however out of the box there aren't very many network devices that truly support QoS in any form. And, in most cases if they do support some form of QoS prioritization, their support is not well documented in their marketing/sales material or spec sheets. QoS really does not do much good unless the majority of network devices between the voip endpoints all support QoS. In the case of AP's, there is already a problem with queuing prior to the voip traffic "reaching" the AP from the wireless client (eg, queuing to grab a piece of the wireless bandwidth does not involve QoS). Even if all network devices support QoS, managing the queues is still a major operational problem. E.g., what happens when the high priority queue is full and additional traffic arrives? How do you know when the queue is full and how do you know when to add more bandwidth? I've been doing professional network performance analysis for corporations in 40+ states since 1993, and I've not seen any network support organization truly manage their bandwidth or network quality yet, let alone QoS. If one thinks about how current wireless endpoints control the quality of wireless transmission by varying bandwidth, and combine that with how one manages the QoS queues, don't think there will be any real implementations that actually work using current technology. The current stuff does work fine with voip for low usage wireless links, but as that traffic increases (or one/two wireless devices hog bandwidth) the voip traffic will be impacted one way or another. Those of us that have analyzed iax and iax2 queuing already know that well designed jitter buffers (etc) can handle 500 millisecond latency with hugh jitter variations and maintain quality audio. In the short term, there is more to be gained in optimizing the jitter buffers then there is in truly attempting to manage QoS on an end-to-end network basis. (Obviously there are some examples of where QoS can have a significant impact though, but most are temporary point solutions.) Rich ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Raising loop current limit on the Proslic (reg.71)
> > After I hit send I realized I was "out of context" with the original > > topic. For the central office based loops, the 12 to 30+ still holds > > true for many CO switches. There are still a large number of CO switches > > that are not current regulated loops; those are still I=E/R with E fixed > > at -48 and R varing depending on the distance. Try some 10 mile loops. ;) > > Yikes. I was not aware of this. Thanks for the note though, along with > Matteo's fixes for "heavier" loads for the TDM400P I think the archives are > much better off for it all. :-) Not that this has any real value, for grins I just checked one of our pstn lines. Stats: 51.8 vdc and 31 ma actual using a very old ITT desk phone. The short-circuit current (placing a ammeter directly across the tip/ring pair) was 37 ma, indicating the copper plant plus CO hardware was the equivalent of 1400 ohms. I don't have a clue what gauge of copper plant the telco is using, but I do know we're on an electronic CO and within dsl distance. (26 gauge telco cable runs about 80 ohms per 1,000 feet.) So from that, its fairly easy to determine whether the central office has any form of current-regulated loop, and obviously in this case it does not (31 ma verses 37 ma). Pure educated guess is we're about 10,000 feet from the central office. I've not heard of any case where a central office provides current-regulated loops, but then I'm not in a position where I would have any need to hear about them any more. (They may exist, just don't have a real clue.) For someone that is located right next door to the central office, I'd expect to see about 70 ma while someone five miles from the office is likely to see about 15 ma (give or take a little depending upon how the copper was engineered, etc). There is no such thing as a 20 ma standard or telco objective in the US other then as a order of magnitude value. As a side note, I also checked the "remote-disconnect-supervision". It consisted of approximately a one-second open loop (no current whatsoever) about five-to-seven seconds after the remote party hung up. (I'd suspect this is also central office equipment dependent and probably varies some between different types of offices.) Isn't trivia fun. ;) ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Raising loop current limit on the Proslic (reg.71)
> > The 20ma loop is sort of typical. It actually can range from a low of > > about 12 ma up to about 30+ ma depending upon how far away from the > > central office the user happens to be, the gauge of copper plant, the > > telco engineers, etc. > > uh... The whole *point* of current loops is that they are insensitive to > distance and have better noise immunity when compared to voltage > signalling. And even 30AWG is capable of handling 20mA. :-) > > The only thing that would affect the loop in your list is the telco > engineers, I'm afraid... That and craptastic sourcing equipment. After I hit send I realized I was "out of context" with the original topic. For the central office based loops, the 12 to 30+ still holds true for many CO switches. There are still a large number of CO switches that are not current regulated loops; those are still I=E/R with E fixed at -48 and R varing depending on the distance. Try some 10 mile loops. ;) ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [Asterisk-Dev] Asterisk server hangs
> > This never happen to me under redhat 7.3 but I just happen to checkout > > from cvs under Redhat 9 and now it's happening to me. So, I think is a > > version related issue with Redhat 9. Unless it's is also happening on Redhat > > 7.3 ??? > > We are indeed running on Red Hat 9. I don't remember if we have > experienced an Asterisk lockup (apart from a configuration error) but we > have experienced file descriptor leaks and unexplained terminations of the > Asterisk process, as well as it getting into a state where it could no > longer accept calls over CAPI. As a data-point only, we're running RHv9 with sip, moh, x100p's, and iax only. System has never hung, but call volumes are very low. Rich ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Re: [Asterisk-Users] CVS repository changes
> So, the CVS repository has been redone, like we said a couple of weeks ago. > This means that some modules will have to be checked out fresh -- just doing > "cvs update" (or "make update") will *NOT* work. The modules in question > are: > > asterisk > gastman > gnophone > libpri > zapata > zaptel For those of us that are asterisk users but not linux junkies (no disrespect intended), would you or someone post a simple email that _briefly_ summarizes a couple of the more common ways to update our source? I realize there has been bits and pieces posted in various emails, how about consolidating those into a one/two page summary. Thanks ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev
