[Home]

Summary:ASTERISK-13064: After upgrading from 1.4.21.2 to 1.4.22 unaswered calls aren't correctly saved as CDR
Reporter:Igor Zamocky (dzajro)Labels:
Date Opened:2008-11-12 17:11:51.000-0600Date Closed:2011-06-07 14:02:47
Priority:MajorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20090130-rel_cause_1_unaswered_yes.txt
( 1) 20090130-rel_cause_1.txt
( 2) 20090130-rel_cause_3.txt
( 3) 20090131_rel_cause_1_unanswered_yes_callattempts_yes.txt
( 4) call_to_number_with_rel_cause_1.txt
( 5) call_to_number_with_rel_cause_3.txt
( 6) d14.dig1
Description:Call from SIP extension into PSTN via Zap to non-existing number. PSTN is correctly returning unassigne/unallocated number.

   -- Executing [s@macro-to-pstn-4:3] Dial("SIP/421232660232-0a2d22d8", "Zap/g4/421230123123") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called g4/421230123123
   -- Zap/1-1 is proceeding passing it to SIP/421232660232-0a2d22d8
   -- Channel 0/1, span 1 got hangup request, cause 1
   -- Hungup 'Zap/1-1'
 == Everyone is busy/congested at this time (1:0/0/1)

With 1.4.21.2 and "unanswered = no" in cdr.conf * produces following CDR:

src=421232660232
dst=421230123123
channel=SIP/421232660232-xxx
dstchannel=Zap/1-1
duration=0
billsec=0
disposition=NO ANSWER

1.4.21.2 with "unanswered = yes" produces the same PLUS (the are 2 CDR for the same call, with the same call_date):

src=421232660232
dst=s
channel=Zap/1-1
dstchannel=
duration=0
billsec=0
disposition=NO ANSWER

With 1.4.22 and "unanswered = no" system produces NO CDR

With 1.4.22 and "unanswered = yes" system produces only ONE CDR:
src=
dst=s
channel=Zap/1-1
dstchannel=
duration=0
billsec=0
disposition=NO ANSWER

This CDR is unusable for billing/documentary purpose, there's NO SRC, no real channel.
Comments:By: Grey VoIP (greyvoip) 2008-11-13 05:26:40.000-0600

Probably related to the changes that have been going on for http://bugs.digium.com/view.php?id=11849.
By: Martin B. Smith (martins) 2008-11-13 12:19:47.000-0600

We've also encountered this problem. Here's our setup:

1. Software activates SIP TAPI, which connects via SIP to Asterisk
1. SIPTAPI calls the user at the same SIP/xyz address, does SIP REFER to Zap/number

When we upgraded to 1.4.22, we noticed we're missing a huge amount of calls we used to be able to corroborate with CDRs -- almost every single one is an unanswered call. We average more than millions of calls in a 2-month period, and this popped up immediately on the upgrade.
By: Steve Murphy (murf) 2008-12-02 22:41:47.000-0600

I've uploaded a patch against 1.4 svn, that should give you the results you expect. A cdr_update is done early in the dial() sequence, to make sure the dest, dcontext are properly set when NO_ANSWER prevents the update in the bridge.

I also (when unanswered=yes cdr.conf) generate more appropriate CDR's for the
unanswered dial attempts in multi-target dials.

Give it a spin and see if solves this problem.

By: Igor Zamocky (dzajro) 2008-12-03 17:09:37.000-0600

So, I tried the patch on 1.4.22

with unanswered=no, there's still no cdr for calls ended with release cause 1 (unassigned/unallocated), the same behaviour as earlier.

with unanswered=yes, every time I called non_existent number (unassigned/unallocated), asterisk crashed.
By: Steve Murphy (murf) 2008-12-03 17:16:59.000-0600

Hmmm. Interesting. Could you try this against the current SVN of 1.4?
Other patches already committed may be playing a part...
By: Igor Zamocky (dzajro) 2008-12-03 17:40:09.000-0600

