Summary:	ASTERISK-23127: feature code transfer - transferred channel's CDR(uniqueid) is updated with uniqueid from the transferor's channel
Reporter:	Jaco van Niekerk (faqterson)	Labels:
Date Opened:	2014-01-09 01:01:54.000-0600	Date Closed:	2014-02-11 20:49:05.000-0600
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_mixmonitor
Versions:	11.6.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	Centos 5.10 Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz 4Gig Memory	Attachments:
Description:	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.
Comments:	By: Matt Jordan (mjordan) 2014-01-10 09:32:24.003-0600 Did you enable AUDIOHOOK_INHERIT on the channel? This allows the call recording to continue during transfer scenarios. [https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Function_AUDIOHOOK_INHERIT] By: Jaco van Niekerk (faqterson) 2014-01-12 23:18:50.824-0600 Let me try that and get back to you with the results. Regards By: Jaco van Niekerk (faqterson) 2014-01-13 00:05:40.418-0600 Caller A phone Caller B then caller B blind transfers to Caller C: (## transfer) Caller A to Caller B - Uniqueid: 1389592359.27 CDR(uniqueid): 1389592359.27 Recording folder: Both Caller B to Caller C - Uniqueid: 1389592359.27 CDR(uniqueid): 1389592359.29 Recording folder: Second Caller A phone Caller B then caller B blind transfers to Caller C: (button transfer) Caller A to Caller B - Uniqueid: 1389592503.32 CDR(uniqueid): 1389592503.32 Recording folder: Both Caller B to Caller C - Uniqueid: 1389592503.32 CDR(uniqueid): 1389592503.32 Recording folder: Same Caller A phone Caller B then caller A blind transfers to Caller C: (## transfer) Caller A to Caller B - Uniqueid: 1389592579.37 CDR(uniqueid): 1389592579.37 Recording folder: First Caller A to Caller C - Uniqueid: 1389592589.40 CDR(uniqueid): 1389592579.37 Recording folder: None I am getting the same results: {noformat} [macro-check-record]    exten => s,1,GotoIf($[${RECORD}=YES]?yes:no)    exten => s,n(yes),NoOp(${UNIQUEID})    exten => s,n,NoOp(${CDR(uniqueid)})    exten => s,n,Set(EXISTS=${STAT(e,/var/spool/asterisk/monitor/${CDR(uniqueid)}.wav)})    exten => s,n,GotoIf(${EXISTS}?no)    exten => s,n,MixMonitor(${CDR(uniqueid)}.wav,b,/usr/local/bitco/convert ${CDR(uniqueid)})    exten => s,n,Set(AUDIOHOOK_INHERIT(MixMonitor)=yes)    exten => s,n(no),NoOp(RECORD: ${RECORD}) {noformat} By: Jaco van Niekerk (faqterson) 2014-01-20 00:07:23.464-0600 Any body else been able to replicate this issue? By: Rusty Newton (rnewton) 2014-02-11 19:59:00.288-0600 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. By: Matt Jordan (mjordan) 2014-02-11 20:48:53.719-0600 Nope, Rusty is correct. This is the expected behaviour, and is not a bug. In Asterisk 1.8/11, a masquerade (an internal operation that occurs during transfers) changes the channel's name, but allows the channel to retain its original uniqueid. This has been a much debated behaviour - see [http://lists.digium.com/pipermail/asterisk-dev/2009-May/038430.html] and again here [http://lists.digium.com/pipermail/asterisk-dev/2010-June/044754.html]. As it turns out, Asterisk 12 removed all of this behaviour when it modified the bridging core to provide stable handles and lifetimes for channels/bridges. So, in 12+, the uniqueid for a channel will always remain the same - mostly because masquerades are no longer a visible operation.