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 jeff at sunfone.com
On 12/02/2010 10:58 AM, Jeff LaCoursiere wrote:> 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.It can't be relayed; the alarm protocol is interactive, so a solution analogous to T.38 must be used.> 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?Guess what? There is already a standard for this, called V.150, Modem over IP. It certainly would be possible to implement this sort of thing for Asterisk, and some small steps in that direction have been taken way in the past... I'd suggest doing some Google searching to see what you can find.> 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.Or those customers could switch to cell-connected alarm panels (which are rapidly becoming less expensive and provide reliability benefits), or even IP-connected alarm panels. Either choice would be better in the long term than trying to convince an ancient alarm panel's modem to work over a packet network. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming at digium.com Check us out at www.digium.com & www.asterisk.org
On Thu, 2 Dec 2010, Kevin P. Fleming wrote:> On 12/02/2010 10:58 AM, Jeff LaCoursiere wrote: > >> 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? > > Guess what? There is already a standard for this, called V.150, Modem > over IP. It certainly would be possible to implement this sort of thing > for Asterisk, and some small steps in that direction have been taken way > in the past... I'd suggest doing some Google searching to see what you > can find.I did find an interesting thread for this in 2006 :) I wonder if it is being made overly complicated, though. I guess what I was envisioning is something like IAXModem that would provide a serial device... if that could be done, to the point where minicom or similar could actually make data calls via a PSTN line, then I would be very close to what I need. I envision this: An ATA on the local LAN with a dockstar running asterisk. An instance on this machine of an "iaxmodem-like" DSP that registers as an IAX extension and can be called by the ATA. A "serial proxy" daemon on that same machine that has the tty device open and sees the inbound call, answers it, then constructs a TCP session to the "serial proxy" daemon on the remote asterisk server. On the remote asterisk server another instance of an "iaxmodem-like" DSP accepts the Hayes commands to dial out again to the alarm company's modem pool, and once connected starts feeding it the data stream coming from the alarm panel at the client's site, and sends back the replies in the same manner. I really think this would work, and the daemon wouldn't be that difficult to write. I don't think I have a prayer of hacking iaxmodem to do what is needed to emulate a modem though :) 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.> >> 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. > > Or those customers could switch to cell-connected alarm panels (which > are rapidly becoming less expensive and provide reliability benefits), > or even IP-connected alarm panels. Either choice would be better in the > long term than trying to convince an ancient alarm panel's modem to work > over a packet network.Totally agreed - but in our remote area of the world ancient technology will continue to be used for some time to come, and I need a way to sell service to those people that will refuse to replace any of their equipment. I don't think I am alone here... and the concept would also apply to credit card processing machines, ATM machines, and other embedded modem devices that will probaby be with us for some time. 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. 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? A little more searching today turned up this: http://www.gouloum.fr/code/sm/sm.html Which is REALLY close to what I need... Cheers, -- Jeff LaCoursiere SunFone
On Thu, Dec 2, 2010 at 11:58 AM, Jeff LaCoursiere <jeff at 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 > jeff at 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
On Sat, 4 Dec 2010, Lee Howard wrote:> > 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. >I did notice that he based his stuff on a newer spandsp, and that his app is actually functional to a point, though it is based on jack audio which I really don't need. So it doesn't seem far off at all. In fact it seems that it should be possible to take the functional parts from his work and merge it into iaxmodem. Not too far beyond my own capabilities, but for lack of time :)>> 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.Ah, but it is not for me personally, it is for the ~20,000 residents of the US Virgin Islands that currently pay $40/month for a POTS line just for their alarm monitoring. As far as the reliability of POTS lines - in our area, that is exactly the problem. The ancient copper pairs are rusting in our salt air and haven't been replaced in decades, and the phone company is dealing with bankruptcy, so won't be addressing it anytime soon. Dead lines are a common occurance, and I am willing to bet that many of the alarm panels are at this moment unable to place calls and the owner doesn't even know. Regardless the solution would also be good for non-emergency equipment like ATMs, postage stamp meters, CC machines, etc. Not that the "product" has a ten year life span or anything, but what does these days? Thanks everyone for the comments - I was unaware of the DTMF methods used by some panels, and may start running some tests in our lab. I'll post back to the list if we get anything working reliably. Cheers, -- Jeff LaCoursiere SunFone
On Thu, Dec 2, 2010 at 11:58, Jeff LaCoursiere <jeff at sunfone.com> wrote:> 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.You would desire the entire path to be UL listed if you are doing anything other than facilitating the phone call to the central station. There is app_alarmreciever in Asterisk, and furthermore the ContactID protocol is pure DTMF so that should work without issues. But why use phone lines at all? Recently I installed a DSC T-Link TL260GS which uses internet and GSM, there is no phone line plugged into the alarm panel at all.> 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.SIA format is 110 or 300 baud, ContactID is (rapid) DTMF. -- Med Vennlig Hilsen, A. Helge Joakimsen