[asterisk-bugs] [Asterisk 0018672]: MOH on park stops and restarts - causes CDR error as well

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18672 
====================================================================== 
Reported By:                Raffles
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18672
Category:                   Features/Parking
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.2.16.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-01-25 03:45 CST
Last Modified:              2011-02-08 03:47 CST
====================================================================== 
Summary:                    MOH on park stops and restarts - causes CDR error as
well
Description: 
On call park - the MOH is stopped only to start again/  This, also, seems
to cause a CDR problem (see below).

    -- Executing [7000 at chambers:1] Park("SIP/2000-00000008", "") in new
stack
  == Parked SIP/2000-00000008 on 7001 (lot default). Will timeout back to
extension [chambers] s, 1 in 60 seconds
    -- Added extension '7001' priority 1 to parkedcalls (0xb6fd1160)
    -- <SIP/2000-00000008> Playing 'digits/7.gsm' (language 'en')
    -- <SIP/2000-00000008> Playing 'digits/0.gsm' (language 'en')
    -- <SIP/2000-00000008> Playing 'digits/0.gsm' (language 'en')
    -- <SIP/2000-00000008> Playing 'digits/1.gsm' (language 'en')
  == Spawn extension (chambers, s, 1) exited non-zero on
'Parked/SIP/2000-00000008<ZOMBIE>'
    -- Stopped music on hold on DAHDI/1-1
    -- Started music on hold, class 'dv-ip', on DAHDI/1-1
[Jan 21 13:39:17] ERROR[22913]: cdr_addon_mysql.c:313 mysql_log: Failed to
insert into database: (1062) Duplicate entry 'DV-IP-1295617064.8' for key
1
  == Spawn extension (park-dial, SIP02000, 1) exited non-zero on
'SIP/2000-00000008<ZOMBIE>'

BTW 'DV-IP-1295617064.8' is the CDR entry for when the call first came in
to the queue.  So, it looks like it's trying to use the same unique ID
again.
====================================================================== 

---------------------------------------------------------------------- 
 (0131646) one47 (reporter) - 2011-02-08 03:47
 https://issues.asterisk.org/view.php?id=18672#c131646 
---------------------------------------------------------------------- 
If I am parsing your sequence of events correctly, this is how parking
works if you attended-transfer a call. What you are asking for is IMHO a
new feature (a nice one) and not a fix to a bug.

When you do an attended transfer as you describe, the original call leg is
put on hold, and gets MOH (random choice 1) - the 2nd call leg, which hears
the orbit number gets a separate MOH (random choice 2).

When the call is transferred/bridged, the caller is taken off hold,
destroying MOH 1, and they are connected to the park orbit, which is
playing MOH 2.

Here, we have a number of asterisk users who would love for this to be
enhanced, but most of them make-do, or use blind transfers and turn off the
park-position prompt.

Thoughts on how this might be fixed are welcome. Perhaps a channel-flag
that is set by the Park orbit, which causes MOH to be swapped over as part
of the MASQ process (?) I've not put that much thought into it. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-08 03:47 one47          Note Added: 0131646                          
======================================================================