I apologize, but probably I can't do that. I don't have testing instalation with PRI cards to fully simulate production network :-(.
By: Igor Zamocky (dzajro) 2008-12-03 18:20:01.000-0600

Btw, what is really strange. I uploaded output (verbose 4 / debug 1) from 2 calls.

First is attempt to call unassigned number (rel. cause=1).
Second is to currently unreachable number / No route to destination number (rel. cause 3).

First ends without storing CDR, second stored CDR.
By: Steve Murphy (murf) 2009-01-07 17:46:27.000-0600

Hey, when there's a failure, and it crashes, could you get stack trace with gdb and attach it to this bug? It hopefully is something simple & easy.



By: Igor Zamocky (dzajro) 2009-01-09 07:05:18.000-0600

Uhm, crashes?
Was anybody talking about crashes? The're no crashes related to this bug, just missing CDRs.
By: Leif Madsen (lmadsen) 2009-01-09 07:08:57.000-0600

dzajro: ummm... you were. And I quote:

"with unanswered=yes, every time I called non_existent number (unassigned/unallocated), asterisk crashed. "
By: Steve Murphy (murf) 2009-01-30 00:14:14.000-0600

OK, I reproduced the "missing CDR effect" when you try to call a device that doesn't exist: you get no CDR at all. And I think I have it.

Please download and apply the "d1.dig1" patch.

It mods chan_dahdi to return a more accurate cause when a channel can't be matched. It forces a CDR to be output when such a failure occurs, whether you say "unanswered=yes" or not.

Now, when you do a dial(dahdi/1/888888) and dahdi/1 is a PRI, the guy at the other end will most likely choke on the 888888, but all you'll be able to say about it is probably "NO ANSWER", because the remote systems hangup cause doesn't seem to be returned-- which may be a bug; at least I've covered the problems with CDRs and dial.

Please test ASAP. I'd like to get this into the next release. I'd love to get your feedback on this, but really, I need to get this in today...
By: Igor Zamocky (dzajro) 2009-01-30 09:02:21.000-0600

Murf, I will try it as soon as possible, but I have to wait to night hours.
I need to patch production gw. It's exactly 16:02, give me 8 hours. I'll give You answer till 0:00.
By: Steve Murphy (murf) 2009-01-30 14:08:48.000-0600

dzajro-- This morning, I tracked down the case where an incoming call for exten 88888 can't be found (in PRI); a channel is not yet created. I wrote code to generate a CDR for such a case, but in discussion with other devs, they wonder if enough calls could be generated to flood the CDR backend and swamp your system (a DOS attack). so I added the variable 'callattempts' to cdr.conf.

If you specify

callattempts = yes

you get these CDR's. Otherwise you don't.


 Anyway, I'm going to post the diffs (again)... this will be d2.dig1.
By: Steve Murphy (murf) 2009-01-30 15:12:17.000-0600

Oh, just to report on the d2.dig1 patch;

If the extension isn't found on the target system, on the calling system,
you get this CDR:

(for reference, use cdr_custom.conf to see what fields are listed, and in what order; in the following DAHDI/51 is a regular fxs extension; DAHDI/10 and DAHDI/13 are in a T1 set that have the same names in both the calling and the called systems... Dahdi/25 is the device you get when you call 125 on the called system;  and 'unanswered=no' on the called system)

""fxs.51" <151>","151","303","extension","DAHDI/51-1","DAHDI/13-1","Dial","Dahdi/13/1800|30|TtWwHhKkXx","2009-01-30 13:07:24","","2009-01-30 13:07:30","6","0","FAILED","DOCUMENTATION","","1233346044.6","",""


and on the called system, you get this report (assuming you have callattempts=yes set in the [general] section of cdr.conf):

""fxs.51" <151>","151","1800","t1incoming","DAHDI/13-1","<unknown>","","","2009-01-30 13:07:22","","2009-01-30 13:07:22","0","0","FAILED","DOCUMENTATION","","1233346042.x0","",""

if you haven't got callattempts = yes set, then you get nothing (but a message on the console if you turn verbosity high enough)

Now, if you call a legal exten on the target system, but that device is gone/not working or whatever, you get this on the calling system:

""fxs.51" <151>","151","302","extension","DAHDI/51-1","DAHDI/10-1","Dial","Dahdi/10/180|30|TtWwHhKkXx","2009-01-30 13:46:27","","2009-01-30 13:46:34","7","0","NO ANSWER","DOCUMENTATION","","1233348387.10","",""


and you get this on the called system:  (Dahdi/80 doesn't exist)

""fxs.51" <151>","151","180","t1incoming","DAHDI/10-1","Dahdi/80","Dial","Dahdi/80|30|eTtWwKkHhXx","2009-01-30 13:46:25","","2009-01-30 13:46:29","4","0","FAILED","DOCUMENTATION","","1233348385.1","",""




when you dial a legal exten via PRI you will get:
(on the calling system)

""fxs.51" <151>","151","301","extension","DAHDI/51-1","DAHDI/10-1","Dial","Dahdi/10/125|30|TtWwHhKkXx","2009-01-30 13:58:52","2009-01-30 13:59:04","2009-01-30 13:59:09","17","5","ANSWERED","DOCUMENTATION","","1233349132.12","",""


(on the called system)

""fxs.51" <151>","151","125","t1incoming","DAHDI/10-1","DAHDI/25-1","Dial","Dahdi/25|30|eTtWwKkHhXx","2009-01-30 13:58:53","2009-01-30 13:59:00","2009-01-30 13:59:04","11","4","ANSWERED","DOCUMENTATION","","1233349133.2","",""



And, when the pone on the called system doesn't answer, you get:

(on the calling system)

""fxs.51" <151>","151","301","extension","DAHDI/51-1","DAHDI/10-1","Dial","Dahdi/10/125|30|TtWwHhKkXx","2009-01-30 14:01:03","","2009-01-30 14:01:36","33","0","NO ANSWER","DOCUMENTATION","","1233349263.14","",""

and on the called system, we see:

""fxs.51" <151>","151","125","t1incoming","DAHDI/10-1","DAHDI/25-1","Dial","Dahdi/25|30|eTtWwKkHhXx","2009-01-30 14:01:00","","2009-01-30 14:01:32","32","0","NO ANSWER","DOCUMENTATION","","1233349260.4","",""
By: Igor Zamocky (dzajro) 2009-01-30 16:41:39.000-0600

I've just tested d1.dig1, sorry but the same behaviour.

Call to number released by PSTN with rel. cause 0x03 (no route) - there was CDR generated, see 20090130-rel_cause_3.txt (set verbose 3, set debug 1)

Call to number released by PSTN with rel. cause 0x01 (unassigned) - there was NO CDR, see 20090130-rel_cause_1.txt (set verbose 3, set debug 1)

AS I understand it properly, d2.dig1 is the same patch with whole callattempts=yes limitation, right?
By: Igor Zamocky (dzajro) 2009-01-30 16:42:43.000-0600

Yes, and 'unanswered' was set to No.
By: Igor Zamocky (dzajro) 2009-01-30 16:51:04.000-0600

In 20090130-rel_cause_1_unanswered_yes.txt is call attempt to the same number (again released by PSTN with rel. cause 0x01) with 'unanswered=yes'. There is one CDR generated, but this CDR has no destination (instead destination there is just 's') so this CDR is unusable.

Not to mention, that with unanswered=yes call attempt to number released by PSTN with rel. cause 3, 2 CDRs are generated. One with destination='s', second with correct destination.
By: Igor Zamocky (dzajro) 2009-01-30 17:17:15.000-0600

Btw, these two latest patches I tried without previous 13892.patch.
With 13892.patch applied d2.dig1 was rejected.
By: Igor Zamocky (dzajro) 2009-01-30 17:19:22.000-0600

And last thing, sorry for my note from 2009-01-09, meanwhile I forgot crashes :-(.

With 13892.patch, unaswered=yes and call to number released by PSTN with 0x01 => crash:
---------------------------------------------------------------------------
rogram received signal SIGSEGV, Segmentation fault.
[Switching to Thread 78375840 (LWP 26303)]
0x00a6ae2f in dial_exec_full (chan=0x8c1d318, data=Variable "data" is not available.
) at app_dial.c:1449
1449                                    if (strcmp(o->chan->cdr->dstchannel, chan->cdr->dstchannel) == 0) {
(gdb) bt
#0  0x00a6ae2f in dial_exec_full (chan=0x8c1d318, data=Variable "data" is not available.
) at app_dial.c:1449
#1  0x00a6d3e4 in dial_exec (chan=0x0, data=0xffffffff) at app_dial.c:1869
#2  0x080cafb0 in pbx_extension_helper (c=0x8c1d318, con=Variable "con" is not available.
) at /usr/src/asterisk/asterisk-1.4.22/include/asterisk/strings.h:35
#3  0x080cb4fa in ast_spawn_extension (c=0x0, context=0xffffffff <Address 0xffffffff out of bounds>,
   exten=0xffffffff <Address 0xffffffff out of bounds>, priority=-1, callerid=0xffffffff <Address 0xffffffff out of bounds>)
   at pbx.c:2317
#4  0x00142ff6 in _macro_exec (chan=0x8c1d318, data=Variable "data" is not available.
) at app_macro.c:308
ASTERISK-1  0x080cafb0 in pbx_extension_helper (c=0x8c1d318, con=Variable "con" is not available.
) at /usr/src/asterisk/asterisk-1.4.22/include/asterisk/strings.h:35
ASTERISK-2  0x080cf766 in __ast_pbx_run (c=0x8c1d318) at pbx.c:2317
ASTERISK-3  0x080d162e in pbx_thread (data=0x8c1d318) at pbx.c:2621
ASTERISK-4  0x08101835 in dummy_start (data=0xffffffff) at utils.c:912
ASTERISK-5  0x0074b3cc in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-6 0x006a41ae in clone () from /lib/tls/libc.so.6
By: Steve Murphy (murf) 2009-01-30 18:35:29.000-0600

