I am complete newbie to Asterisk. I do have experience in building IVR and ACD applications using Dialogic hardware. (E1 cards). Though stopped working on telecom applications quite a while ago.
Now, I am doing an analysis for one of my would be client about building a system for teleconferencing. And I am hoping the experienced folks will guide in deciding if this is the platform we need.
The goal of the system is,
A user dials into a toll free number.
The call lands on the “system” we are attempting to build
“System” plays greeting and prompts to enter bridge number
Some business logic is needed in the system here (at the minimum, check if maximum number of people are already joined etc)
Connect user to the bridge
While bridge is active, can asterisk generate CDR records?
Now, what kind of hardware I am looking at? Does a T1/E1 board is sufficient? Does this board can be just network or it needs Network + Voice resources on it? Any suggestions?
Does this functionality comes out-of-box (if not 100%, how big a deal is to customize or add custom functionality)
Can we add bridge numbers or PINs to database and make asterisk check against the database.
use a sip trunk instead of the E1. It wil keep life more simple because you keep the complexity of the pstn connection at the SIP trunk providers infrastructure. I also think (I’m not sure about this) that with a pure SIP solution Meetme() will be able to handle more channels.
use ulaw because that is the codec that Meemte() uses internally. When using an other codec transcoding will be needed.
Meetme() needs a timer source. You can use the dahdi dummy or, if you have a card available am fxo or bri or pri card supported by dahdi.
[quote=“lesouvage”]The meetme() app will do the job (see voip-info.org/wiki/view/Asterisk+cmd+MeetMe) without any further progamming. There are lots of parameters that might be useful.
Just some points of advice:
use a sip trunk instead of the E1. It wil keep life more simple because you keep the complexity of the pstn connection at the SIP trunk providers infrastructure. I also think (I’m not sure about this) that with a pure SIP solution Meetme() will be able to handle more channels.
use ulaw because that is the codec that Meemte() uses internally. When using an other codec transcoding will be needed.
Meetme() needs a timer source. You can use the dahdi dummy or, if you have a card available am fxo or bri or pri card supported by dahdi.[/quote]
Hopefully the spam that re-awoke this thread will get removed, but in the meantime, in relation to the original thread, it should be noted thatMeetMe uses signed linear not Mu-law, so the highest quality codec is the codec used by the PSTN operator at the PSTN break out point. This is generally true, not just for conferencing. In most of the world, this would be A-law, not Mu-law. Mu-law is used in the USA, and possibly the rest of the Americas.
Also, there is now an alternative conferencing application.