[Home]

Summary:ASTERISK-10481: Zap assisted xfer via hookflash yield CDR errors and bad CDR's.
Reporter:Steve Murphy (murf)Labels:
Date Opened:2007-10-09 11:14:35Date Closed:2010-06-30 08:22:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) additional-info.txt
Description:While most assisted xfer scenarios seem to work OK
within chan_zap, one sequence has CDR problems.

****** STEPS TO REPRODUCE ******

Zap/52 picks up phone and dials Zap/51.
Zap/51 answers, and they talk.
Zap/52 hookflashes, and gets dialtone. Zap/51 gets MOH.
Zap/52 dials Zap/50
Zap/50 answers, and they talk.
Zap/52 hookflashes. All 3 parties are connected.
Zap/52 hangs up. (CDR errors happen at this point in time) 50/51 are still conversing.
Zap/50 and/or Zap/51 hang up.

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

The only requirement is that zap/52 be a zap channel. Same error happens if connects any other devices together, like two SIP channels, etc.

Oh, and remember that "zap/52" stands for ANY generic zap channel.
Comments:By: Steve Murphy (murf) 2007-10-09 12:01:46

I created a new CDR scenario (ASTERISK-18) that follows the procedure outlined above. Schenarios 5,6,7 do roughly the same thing, but instead of zap/52 hookflashing after the first dial, it's zap/51 that does the transfer... So this is different, and therefore, this is a bug that's most likely been around since time began.
These "scenarios" I'm talking about are explained and enumerated in some blog I did. If not, then they are in my personal notebook. Anyway, now I get to dive into the channels/chan_zap.c code, and try to understand the SUB_REAL, SUB_THREEWAY, stuff in attempt_transfer()...!

By: Steve Murphy (murf) 2007-10-09 15:27:43

hmmm further experiments show that indeed, it's almost impossible to do 3way via zaptel, WITHOUT triggering this CDR error. So, I take it back. It is new, introduced thru some change in the last number of months.

By: deeperror (deeperror) 2007-10-11 15:54:50

I'm not sure if this is related, but I see this happen once every few days and this time I noticed that it is occuring after the CDR warnings being worked on in this bug.  

Also seems to be related closely to moh.  I always see moh ended when the errors stop.

Added a file with messages output.

By: Steve Murphy (murf) 2008-02-25 11:23:38.000-0600

Sorry, I suspended work on this (about a weeks worth, iirc) in favor of other projects. Will have to get back to it soon.

By: Steve Murphy (murf) 2008-06-12 11:33:58

OK, good news.

Try checking out http://svn.digium.com/svn/asterisk/team/murf/CDRfix4

which is based on 1.4;

or, if you are more interested in trunk/1.6, then check out

http://svn.digium.com/svn/asterisk/team/murf/CDRfix6.

I just tested your sequence and no CDR errors; I get two CDR's.


By: deeperror (deeperror) 2008-06-12 12:30:50

I'm using 1.4.20.1 currently so I'll test out your updates in about an hour and report back the status.

By: deeperror (deeperror) 2008-06-12 13:35:35

After testing the 2 warnings and 1 notice are no longer showing up.  However, I do see this

[Jun 12 14:20:34] WARNING[21178] chan_zap.c: Unable to get index, and nullok is not asserted
[Jun 12 14:23:24] WARNING[21196] cdr.c: CDR on channel 'Zap/47-1' has no answer tune
[Jun 12 14:23:50] WARNING[21203] chan_zap.c: Unable to get index, and nullok is not asserted


The Unable to get index, and nullok is not asserted I've seen before and could be a coincidence.  The has no answer tune I've never seen.

By: Steve Murphy (murf) 2008-06-13 09:16:17

The "No answer tune" is a typo; I corrected it to say "No answer time" instead.
The code that generates this message is kinda new to the CDRfix4/5/6 set, and it may or may not be meaningful. For instance, if the disposition is NO_ANSWER, then not having an answer time is no crime. I can arrange to make the warning more relevant, or remove it altogether if in the end, the CDR's are what we would expect.


