[asterisk-bugs] [JIRA] (ASTERISK-21394) Fundamental changes to CDR within single asterisk family (1.8)

Thu Apr 25 09:47:38 CDT 2013

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205830#comment-205830 ] 

Matt Jordan commented on ASTERISK-21394:
----------------------------------------

Thanks for running this down and creating a patch Steve. I think this goes to show just how brittle CDRs can be in the current bridging code.

In your patch, it looks like the following should be combined:

{noformat}
-	if (ast_test_flag(&config->features_caller, AST_FEATURE_NO_H_EXTEN)) {
+	if (chan->_softhangup & (AST_SOFTHANGUP_ASYNCGOTO | AST_SOFTHANGUP_UNBRIDGE)) {
+		/*
+		 * If the bridge was broken for a hangup that isn't real,
+		 * then don't run the h extension, because the channel isn't
+		 * really hung up. This should really only happen with AST_SOFTHANGUP_ASYNCGOTO,
+		 * but it doesn't hurt to check AST_SOFTHANGUP_UNBRIDGE either.
+		 */
+		h_context = NULL;
+	} if (ast_test_flag(&config->features_caller, AST_FEATURE_NO_H_EXTEN)) {
 		h_context = NULL;
 	} else if (ast_exists_extension(chan, chan->context, "h", 1,
 		S_COR(chan->caller.id.number.valid, chan->caller.id.number.str, NULL))) {
{noformat}

to:

{noformat}
-	if (ast_test_flag(&config->features_caller, AST_FEATURE_NO_H_EXTEN)) {
+	/*
+	 * If the bridge was broken for a hangup that isn't real,
+	 * then don't run the h extension, because the channel isn't
+	 * really hung up. This should really only happen with AST_SOFTHANGUP_ASYNCGOTO,
+	 * but it doesn't hurt to check AST_SOFTHANGUP_UNBRIDGE either.
+	 */
+	if ((chan->_softhangup & (AST_SOFTHANGUP_ASYNCGOTO | AST_SOFTHANGUP_UNBRIDGE)) || (ast_test_flag(&config->features_caller, AST_FEATURE_NO_H_EXTEN))) {
 		h_context = NULL;
 	} else if (ast_exists_extension(chan, chan->context, "h", 1,
 		S_COR(chan->caller.id.number.valid, chan->caller.id.number.str, NULL))) {
{noformat}

Otherwise, we could set {{h_context}} to NULL, fail the check for {{AST_FEATURE_NO_H_EXTEN}}, do a look up of the {{h}} extension, find that it exists, and end up setting {{h_context}} to something other than NULL.

> Fundamental changes to CDR within single asterisk family (1.8)
> --------------------------------------------------------------
>
>                 Key: ASTERISK-21394
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21394
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/General
>    Affects Versions: 1.8.18.0, 1.8.20.0, 1.8.21.0
>         Environment: Centos 5
>            Reporter: Ishfaq Malik
>            Assignee: Ishfaq Malik
>         Attachments: fix_missing_blindXfer_cdr
>
>
> The way that asterisk handles the CDR for blind transfers has changed between version 1.8.7.0 and 1.8.18.0. The call path is: inbound call from SIP provider -> asterisk server -> SIP peer -> transfer to another SIP Peer. The transfer is done by using the dedicated keys on the hardware and not the features.conf method.
> In version 1.8.7.0 this would produce 2 entries in the CDR, 1 showing the time the inbound call started and which context it was handles by, the second showing the the context the peer belongs to and looking like an extension to extension call.
> We tried upgrading to 1.8.18.0 and did some regression testing and found that the CDR now only produces a single entry with the details all pertaining to the second leg of the call (bar the duration which is for the full life of the call). It has no reference to the inbound context that initially handled the call.
> This is a pretty big change to be inside a single branch and I'm guessing it wasn't intentional.
> Also, all our servers are installed using Puppet so the configuration on them all is the same and we use RealTime Architecture from a single database.
> Here is an example (with sanitised data):
> Here is how an inbound blind transferred call is recorded in 1.8.7.0
> {noformat}
> *************************** 1. row ***************************
>    calldate: 2013-04-04 11:42:09
>        clid: 
>         src: <my-mobile>
>         dst: s
>    dcontext: <inbound-number-context>
>     channel: SIP/xxx.xxx.xxx.xxx-00002ba3
>  dstchannel: SIP/501-00002ba7
>     lastapp: Dial
>    lastdata: SIP/501&SIP/511&SIP/531,10
>    duration: 22
>     billsec: 12
> disposition: ANSWERED
>    amaflags: 3
> accountcode: 
>   userfield: 
> *************************** 2. row ***************************
>    calldate: 2013-04-04 11:42:31
>        clid: 
>         src: <my-mobile>
>         dst: 504
>    dcontext: <peer-context>
>     channel: SIP/xxx.xxx.xxx.xxx-00002ba3
>  dstchannel: SIP/504-00002bbb
>     lastapp: Dial
>    lastdata: SIP/504,20
>    duration: 7
>     billsec: 5
> disposition: ANSWERED
>    amaflags: 3
> accountcode: 
>   userfield: 
> 2 rows in set (0.03 sec)
> {noformat}
> And here is how it is recorded in 1.8.18.0
> {noformat}
> *************************** 1. row ***************************
>    calldate: 2013-04-04 11:39:24
>        clid: 
>         src: <my-mobile>
>         dst: 503
>    dcontext: <peer-context>
>     channel: SIP/xxx.xxx.xxx.xxx-000000ea
>  dstchannel: SIP/503-000000ed
>     lastapp: Dial
>    lastdata: SIP/503,20
>    duration: 34
>     billsec: 9
> disposition: ANSWERED
>    amaflags: 3
> accountcode: 
>   userfield: 
> {noformat}
> In the newer version there is only one entry which has the combined call
> time in it but the dcontext corresponds with the second leg of the call
> which means we can't see what number was dialled.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira