[Home]

Summary:ASTERISK-12839: Missing userfield for Queue call with NO ANSWER
Reporter:Atis Lezdins (atis)Labels:
Date Opened:2008-10-07 09:42:28Date Closed:2009-06-08 11:13:40
Priority:MajorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) answered.log
( 1) no_answer.log
( 2) queue_cdr.tar.gz
( 3) sample_config_2.tar.gz
( 4) scenario_1.log
( 5) scenario_2.log
( 6) scenario_3.log
( 7) scenario_4.log
( 8) scenario_5.log
( 9) scenario_6.log
(10) scenario_7.log
(11) scenario_8.log
Description:Sample dialplan (attached) has two SIP devices:

90023 -> Queue(22901) -> 90132

If 90023 hangs up, queue cancels call and resulting CDR is missing userfield (set before entering queue).

Comments:By: Steve Murphy (murf) 2008-10-07 16:16:51

Oh, atis, if only you knew what you were asking...!

I know why this is happening, I know roughly what to do, and I'm pondering the fine points. This and app_dial should both have the same things done.

This is *the* simple case, and the CDR you want isn't printing, because on no-answer, it's disposition is not updated. Updating the disposition and letting it post is *not* the best/most complete option, tho, with unanswered=yes set in your cdr.conf. A much more interesting case is if you dial 2 or more phones. The CDR you do see, is the one attached to "peer" (dialed) channel. Your userinfo is stored on the "chan"'s CDR, and that is the one you'd rather probably see... but, in the case where multiple channels are rung, and none answer, what is the 'destination channel"?

So, maybe now is the time to "do it right", and output the unanswered channel CDRs with the proper info attached, like src & dest channels, etc, and userinfo, etc.
By: Atis Lezdins (atis) 2008-10-07 17:12:54

I don't quite understand what you are saying about peer channel.

If i would use local channels, i would get CDR for every peer dialed (actually two of them, i just ignore one without userfield). And i get the same queue CDR without userfield.

Perhaps i'll try illustrating this with local channels as my full dialplan has.
By: Steve Murphy (murf) 2008-10-08 13:06:36

The goal of Queue is much like Dial: that of connecting two channels together.
The incoming call is "channel", and each of the lines it will ring are called 'peer' in that code. Every channel automatically gets a CDR. The hard part is sorting out which CDR's to post, and which to throw away. It is doing it wrong,
because the incoming channel gets NO_ANSWER, and its disposition is not updated by app_queue, so the logic throws the main CDR away, and the one from the ring attempt (peer) is left, and it is getting posted. It's all messed up, I admit, but I have an idea on how to make those ring attempts get posted with useful info in them...
By: Atis Lezdins (atis) 2008-10-08 14:31:10

Ok, that explains what i observed in tests (i'll attach them shortly).

However if i set unanswered=yes, i would defineately want all the CDRs. In case of multiple phones - CDR for each one.

As for Queue, i already have my dialplan built over concept that queue generates one long CDR for all the time caller spends there, if it's answered - it shows dstchannel of bridged peer (but thanks to my userfield magic i don't need it :). And each call from queue generates separate CDR for ringing time, by having it's start time i can exactly calculate whatever durations necessary.
Of course having one CDR for time in queue and another for ring and conversation would be way better, but that would be too huge change for 1.6

About unanswered CDR's - i'm already used to have some unnecessary duplicates since that major change in 1.4. I just trash them, and use whatever i have with userfield set. Now in 1.6 i see that there are even more of them (or perhaps i just didn't analyzed them in 1.4 as i had all i need).

But, if i have unanswered=yes, i still wonder - why there's no CDR with queue call. While testing, i noticed that putting ResetCDR(w) after Queue writes it, so it's somewhere.. but this would require quite some refactoring of dialplan, putting ResetCDR's in hangup extensions or after queue calls. I wouold have to check disposition, as i don't want to do ResetCDR after answered call. Sounds like a big headache.

Please see my next post with test scenarios and some comments.
By: Atis Lezdins (atis) 2008-10-08 14:31:34

<pre>
Scenario #1.

90023 -> Queue -> 90132 (ANSWERED)

(agent 1)
Local/90132@default_queue-4a92;2 #call_id=1223489162.2#agent=90132 ANSWERED

(queue)
SIP/90023-0825d188 #call_id=1223489162.0#queue=22901 ANSWERED

Scenario #2

90023 -> Queue -> 90132 (NO ANSWER)
-> 90219 (ANSWERED)

(agent 1)
SIP/90132-08258c68 NO ANSWER
Local/90132@default_queue-331c;2 #call_id=1223489375.2#agent=90132 NO ANSWER
Local/90132@default_queue-331c;1 NO ANSWER

(agent 2)
Local/90219@default_queue-9025;2 #call_id=1223489385.5#agent=90219 ANSWERED

(queue)
SIP/90023-08254ac0 #call_id=1223489375.0#queue=22901 ANSWERED

Weirdly now there are 3 CDRs for Agent 1, but since i'm using those with userfield and they have correct durations, i just don't care :)

