[asterisk-bugs] [JIRA] (ASTERISK-23127) MixMonitor and Call transfers

[Rusty Newton (JIRA)]

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

Rusty Newton edited comment on ASTERISK-23127 at 2/11/14 8:01 PM:
------------------------------------------------------------------

So after some confusion, I was able to reproduce the behavior. I believe it is not a bug.

bq. I don't think this issue to be related to MixMonitor but related to difference in PBX transfer and Phone transfer on Asterisk is self. If the PBX transfer can act the same as Phone transfer this issue should be resolved.

I do believe this is just the behavior of CDR during a feature code transfer.

Take these two cases:

Case A:

6001 calls 6002
6001 channel executes dialplan
6002 feature code blind-xfers to 6003
6001 channel executes dialplan

Case B:

6001 calls 6002,
6001 channel executes dialplan
6001 feature code blind-xfers to 6003
6002 channel executes dialplan

(by executes dialplan, I specifically mean hitting your macro and then a Dial)

I think the behavior that is troubling you is that after the feature code transfer the CDR variable "uniqueid" on the channel *executing dialplan* gets updated with the channel variable UNIQUEID of the channel that *initiated* the feature code transfer. In Case B, this makes your second read of CDR(uniqueid) match the first read. 

I suppose the CDR for the transferred party needs to reflect the uniqueid of the channel that initiated the transfer. However I'm not totally sure that is the reason. If it is, then this isn't a bug. I'll ping a dev that knows CDR in 11 to chime in.

I could also have all of this wrong, as CDR is quite confusing.
                
      was (Author: rnewton):
    So after some confusion, I was able to reproduce the behavior. I believe it is not a bug.

bq. I don't think this issue to be related to MixMonitor but related to difference in PBX transfer and Phone transfer on Asterisk is self. If the PBX transfer can act the same as Phone transfer this issue should be resolved.

I do believe this is just the behavior of CDR during a feature code transfer.

Take these two cases:

Case A:

6001 calls 6002
6001 channel executes dialplan
6002 feature code blind-xfers to 6003
6001 channel executes dialplan

Case B:

6001 calls 6002,
6001 channel executes dialplan
6001 feature code blind-xfers to 6003
6002 channel executes dialplan


I think the behavior that is troubling you is that after the feature code transfer the CDR variable "uniqueid" on the channel *executing dialplan* gets updated with the channel variable UNIQUEID of the channel that *initiated* the feature code transfer. In Case B, this makes your second read of CDR(uniqueid) match the first read. 

I suppose the CDR for the transferred party needs to reflect the uniqueid of the channel that initiated the transfer. However I'm not totally sure that is the reason. If it is, then this isn't a bug. I'll ping a dev that knows CDR in 11 to chime in.

I could also have all of this wrong, as CDR is quite confusing.
                  
> MixMonitor and Call transfers
> -----------------------------
>
>                 Key: ASTERISK-23127
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23127
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_mixmonitor
>    Affects Versions: 11.6.0
>         Environment: Centos 5.10
> Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz
> 4Gig Memory
>            Reporter: Jaco van Niekerk
>            Assignee: Matt Jordan
>            Severity: Trivial
>
> I believe I have found the problem, it seams like Mixmonitor doesn't continue recording the message because it sees the blind transfer from (PBX Transfer in features.conf) ## as 2 different uniqueid. Call 1 gets recorded but the second part of the call stops on transfer.
> Below are transferred calls that record fine with our any issues:
> Caller A phone Caller B then caller B blind transfers to Caller C: (## transfer)
> Caller A to Caller B -
> Uniqueid: 1389173420.258 
> CDR(uniqueid): 1389173420.258
> Recording folder: /var/spool/asterisk/monitor/1389173420.258.WAV (Both recordings are linked)
> Caller B to Caller C -
> Uniqueid: 1389173420.258
> CDR(uniqueid): 1389173420.260
> Recording folder: /var/spool/asterisk/monitor/1389173420.260.WAV (Only Second call)
> Caller A phone Caller B then caller B blind transfers to Caller C: (button transfer)
> Caller A to Caller B -
> Uniqueid: 1389173770.287
> CDR(uniqueid): 1389173770.287
> Recording folder: /var/spool/asterisk/monitor/1389173770.287.WAV (Both calls together)
> Caller B to Caller C -
> Uniqueid: 1389173770.287
> CDR(uniqueid): 1389173770.287
> Recording folder: Same
> Both these calls the Recording continues to record in one stream. What I have found is that the calls are recorded in one stream as Both the uniqueid match each other. 
> Also below is my Record Macro:
> {noformat}
> [macro-check-record]
> exten => s,1,GotoIf($[${RECORD}=YES]?2:5)
> exten => s,2,Set(EXISTS=${STAT(e,/var/spool/asterisk/monitor/${CDR(uniqueid)}.wav)})
> exten => s,3,GotoIf(${EXISTS}?5)
> exten => s,4,MixMonitor(${CDR(uniqueid)}.wav,b,/usr/local/bitco/convert ${CDR(uniqueid)})
> exten => s,5,NoOp(RECORD: ${RECORD})
> {noformat}
> I am doing a check to see if a recording exist not to over ride it. So as long as the CDR(Uniqueid) doesn't match on both calls each call will be recorded separately, which is perfect for all other forms of transfers.
> _---------------------------------------_
> Problem call:
> Caller A phone Caller B then caller A blind transfers to Caller C: (## transfer)
> Caller A to Caller B -
> Uniqueid: 1389173483.263
> CDR(uniqueid): 1389173483.263
> Recording folder: /var/spool/asterisk/monitor/1389173483.263.WAV (Only first call)
> Caller A to Caller C -
> Uniqueid: 1389173488.266
> CDR(uniqueid): 1389173483.263
> Recording folder: None
> This is the calls I am having problem with, as we can see the blind transfer using the PBX transfer feature creates the new call as unique call. The uniqueid for the first call and the second call is different. However the CDR(uniqueid) matches and because of the Macro the second call will not being recorded.
> I don't think this issue to be related to MixMonitor but related to difference in PBX transfer and Phone transfer on Asterisk is self. If the PBX transfer can act the same as Phone transfer this issue should be resolved.

--
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