a)In chan_zap, set the clid, src fields in channel_alloc call. b)in the channel_alloc func, set the cid_num and name fields from the arglist[blush]. c) don't update the channel app & app data fields if you are in the 'h' extension. d)the load_module func in cdr_radius needs to return DECLINE, SUCCESS.

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62689 65c4cc65-6c06-0410-ace0-fbb531ad65f3

cdr/cdr_radius.c

@@ -238,6 +238,7 @@ static int unload_module(void)
 static int load_module(void)
 {
 	struct ast_config *cfg;
+	int res;
 	const char *tmp;
 
 	if ((cfg = ast_config_load(cdr_config))) {
@@ -256,16 +257,17 @@ static int load_module(void)
 	/* read radiusclient-ng config file */
 	if (!(rh = rc_read_config(radiuscfg))) {
 		ast_log(LOG_NOTICE, "Cannot load radiusclient-ng configuration file %s.\n", radiuscfg);
-		return -1;
+		return AST_MODULE_LOAD_DECLINE;
 	}
 
 	/* read radiusclient-ng dictionaries */
 	if (rc_read_dictionary(rh, rc_conf_str(rh, "dictionary"))) {
 		ast_log(LOG_NOTICE, "Cannot load radiusclient-ng dictionary file.\n");
-		return -1;
+		return AST_MODULE_LOAD_DECLINE;
 	}
 	
-	return ast_cdr_register(name, desc, radius_log);
+	res = ast_cdr_register(name, desc, radius_log);
+	return AST_MODULE_LOAD_SUCCESS;
 }
 
 AST_MODULE_INFO_STANDARD(ASTERISK_GPL_KEY, "RADIUS CDR Backend");

channels/chan_zap.c

@@ -5184,7 +5184,7 @@ static struct ast_channel *zt_new(struct zt_pvt *i, int state, int startpbx, int
 		}
 		y++;
 	} while (x < 3);
-	tmp = ast_channel_alloc(0, state, 0, 0, i->accountcode, i->exten, i->context, i->amaflags, b2);
+	tmp = ast_channel_alloc(0, state, i->cid_num, i->cid_name, i->accountcode, i->exten, i->context, i->amaflags, b2);
 	if (b2) /*!> b2 can be freed now, it's been copied into the channel structure */
 		free(b2);
 	if (!tmp)

configs/extensions.conf.sample

@@ -140,15 +140,48 @@ TRUNKMSD=1					; MSD digits to strip (usually 1 or 0)
 ;
 ; Contexts contain several lines, one for each step of each
 ; extension, which can take one of two forms as listed below,
-; with the first form being preferred.  One may include another
-; context in the current one as well, optionally with a
-; date and time.  Included contexts are included in the order
-; they are listed.
+; with the first form being preferred. 
 ;
 ;[context]
 ;exten => someexten,{priority|label{+|-}offset}[(alias)],application(arg1,arg2,...)
 ;exten => someexten,{priority|label{+|-}offset}[(alias)],application,arg1|arg2...
 ;
+; Included Contexts
+;
+; One may include another context in the current one as well, optionally with a
+; date and time.  Included contexts are included in the order
+; they are listed.
+; The reason a context would include other contexts is for their 
+; extensions.
+; The algorithm to find an extension is recursive, and works in this
+; fashion: 
+;	 first, given a stack on which to store context references, 
+;           push the context to find the extension onto the stack...
+;    a) Try to find a matching extension in the context at the top of 
+;       the stack, and, if found, begin executing the priorities
+;       there in sequence.
+;    b) If not found, Search the switches, if any declared, in
+;       sequence.
+;    c) If still not found, for each include, push that context onto 
+;       the top of the context stack, and recurse to a).
+;    d) If still not found, pop the entry from the top of the stack; 
+;       if the stack is empty, the search has failed. If it's not, 
+;       continue with the next context in c).
+; This is a depth-first traversal, and stops with the first context 
+; that provides a matching extension. As usual, if more than one
+; pattern in a context will match, the 'best' match will win.
+; Please note that that extensions found in an included context are
+; treated as if they were in the context from which the search began.
+; The PBX's notion of the "current context" is not changed.
+; Please note that in a context, it does not matter where an include
+; directive occurs. Whether at the top, or near the bottom, the effect 
+; will be the same. The only thing that matters is that if there is 
+; more than one include directive, they will be searched for extensions 
+; in order, first to last.
+; Also please note that pattern matches (like _9XX) are not treated
+; any differently than exact matches (like 987). Also note that the
+; order of extensions in a context have no affect on the outcome.
+;
 ; Timing list for includes is 
 ;
 ;   <time range>|<days of week>|<days of month>|<months>

main/channel.c

@@ -800,6 +800,9 @@ struct ast_channel *ast_channel_alloc(int needqueue, int state, const char *cid_
 			(long) time(NULL), ast_atomic_fetchadd_int(&uniqueint, 1));
 	}
 
+	tmp->cid.cid_name = ast_strdup(cid_name);
+	tmp->cid.cid_num = ast_strdup(cid_num);
+	
 	if (!ast_strlen_zero(name_fmt)) {
 		/* Almost every channel is calling this function, and setting the name via the ast_string_field_build() call.
 		 * And they all use slightly different formats for their name string.

main/pbx.c

@@ -516,7 +516,7 @@ int pbx_exec(struct ast_channel *c, 		/*!< Channel */
 	const char *saved_c_appl;
 	const char *saved_c_data;
 
-	if (c->cdr)
+	if (c->cdr && !(c->exten[0] == 'h' && c->exten[1] == 0) )
 		ast_cdr_setapp(c->cdr, app->name, data);
 
 	/* save channel values */