Scenario #3

90023 -> Queue -> 90132 (NO ANSWER)
-> 90219 (NO ANSWER)
caller hangs up before timeout for agent 2 is over.

(agent 1)
SIP/90132-08258c68 NO ANSWER
Local/90132@default_queue-7a1f;2 #call_id=1223489892.9#agent=90132 NO ANSWER
Local/90132@default_queue-7a1f;1 NO ANSWER

(agent 2)
SIP/90219-08260dc0 NO ANSWER
Local/90219@default_queue-6ab7;2 #call_id=1223489903.12#agent=90219 NO ANSWER
Local/90219@default_queue-6ab7;1 NO ANSWER

and no CDR for queue at all.

Scenario #4

90023 -> Queue -> 90132 (NO ANSWER)
-> 90219 (NO ANSWER)
caller waits up to queue timeout, not reaching any agent

(agent 1)
SIP/90132-08257530 NO ANSWER
Local/90132@default_queue-3be4;2 #call_id=1223490480.16#agent=90132 NO ANSWER
Local/90132@default_queue-3be4;1 NO ANSWER

(agent 2)
Local/90219@default_queue-4b8d;1 NO ANSWER
SIP/90219-0825f688 NO ANSWER
Local/90219@default_queue-4b8d;2 #call_id=1223490490.19#agent=90219 NO ANSWER

And no queue CDR again.

Scenario ASTERISK-1

90023 -> Queue -> 90132 (NO ANSWER)
-> 90219 (NO ANSWER)
-> Voicemail (ANSWERED)
caller waits up to queue timeout, then goes to voicemail

(agent 1)
SIP/90132-08257530 NO ANSWER
Local/90132@default_queue-1891;2 #call_id=1223490862.23#agent=90132 NO ANSWER
Local/90132@default_queue-1891;1 NO ANSWER

(agent 2)
Local/90219@default_queue-2b9a;1 NO ANSWER

(queue)
SIP/90023-08227028 #call_id=1223490862.21#queue=22901 NO ANSWER

(agent 2)
SIP/90219-0825f688 NO ANSWER
Local/90219@default_queue-2b9a;2 #call_id=1223490872.26#agent=90219 NO ANSWER

(voicemail)
SIP/90023-08227028 #call_id=1223490862.21#vm=22901 ANSWERED

Weirdly, queue CDR is posted in middle of everything from agent 2, but it should be ok in general.

Scenario ASTERISK-1

90023 -> Queue -> 90132 (NO ANSWER)
-> 90219 (NO ANSWER)
-> Other
caller waits up to queue timeout, then goes somewhere else where don't get answered

(agent 1)
SIP/90132-08257530 NO ANSWER
Local/90132@default_queue-360b;2 #call_id=1223491293.30#agent=90132 NO ANSWER
Local/90132@default_queue-360b;1 NO ANSWER

(agent 2)
Local/90219@default_queue-2bd3;1 NO ANSWER

(queue)
SIP/90023-08227028 #call_id=1223491293.28#queue=22901 NO ANSWER

(agent 2)
SIP/90219-0825f688 NO ANSWER
Local/90219@default_queue-2bd3;2 #call_id=1223491303.33#agent=90219 NO ANSWER

And no CDR for unanswered last part.


Scenario ASTERISK-2
90023 -> Queue -> 90132 (NO ANSWER)
-> Voicemail (ANSWERED)

(agent 1)
Local/90132@default_queue-aed3;1 NO ANSWER

(queue)
SIP/90023-b77004e8 #call_id=1223491791.35#queue=22901 NO ANSWER

(agent 1)
SIP/90132-08227028 NO ANSWER
Local/90132@default_queue-aed3;2 #call_id=1223491791.37#agent=90132 NO ANSWER

(voicemail)
SIP/90023-b77004e8 #call_id=1223491791.35#vm=22901 ANSWERED