As to the nullok message, I have no idea what the problem is. Any guess I might make to explain it would be pure conjecture. If your Zap channels are working as expected, you might be able to ignore it. Sometimes the guys working on the channel drivers throw in diagnostics, and don't get to test it with the all the common scenarios. If enough people complain they are seeing this diagnostic message, and there aren't any real problems, they get tired of the questions, and remove the diagnostic.

So, if we ignore these diagnostics for the moment, what about the output CDR's? Are they OK?

By: deeperror (deeperror) 2008-06-13 10:06:25

nullok is unrelated to this issue.

Output CDR's seems find as I'm now getting both legs of the call in Master.csv.  

In our environment the only time I'm seeing "No Answer Time" is when an outbound call occurs and no one answers.  So from what I see the warning doesn't need to be there.  

What is a time line or how long would a fix like this take to get into stable release?



By: Steve Murphy (murf) 2008-06-13 11:13:10

Well, since this set of fixes is aimed at closing several bug reports,
it would be good to have a good amount of feedback. For instance, I've
been hearing a lot of noise about dropped accountcodes... is that still a problem?

Another fly in the ointment is that I plan to svnmerge in the dahdi
code today, which will trade the zap for dahdi names, which shouldn't
make any difference, but... you never know.

I do have some requests to fix the CDR generation for things like
attended xfers, to generate 3 CDR's instead of 2. But I need some sort
of agreement about how the 3rd CDR should appear.  I've been thinking
on it, and the transferer should be the originator, even if he didn't
participate in the call, because he's the one that dialed it. So, if
he transfers the call to a long-distance external number, he should most
likely get assigned the $400 expense. Perhaps the lastapp could be 'xfer',
and the lastdata could indicate that he transferred the call to "Zap/11"
or somesuch... at any rate, such structural changes to the way CDR's are
getting generated will most likely not be welcome in 1.4, but depending
on who you talk to, it could either be considered an enhancement or a bug fix.
In such cases, I'd have to go with the guys whose apps would be broken,
and call it an enhancement, and intro it in trunk for the next 1.6 release.
What do you-all think?

By: Steve Murphy (murf) 2008-06-13 12:47:02

OK, I've svnmerged and now we are dahdi based instead of zaptel based.
What you need to do is check out:

http://svn.digium.com/svn/dahdi/linux/trunk
http://svn.digium.com/svn/dahdi/tools/trunk

build and install first the linux half
then build and install the tools half;

then run ./configure in the CDRfix* dir make menuselect; make; make install
there. Make sure the channel driver "chan_dahdi" is selected (if you use
any zap stuff), and built.

By: Steve Murphy (murf) 2008-06-16 11:21:57

OK, I slightly modified that warning message to only be emitted if the
CDR is marked "ANSWERED", and there is no answer time set. This makes
it a little more useful; it should never appear in normal operating
conditions. This has been committed to CDRfix4 and CDRfix6.

By: Digium Subversion (svnbot) 2008-07-02 19:09:00

Repository: asterisk
Revision: 127663

U   branches/1.4/channels/chan_dahdi.c
U   branches/1.4/channels/chan_sip.c
U   branches/1.4/include/asterisk/cdr.h
U   branches/1.4/main/cdr.c
U   branches/1.4/main/channel.c
U   branches/1.4/main/pbx.c
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r127663 | murf | 2008-07-02 19:08:58 -0500 (Wed, 02 Jul 2008) | 30 lines

The CDRfix4/5/6 omnibus cdr fixes.

(closes issue ASTERISK-10481)
Reported by: murf
Tested by: murf, deeperror

(closes issue ASTERISK-12240)
Reported by: falves11
Tested by: murf, falves11


(closes issue ASTERISK-11309)
Reported by: greyvoip

As to 11849, I think these changes fix the core problems
brought up in that bug, but perhaps not the more global
problems created by the limitations of CDR's themselves
not being oriented around transfers.

Reopen if necc, but bug reports are not the best
medium for enhancement discussions. We need to start
a second-generation CDR standardization effort to cover
transfers.

(closes issue ASTERISK-10625)
Reported by: rossbeer
Tested by: greyvoip, murf



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

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