mirror of
				https://github.com/asterisk/asterisk.git
				synced 2025-10-31 02:37:10 +00:00 
			
		
		
		
	Merged revisions 315643 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r315643 | twilson | 2011-04-26 14:27:44 -0700 (Tue, 26 Apr 2011) | 25 lines Merged revisions 315596 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r315596 | twilson | 2011-04-26 14:16:10 -0700 (Tue, 26 Apr 2011) | 18 lines Allow transfer loops without allowing forwarding loops We try to avoid the situation where two phones may be forwarded to each other causing an infinite loop by storing each dialed interface in a channel datastore and checking the list before dialing out. This works, but currently breaks situations like A calls B, A transfers B to C, B transfers C to A, and A transfers C to B. Since human interaction is happening here and not an automated forwarding loop, it should be allowed. This patch removes the dialed_interfaces datastore when a call is bridged (a suggestion from the brilliant mmichelson). If a call is being bridged, it should be safe to assume that we aren't stuck in a loop. Since we are now handling this is the bridge code, the previous attempts at handling it in app_dial and app_queue are removed. Review: https://reviewboard.asterisk.org/r/1195/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@315644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
		| @@ -2395,14 +2395,6 @@ static int dial_exec_full(struct ast_channel *chan, const char *data, struct ast | ||||
| 	peer = wait_for_answer(chan, outgoing, &to, peerflags, opt_args, &pa, &num, &result, | ||||
| 		dtmf_progress, ignore_cc, &forced_clid, &stored_clid); | ||||
|  | ||||
| 	/* The ast_channel_datastore_remove() function could fail here if the | ||||
| 	 * datastore was moved to another channel during a masquerade. If this is | ||||
| 	 * the case, don't free the datastore here because later, when the channel | ||||
| 	 * to which the datastore was moved hangs up, it will attempt to free this | ||||
| 	 * datastore again, causing a crash | ||||
| 	 */ | ||||
| 	if (!ast_channel_datastore_remove(chan, datastore)) | ||||
| 		ast_datastore_free(datastore); | ||||
| 	if (!peer) { | ||||
| 		if (result) { | ||||
| 			res = result; | ||||
|   | ||||
| @@ -4567,17 +4567,6 @@ static int try_calling(struct queue_ent *qe, const char *options, char *announce | ||||
| 	if (need_weight) | ||||
| 		ao2_unlock(queues); | ||||
| 	lpeer = wait_for_answer(qe, outgoing, &to, &digit, numbusies, ast_test_flag(&(bridge_config.features_caller), AST_FEATURE_DISCONNECT), forwardsallowed, update_connectedline); | ||||
| 	/* The ast_channel_datastore_remove() function could fail here if the | ||||
| 	 * datastore was moved to another channel during a masquerade. If this is | ||||
| 	 * the case, don't free the datastore here because later, when the channel | ||||
| 	 * to which the datastore was moved hangs up, it will attempt to free this | ||||
| 	 * datastore again, causing a crash | ||||
| 	 */ | ||||
| 	ast_channel_lock(qe->chan); | ||||
| 	if (datastore && !ast_channel_datastore_remove(qe->chan, datastore)) { | ||||
| 		ast_datastore_free(datastore); | ||||
| 	} | ||||
| 	ast_channel_unlock(qe->chan); | ||||
| 	ao2_lock(qe->parent); | ||||
| 	if (qe->parent->strategy == QUEUE_STRATEGY_RRMEMORY || qe->parent->strategy == QUEUE_STRATEGY_RRORDERED) { | ||||
| 		store_next_rr(qe, outgoing); | ||||
|   | ||||
		Reference in New Issue
	
	Block a user