Summary:	ASTERISK-03332: [patch] Outcalling from within meetme
Reporter:	mochouinard (mochouinard)	Labels:
Date Opened:	2005-01-22 15:30:56.000-0600	Date Closed:	2005-09-22 18:46:36
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_meetme
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_meetme.c_outboundcall_rev3.txt ( 1) outbound_with_inviteeflags_v3.txt
Description:	This patch add 1 flag, 'o'.  If set, a ADMIN can call outbound  if he have access to the menu, using option '4'. He will get a dial prompt, he can dial the number and press #.  It will use the default context, unless overwriden using ${MEETME_OUTBOUNDCONTEXT}.  Once the remote user answer, you can speak with him, and will only be in the conference, when you press *. Pressing # will end the called party, and bring you back to the conference. ****** ADDITIONAL INFORMATION ****** Ive used a few stuff from bug 1294 for the prompt for the dialling.
Comments:	By: mochouinard (mochouinard) 2005-01-22 15:32:40.000-0600 Maybe you dont like the design, and Im open to sugestions.  But I like the fact, that you can talk to the person before puting him into the conference By: Mark Spencer (markster) 2005-01-22 16:11:55.000-0600 I suggest we use caller's context by default instead of "default" By: mochouinard (mochouinard) 2005-01-22 16:35:03.000-0600 weird, I tryed the chan->context but it didnt work, it why I used 'default'.. but now it work... I must be tired hehe By: Mark Spencer (markster) 2005-02-22 09:45:23.000-0600 What prompts do we need recorded for this? By: mochouinard (mochouinard) 2005-02-27 19:59:55.000-0600 Only the admin menu to add option 4 for outbound calling. Anyone tested it ? By: kuj (kuj) 2005-02-28 18:11:12.000-0600 Works as advertised for me. However, it seems the "marked user" flag (and possibly all existing flags, except for admin flag) gets inherited by the called party after being conferenced into the meetme. This may be particular to my implementation, but I have two classes of users: usually several "participants" (MeetMe flags "Mwsx") and a single conference leader ("MAasxo"). Participants will have to wait for the leader, and as soon as the leader (single marked user) hangs up, the conference will be ended. As it is now, with a new user added to the conference from the outbound call, and that user also being a "marked user", the conference will not be ended when the conference admin/leader exits. Or do we need a more generic approach that lets us define MeetMe flags for the called party via a variable, similar to what you did for ${MEETME_OUTBOUNDCONTEXT}? edited on: 02-28-05 19:52 edited on: 02-28-05 19:54 By: kuj (kuj) 2005-03-01 15:01:33.000-0600 To illustrate my previous idea, I've uploaded some code that extends moc's patch to also let me specify the conf flags for users brought into a conference by outbound dialing. In the dialplan, set variable ${MEETME_INVITEECONFFLAGS} to desired flags (defaults to "Mwsx" right now). Obviously, a few flags don't make sense (d,D,e,E,P,o,a), so they will not be parsed. This patch is against current CVS head. It is also somewhat ugly in that it duplicates the flag parsing code into the meetme_outbounddial function. But it should illustrate the idea. By: Mark Spencer (markster) 2005-03-01 23:43:39.000-0600 Perhaps "options2flags" is in order? By: kuj (kuj) 2005-03-02 13:18:02.000-0600 That's what I thought :) outbound_with_inviteeflags_v2 does just that. Again, this is against HEAD. DISCLAIMER emailed to markster. By: Mark Spencer (markster) 2005-04-07 13:56:38 Sorry to have let this sit around so long.  Lets try the options API if that's appropriate. By: Mark Spencer (markster) 2005-04-07 13:58:21 Also, ast_app_dtget might be in order. By: kuj (kuj) 2005-04-07 19:37:31 Latest upload (inviteeflags_v3) is patch against CVS HEAD, using ast_parseoptions for options parsing. Obviously also has the MEETME_INVITEECONFFLAGS change so that we can define which options to assign a meetme participant that is brought into the conference by somebody calling out from a conf. I wouldn't know how to convert this to ast_app_dtget, though. By: Michael Jerris (mikej) 2005-05-23 22:02:19 Can we suspend this and roll it into the work done on meetme re-design in 4269.  I lean towards testing\committing the redesign as a new meetme, then, as all the current meetme functionality is ported to it, renaming it to meetme.  And implementing all new features only in the new version. By: petersv (petersv) 2005-05-24 01:33:10 Do we have any idea as to the time frame for the next major version of meetme? This patch does have the advantage of working here and now. By: Clod Patry (junky) 2005-05-25 06:59:47 I've delete older files here, just to be with the latest patches. By: Clod Patry (junky) 2005-06-01 19:20:52 and i've that output with current HEAD: debian:/usr/src/asterisk# patch -p0 < app_meetme.c_outboundcall_rev3.txt patching file apps/app_meetme.c Hunk #1 FAILED at 33. Hunk #2 succeeded at 64 with fuzz 2 (offset 2 lines). Hunk #3 succeeded at 113 (offset 4 lines). Hunk #4 succeeded at 169 (offset 10 lines). Hunk ASTERISK-1 FAILED at 197. Hunk ASTERISK-2 FAILED at 559. Hunk ASTERISK-3 succeeded at 722 with fuzz 1 (offset 94 lines). Hunk ASTERISK-4 FAILED at 1075. Hunk ASTERISK-5 FAILED at 1427. Hunk ASTERISK-6 succeeded at 1924 (offset 236 lines). 5 out of 10 hunks FAILED -- saving rejects to file apps/app_meetme.c.rej debian:/usr/src/asterisk# Maybe a patch against current HEAD will be needed here. By: Clod Patry (junky) 2005-06-13 18:55:22 Where are we with that patch? Can't we merge that one with ASTERISK-4169 ? If someone really want that feature, please attach a patch against HEAD. Thanks. By: Michael Jerris (mikej) 2005-06-23 16:05:06 Closed at MOC's request.