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

Matt Jordan (JIRA) noreply at issues.asterisk.org
Fri Jan 10 09:33:03 CST 2014


     [ https://issues.asterisk.org/jira/browse/ASTERISK-23127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-23127:
-----------------------------------

    Assignee: Jaco van Niekerk
      Status: Waiting for Feedback  (was: Triage)
    
> 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: Jaco van Niekerk
>            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



More information about the asterisk-bugs mailing list