Re: [asterisk-users] alarm POTS lines
You all do know that this is something you could be sued for since this is 'life safety equipment' ? I've heard from multiple sources that if it isn't against the nfpa that it will be very soon Ask yourself if you want to be subject to a lawsuit if someones house is robbed, someone dies, house/business burns down and the alarm panel is unable to communicate? Ask your insurance rep if they will cover you doing this type of voip stuff and they'll most likely tell you not too. Bottom line is this is NOT a smart thing to put on voip. Tammy Tammy A Wisdom Summit Open Source Development Group -Original Message- From: Ryan Wagoner rswago...@gmail.com Sender: asterisk-users-boun...@lists.digium.com Date: Sat, 4 Dec 2010 00:03:25 To: Asterisk Users Mailing List - Non-Commercial Discussionasterisk-users@lists.digium.com Reply-To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Subject: Re: [asterisk-users] alarm POTS lines On Thu, Dec 2, 2010 at 11:58 AM, Jeff LaCoursiere j...@sunfone.com wrote: Hi, I've brought this up in the past and there was a good discussion - am wondering if there have been any new developments. Our dialtone service, like I am sure is true for most ITSPs, touts the ability to drop your POTs lines for significant savings. For businesses we have a low-cost Atom based PBX and a fax relay setup locally with hylafax/iaxmodem to solve that issue, and it is working very well. We don't however, have a solution for their alarm lines. The problem is of course that modem calls over VoIP are flaky at best. Even though these alarm calls are low baud rate, when we test with the alarm company we only pass about 30% of the time (ulaw from customer site to our central switch, then out a T1). To be fair there is no QoS on their Internet links yet, and that certainly plays a role. But it seems to me that there should be a solution much like our fax relay, where we literally accept the fax call over the local LAN, produce a PDF file, transfer it to the central switch which then dials it back out over a T1. In that case the only modem over VoIP is on their local LAN, which has performed well for us. I would love to see a DSP modem that could answer an asterisk channel, send the data stream over TCP to some remote asterisk, which could then relay the stream by making an outbound DSP modem call on a PSTN trunk. Has anyone attempted anything like this? As an aside, since the recent thread on Seagate Dockstar installs, I have several running. This would be the perfect platform for the relay on the customer end, being so ridiculously cheap (I bought three for $30 each, plus 3 $10 4G USB sticks). So hoping this will spark some comments on the concept in general, and really hoping someone has actually tackled something similar. It could open up a nice niche for even residential customers with expensive POTS lines dedicated to alarm systems. Cheers, -- Jeff LaCoursiere SunFone j...@sunfone.com Alarm panel communication, at least with Ademco, is done only with DTMF. When I tested the Asterisk AlarmReceiver application I found that the DTMF tones were so short they weren't always recognized by my ATA in RFC 2833 mode. Changing it to inband DTMF worked better, but then I was having issues with the AlarmReceiver application. Have a look at the below link, which touches on alarm panel communicates. http://www.voip-info.org/wiki/view/Asterisk+cmd+AlarmReceiver Since the communication is done with short DTMF it only takes a few seconds once the remote end answers to relay the message. This is not the same as modem communication when sending a fax. At least for alarm communication the solution would be an ATA that can correctly recognize and translate the DTMF to RFC 2833. Then it is up to the remote end to correctly translate this back to DTMF to send over the T1. The below link explains the different DTMF modes supported by Asterisk. http://www.voip-info.org/wiki/view/Asterisk+sip+dtmfmode Ryan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] alarm POTS lines
On 12/04/2010 03:01 AM, Tammy A Wisdom wrote: You all do know that this is something you could be sued for since this is 'life safety equipment' ? I've heard from multiple sources that if it isn't against the nfpa that it will be very soon Ask yourself if you want to be subject to a lawsuit if someones house is robbed, someone dies, house/business burns down and the alarm panel is unable to communicate? Ask your insurance rep if they will cover you doing this type of voip stuff and they'll most likely tell you not too. Bottom line is this is NOT a smart thing to put on voip. Tammy Tammy A Wisdom Summit Open Source Development Group nfpa only applies where nfpa is actually a requirement, ANYTHING anyone does that is not required (residential fire and burglar alarm) is better than the alternative of nothing at all. Calling yourself a ulc certified monitoring center or something like that is a no no if you don't meet those requirements, but selling a service as what it is, is perfectly fine, if you are not guaranteeing something you can't provide you are in the clear. All that aside things are moving to direct tcp/ip communication, using voip to talk to antiquated monitoring equipment is just an interim fix as the consumer end technology is moving faster than the central station technology. The argument voip is unreliable compared to pots really is not true if everything is setup properly. tcp/ip and anything that lives on top of that protocol like voip etc., has much more flexible routing and failover than any pots circuit could ever hope to have, and can use multiple independant paths for communication, and the connection can be held open like a dvacs circuit for continuous monitoring without all the overhead of individual copper pairs and multiplexers at the monitoring center. Its hard for the manufacturers of this equipment to stomach though that a pc with a network card is actually more functional than a multimillion dollar piece of hardware they used to sell, so change is slow coming. -Original Message- From: Ryan Wagonerrswago...@gmail.com Sender: asterisk-users-boun...@lists.digium.com Date: Sat, 4 Dec 2010 00:03:25 To: Asterisk Users Mailing List - Non-Commercial Discussionasterisk-users@lists.digium.com Reply-To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Subject: Re: [asterisk-users] alarm POTS lines On Thu, Dec 2, 2010 at 11:58 AM, Jeff LaCoursierej...@sunfone.com wrote: Hi, I've brought this up in the past and there was a good discussion - am wondering if there have been any new developments. Our dialtone service, like I am sure is true for most ITSPs, touts the ability to drop your POTs lines for significant savings. For businesses we have a low-cost Atom based PBX and a fax relay setup locally with hylafax/iaxmodem to solve that issue, and it is working very well. We don't however, have a solution for their alarm lines. The problem is of course that modem calls over VoIP are flaky at best. Even though these alarm calls are low baud rate, when we test with the alarm company we only pass about 30% of the time (ulaw from customer site to our central switch, then out a T1). To be fair there is no QoS on their Internet links yet, and that certainly plays a role. But it seems to me that there should be a solution much like our fax relay, where we literally accept the fax call over the local LAN, produce a PDF file, transfer it to the central switch which then dials it back out over a T1. In that case the only modem over VoIP is on their local LAN, which has performed well for us. I would love to see a DSP modem that could answer an asterisk channel, send the data stream over TCP to some remote asterisk, which could then relay the stream by making an outbound DSP modem call on a PSTN trunk. Has anyone attempted anything like this? As an aside, since the recent thread on Seagate Dockstar installs, I have several running. This would be the perfect platform for the relay on the customer end, being so ridiculously cheap (I bought three for $30 each, plus 3 $10 4G USB sticks). So hoping this will spark some comments on the concept in general, and really hoping someone has actually tackled something similar. It could open up a nice niche for even residential customers with expensive POTS lines dedicated to alarm systems. Cheers, -- Jeff LaCoursiere SunFone j...@sunfone.com Alarm panel communication, at least with Ademco, is done only with DTMF. When I tested the Asterisk AlarmReceiver application I found that the DTMF tones were so short they weren't always recognized by my ATA in RFC 2833 mode. Changing it to inband DTMF worked better, but then I was having issues with the AlarmReceiver application. Have a look at the below link, which touches on alarm panel communicates.
Re: [asterisk-users] alarm POTS lines
jon pounder wrote: On 12/04/2010 03:01 AM, Tammy A Wisdom wrote: You all do know that this is something you could be sued for since this is 'life safety equipment' ? I've heard from multiple sources that if it isn't against the nfpa that it will be very soon Ask yourself if you want to be subject to a lawsuit if someones house is robbed, someone dies, house/business burns down and the alarm panel is unable to communicate? Ask your insurance rep if they will cover you doing this type of voip stuff and they'll most likely tell you not too. Bottom line is this is NOT a smart thing to put on voip. Tammy Tammy A Wisdom Summit Open Source Development Group nfpa only applies where nfpa is actually a requirement, ANYTHING anyone does that is not required (residential fire and burglar alarm) is better than the alternative of nothing at all. Calling yourself a ulc certified monitoring center or something like that is a no no if you don't meet those requirements, but selling a service as what it is, is perfectly fine, if you are not guaranteeing something you can't provide you are in the clear. You want to bet your business and liability insurance on that position? Anyone considering this direction had better run it by their business insurance risk management department, and a good lawyer versed in laws involved in the state(s) involved. All that aside things are moving to direct tcp/ip communication, using voip to talk to antiquated monitoring equipment is just an interim fix as the consumer end technology is moving faster than the central station technology. The argument voip is unreliable compared to pots really is not true if everything is setup properly. tcp/ip and anything that lives on top of that protocol like voip etc., has much more flexible routing and failover than any pots circuit could ever hope to have, and can use multiple independant paths for communication, and the connection can be held open like a dvacs circuit for continuous monitoring without all the overhead of individual copper pairs and multiplexers at the monitoring center. Its hard for the manufacturers of this equipment to stomach though that a pc with a network card is actually more functional than a multimillion dollar piece of hardware they used to sell, so change is slow coming. VOIP is NOT yet as reliable as a POTS circuit. The degree of unreliability depends on the providers involved, but network managers have yet to put into place It certainly is getting somewhat better, and one can skew the statistics with the volume of data involved, but when life safety issues are involved, it isn't there yet. Even Mobile ( radio ) backup is considered secondary for reporting, and then not for fire/sprinkler systems. the safest circuit for monitoring, though seldom available anymore, is the supervised loop to the monitoring station. A PC with it's inherent frailty is way down the list in terms of reliability John Novack -Original Message- From: Ryan Wagonerrswago...@gmail.com Sender: asterisk-users-boun...@lists.digium.com Date: Sat, 4 Dec 2010 00:03:25 To: Asterisk Users Mailing List - Non-Commercial Discussionasterisk-users@lists.digium.com Reply-To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Subject: Re: [asterisk-users] alarm POTS lines On Thu, Dec 2, 2010 at 11:58 AM, Jeff LaCoursierej...@sunfone.com wrote: Hi, I've brought this up in the past and there was a good discussion - am wondering if there have been any new developments. Our dialtone service, like I am sure is true for most ITSPs, touts the ability to drop your POTs lines for significant savings. For businesses we have a low-cost Atom based PBX and a fax relay setup locally with hylafax/iaxmodem to solve that issue, and it is working very well. We don't however, have a solution for their alarm lines. The problem is of course that modem calls over VoIP are flaky at best. Even though these alarm calls are low baud rate, when we test with the alarm company we only pass about 30% of the time (ulaw from customer site to our central switch, then out a T1). To be fair there is no QoS on their Internet links yet, and that certainly plays a role. But it seems to me that there should be a solution much like our fax relay, where we literally accept the fax call over the local LAN, produce a PDF file, transfer it to the central switch which then dials it back out over a T1. In that case the only modem over VoIP is on their local LAN, which has performed well for us. I would love to see a DSP modem that could answer an asterisk channel, send the data stream over TCP to some remote asterisk, which could then relay the stream by making an outbound DSP modem call on a PSTN trunk. Has anyone attempted anything like this? As an aside, since the recent thread on Seagate Dockstar installs, I have
Re: [asterisk-users] alarm POTS lines
Jeff LaCoursiere wrote: I don't think I have a prayer of hacking iaxmodem to do what is needed to emulate a modem though :) I can't pretend to know what an alarm system needs out of a modem, but as far as iaxmodem acquiring data-modem capabilities that part is already developing. IAXmodem inherits its DSP capabilities from spandsp, and you can see on the spandsp that certain modem types are already available in the newer spandsp snapshots. That doesn't mean that you can expect iaxmodem or spandsp to work for you anytime soon out-of-the box, but know that eventually you'll see this happen. Between the dockstar and the ATA (which I am already providing for dialtone anyway) it is around a $40 cost solution for me, and the customer gets to drop the POTS line, which is around a $30/month savings for them. I'd probably just eat the added cost to get the customer, and could even charge some modest fee for the alarm connection that would still in the end save them money. Look at fax, for example. Wouldn't we love to tell our customers to dump their old fax machines for scanners and email? Some people just won't until the thing catches fire or otherwise dies. There are many reasons besides ignorance that faxes (and thus fax machines) are still around. For one, there is a serious technological work-flow hurdle involved with the scan-to-email approach replacing fax completely because, for one, it's not like you can do that for every one of your would-be fax recipients. Consequently trying to replace faxing with a scan-to-email approach ultimately means that someone still has to do some faxing. As it's typically easier to send a fax than to scan/attach/email, work-flow productivity will actually drop by forcing the abandonment of fax machines (i.e. by utilizing a mail-to-fax service for intended recipients where a direct e-mail will not work). (I'm convinced that fax machines are with us for the long-haul. Now, whether or not futuristic fax machines operate directly with a POTS line or with IP connectivity seems clear that it will eventually become a hybridization, but I truly believe that those who engineer that future technology will necessarily have to divorce the IP-side of the systems away from the whole modulation/demodulation over audio channels bit. On an IP network it simply makes no sense to take a data stream, and modulate it to audio only to demodulate it back to a data stream again because the IP network makes the modulation/demodulation superfluous where it was necessary on the PSTN. So this running of T.38 FoIP over SIP VoIP is consequently a passing phase; it's not a solid-enough solution to replace traditional faxing.) So is there anyone out there with the DSP skills to do the iaxmodem-like part of what I describe above? Would a bounty raise any interest? As I said before, I think the work is already being done. And for what it's worth, the monthly $30 or $40 summed over years is a petty amount compared to the necessary development cost of the kinds of technologies you're discussing. You'll gladly pay $40 monthly for life than need to pay $100K to develop this stuff. A little more searching today turned up this: http://www.gouloum.fr/code/sm/sm.html Which is REALLY close to what I need... And note that it uses spandsp (albeit a newer snapshot than iaxmodem currently uses), so iaxmodem is therefore not far-off from where you claim to need it to be. Thanks, Lee. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Error messages with chan_dahdi
On 12/4/10 9:15 AM, equis software wrote: HI, I'm using asterisk-1.4.24, dahdi-linux-complete-2.4.0+2.4.0 and libpri-1.4.11.4 When dial, when 492131 answer, in console appear some error messages -- AGI Script Executing Application: (DIAL) Options: (DAHDI/g1/492131|60) -- Requested transfer capability: 0x00 - SPEECH -- Called g1/492131 [Dec 4 11:15:59] WARNING[7669]: chan_dahdi.c:1776 dahdi_enable_ec: Unable to enable echo cancellation on channel 2 (No such device) -- DAHDI/2-1 is ringing [Dec 4 11:16:02] WARNING[7669]: chan_dahdi.c:1776 dahdi_enable_ec: Unable to enable echo cancellation on channel 2 (No such device) These No such device errors when trying to enable the echocan are most likely the result of not having configured an echocan for the channel in /etc/dahdi/system.conf. See line 309 in http://svn.asterisk.org/view/dahdi/tools/trunk/system.conf.sample?view=markup -- DAHDI/2-1 answered DAHDI/1-1 -- Native bridging DAHDI/1-1 and DAHDI/2-1 [Dec 4 11:16:02] ERROR[7669]: chan_dahdi.c:8735 dahdi_pri_error: ROSE REJECT: [Dec 4 11:16:02] ERROR[7669]: chan_dahdi.c:8735 dahdi_pri_error: INVOKE ID: 3 [Dec 4 11:16:02] ERROR[7669]: chan_dahdi.c:8735 dahdi_pri_error: PROBLEM: Invoke: Unrecognized Operation These errors I don't know about off the top of my head (and they are probably the more critical ones for you I'm guessing). -- Shaun Ruffell Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] ISDN TE/NT Mode
Hi,am using an atcom isdn pbx its using a colegne HFC chip..It comes in TE mode..I want to switch it to NT mode.Its not possible to select NT mode in the GUI so I went to config filesmisdn-init.config and edited it there.But everytime I do misdn show port 1 its alway in TE mode.Can anyone help me with this ISDN stuff?CheersJames-- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Zaptel / Asterisk on Solaris
Hi Bruce, Thanks again for your generous response, please see a few comments inline On Sat, Dec 4, 2010 at 6:27 AM, Bruce McAlister bruce.mcalis...@blueface.ie wrote: Hi RR, Replies inline below *From:* asterisk-users-boun...@lists.digium.com [mailto: asterisk-users-boun...@lists.digium.com] *On Behalf Of *RR *Sent:* 04 December 2010 01:17 *To:* Asterisk Users Mailing List - Non-Commercial Discussion *Subject:* Re: [asterisk-users] Zaptel / Asterisk on Solaris On Wed, Dec 1, 2010 at 3:58 PM, RR ranjt...@gmail.com wrote: Zaptel package isn't installing though ...crashes midway complaining that: *Operating environment requirement not met.** This package requires Solaris 7 or better. checkinstall script suspends* huh? I'm running 5.11, which according to some rigorous mathematical calculations, I concluded IS better than v5.7. Unfortunately, I've been away from the development world so long that I can't remember where to go about hacking a package and extract the scripts etc to change the logic or fix whatever is causing it to believe that my OS isn't meeting the min. req. Lastly, w.r.t to running it within a VM, yes, I do understand the timing problems etc, but this exercise is just to document how to compile Asterisk/Zaptel under Solaris 10/11 so when I do get a real Solaris machine, I have already sorted out all the issues with installing/compiling etc Thanks \R As of this writing, I have recreated my Solaris VM with the latest Solaris 10 U9 version and have managed to install and load the zaptel driver. This is from the SolarisVoIP but it must be a really old (haven't checked the version yet). Now, trying to go crazy here and compile the stock Asterisk 1.6.2.14 with it. -- I suspected it would have been changes/differences between OpenSolaris and Solaris. The packages at SolarisVoIP were built on the standard Solaris OS, as you found out J Try to compile version 1.6.2.15-rc1 as I had issues with a “timersub” routine on 1.6.2.14 that appears to have been fixed in 1.6.2.15-rc1 -- Ok, awesome. Will give 1.6.2.15-rc1 a try although in the beginning I did see compilation errors w.r.t to timersub routine, I don't see them anymore. I think it was complaining about some library that I then created a soft link for in a lib directory and that seems to have got fixed. But neverttheless I'll get the build you recommend. Question for the Digium dev team (if they bother reading emails from lowlifes like me): Are their special optimizations/options/conditions/checks ALREADY in place within the makefile/configure files that detect Solaris and if we want to go really crazy then detect 64-bit Solaris? Do I just fix my library paths with the LDFLAGS and just run configure or should I be doing something more, modifying makefile, makefile.rules, makefile.opts or the configure script itself?? -- The makefile already has some options specific to Solaris, however, I usually edit the makefile to include /usr/sfw which is where the standard ssl etc libraries are located on Solaris. The default makefile looks for them in /usr/local. If you also want to keep your application in the /opt tree then you will need to modify the installation path as well. I seem to recall an issue with ncurses or tr or something along those lines which made me include /usr/xpg4/bin in the beginning of my PATH so that it found the proper tool in one of the scripts. Other than that it should build cleanly on Solaris. With regards the 64-bit build, I’ve not tried it yet, but bear in mind that the 64-bit libraries for the likes of ogg/vorbis are not there by default in Solaris, most of the other standard asterisk library requirements are, you should, in theory only have to export libdir/64 to link in the 64 bit libraries. I’ve not tried to build a 664-bit version yet so I’m shooting in the dark here. -- Ok, right so this is where I'm having serious issues almost every step of the way. The problem is the stupid paackaging of Solaris and the difficulty in obtaining packages for them and their dependencies. Like for a week I struggled with figuring out how I could install/upgrade solaris 8 over the network to Solaris 10 with JUST a minimal core and the devlopment tools like gcc, gmake and some libraries etc. then I gave in and decided to just install the developers Metacluster since compiling/building Asterisk on it was more important to me right now. Then if I want to stick with purely the Solaris version of everything, my only option is to manually download packages I think I need from sunfreeware.com. If I use pkgutil or pkg-get, then I end up with the CSW packages and that will add to the complexity of PATHs to my libraries and binaries. Anyway, now that I'm done b**ching about Solaris (haha) you have hit on the core of my problem. It's the library paths that are messing me up. So this is how I ran configure: *LDFLAGS='-R/lib -R/usr/lib
Re: [asterisk-users] Zaptel / Asterisk on Solaris
Hi Tilghman, Thanks for your response. Please see my response below. On Sat, Dec 4, 2010 at 2:17 PM, Tilghman Lesher tles...@digium.com wrote: Changes that you need to make to get Asterisk to compile reliably on Solaris would be welcome reports on the issue tracker. What we have now are paths that worked for someone at sometime. Adding extra include and library paths should not cause problems, but what really should happen is that the configure script should be detecting the right paths and automatically adding them to the Makefile variables. Our standard build script for Solaris (1.8 and trunk only) does not alter the source at all, but does set PATH and LD_LIBRARY_PATH to ensure that certain values are included, and it does compile and run (and pass) our unit tests. So as mentioned in my response to Bruce, I did try to prepend these library paths to the configure script via the LDFLAGS variable. You're right about all the includes and library paths. The problem is, as I've mentioned earlier, for non-developer people like me, this isn't second nature and eveytime I have to do something like this, it's usually months or many times years since I'd last had to build anything from source and modify something anything in the code. So it would help if after these unit and sanity tests that are done for whichever build/release/version, if these can be added to the README or INSTALL notes for Solaris, for *that* build in a file like INSTALL.solaris or something. This won't happen everytime or for every release/, and I understand and appreciate that but it's a bit hard to get this going whent eh only resource we have are the pages from SolarisVoIP people which is almost 3-5 yrs old and I have not heard from Joe at thrallingpenguin after I sent him 2 emails about 3-4 weeks ago. We'll we more than happy to help in whatever way, if we can get a bit of hand holding and relatively fast turnaround/attention from the developers who can just point us in the right direction ... don't have to use up your machines, dev cycles or testing time, we'll do all of that if we can get help in troubleshooting the build environment. Anyway, coming back to the point, so are you saying that I should try trunk or 1.8 instead of mucking around with 1.6x versions? Sorry I have got back to Asterisk after almost 3 years, so haven't kept up with where I should be going and is it better to stick with 1.6x or just go to 1.8 as there's no upgrades or backward compatability requirements for me. Once I get this going, I promise to have an updated document uploaded somewhere or will mail to the list so someone can put it on the wiki. Thanks, RR -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Version compatibility question...
On Thu, Dec 02, 2010 at 09:09:25PM -0300, equis software wrote: Hi, Could I install Asterisk 1.4.19, Dahdi 2.4.0 and libpri 1.4.3 ?? No. Asterisk 1.4.22 cannot use DAHDI. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