Sorry, but the original 13892.patch is outdated; don't touch it.

Test only the d2.dig1 patch, all by itself; on the latest svn of 1.4
The reason: I'm staging patches in sequence: If you apply this patch to some
tarball release, you'll be missing bugs fixed earlier.

You can play with both unanswered=yes/no   and callattempts=yes/no

by default, both are turned off. If you want to see the call attempts where cause=1, you'll need to set callattempts=yes;
By: Igor Zamocky (dzajro) 2009-01-31 02:32:20.000-0600

Okej, forgetting 13892.patch :)

Regarding callattempts=yes / unanswered = yes

In 20090130-rel_cause_1_unanswered_yes.txt is call attempt to the same number (again released by PSTN with rel. cause 0x01) with 'unanswered=yes'. There is one CDR generated, but this CDR has no destination (instead destination there is just 's').

Is there a chance this will be fixed?

Another question, do You think it's a good idea to run latest svn of 1.4 in production environment ? We have thousands of SIP and hundreds of iax2 peers. Stability is critical for us.
By: Steve Murphy (murf) 2009-01-31 12:55:21.000-0600

The "s" is because of the macro call; hmmmm. What should it be? 421232000000?

As to the question about 1.4 svn in a production environment...

That's a question only YOU can answer! If you are not doing it already,
you should be doing this:

