[Home]

Summary:ASTERISK-05763: [patch] Disposition showing FAILED even though call is answered successfully
Reporter:Pedro Tomas (tracinet)Labels:
Date Opened:2005-12-02 14:08:47.000-0600Date Closed:2008-01-15 17:48:04.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) mydiff
Description:When a call placed to a SIP device registered to Asterisk and the call is answered, all seems fine but when you go and look at the cdr log, the DISPOSITION field shows as FAILED instead of ANSWERED.
Comments:By: Pedro Tomas (tracinet) 2005-12-08 15:23:51.000-0600

I believe this should be upgraded to MAJOR based on the fact that the billsec field is showing 0 seconds for calls that are completed, but show as FAILED.  This is really an issue with cdr billing which can cost a VoIP provider quite  a bit of money.  I did not realize this was happening at first or I would have marked it as MAJOR to begin with.
By: vortex_0_o (vortex_0_o) 2005-12-21 12:19:25.000-0600

not sure is this is related but if you have a dialplan like this (using peer2 for failover):

exten => _0[1-9].,1,Dial(SIP/44${EXTEN:1}@peer1)
exten => _0[1-9].,2,Dial(SIP/44${EXTEN:1}@peer2)

and peer1 fails for some reason but peer 2 goes through ok the DISPOSITION field shows up as FAILED even though the call is completed fine
By: Jason Parker (jparker) 2005-12-21 12:35:47.000-0600

tracinet, are you also seeing this only during failover scenarios?

You could probably work around this by doing a ResetCDR after the first failure.

It also appears at first glance, that the code is only setting the disposition to ANSWERED if it was already NO ANSWER (the default, if unset) or BUSY.  Can anybody think of a legitimate reason it might be doing this?

if (cdr->disposition < AST_CDR_ANSWERED)
       cdr->disposition = AST_CDR_ANSWERED;
By: Pedro Tomas (tracinet) 2005-12-21 12:39:08.000-0600

In my case there is no failover.  My setup is as follows:

incoming call from PSTN ---SIP---> asteriskA ---IAX2---> asteriskB ---SIP---> SIP Phone

The call log does show disposition ANSWERED on asteriskA, but FAILED on asteriskB.
By: Andrew Kohlsmith (akohlsmith) 2005-12-27 06:17:46.000-0600

I just got this myself last night.

Unlimitel -> SIP -> Colo* -> IAX2 -> Home* -> TDM400 - cordless phone

Colo* shows the CDR as "ANSWERED" but Home* shows it as "FAILED" -- both are at the same version (SVN-trunk-r7230).

Now I had one-way audio on this too.  I could hear them when I picked up the ringing phone, but they could not hear me.

From Colo*:
   -- Executing Goto("SIP/5194894902-eb80", "call-andrew|5194894902|1") in new stack
   -- Goto (call-andrew,5194894902,1)
   -- Executing Goto("SIP/5194894902-eb80", "2914574|1") in new stack
   -- Goto (call-andrew,2914574,1)
   -- Executing System("SIP/5194894902-eb80", "/usr/bin/perl /usr/local/scripts/astbot.pl '5192427100'") in new stack
   -- Executing NoOp("SIP/5194894902-eb80", "CALLERID is '5192427100' and CALLERANI is '' and CALLINGANI2 is '0'") in new stack
   -- Executing Dial("SIP/5194894902-eb80", "IAX2/wu-ast@andrew&IAX2/benphone@benphone/2914574|12|rt") in new stack
   -- Called wu-ast:aksecret@andrew
   -- Called benphone@benphone/2914574
   -- Call accepted by 192.168.2.2 (format gsm)
   -- Format for call is gsm                                                            
   -- Call accepted by 165.x.x.x (format gsm)
   -- Format for call is gsm
   -- IAX2/andrew-14 is ringing
   -- IAX2/benphone-23 is proceeding passing it to SIP/5194894902-eb80
   -- IAX2/benphone-23 is ringing
   -- IAX2/andrew-14 answered SIP/5194894902-eb80