Scenario ASTERISK-3
90023 -> Queue -> 90132 (NO ANSWER)

caller hangs up before anybody picks up

(agent 1)
Local/90132@default_queue-318b;1 NO ANSWER
SIP/90132-08227028 NO ANSWER
Local/90132@default_queue-318b;2 #call_id=1223492043.41#agent=90132 NO ANSWER

and no CDR for queue.

Scenario ASTERISK-4
90023 -> Queue -> 90132 (NO ANSWER)

caller waits for queue timeout

(agent 1)
Local/90132@default_queue-7068;1 NO ANSWER
SIP/90132-08227028 NO ANSWER
Local/90132@default_queue-7068;2 #call_id=1223492171.45#agent=90132 NO ANSWER

and again no queue CDR.
</pre>


By: Steve Murphy (murf) 2008-10-08 16:20:08

atis-- questions about the scenarios above:

#2 (and on) I assume that the call to 90219 doesn't happen until 90132
times out? Or are both calls in parallel? You only specified 1 member
in the queue config file...

ASTERISK-1 and others using voicemail: how exactly do you send the callers into voicemail?
By: Atis Lezdins (atis) 2008-10-08 16:34:39

No, there are two members with local channels. Please see sample_config_2.tar.gz

As for voicemail - i didn't bothered to use actual voicemail, i just did what i usually do for voicemail:

