Slashdot Mirror

Why? Simple: it was dictated by the hardware we used. To support a few hundred VOIP connections, you need to offload work like the codecs and in some cases the H.323 stack to DSPs and CPUs on the cards. These cards -- usually CompactPCI -- are very expensive. These cards don't give you a lot of choice on the platform to run: "you can have any color as long as it's black."

If you want telephony to use free OSs, talk to the vendors -- e.g. Dialogic (now Intel). Natural Microsystems (NMS) actually does release Linux drivers now (it didn't two years ago, Solaris was the only Unix available) but it's doubtful Intel ever will.

As stated before, Intel sells a nice MSI card available in both PCI and ISA form factors. I have developed for the cards under both NT and 2000 and both platforms seem to run stable. There are several SDKs available for the cards, but the one we choose to use was 'Visual Voice' by Pronexus. It was a toolkit available for VisualBasic which worked well, but I dont believe it is being sold anylonger.

Intel has a SDK made by them for the boards, and the boards come in various flavors. There are boards for use with T1/E1s, ISDN lines, MSI systems and there is also a board that can be used for general TAPI applications such as an IVR (Interactive Voice Response) system. As for Intels SDK, it seems to be able to be used in both VisualBasic and C++.

More info can be found at http://www.dialogic.com

I presume that this was the case in the UK (by your address and the term "rails"), but I don't think it was ever the case in the US. There were company imposed restrictions on what "official" equipment could be hooked up to phone lines, but those have long since been removed.

WHOA! Sorry dude, you still need approval under certain circumstances. Quoting:

Rules:
Governing Water and Electric Service November 1996
Los Angeles Department of Water and Power As Established September 4, 1983 and Amended by Resolution
PART 2-E DESCRIPTION OF ELECTRIC SERVICE
D. Alternating Current
Frequency, Voltage, and Phase
Single-phase loads with a service ampacity of 600 amperes or less at 240/120 volts normally will be supplied through one main meter. Where such service ampacity is in excess of 600 amperes, approval must be obtained from the Department regarding metering requirements and related facilities, including switches and circuits.

(1) Any single-phase motor having locked-rotor current not exceeding 46 amperes, and full-load running current not exceeding 12 amperes, may be operated at 120 volts.
(2) Single-phase, 240-volt motors installed for residential air conditioning shall be limited so that the arithmetical sum of the locked rotor currents of all motors in a particular unit shall not exceed 450 percent of the similar sum of full-load currents nor a total of 150 amperes.
(3) Single-phase motors of five hp or more may be connected to a service supplying lighting only upon special permission from, and in the manner specified by, the Department.
Single-phase commercial cooking and heating loads and other miscellaneous single-phase power loads may, at the option of the Department, be supplied through a three-phase service at 240 volts. However, approval for such service shall be obtained in advance if none of the individual loads to be supplied is three-phase.

Just when you thought it was all under control.....
......The latest elements in the EMC Compliance requirement.
In order to limit the ever increasing harmonic distortion imposed on the public mains supply the Harmonics and Flicker standards are to be introduced.
As from Jan 1st 2001, compliance with these Harmonics and Flicker standards becomes a mandatory part of the EMC Directive.
This applies to all products within the scope of these standards.

You might see if you can get a hold of a Dialogic Board.

See my previous posting about a system I implemented here .
The company that offered the dial-out product no longer produces interactive outgoing voice systems or I would include a link here.

You can look at commercial packages like that offered by VoiceGenie, or Nuance.

Bayonne, suggested earlier, has pretty strict licensing on it for commercial use.

VoiceGenie may be a little young yet with regards to their Linux offering, but it does seem to work ok.

You can check out LinuxTelephony.org, for more ideas.

Caveat with the Dialogic hardware:

• The drivers are closed source and only works on the 2.2.5-14.0 kernel.
• 
  It is dependent on the archaic LiS (Linux Streams) modules.
  Good Luck trying to install security patches or upgrades.
  
  Their hardware pricing is also very strange and counterintuitive.
  Often, More Features != Higher Cost.
  
  There is a new version of the Dialogic drivers coming out, but I've heard they are pretty unstable still, and may not be solid for many more months.

Check out the Bayonne project if you want to create the system yourself. It doesn't support a whole bunch of hardware, and to be honest this will be your biggest problem. Find hardware that is supported by linux and you'll probably find software/libs/apps for free.

Dialogic cards are probably your best bet, but they're not cheap, and you'll have to be careful in regards to which models work (well) under Linux. Some can be a nightmare. You might want to check out Pika cards too. I haven't used them, but I've heard they do the job.

If you're looking for a relatively cheap box that does all this for you, take a look at Ostel's IVR100B. Around $2k for a 4 port box.

Good luck.

Netergy

IBM's AlphaWorks

Lucent's PassageWay

NOTE: I've priced the lucent system, the quote that came back was in the six figures!!!

JTAPI is relatively new, and the only people with implementations are those who helped design the spec. If my company decides to sell the implementation I'm in the process of writing as a package, I'll be sure to email you.
--
He had come like a thief in the night,

An interface like TAPI or CSTA should not be too difficult to implement - I work a lot with PBX, PABX, un-PBX equipment, and a common request in the current call-centre market is for CT - interoperability between some agent-focussed CRM software, and the best telephony solution out there. Often the best way to go is a little bit of glue code sitting between the two.

The current business world being what it is, Win32 is where the IS team have their expertise, and that is where the direction is forced to go for now, but with the continual expansion of Linux and *BSD into the mainstream, it can't be too long before the big black box makers, Nortel, Lucent, Ericsson, Mitel, Tadiran, Toshiba, Panasonic, start wandering down the reliability route.

Another route worth watching is CTMedia. This is an emerging technology, still in development, but backed by M$. Although touted as an "Open Standard", the idea is based on a M$ OS, but may expand outwards - Dialogic (who make the hardware) have support for Linux currently.

And for something M$ should worry about - an interface they don't have much input into, see this article, specifically the bits about SCSA, although it's a good all-round discussion of various technologies.

/prak
--
We may be human, but we're still animals.

An interface like TAPI or CSTA should not be too difficult to implement - I work a lot with PBX, PABX, un-PBX equipment, and a common request in the current call-centre market is for CT - interoperability between some agent-focussed CRM software, and the best telephony solution out there. Often the best way to go is a little bit of glue code sitting between the two.

The current business world being what it is, Win32 is where the IS team have their expertise, and that is where the direction is forced to go for now, but with the continual expansion of Linux and *BSD into the mainstream, it can't be too long before the big black box makers, Nortel, Lucent, Ericsson, Mitel, Tadiran, Toshiba, Panasonic, start wandering down the reliability route.

Another route worth watching is CTMedia. This is an emerging technology, still in development, but backed by M$. Although touted as an "Open Standard", the idea is based on a M$ OS, but may expand outwards - Dialogic (who make the hardware) have support for Linux currently.

And for something M$ should worry about - an interface they don't have much input into, see this article, specifically the bits about SCSA, although it's a good all-round discussion of various technologies.

/prak
--
We may be human, but we're still animals.

An interface like TAPI or CSTA should not be too difficult to implement - I work a lot with PBX, PABX, un-PBX equipment, and a common request in the current call-centre market is for CT - interoperability between some agent-focussed CRM software, and the best telephony solution out there. Often the best way to go is a little bit of glue code sitting between the two.

The current business world being what it is, Win32 is where the IS team have their expertise, and that is where the direction is forced to go for now, but with the continual expansion of Linux and *BSD into the mainstream, it can't be too long before the big black box makers, Nortel, Lucent, Ericsson, Mitel, Tadiran, Toshiba, Panasonic, start wandering down the reliability route.

Another route worth watching is CTMedia. This is an emerging technology, still in development, but backed by M$. Although touted as an "Open Standard", the idea is based on a M$ OS, but may expand outwards - Dialogic (who make the hardware) have support for Linux currently.

And for something M$ should worry about - an interface they don't have much input into, see this article, specifically the bits about SCSA, although it's a good all-round discussion of various technologies.

/prak
--
We may be human, but we're still animals.

An interface like TAPI or CSTA should not be too difficult to implement - I work a lot with PBX, PABX, un-PBX equipment, and a common request in the current call-centre market is for CT - interoperability between some agent-focussed CRM software, and the best telephony solution out there. Often the best way to go is a little bit of glue code sitting between the two.

The current business world being what it is, Win32 is where the IS team have their expertise, and that is where the direction is forced to go for now, but with the continual expansion of Linux and *BSD into the mainstream, it can't be too long before the big black box makers, Nortel, Lucent, Ericsson, Mitel, Tadiran, Toshiba, Panasonic, start wandering down the reliability route.

Another route worth watching is CTMedia. This is an emerging technology, still in development, but backed by M$. Although touted as an "Open Standard", the idea is based on a M$ OS, but may expand outwards - Dialogic (who make the hardware) have support for Linux currently.

And for something M$ should worry about - an interface they don't have much input into, see this article, specifically the bits about SCSA, although it's a good all-round discussion of various technologies.

/prak
--
We may be human, but we're still animals.

I was using telephony hardware from Dialogic Corp. The cards were ISA based and handled either 4 or 16 POTS lines or up to 2 T1 terminations.
The cards shipped with libraries that had a C-based API and a straight-forward state machine was able to capture the interaction model very nicely. The whole system was implemented in C with a Motif GUI.
I think we were using Solaris x86, I noticed that there doesn't appear to be a mention of linux on the Dialogic site. This might be problematic. Perhaps other cards are available, I noticed that the more recent kernels have support for the PhoneJack hardware -- perhaps it can be used for this purpose.

These days, Dialogic offers their QuadSpan VoiceSeries PCI based cards that look like the modern version of the old cards that I was using. I implemented a tight table driven state machine for the interaction model. It was fun and very straightforward.
The system was used to call people in communities and alert them of changes in oil and gas drilling operations in their vicinity, as required by law.

I was using telephony hardware from Dialogic Corp. The cards were ISA based and handled either 4 or 16 POTS lines or up to 2 T1 terminations.
The cards shipped with libraries that had a C-based API and a straight-forward state machine was able to capture the interaction model very nicely. The whole system was implemented in C with a Motif GUI.
I think we were using Solaris x86, I noticed that there doesn't appear to be a mention of linux on the Dialogic site. This might be problematic. Perhaps other cards are available, I noticed that the more recent kernels have support for the PhoneJack hardware -- perhaps it can be used for this purpose.

These days, Dialogic offers their QuadSpan VoiceSeries PCI based cards that look like the modern version of the old cards that I was using. I implemented a tight table driven state machine for the interaction model. It was fun and very straightforward.
The system was used to call people in communities and alert them of changes in oil and gas drilling operations in their vicinity, as required by law.

http://support.dialogic.com/appnotes/a ni.htm was found via a quick search..

The technical detail is interesting (if you're a phone person).

There's a survey at http://www.dialogic.com/uk/forms/ossu rvey.htm which asks what OSes we use (and perhaps would like to use CTI on). It says UK on the URL and Diaogic customer on the page, but I'm sure they won't mind if we showed them our support for our favorite OS. If you would like to see a Dialogic SDK for Linux, please sign up!

There's a survey at http://www.dialogic.com/uk/forms/ossu rvey.htm which asks what OSes we use (and perhaps would like to use CTI on). It says UK on the URL and Diaogic customer on the page, but I'm sure they won't mind if we showed them our support for our favorite OS. If you would like to see a Dialogic SDK for Linux, please sign up!

There's a survey at http://www.dialogic.com/uk/forms/ossu rvey.htm which asks what OSes we use (and perhaps would like to use CTI on). It says UK on the URL and Diaogic customer on the page, but I'm sure they won't mind if we showed them our support for our favorite OS. If you would like to see a Dialogic SDK for Linux, please sign up!

My sources at Dialogic say they'll probably have a Linux port of their drivers out sometime early next year, while the good folks at Aculab already have Linux drivers for some of their products and will release more Linux drivers in the coming months.

Aculab is also pretty good about releasing hardware specs if you're really interested in doing a port yourself. Dialogic has never quite understood that they could boost sales of their products by releasing enough information to allow outside parties to write more drivers.