Dec 27 00:19:56 NOTICE[1460]: sched.c:296 ast_sched_del: Attempted to delete nonexistent schedule entry 436308!
   -- Hungup 'IAX2/benphone-23'
   -- Hungup 'IAX2/andrew-14'

And on my home * box:
   -- Accepting AUTHENTICATED call from 165.x.x.x:
      > requested format = ulaw,
      > requested prefs = (),
      > actual format = gsm,
      > host prefs = (gsm),
      > priority = mine
   -- Executing Dial("IAX2/ak_ulaw-2", "Zap/1&Zap/2&IAX2/andrew-bt||r") in new stack
   -- Called 1
   -- Called 2
Dec 27 00:27:52 NOTICE[18340]: app_dial.c:1010 dial_exec_full: Unable to create channel of type 'IAX2' (cause 3 - No route to destination)
   -- Zap/1-1 is ringing
   -- Zap/2-1 is ringing
   -- Zap/1-1 is ringing
   -- Zap/2-1 is ringing
   -- Zap/1-1 is ringing
   -- Zap/2-1 is ringing
   -- Zap/1-1 answered IAX2/ak_ulaw-2
   -- Hungup 'Zap/2-1'

(you'll notice that both generate an "answered" message)

CDR from Colo*:
"","5192427100","2914574","call-andrew","5192427100","SIP/5194894902-eb80","IAX2/andrew-14","Dial","IAX2/wu-ast@andrew&IAX2/benphone@benphone/2914574|12|rt","2005-12-27 00:19:44","2005-12-27 00:19:56","2005-12-27 00:20:12",28,16,"ANSWERED","DOCUMENTATION"

CDR from Home*:
"","5192427100","s","incoming","5192427100","IAX2/ak_ulaw-2","Zap/1-1","Dial","Zap/1&Zap/2&IAX2/andrew-bt||r","2005-12-27 00:27:52","2005-12-27 00:28:03","2005-12-27 00:28:19",27,16,"FAILED","BILLING"

(note the billsec is the same)
By: Andrew Kohlsmith (akohlsmith) 2005-12-27 11:14:59.000-0600

the FAILED disposition occurs with EVERY answered incoming call, whether it's one-way or not, coming from SIP or not.
By: Jan-Peter Koopmann (jkoopmann) 2006-01-06 06:01:46.000-0600

I can confirm the issue. Started with 1.2 as far as I remember 1.0.9 did not show this behaviour. I too get disposition FAILED on every incoming call (same as akohlsmith)

Could someone please upgrade this to major?
By: Russell McConnachie (morale) 2006-01-07 20:05:55.000-0600

[macro-regular]
exten => s,1,Set(CALLERID(all)=${ARG2})
exten => s,2,Dial(${ARG1},50)
exten => s,3,Goto(s-${DIALSTATUS},1)
exten => s-NOANSWER,1,Playback(number-not-answering)
exten => s-NOANSWER,2,MacroExit
exten => s-BUSY,1,Playback(is-curntly-busy)
exten => s-BUSY,2,MacroExit
exten => s-CONGESTION,1,Playback(is-curntly-busy)
exten => s-CONGESTION,2,MacroExit
exten => s-ANSWERED,1,NoOp(Call answered and has been terminated)
exten => s-ANSWERED,2,MacroExit
exten => _s-.,1,Goto(s-NOANSWER,1)

[trunklocal]
exten => _9NXXXXXX,1,Macro(regular,${FWDTRUNK}/1403${EXTEN:${FWDTRUNKMSD}},R K McConnachie <403XXXXXXX>)
exten => _9NXXXXXX,2,Hangup

exten => _9NXXXXXXXXX,1,Macro(regular,${FWDTRUNK}/1${EXTEN:${FWDTRUNKMSD}},R K McConnachie <403XXXXXXX>)
exten => _9NXXXXXXXXX,2,Hangup
By: Russell McConnachie (morale) 2006-01-07 20:07:19.000-0600

asterisk=# select calldate, clid, src, dst, duration, disposition from cdr where calldate like '2006-%' AND disposition='FAILED';
       calldate        |    clid    |    src     |     dst     | duration | disposition
------------------------+------------+------------+-------------+----------+-------------
2006-01-01 00:20:06-07 |            |            | 14036681593 |       60 | FAILED
2006-01-01 01:37:41-07 | 4036153701 | 4036153701 | 14036681593 |       32 | FAILED
2006-01-01 01:38:53-07 | 4036197549 | 4036197549 | 14036681593 |       58 | FAILED
2006-01-01 11:43:07-07 | 2504267115 | 2504267115 | 14036681593 |      344 | FAILED

and so on..
By: Russell McConnachie (morale) 2006-01-07 20:09:50.000-0600

Zaptel Configuration
======================

Channel map:

Channel 04: FXO Kewlstart (Default) (Slaves: 04)

1 channels configured.

[~] ~ root@silicon> lsmod | grep -E '(wc|zap)'
wcfxo                  10528  0
wctdm                  33472  1
zaptel                185092  9 wcfxo,wctdm,ztdummy

Asterisk (Asterisk 1.2.1 built by kk @ nyx on a x86_64 running Linux on 2006-01-02 00:19:54 UTC)

[/proc/zaptel] ~ root@silicon> cat *
Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"

Span 2: WCTDM/0 "Wildcard TDM400P REV I Board 1"

          1 WCTDM/0/0
          2 WCTDM/0/1
          3 WCTDM/0/2
          4 WCTDM/0/3 FXOKS (In use)
Span 3: WCFXO/0 "Generic Clone Board 1" RED

          5 WCFXO/0/0
Span 4: WCFXO/1 "Generic Clone Board 2" RED

          6 WCFXO/1/0
By: Pedro Tomas (tracinet) 2006-01-24 06:34:48.000-0600

Issue still present on v. 1.2.2 - any ideas on how to fix this yet?
By: Pedro Tomas (tracinet) 2006-01-24 12:56:38.000-0600

Thanks to Mark Spencer for the attached file that appears to fix this bug which apparently was only happening when the Dial statement contained more than one SIP user and when those SIP users were not connected.
By: Juan Pablo Abuyeres (jpabuyer) 2006-02-04 07:12:02.000-0600

the patch is still not commited on svn, right?
By: Marco Cintolesi (dartvader) 2006-03-15 03:46:28.000-0600

Any news about that ?!?!
Still not committed in 1.2.5.....
I think many providers need that patch committed ASAP.
By: Pedro Tomas (tracinet) 2006-03-15 07:15:40.000-0600

Agreed - been using the patch for 2 months without issue.  Would be nice to have it in the official release or at least branch.
By: Matteo Piscitelli (picciux) 2006-03-17 03:40:52.000-0600

we've been using this patch for a few days and it works. Someone else have been using this for longer with no issues. I think it has to go in 1.2.6: it's a bug.
By: Joshua C. Colp (jcolp) 2006-03-22 15:44:50.000-0600

Fixed in both 1.2 and trunk since it was a bug. Enjoy folks!
By: Digium Subversion (svnbot) 2008-01-15 17:48:03.000-0600

Repository: asterisk
Revision: 14234

U   branches/1.2/cdr.c
U   branches/1.2/include/asterisk/cdr.h

------------------------------------------------------------------------
r14234 | file | 2008-01-15 17:48:02 -0600 (Tue, 15 Jan 2008) | 2 lines

Issue ASTERISK-5763 - Disposition showing FAILED even though call is answered successfully (Reported by tracinet)

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

http://svn.digium.com/view/asterisk?view=rev&revision=14234
By: Digium Subversion (svnbot) 2008-01-15 17:48:04.000-0600

Repository: asterisk
Revision: 14235

_U  trunk/
U   trunk/cdr.c
U   trunk/include/asterisk/cdr.h

------------------------------------------------------------------------
r14235 | file | 2008-01-15 17:48:03 -0600 (Tue, 15 Jan 2008) | 10 lines

Merged revisions 14234 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r14234 | file | 2006-03-22 17:38:32 -0400 (Wed, 22 Mar 2006) | 2 lines

Issue ASTERISK-5763 - Disposition showing FAILED even though call is answered successfully (Reported by tracinet)

........

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

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