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
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_meetme
Versions:		Frequency of Occurrence
Related Issues:
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 jd-girard@esoft.pf.
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? /O 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.