[asterisk-bugs] [JIRA] (ASTERISK-23127) feature code transfer - transferred channel's CDR(uniqueid) is updated with uniqueid from the transferor's channel

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-23127:
----------------------------------------

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.
                
> feature code transfer - transferred channel's CDR(uniqueid) is updated with uniqueid from the transferor's channel
> ------------------------------------------------------------------------------------------------------------------
>
>                 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