ResetCDR(w);
Set(CDR(userfield)=#call_id=...#voicemail=n);

then Answer() and Wait() - as would do voicemail. It's all in sample dialplan. In tests i adjusted timeouts a little, so that i get out of queue sooner or later, commented voicemail context and other small changes.

Anyway, i'll be waiting for some solution from you, and i'm ready to test whatever ideas you have.

Oh, and tests are - what happens on 1.6, however what i would like to get is:

CDR 1: #queue=22901 (ANSWERED or NO ANSWER)
CDR 2: #agent=123 (ANSWERED or NO ANSWER)
CDR 3: #voicemail=22901 (ANSWERED - if caller gets to vm app)

in general, i'm used to frequent use of ResetCDR(w) and changing userfield whenever i send caller to other side of dialplan. So, before queue there could be #ivr=abc, #agi=myagi.php and so on - in total this makes nice alternative to CEL :)
By: mdu113 (mdu113) 2008-10-29 14:33:12

Don't know if it's related or it's a separate issue, but here's another scenario in which userfield is lost involving semi-attended transfer:
1. A calls B
2. B answers
3. A puts B on hold and dials C
4. A transfers B to C before C answers
Result:
1. CDR for call from A to B does have userfield set
2. CDR for call from A to C has no userfield.
I'm using similar to atis's technique of encoding what happens to the call into userfield and know for sure that every call involves setting userfield, but in this case it's not propagated to the cdr backend - pgsql in my case. Also, if that matters, in my case all call processing including setting userfield is done in fastagi application.
Please let me know if you want me to open a separate bug report on this.
By: mdu113 (mdu113) 2008-10-29 14:36:24

Forgot to say: if I do attended transfer, i.e. A waits for C to answer and then complete the transfer then userfield is propagated to cdr just fine. The issue exists only for semi-attended transfer
By: Steve Murphy (murf) 2009-01-27 16:08:03.000-0600

I've marked that this bug is related to 13691; I've attached a patch there;
please evaluate and report results wrt this bug.
By: Leif Madsen (lmadsen) 2009-03-04 12:43:50.000-0600

Pinging original reporter of this issue. Any comments?
By: Atis Lezdins (atis) 2009-03-12 14:56:39

Patch 13691.patch from ASTERISK-12890 indeed fixes those issues in Asterisk 1.6.0.6
By: Leif Madsen (lmadsen) 2009-03-18 08:26:32

Confirming this issue as a reporter indicates a patch from another issue resolves his issue.
By: Matthew Nicholson (mnicholson) 2009-04-21 11:50:14

I have marked this issue as resolved, but I am keeping it open until 0013691 is closed.
By: Digium Subversion (svnbot) 2009-05-12 17:15:54

Repository: asterisk
Revision: 194028

U   branches/1.4/apps/app_queue.c

------------------------------------------------------------------------
r194028 | mnicholson | 2009-05-12 17:15:50 -0500 (Tue, 12 May 2009) | 16 lines

This change modifies app_queue to properly generate CDR records in failure
situations.

This involves setting a proper cdr disposition coresponding to the given
failure condition and ensuring the proper information is stored in the cdr
record.

(closes issue ASTERISK-12890)
Reported by: dferrer
Tested by: mnicholson

(closes issue ASTERISK-12839)
Reported by: atis
Tested by: atis


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194028
By: Digium Subversion (svnbot) 2009-05-12 17:32:20

Repository: asterisk
Revision: 194057

_U  trunk/
U   trunk/apps/app_queue.c

------------------------------------------------------------------------
r194057 | mnicholson | 2009-05-12 17:32:18 -0500 (Tue, 12 May 2009) | 22 lines

Merged revisions 194028 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r194028 | mnicholson | 2009-05-12 17:15:45 -0500 (Tue, 12 May 2009) | 16 lines
 
 This change modifies app_queue to properly generate CDR records in failure
 situations.
 
 This involves setting a proper cdr disposition coresponding to the given
 failure condition and ensuring the proper information is stored in the cdr
 record.
 
 (closes issue ASTERISK-12890)
 Reported by: dferrer
 Tested by: mnicholson
 
 (closes issue ASTERISK-12839)
 Reported by: atis
 Tested by: atis
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194057
By: Digium Subversion (svnbot) 2009-05-12 17:48:21

Repository: asterisk
Revision: 194059

_U  branches/1.6.2/
U   branches/1.6.2/apps/app_queue.c

------------------------------------------------------------------------
r194059 | mnicholson | 2009-05-12 17:48:19 -0500 (Tue, 12 May 2009) | 29 lines

Merged revisions 194057 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r194057 | mnicholson | 2009-05-12 17:32:13 -0500 (Tue, 12 May 2009) | 22 lines
 
 Merged revisions 194028 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r194028 | mnicholson | 2009-05-12 17:15:45 -0500 (Tue, 12 May 2009) | 16 lines
   
   This change modifies app_queue to properly generate CDR records in failure
   situations.
   
   This involves setting a proper cdr disposition coresponding to the given
   failure condition and ensuring the proper information is stored in the cdr
   record.
   
   (closes issue ASTERISK-12890)
   Reported by: dferrer
   Tested by: mnicholson
   
   (closes issue ASTERISK-12839)
   Reported by: atis
   Tested by: atis
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194059
By: Digium Subversion (svnbot) 2009-05-12 18:01:56

Repository: asterisk
Revision: 194062

_U  branches/1.6.1/
U   branches/1.6.1/apps/app_queue.c

------------------------------------------------------------------------
r194062 | mnicholson | 2009-05-12 18:01:54 -0500 (Tue, 12 May 2009) | 29 lines

Merged revisions 194057 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r194057 | mnicholson | 2009-05-12 17:32:13 -0500 (Tue, 12 May 2009) | 22 lines
 
 Merged revisions 194028 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r194028 | mnicholson | 2009-05-12 17:15:45 -0500 (Tue, 12 May 2009) | 16 lines
   
   This change modifies app_queue to properly generate CDR records in failure
   situations.
   
   This involves setting a proper cdr disposition coresponding to the given
   failure condition and ensuring the proper information is stored in the cdr
   record.
   
   (closes issue ASTERISK-12890)
   Reported by: dferrer
   Tested by: mnicholson
   
   (closes issue ASTERISK-12839)
   Reported by: atis
   Tested by: atis
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194062
By: Digium Subversion (svnbot) 2009-05-12 18:04:05

Repository: asterisk
Revision: 194063

_U  branches/1.6.0/
U   branches/1.6.0/apps/app_queue.c

------------------------------------------------------------------------
r194063 | mnicholson | 2009-05-12 18:04:02 -0500 (Tue, 12 May 2009) | 29 lines

Merged revisions 194057 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r194057 | mnicholson | 2009-05-12 17:32:13 -0500 (Tue, 12 May 2009) | 22 lines
 
 Merged revisions 194028 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r194028 | mnicholson | 2009-05-12 17:15:45 -0500 (Tue, 12 May 2009) | 16 lines
   
   This change modifies app_queue to properly generate CDR records in failure
   situations.
   
   This involves setting a proper cdr disposition coresponding to the given
   failure condition and ensuring the proper information is stored in the cdr
   record.
   
   (closes issue ASTERISK-12890)
   Reported by: dferrer
   Tested by: mnicholson
   
   (closes issue ASTERISK-12839)
   Reported by: atis
   Tested by: atis
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=194063