|Summary:||ASTERISK-05657: [patch] Text conferencing|
|Reporter:||Jean-Denis Girard (jdg)||Labels:|
|Date Opened:||2005-11-20 13:37:23.000-0600||Date Closed:||2011-06-07 14:03:10|
|Environment:||Attachments:||( 0) text_conferencing-1.2.0.patch|
( 1) text_conferencing-b-1.2.0.patch
|Description:||This trivial patch adds text conferencing to meetme. Text sent by a conference member will be sent to all members provided their channel supports text.|
****** ADDITIONAL INFORMATION ******
Tried to use ast_sendtext() from channel.c but it generates a locking warning, so I use chan->tech->send_text() directly. Someone with better understanding of locking should have a look.
I've already sent disclaimer very long time ago as, my email address was email@example.com.
|Comments:||By: BJ Weschke (bweschke) 2005-11-20 16:32:51.000-0600|
you're doing this within the thread of the user that submitted the thread. doesn't this then have the potential to disrupt audio for this channel if there are a significant number of users in the conference? We probably should follow the muxing model that already exists for distribution of voice frames.
By: Jean-Denis Girard (jdg) 2005-11-20 17:39:07.000-0600
Well, you are probably right, in theory text sending should be in a separate thread. But I believe sending text to supported channels is very cheap, and I don't think it will have an impact on audio in real meetme conferences. As far as I understand it the pseudo channel only supports voice frames, so we can't reuse it for text.
By: BJ Weschke (bweschke) 2005-11-21 07:52:07.000-0600
It may be, but you're taking a real risk with this approach. If any of the receiving channels locks for any reason, you're going to start blocking on the sending channel's thread in the conference. This may be why you cannot use ast_sendtext() already. You're right that the zap mux does't support muxed text frames, but we should probably try and think of an approach that follows the original design intended for the application.
By: Jean-Denis Girard (jdg) 2005-11-21 19:38:39.000-0600
I've uploaded version b of the patch, which creates a new thread for actually sending text, so the text sender will not be blocked. There is one thread created per received text, but as the thread should exit pretty fast I don't think it is a problem. ast_sendtext() still generates warning, so I still don't use it.
By: Mark Spencer (markster) 2005-12-20 03:30:23.000-0600
The problem here is that you can't just start acting on a channel sending text when you're not the thread that has the channel. I suggest that you add a list of text messages on each conference user and then queue the message to that list, then check / dequeue from that list within the main conf_run area. That way each thread of the conference handles the send text for itself.
By: Olle Johansson (oej) 2006-01-09 14:38:17.000-0600
This is a cool feature. Any updates?
By: Jean-Denis Girard (jdg) 2006-01-09 16:10:29.000-0600
I just came back from vacation yesterday, and noticed markster's note; I'll try to implement what he suggested.
By: Matt O'Gorman (mogorman) 2006-02-28 12:16:25.000-0600
any luck or update?
By: Jean-Denis Girard (jdg) 2006-03-02 10:45:58.000-0600
No update, sorry, I'm too busy right now. I've not given up, will come back to that patch when I have some time.
By: Tilghman Lesher (tilghman) 2006-03-02 12:12:09.000-0600
Bug suspended. Reopen when you have a new patch to post.