[Home]

Summary:ASTERISK-17280: MOH on park stops and restarts - causes CDR error as well
Reporter:Andrew Thomas (raffles)Labels:
Date Opened:2011-01-25 03:45:25.000-0600Date Closed:2011-06-07 14:04:49
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Features/Parking
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:On call park - the MOH is stopped only to start again/  This, also, seems to cause a CDR problem (see below).

   -- Executing [7000@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.

****** ADDITIONAL INFORMATION ******

I've applied the patch to features.c (from 18262) to get this far (no MOH was playing on park before the patch).

Comments:By: Steve Davies (one47) 2011-01-25 08:51:23.000-0600

I am using 1.6.2.16.1 with the same MOH patch.

As far as the MySQL duplicate entry, I suspect that you have put a duplicate key on your "uniqueid" column - This is not valid. If a CDR forks (as it often does) then the uniqueid will not necessarily change, and is ofthen useful for tracking a call's progress.

I have been unable to replicate the reversed Stop/Start MOH messages that show in your debug. I get the following:


 == Parked SIP/t28-0000000e on 211 (lot default). Will timeout back to extension [external] 210, 13 in 90 seconds
   -- Added extension '211' priority 1 to parkedcalls_default (0x9620190)
   -- <SIP/t28-0000000e> Playing 'digits/2.alaw' (language 'en')
   -- <SIP/t28-0000000e> Playing 'digits/1.alaw' (language 'en')
   -- <SIP/t28-0000000e> Playing 'digits/1.alaw' (language 'en')
   -- Started music on hold, class 'm-default', on SIP/t28-0000000e
 == Spawn extension (external, s, 1) exited non-zero on 'Parked/SIP/t28-0000000e<ZOMBIE>'
   -- Stopped music on hold on SIP/t28-0000000e

What is the exact sequence of events that occurs to the call to cause that issue? Does it have to go through a Queue first?
By: Andrew Thomas (raffles) 2011-01-25 09:10:14.000-0600

Firstly, I am using DAHDI (2.4.0 of both).  Not sure if this is a DAHDI timing related issue only (as first thought over at 18262).  Are you using DAHDI?

The call does go to a queue first - I can't remember if I tried it to a direct extension.  I'll try that and retest.

As for the mySQL error - I've just found this on the wiki:

"Attention! The uniqueid field is not guaranteed to be unique across the different CDR entries, even though the name suggests exactly that. In fact Uniqueid has never been guaranteed to be unique across all CDRs: It is only unique across a channel, and a channel may have multiple CDRs."

I've obviously got my table definition a bit wrong there (that'll teach me to copypasta!).  I'll trundle away and fix ;).

Thanks
By: Steve Davies (one47) 2011-01-25 10:17:35.000-0600

Yes, I am using DAHDI 2.4.0.
By: Leif Madsen (lmadsen) 2011-01-31 13:07:03.000-0600

Would be ideal to get enough information to reproduce this.
By: Andrew Thomas (raffles) 2011-02-07 11:09:09.000-0600

Sorry for late reply - had to rebuild a server ;)

Anyway, I've created a copy of this PBX on another machine and the problem follows it.

Scenario (this time):

x802 calls x801.  x801 answers with no problem.  x801 transfers x802 to 700 (park code).  x801 hears '701' (first park slot).  x802 hears MOH.  x801 hangs up.  x802 still hears MOH BUT now hears a different piece of music (I have 6 files all together).

This is because the MOH stopped and started again.  Call comes back to x801 after 30 seconds and call proceeds (between x802 and x801).

This is SIP to SIP btw.

   -- Called 801
   -- SIP/801-00000003 is ringing
   -- SIP/801-00000003 answered SIP/802-00000002
   -- fixed jitterbuffer created on channel SIP/802-00000002
   -- fixed jitterbuffer created on channel SIP/801-00000003
   -- Started music on hold, class 'dv-ip', on SIP/802-00000002
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
   -- Executing [700@dv-ip:1] Park("SIP/801-00000004", "") in new stack
 == Parked SIP/801-00000004 on 701 (lot default). Will timeout back to extension [dv-ip] s, 1 in 30 seconds
   -- Added extension '701' priority 1 to parkedcalls (0x8866ea0)
   -- <SIP/801-00000004> Playing 'digits/7.gsm' (language 'en')
   -- <SIP/801-00000004> Playing 'digits/0.gsm' (language 'en')
   -- <SIP/801-00000004> Playing 'digits/1.gsm' (language 'en')
 == Spawn extension (dv-ip, s, 1) exited non-zero on 'Parked/SIP/801-00000004<ZOMBIE>'
   -- Stopped music on hold on SIP/802-00000002
   -- Started music on hold, class 'dv-ip', on SIP/802-00000002

[x801 hung up here]
   -- fixed jitterbuffer destroyed on channel SIP/801-00000003
   -- fixed jitterbuffer destroyed on channel SIP/801-00000004<ZOMBIE>
   -- Stopped music on hold on SIP/802-00000002
   -- Registered extension context 'park-dial' (0xb5c02538) in table 0x885fd78; registrar: features
   -- Added extension 'SIP0801' priority 1 to park-dial (0xb5c02538)
 == Timeout for SIP/802-00000002 parked on 701 (default). Returning to park-dial,SIP0801,1
   -- Executing [SIP0801@park-dial:1] Dial("SIP/802-00000002", "SIP/801,30,Wtw") in new stack
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
   -- Called 801
   -- SIP/801-00000005 is ringing
   -- SIP/801-00000005 answered SIP/802-00000002
   -- fixed jitterbuffer created on channel SIP/801-00000005
   -- fixed jitterbuffer destroyed on channel SIP/801-00000005
 == Spawn extension (park-dial, SIP0801, 1) exited non-zero on 'SIP/802-00000002'

Would you like full debug thingy for this?  If so, can you please post the instructions again?  

Thanks
By: Steve Davies (one47) 2011-02-08 03:47:06.000-0600

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.
By: Andrew Thomas (raffles) 2011-02-09 06:03:25.000-0600

Thanks for that explanation. It even makes sense :).

So, to put this in simple terms - it's actually treated as two separate holds/calls.

I suppose it's going to be a 'make-do' for quite a while - or I could simply 'stream' MOH in instead of using the 'files' method (not pretty - but better for the caller).

This can be closed now Leif, as no 'fix' can occur (without a major re-write of the park/MOH code - and that's simply not worth the effort).

Thanks again.