|Summary:||ASTERISK-01613: [Design] MeetMe enter/leave signal|
|Date Opened:||2004-05-13 19:15:46||Date Closed:||2004-09-25 02:15:31|
|Environment:||Attachments:||( 0) app_meetme_ELbyThread.c.diff|
|Description:||Should the current implementation be replace by something manage by each thread for each users, example attached. So it allow GSM to be played backed|
****** ADDITIONAL INFORMATION ******
Big problem with this example is... Audio is suspended during the play of the 'tone', instead of merging it.
|Comments:||By: mochouinard (mochouinard) 2004-05-13 19:57:11|
also, take more resources if there is ALOT of users in the conference
By: Mark Spencer (markster) 2004-05-15 01:58:24
I'm rather a fan of the way the conferencing works right now. Why the big desire to change the enter/leave sounds anyway?
By: mochouinard (mochouinard) 2004-05-15 03:33:46
Well someone asked for option to change the beep. So Ive search into HOW to make a GSM file into that raw binary thing, but couldn't quite figure out, so I found meetme used mostly asterisk defined function except for that conf_play, which look very hard to play arround. So I just did this little thing to see how to bug arround my primary problem. Anyway, that why
By: Mark Spencer (markster) 2004-05-15 12:59:05
Hrm... One option would be to have a thread per-conference which did all the announcements on the pseudo, if we could make the pseudo look like a channel (Or requested one from chan_zap). It's still not as efficient as the code we have, but would potentially give us the abilility to do more advanced things like have an automated operator say "<recorded file of name> has entered the conference" and "<recorded file of name> has left the conference and so on. In any case such an option would have to be just that -- an option, with the default behavior being the same as what it is right now since that's nice, simple, and fast.
By: paulc (paulc) 2004-05-20 05:00:14
I wrote a conferencing app in my previous job using Dialogic hardware. For entry and exit notifications, we'd mute the caller from the conference then play them "<name recording> ..has joined the conference". They missed out on conference audio for the duration of the notification, but the conference moderator could turn this function on and off at will. One customer requested simple tones, so we built that in too, but the majority of people seemed happy with full announcements. I too debated having a resource playing it in to the conference versus doing it the way we did it. Can't remember the big reason behind my decision, but it may have been to do with timing - the new person enters the conference and catches the tail end of their own entry notification?
By: Tony Mountifield (softins) 2004-05-26 12:14:44
Markster - I've been looking at how to make the pseudo into a channel. I want to replace meetme's fd=open("/dev/zap/pseudo") with chan=ast_request("zap",format,"pseudo") as done in app_rpt.c (Jim's Radio Repeater - is Jim still around?). However, it doesn't work correctly in chan_zap, due to there not being a zt_pvt for pseudo on the interface list. The code that parses zapata.conf suggests that "channel=pseudo" will create one, but when I try that, it doesn't open /dev/zap/pseudo on the real fd before trying to do an ioctl on it. I'll look at it more over the next few days, but pointers would be appreciated.
By: Tony Mountifield (softins) 2004-06-02 05:07:38
Please see bug ASTERISK-1741 for changes to app_meetme to provide a true channel for announcements.
By: Mark Spencer (markster) 2004-06-04 15:54:47
The most basic of the framework for this is in CVS head. The only trick now is going to be ordering things so that we don't pool up around that entry code when lots of people join the conference.