Re: [Asterisk-Users] zttest
On Mon, May 16, 2005 at 08:59:23PM +1200, Damian Funnell wrote: Hi Waldo, I would be money on your problem being related to the accuracy of zttest. One way of checking IRQ's is to run cat /proc/interrupts, but it is a lot more accurate to run lspci -v and lspci -vb. I would recommend Googling the lspci command, although the output is pretty self explanatory. The TDM appears as a TigerJet card, not sure what TE410P will list as. PCI devices have their IRQ's dictated by the BIOS of the host system. How (and if) you can configure these manually depends on the type of BIOS you have... in our IBM xSeries 206 we had to actually juggle cards between slots to get it to assign a unique IRQ to the TDM400P. Good luck! Before changing IRQ in BIOS I had: 4: 23643 XT-PIC eth0, wctdm After changing IRQ in BIOS I had: b2:/usr/src/zaptel# cat /proc/interrupts CPU0 0: 51108 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 7: 23643 XT-PIC eth0, wctdm 14: 3073 XT-PIC ide0 15: 2 XT-PIC ide1 NMI: 0 LOC: 51070 ERR: 0 MIS: 0 Then I changed the TDM400P card to a different PCI slot and I get: b2:/usr/src/zaptel# cat /proc/interrupts CPU0 0: 6966 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 4:321 XT-PIC eth0 9: 6143 XT-PIC wctdm 14: 1099 XT-PIC ide0 15: 2 XT-PIC ide1 NMI: 0 LOC: 6929 ERR: 0 MIS: 0 But then I found other evidence of sharing (which I verified with lspci -vv): May 18 22:11:31 b2 kernel: Zapata Telephony Interface Registered on major 196 May 18 22:11:33 b2 kernel: PCI: Found IRQ 9 for device 01:07.0 May 18 22:11:33 b2 kernel: PCI: Sharing IRQ 9 with 00:02.0 May 18 22:11:33 b2 kernel: Freshmaker version: 71 May 18 22:11:33 b2 kernel: Freshmaker passed register test May 18 22:11:33 b2 kernel: Module 0: Installed -- AUTO FXO (FCC mode) May 18 22:11:33 b2 kernel: Module 1: Not installed May 18 22:11:33 b2 kernel: Module 2: Installed -- AUTO FXS/DPO May 18 22:11:33 b2 kernel: Module 3: Not installed May 18 22:11:33 b2 kernel: Found a Wildcard TDM: Wildcard TDM400P REV E/F (4 modules) May 18 22:11:33 b2 kernel: Registered tone zone 0 (United States / North America) The BIOS always showed that I was sharing an IRQ with something else regardless of the which of the four slots I tried. I ended up with the BIOS telling me I was sharing with the USB; I turned USB off in the BIOS along with everything else like serial and parallel ports.: b2:/usr/src/zaptel# cat /proc/interrupts CPU0 0: 24659 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 205151 XT-PIC wctdm 4:569 XT-PIC eth0 14: 1134 XT-PIC ide0 15: 2 XT-PIC ide1 NMI: 0 LOC: 24621 ERR: 0 MIS: 0 May 18 23:28:34 b2 kernel: Zapata Telephony Interface Registered on major 196 May 18 23:28:36 b2 kernel: PCI: Found IRQ 3 for device 01:0a.0 May 18 23:28:36 b2 kernel: Freshmaker version: 71 May 18 23:28:36 b2 kernel: Freshmaker passed register test May 18 23:28:36 b2 kernel: Module 0: Installed -- AUTO FXO (FCC mode) May 18 23:28:36 b2 kernel: Module 1: Not installed May 18 23:28:36 b2 kernel: Module 2: Installed -- AUTO FXS/DPO May 18 23:28:36 b2 kernel: Module 3: Not installed May 18 23:28:36 b2 kernel: Found a Wildcard TDM: Wildcard TDM400P REV E/F (4 modules) May 18 23:28:36 b2 kernel: Registered tone zone 0 (United States / North America) ...and lspci -vv shows no sharing either. The test numbers are quite similar to those of the stronger machine described near the end of this post. The test numbers were the same for all the PCI slots and IRQ combinations I tried. b2:/usr/src/zaptel# ./zttest Opened pseudo zap interface, measuring accuracy... 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 100.00% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 100.00% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% 99.987793% --- Results after 71 passes ---
Re: [Asterisk-Users] CNAM lookup: new method for Caller ID Name delivery
On Fri, May 06, 2005 at 10:20:55AM -0400, Nathan Goodwin wrote: John Todd wrote: Downsides: 1) They want you to sign an NDA before they'll discuss the methods with you. Industry typical. They should be reciprocal. Both parties have to announce anything confidential is going to be said, shown, or transmitted. You can refuse to receive the indicated material and ask questions about how your business might be affected after having received the indicated information. It is often used to protect pricing information or contract terms. It could cover interface technology to slow down the competitors. NDAs are often written in plain English and are 1-2 pages long. 2) They have a $100 monthly minimum charge. This charge seems like it invites small business and repels hobbyists. $100/month versus nX$1000/month for SS7 may be useful to some. I like your paypal idea. I think something like that will be available before too long. I like the idea of offering a full menu of SS7 services over IP using a paypal remuneration scheme. 3) There may be hidden problems with the application; I haven't run it, so I can't vouch for it. I know how CNAM works. It's bone simple. I think you can count on the Accudata offering working. Other notes: The clever integrator of this application will save themselves some lookup $ by caching the responses from the database into their own database, along with a datestamp. Contractual terms may prevent this. If it isn't agiast there agement, I would happy setup a resale server for this just as you said, and probly at the prces you listed, I will look into this abit more later today. Talk with Accudata. If you have a way to aggregate volume and deliver it to them from a single billing point, they probably going to listen. -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] TDM users: modified zttest.c for testing
On Thu, May 05, 2005 at 09:22:24PM -0600, Rich Adamson wrote: P3 1Ghz under Tao Linux 1.0 (2.4 Kenrnel) cvs-stable w/ X101P --- Results after 66 passes --- Best: 1.024461 -- Worst: 1.024420 -- Average: 1.024447 And on our new gateway box... P4 3.0 Ghz under Tao Linux 4.0 (2.6 Kernel) cvs-stable w/ TE405P --- Results after 106 passes --- Best: 1.023967 -- Worst: 1.023953 -- Average: 1.023960 Have you tried to use spandsp at all? How about trying a fax or modem on lines on the two machines? -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: Problems with TDM400P card
On Thu, May 05, 2005 at 08:46:45PM +0800, Steve Underwood wrote: Mike Mueller wrote: I am new to Asterisk, but so far, having looked at this thread (which is quite long and full of lot's of hard work), the zttest code, the Digium web site, and the spandsp website, and having talked to Digium sales/support about the TDM, I think the issue belongs the spandsp community. They may be able to point out an improvement to the TDM product that Digium may or may not implement. Or they may need to adapt to an improvement on new TDM cards. It does not appear that Digium has promised support to the spandsp add-on function to Asterisk. I also didn't see where the spandsp project was committed to staying up to date with each new revision of TDM card - that's what the community is for. Then you think wrong. This is totally unrelated to spandsp. Probably. I was careful to (CYA) point out my conclusion came only from what I learned in the recent discussions and research. Any FAX machine, modem, or other timing critical device has the same problems with these cards. I was hoping to learn if this was the case or not. But are all or some fax/modems not working with recent TDM? The system test becomes more complex now: The benchmark becomes a wide selection of reputable fax/modems. Pass 1 is TDM (including multiple revs of TDM, software and hosts) vs benchmark. Pass 2 is spandsp vs benchmark. Pass 3 is TDM vs spandsp. It's possible a pattern will emerge from Pass 1 that will obviate the need for Pass 2/3. Something is broken, and since it used to work OK with the hardware I am using now I assume it is the TDM driver. TDM not working with fax/modems is a powerful indictment against TDM. Also, if spandsp is reliable with spans and not TDM, yet another indictment accrues against TDM. By the way. Where is this spandsp community? I've never heard of them. :-) Ouch :) Where's your P.C.? Rich is a pretty strong advocate. He was using spandsp to slap TDM. I wasn't sure he could do that at first. Now I think its OK, but using modems and faxes to smack TDM will inflict much more pain. Lot's of users can be organized into a system test program the likes of which no private concern can match. This thread induced a spontaneous ad hoc system test using zttest. Pass 1 described above could be done as follows: 1. Write up the test procedure. The test cases are: - line to line (3 cases: fxs/fxs, fxo/fxs, fxo/fxo) - line to span (2 cases: fxs/span, fxo/span) - line to IP (2 cases: fxs/IP, fxo/IP) for a total 7 conduit cases. Running the test in two directions for each conduit combination yields 14 possible test cases for each modem or fax. 2. Specify how to report host, software, TDM, etc. configuration; write a script to compile the information. 3. Provide a wiki or something for test reports. I've got FXO and FXS TDM on order, so I'll participate. -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: Problems with TDM400P card
On Thu, May 05, 2005 at 07:57:49AM -0400, Andrew Kohlsmith wrote: My two fax machines (Canon IR3300 and Panasonic something-or-other) do not work with the TDM400P either on fax reception; fax transmission works fine. This is most certainly a TDM400P driver issue. Yeah. Getting smacked with a Cannon or Panasonic hurts. Couple this with the fact that the driver now seems to pull 100% CPU every 5 seconds or so and it didn't before and I think we have a good case for there being something weird in the driver that is causing frame slips or other weirdness that is generally not audible for most people but wreaks havoc even for G3 or ECM (I think that's the term for error-correcting fax) fax machines. As measured with top? Nah; we've been down this road. I just need a block of time to pull wctdm from about a year back and basically do a binary search until I find where the driver started pulling this insane CPU use every 5 seconds or so. diff 'em. It's much faster :). If you use an old driver revision then you can receive faxes? Can you use an old TDM driver in a new Asterisk rev? You comments on zttest and kernel process scheduler are very important, IMO. I don't know, I think Digium made a horrible mistake by not including even a small buffer on these cards. What was that? No buffering? That means its tx/rx ISR should have priority over those servicing interfaces with buffering. Is that happening? So maybe you won't find a significant diff between an old TDM driver and a new one. Instead, the problem may be coming from another driver that is not letting the TDM driver service its interrupts on time. Assuming there are a lot of samples from TDM missing - and that lack of buffering makes that plausible - this could be measured in a working system by dumping TDM input into a file over a 10 minute period as measured by gettimeofday and determining the amount of shrinkage that occurred. Using a long time period like 10m will reduce the effects of Linux scheduler latency and it will ensure capture of the 5-second-100%-CPU effect. -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: Problems with TDM400P card
On Thu, May 05, 2005 at 12:11:51PM -0400, Andrew Kohlsmith wrote: On May 5, 2005 11:13 am, Mike Mueller wrote: What was that? No buffering? That means its tx/rx ISR should have priority over those servicing interfaces with buffering. Is that happening? It's one of the primary reasons these cards are *so* interrupt and system sensitive. But remember; system didn't change, drivers did. the problem was not there with earlier drivers and is now. Therefore, since everything else has remained constant, the problem is with the drivers. Sounds like the problem is isolated. So you have a system that works with the old driver revision and doesn't work with the new driver revision? Can you identify a working revision and an early broken revision so we can do a diff and code review? Assuming there are a lot of samples from TDM missing - and that lack of buffering makes that plausible - this could be measured in a working system by dumping TDM input into a file over a 10 minute period as measured by gettimeofday and determining the amount of shrinkage that occurred. Using a long time period like 10m will reduce the effects of Linux scheduler latency and it will ensure capture of the 5-second-100%-CPU effect. Well I think we're missing frames because the driver is holding the system hostage for such a long amount of time every so often. Steve's proposed a couple of tests for measuring this, we just need to get off our duffs and do it. :-) Do you need to? Seems like code review time. I'll contribute a pair of eyes B-). -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: Problems with TDM400P card
On Tue, May 03, 2005 at 05:27:33PM +, Tony Mountifield wrote: In article [EMAIL PROTECTED], Rich Adamson [EMAIL PROTECTED] wrote: - a modified zttest.c run on both systems to show the delays in reading 8192 bytes from the TDM card as 23,850 microseconds lateness on the old mobo, and 24,000 microsecond lateness on the new system. No significant change resulting from the differences in mobo, pci structure, interrupt structure, cpu speed, quantity of ram, kernel differences (v2.4 vs v2.6), etc. See my response to your zttest-mod.c posting. I think it is 8000 bytes that are due every second, not 8192. That would make the timing on your new system pretty accurate if 8192 bytes are arriving in 1,024,000us. Tony is correct. You should expect 8000 octets/sec from a digital sampler on a POTS line interface. http://lists.digium.com/pipermail/asterisk-users/2005-May/105148.html Reference: http://www.ncta.com/industry_overview/cableGlossary.cfm?indOverviewID=41 Sample Rate - In analog to digital signal processing, the sample rate is the interval at which samples of an analog signal are taken. The sample rate for digital telephony, for example, is 8000 per second. http://www.freesoft.org/CIE/Topics/127.htm G.711 is the international standard for encoding telephone audio on an 64 kbps channel. It is a pulse code modulation (PCM) scheme operating at a 8 kHz sample rate, with 8 bits per sample. According to the Nyquist theorem, which states that a signal must be sampled at twice its highest frequency component, G.711 can encode frequencies between 0 and 4 kHz. Telcos can select between two different varients of G.711: A-law and mu-law. A-law is the standard for international circuits. -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: TDM users: modified zttest.c for testing
On Tue, May 03, 2005 at 09:28:23PM +, Tony Mountifield wrote: I wrote: In article [EMAIL PROTECTED], Rich Adamson [EMAIL PROTECTED] wrote: It would be very interesting to see everyone's results in running this, and even more interesting to report the results with the OS distro in use, mobo in use (if known), etc. If anyone actually get's a result that is very close to 1.000 seconds, I'd really like to know more about those systems. (email off list is fine if you want.) --- Results after 20 passes --- Best: 1.024003 -- Worst: 1.023981 -- Average: 1.023993 This looks very close to 1024ms instead of 1000ms. That got me thinking: I believe your premise is wrong. The sample rate of telephony audio is 8kHz. With 8-bit samples (uLaw or aLaw), that means 8000 bytes should be supplied in 1 second, not 8192. At a rate of 8000 bytes/sec, 8192 bytes will arrive in 1.024 seconds. snip [EMAIL PROTECTED] zaptel]# ./zttest-mod -v Objective: to read 8000 bytes from TDM card in 1.00 seconds. Opened pseudo zap interface, measuring accuracy... read(fd, buf, 8000) returns 1024 read(fd, buf, 6976) returns 1024 read(fd, buf, 5952) returns 1024 read(fd, buf, 4928) returns 1024 read(fd, buf, 3904) returns 1024 read(fd, buf, 2880) returns 1024 read(fd, buf, 1856) returns 1024 read(fd, buf, 832) returns 832 Whew! At least the kernel module is using the len :). 8000 bytes in 1.023988 seconds read(fd, buf, 8000) returns 1024 read(fd, buf, 6976) returns 1024 read(fd, buf, 5952) returns 1024 read(fd, buf, 4928) returns 1024 read(fd, buf, 3904) returns 1024 read(fd, buf, 2880) returns 1024 read(fd, buf, 1856) returns 1024 read(fd, buf, 832) returns 832 8000 bytes in 1.023998 seconds --- Results after 2 passes --- Best: 1.023998 -- Worst: 1.023988 -- Average: 1.023993 [EMAIL PROTECTED] zaptel]# So it looks like the pseudo driver is always handling 1024 byte chunks, and even if you ask it for fewer bytes, it takes 1024 bytes' worth of time. I think it should really be handling 1000-byte chunks in 125ms rather than 1024-byte chunks in 128ms, if it is supposed to be emulating telephony channels. Why? Computers are base-2 oriented and POTS digital telephony is based on adapting to human hearing perception and a massive installed base of analog equipment. Working with base-2 numbers in computer programs is common and often efficient. 1/8000 = 0.000125 sec/sample octet (8 * 1024)samples * 0.000125 sec/sample = 1.024 sec Looks good to me. But zaptel.c is Deep Magic, and I'd be interested in comments from those who are famliar with it in detail. Bah. Just your average 6459 line kernel module ;). I've seen bigger. Here are some guides: http://www.oreilly.com/catalog/linuxdrive2/ http://kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Re: Problems with TDM400P card
On Wed, May 04, 2005 at 03:58:52PM -0600, Rich Adamson wrote: First off, I want to say that I'm getting involved because this is interesting and I want to contribute. I am just getting started with Asterisk so smack me if I say something stupid. snip I think we all understand the 8000 per second. That's not an issue at all at the pcm level. However, the TDM card sends 1024 byte frames, not 1000 byte frames. Frame? It's an octet stream of one octet per 0.000125 sec. It doesn't matter if they are delivered in chunks of 50, 100, 1000, or 1024. Just got to use the corresponding time expectation: n * 0.000125. I understand in this thread from now on, frame means a group of 8192 sample octets that should arrive every 1.024000 seconds. The original zttest.c triggers on data=8000, and that translates into 8192 bytes each 1.024 second (etc). zttest.c looks fine to me (in absence of Linux scheduling delays). It loops 8 times, and count is 8192 8000 so the time report is made. First the seconds element of elapsed time is used to calculate how many chunks of 8000 octets should have arrived. Next the microsecond element is used to calculate how many additional octets should have arrived (1,000,000 / 125 = 8000). Consider the following: sec usec start5 998,000 now 7 22,000 (1.024 sec later when 8192 octets arrive) The calculation yields: 1. (7 - 5) * 8000 = 16,000 2. 16,000 + ((22,000 - 998,000)/125) = 8,192 octets should have arrived This calculation, however, assumes no unwanted delays from the Linux scheduler. zttest.c is a user space program. There is no guaranteed latency between the 8th read and the refresh of the now timestamp. A long delay could jack up the expected number of octets and make the percentage calculation go below 100%. The general Linux scheduling algorithm can insert some long delays where and when you don't want them. All of the numbers reported in this thread are in the 99.9% range aren't they? Given how this code is being run, I think that's fair indication that the TDM samples are coming at the expected rate. If you need better accuracy, then you'll need to put some tools into the driver code. So, 8000 bytes in one second is the same thing as 8192 bytes in 1.024000 seconds. Yep. 1.00 sec that is, and that is the problem in a nutshell. We're still looking for the root cause as to why the TDM card is missing frames in a large percentage of implementations, negatively impacting things like spandsp. Frames in this context means the chunks of 8192 octets collected in zttest. What I understood was that frames weren't missing. Instead some of these reports on 8192 samples were less than 100% which suggested samples were not arriving in a timely fashion. I contend that zttest is inherently incapable of making such a determination accurately, primarily because the calculation depends on low latency which cannot be assumed in a user space program running under the general Linux scheduling alorithm. (You could try SCHED_FIFO policy to improve things; can give code chunk and advice on how to not lock up the node if needed). According to Steve Underwood, spandsp _did_ work with the TDM card some time back and its his general feeling that something has changed that has negatively impacted it. When I called Digium they were forthcoming about recent problems and improvements when asked about defects being discussed on the user list. They said there have been recent firmware improvements with echo-can and some other stuff (the nature of which I can't remember). Could changes or flaws with echo-can have affected spandsp? I am new to Asterisk, but so far, having looked at this thread (which is quite long and full of lot's of hard work), the zttest code, the Digium web site, and the spandsp website, and having talked to Digium sales/support about the TDM, I think the issue belongs the spandsp community. They may be able to point out an improvement to the TDM product that Digium may or may not implement. Or they may need to adapt to an improvement on new TDM cards. It does not appear that Digium has promised support to the spandsp add-on function to Asterisk. I also didn't see where the spandsp project was committed to staying up to date with each new revision of TDM card - that's what the community is for. In summary, it doesn't appear that spandsp not working and zttest output is sufficient to cast doubt on the TDM cards. More comparison between working and non-working spandsp faxing apps might give more reliable clues about where the problem lies. Also, what other applications like spandsp are not working with TDM cards? Thanks for letting a noob jump in. This is some fun sh*t! -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com
[Asterisk-Users] Q.931 to SIGTRAN interface
Hi, In response to: http://lists.digium.com/pipermail/asterisk-users/2005-March/098214.html quote How about simply doing a Q.931 to SIGTRAN conversion module would that not be simpler to implement? /quote Implementing this idea would help Asterisk become integrated with SS7 gateways in a generalized way. A first step could reasonably be to implement a Q.931 to UDP connection. The next step would be to replace UDP with SCTP (now in 2.6 and being back ported to 2.4). Next would be an effort to implement M3UA/SUA/IUA. In parallel would be an effort to implement ISUP on Asterisk. I will contribute SIGTRAN and ISUP code to Asterisk under GPL from my working repository of those protocols. There also is a supposedly working M3UA in Sourceforge whose author still responds to email. -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Q.931 to SIGTRAN interface
On Fri, Apr 01, 2005 at 05:32:43PM -0500, Race Vanderdecken wrote: Thanks Mike, I am getting letters from Europe for doing ISUP first, after the D-Channel and LDAP are working. LDAP or LAPD? If LAPD, then it would be best to avoid that protocol. It's another level 2 protocol chewing up CPU cycles. Putting a socket on the south end of Q.931 is more appealing. Another suggestion has been to create Asterisk as an SG for other asterisk boxes their by taking load off the Asterisk backend farm. More info please. But I think it should run on a single box for the little guys too. The plan is to make the interfaces use sockets to communicate so that the processes can be migrated off the box if that is needed. Remember that Linux can do local host sockets that don't climb the entire stack so the performance penalty is not that great compared to the feature set of using sockets. I don't think an Asterisk box can generate enough calls to cause sockets related performance penalties. Five packets per phone call. What's the max call rate an Asterisk box can support? -- Mike ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