1. You should have a at least one other machine identical to the one you are using for production. It is your "test", or "staging" machine.

2. On the test machine, you should have some way to test candidates for upgrades-- either via simulating normal traffic, or a way to shunt a small percentage of your normal traffic thru it. Simulation is best, because it won't disturb any customers if you encounter total disaster. Tools like sipp could help here. To simulate T1 traffic, you may need to grab a third machine, put a t1 card in it, and use it simulate the pstn, making and getting calls to/from your test machine.

3. You need to keep tight track of your config files. CVS, SVN, or even git would be sufficient for this. You commit every change you make, and record in the logs what you were doing and why.

4. You ONLY change what you have on the production machine after it has been tested to your satisfaction. You would probably copy all config files, etc, as a unit, and log that.

5. "If it isn't broken, don't fix it", is what the engineers always say; it's advice to the wise. Don't upgrade your production boxes unless there is a compelling reason to do so. Never do it just "because". Never do it because "newer versions are available". For instance, you could do it for security fixes, which is a pretty good reason, but if, and only if, your system is actually subject to the security flaw being patched. You might try staging the fix applied to the production systems-- not upgrading to the version that the fix was applied to, but taking the raw security patch, and applying it to the version of the source your production system is running. "Change only one variable at a time", is a scientific way of determining where a problem occurs.

At some point, the "cost" of backporting such fixes will be greater than the cost of upgrading to the latest SVN release; then you've got a good reason to go with the latest version. (after testing, of course!)

So, I ask you: is 1.4 SVN  OK for production?
By: Steve Murphy (murf) 2009-01-31 14:16:22.000-0600

To answer my own question about the "s" exten, I took note that the dst field in the CDR is usually set in this manner: S_OR(c->macroexten, c->exten), which means, that when you are calling a macro, the s exten won't show up in the dst field.

So, I found that in app_dial, I was setting the dst field for peers from just the c->exten field. So I fixed that to do it like it's done everywhere else.

I have high hopes that it will solve the problem. Try the d3.dig1 patch I attached.
By: Igor Zamocky (dzajro) 2009-01-31 15:59:40.000-0600

Sorry, fresh copy of 1.4.22, with patch for 13645, patched with d3.dig1

unanswered = yes
callattempts = yes

Call to number 0232000000, PSTN released call with rel. cause 1.
Result is in attachment. No CDR.

No combination on unanswered=yes/no, callattempts=yes/no helped.

And no, ongoing question, can it be affected with patch for 13645 ?
By: Igor Zamocky (dzajro) 2009-01-31 16:26:45.000-0600

Btw, unanswered=yes (regardless of callattempts setting) makes CDR duplication for answered calls.

Example:

2009-01-31 23:18:24
"421220656110" <421220656110>
421220656110
421949483879
from-c5-routing
SIP/421220656110-b7b5f968
Zap/2-1
Dial
Zap/g4/421949483879
9
2
ANSWERED
3
s421220656110
SIPURI=sip:421220656110@10.129.0.34;SIPUSERAGENT=SJphone/1.65.377a (SJ Labs)

2009-01-31 23:18:24
"421220656110" <421220656110>
421220656110
421949483879
macro-to-pstn-4
SIP/421220656110-b7b5f968
Zap/2-1
Dial
Zap/g4/421949483879
9
2
ANSWERED
3
s421220656110
SIPURI=sip:421220656110@10.129.0.34;SIPUSERAGENT=SJphone/1.65.377a (SJ Labs)

Both CDRs are pretty valid, only difference is context. This will make serious troubles for billing.

I'm not sure, if this happened before applying d3.dig1. Anyway it will make 'unanswered=yes' useless.
By: Steve Murphy (murf) 2009-01-31 17:08:55.000-0600

does it make any difference if you test it applied to latest 1,4-svn? Because I'm running the latest 1.4 svn, and I see no such duplication of CDRs. Neither on the calling nor on the called end. Really, if we are going to test, we have to do it against the latest svn of 1.4... I realize this is hard for you, but it has to be done.

In that spirit, I just updated my 1.4 and got some conflicts with d3.dig1, so I resolved the conflicts and made a d4.dig1. I'll add that now.
By: Igor Zamocky (dzajro) 2009-02-01 03:26:18.000-0600

All right, but this will take some time.
I need few days to prepare fresh 1.4-svn system able to handle part of our traffic. I'll update you.
By: Steve Murphy (murf) 2009-02-06 09:38:10.000-0600

OK, I've been running my own tests... and I think I've tackled all the probs I noticed. I've uploaded d7.dig1, and it replaces all other patches.

I tried these scenarios:

On the calling system, I have a dahdi fxs analog phone at dahdi/51,
and a t1 dual-span card fills dahdi/1 thru dahdi/48. dahdi/1 thru
dahdi/24 crossover cable connected to a single span t1 card in the
other system.
on the calling system I can dial these numbers:

301: will perform Dial(Dahdi/10/125|30|TtWwHhKkXx)  which will
    ring an extension at dahdi/25 on the called system. I looked
    at the results of both answering the call, and not answering
    the call.

302: will perform Dial(Dahdi/10/180|30|TtWwHhKkXx). This will
    attempt to call dahdi/80 on the called system, which doesn't exist,
    although the extension is in the dialplan.

303: Will perform Dial(Dahdi/13/1800|30|TtWwHhKkXx). The 1800
    extension is not in the called systems dialplan.

304: Will perform Dial(Dahdi/13/13|20|TtWwHhKkXx). the 13 exten
    in the called system's dialplan exists, and calls Answer(), and ResetCDR()
    twice, and hits the end of the priorities.

305: Will perform Dial(Dahdi/14/14|20|TtWwHhKkXx). the 14 exten
    in the called system's dialplan exists, and calls ResetCDR()
    twice, and hits the end of the priorities. (no Answer() call).

306: Will perform Dial(Dahdi/14|20|TtWwHhKkXx) Since  no target exten
    is specified at all, the "s" exten is used on the called system.
    At least, this week it does. Previously, 14 would have been called.
    This was a bug that was fixed at the beginning of the week.

In all cases, the results look OK now. Chan_dahdi wasn't paying attention
to the results of some of the most common hangup causes, which would tend
to show "NO ANSWER" instead of "FAILED". I removed the disposition as a
criteria for publishing a CDR. I made the dahdi channel driver set the
dstchannel field to <none> for incoming calls, so all incoming are logged
now (even taking an analog phone offhook and setting it back on hook will
generate a CDR (Let me know if this is irritating, I might be able to
make another config option to get rid of it (or something)).

By forcing chan_dahdi to set "needcongestion", I can push the FAILED
disposition back to the calling system, so its CDR will report a FAILED
disposition also.

Try this patch out on your test system, and I'm hoping you should find it
very satisfactory!
By: Steve Murphy (murf) 2009-02-06 11:58:14.000-0600

I've uploaded d10.dig1, now the new and authoritative patch; I went thru all the permutations of unanswered=yes/no and callattempts=yes/no, and found some other problems, which I cleaned up. Looking even much better now. I still see a small prob with 302 and unanswered = no; will try to solve that too, if possible.
By: Steve Murphy (murf) 2009-02-06 12:14:56.000-0600

OK, I've solved the 302/unanswered=no problem; a fix to a macro in app_dial;
I've uploaded d11.dig1, which is now the authoritative patch for this bug. Test it and it only.
By: Leif Madsen (lmadsen) 2009-02-09 10:27:54.000-0600

I've removed all the old patches so it is a little more obvious as to which patch to test :)
By: Steve Murphy (murf) 2009-02-10 14:00:15.000-0600

Ok, I've uploaded the d14.dig1 patch after running all the tests, I noticed problems with blind xfers via the feature (##) on my phone, for when unanswered=yes, and the situation where A calls B, and B xfers A to C, the second CDR was missing, which I fixed. I also noticed on some calls, if more than one phone is ringed at once, that a CDR could be missing for at least one. I fixed this problem.

As it stands, there are extra CDR's issued for attended transfer cases; I will clean these up over the next few days. I want to guarantee that when I commit this patch, it will generate as few regressions as possible. After testing and cleaning the feature-attended transfer (*2 on my test systems), I will then test the dahdi and SIP channel-driven attended and blind xfer paths, and make sure they are clean also.
By: Igor Zamocky (dzajro) 2009-02-20 10:15:36.000-0600

Sorry for huge delay. I'm ready to test our traffic on svn-1.4, finally.
But first I have to pass through few childish problems, for example:

  [CC] res_musiconhold.c -> res_musiconhold.o
In file included from /usr/src/asterisk-1.4/include/asterisk/dahdi_compat.h:27,
                from res_musiconhold.c:76:
/usr/include/dahdi/user.h:736: error: syntax error before "__s32"
/usr/include/dahdi/user.h:743: error: field `params' has incomplete type
/usr/include/dahdi/user.h:939: error: syntax error before "__s32"
/usr/include/dahdi/user.h:940: error: syntax error before ':' token
make[1]: *** [res_musiconhold.o] Error 1
make[1]: Leaving directory `/usr/src/asterisk-1.4/res'
make: *** [res] Error 2

while compiling asterisk.

below are versions of dahdi/libri/asterisk:
wget http://downloads.digium.com/pub/telephony/dahdi-tools/releases/dahdi-tools-2.1.0.2.tar.gz
wget http://downloads.digium.com/pub/telephony/dahdi-linux/releases/dahdi-linux-2.1.0.4.tar.gz
svn checkout http://svn.digium.com/svn/asterisk/branches/1.4 asterisk-1.4
svn checkout http://svn.digium.com/svn/libpri/branches/1.4 libpri-1.4
wget http://downloads.digium.com/pub/asterisk/releases/asterisk-addons-1.4.7.tar.gz

what is the correct svn version of dahdi-linux/dahdi-tools?
By: Steve Murphy (murf) 2009-02-20 13:23:56.000-0600

I made an inquiry, and Qwell thinks that the latest svn of dahdi fixed that problem; So, do an "svn co http://svn.digium.com/svn/dahdi/linux-complete/trunk dahdi-linux-complete-trunk" should do the trick, I hope.
By: Igor Zamocky (dzajro) 2009-02-20 17:06:56.000-0600

No luck :(

I dit it, but result is the same:

  [CC] res_musiconhold.c -> res_musiconhold.o
In file included from /usr/src/asterisk-1.4/include/asterisk/dahdi_compat.h:27,
                from res_musiconhold.c:76:
/usr/include/dahdi/user.h:738: error: syntax error before "__s32"
/usr/include/dahdi/user.h:747: error: field `params' has incomplete type
/usr/include/dahdi/user.h:943: error: syntax error before "__s32"
/usr/include/dahdi/user.h:944: error: syntax error before ':' token
make[1]: *** [res_musiconhold.o] Error 1
make[1]: Leaving directory `/usr/src/asterisk-1.4/res'
make: *** [res] Error 2

[root@mediator asterisk-1.4]# ls -l /usr/include/dahdi/user.h
-rw-r--r--  1 root root 34358 Feb 21 00:01 /usr/include/dahdi/user.h

dahdi has been downloaded (from svn) and compiled few minutes ago as you can see. I'm UTC+1.
By: Steve Murphy (murf) 2009-02-23 10:37:18.000-0600

compiled... and installed, also, correct?

Then, in asterisk,  you most likely need to do a make distclean, ./configure (--enable-dev-mode if you want); make menuselect;  make; make install

I find that old files seem to get in the way in asterisk, when you have compile probs like this, it is often beneficial to clean it completely out and start over.
By: Steve Murphy (murf) 2009-02-24 16:26:45.000-0600

OOps! I see twilson checked in a change to 1.4 svn (r 178266) to res_musiconhold.c, that fixed a problem:

 "Change include order to make compile on Centos 5 with DAHDI

 "If BIT_TYPES_DEFINED gets defined before linux/types.h is included, the
__s32 type doesn't get defined

-- This looks very much like your problem. Do an svn update and try again!
By: Leif Madsen (lmadsen) 2009-03-04 19:12:58.000-0600

Pinging dzajro!  Any chance of getting a test with the latest 1.4 SVN along with the patch?
By: Matthew Nicholson (mnicholson) 2009-05-14 15:26:04

What is the current status of this bug?  This patch does not look directly related to the original issue.
By: John S. (johnakabean) 2009-05-16 19:47:54

This is a common thing I have ran into; when you upgrade, you must, before make install of asterisk:

rm --force --recursive /var/lib/asterisk/modules

and make && make install asterisk-addons again if applicable
.


By: Leif Madsen (lmadsen) 2009-05-21 10:59:08

I'm setting this to feedback until we can determine what the real issue is here, and what is going on with this.
By: Russell Bryant (russell) 2009-06-23 10:01:58

I am suspending this due to a lack of activity.  There have been a lot of fixes since this issue was originally reported.  If there are still any problems here, please open a new report.  Thanks!