[Home]

Summary:ASTERISK-12567: The field CDR(userfield) does not get written to the database
Reporter:Private Name (falves11)Labels:
Date Opened:2008-08-11 18:53:10Date Closed:2008-08-16 20:53:45
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:CDR/cdr_tds
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) config.log
Description:INSERT INTO cdr (accountcode, src, dst, dcontext, clid, channel, dstchannel, lastapp, lastdata, start, answer, [end], duration, billsec, disposition, amaflags, uniqueid) VALUES ('72.187.243.97', '2127532626', '19544447408', 'defaultproc', '2127532626', 'SIP/45936-007e4418', 'SIP/67.135.78.165-007fe3c8', 'Dial', 'SIP/9544447408@67.135.78.165,45,L(3600000)', '2008/08/11 19:57:31', null, '2008/08/11 19:57:45', 14, 0, 'NO ANSWER', 'DOCUMENTATION', 'S225-1218499051.0')

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

This what I get on SQL Server, but I set CDR(userfield) and I get it on cdr_odbc.
Executing [19544447408@defaultproc:4] Set("SIP/45936-008a58b8", "i=1") in new stack
   -- Executing [19544447408@defaultproc:5] ResetCDR("SIP/45936-008a58b8", "") in new stack
   -- Executing [19544447408@defaultproc:6] While("SIP/45936-008a58b8", "1") in new stack
   -- Executing [19544447408@defaultproc:7] Set("SIP/45936-008a58b8", "CDR(userfield)=a9b1954444_c0.021528d0.021528e0f19544447408x0g91h1954444__i0.005200j0") in new stack
   -- Executing [19544447408@defaultproc:8] Set("SIP/45936-008a58b8", "CDR(accountcode)=72.187.243.97") in new stack
   -- Executing [19544447408@defaultproc:9] Verbose("SIP/45936-008a58b8", "0,"Trying: SIP/9544447408@67.135.78.165"") in new stack
"Trying: SIP/9544447408@67.135.78.165"
   -- Executing [19544447408@defaultproc:10] Dial("SIP/45936-008a58b8", "SIP/9544447408@67.135.78.165,45,L(3600000)") in new stack
   -- Setting call duration limit to 3600 seconds.
 == Using SIP RTP CoS mark 5
 == Using UDPTL CoS mark 5
   -- Called 9544447408@67.135.78.165
   -- SIP/67.135.78.165-aeb2e818 is circuit-busy
 == Everyone is busy/congested at this time (1:0/1/0)
   -- Executing [19544447408@defaultproc:11] Verbose("SIP/45936-008a58b8", "0,"SIP/9544447408@67.135.78.165->CONGESTION From: 72.187.243.97"") in new stack
"SIP/9544447408@67.135.78.165->CONGESTION From: 72.187.243.97"
   -- Executing [19544447408@defaultproc:12] ResetCDR("SIP/45936-008a58b8", "w") in new stack
   -- Executing [19544447408@defaultproc:13] GotoIf("SIP/45936-008a58b8", "0?defaultproc,dropcall,1") in new stack
   -- Executing [19544447408@defaultproc:14] GotoIf("SIP/45936-008a58b8", "0?defaultproc,dropcall,1") in new stack
   -- Executing [19544447408@defaultproc:15] Set("SIP/45936-008a58b8", "i=2") in new stack
   -- Executing [19544447408@defaultproc:16] EndWhile("SIP/45936-008a58b8", "") in new stack
   -- Executing [19544447408@defaultproc:6] While("SIP/45936-008a58b8", "0") in new stack
   -- Executing [19544447408@defaultproc:17] Hangup("SIP/45936-008a58b8", "34") in new stack
Comments:By: Sean Bright (seanbright) 2008-08-11 18:56:54

You are using an outdated version of trunk.  Run 'svn update' rebuild and reinstall.
By: Steve Murphy (murf) 2008-08-11 19:01:36

No need. I looked at the source. It just plain doesn't store the userfield.

I'll add that as an option, so as not to mess up current possible users.
By: Sean Bright (seanbright) 2008-08-11 19:27:44

Spoke with murf on #asterisk-dev.  He wasn't aware that the code was updated in trunk.  He confirmed that the appropriate fix was in place.

falves11, please update to the latest version of trunk and try again and report back your results.
By: Private Name (falves11) 2008-08-11 20:08:53

Yes, it is there,thanks, but I cannot use the current Trunk for the reason below. if you look at the invites that the current Trunk produces, it has a malformed:
"From: "2127532626" <sip:2127532626@66.28.190.225:0>;tag=as500e9512", and 1/2 of my carriers reject the call. Please look at the section".225:0", the ":0" is wrong. I already filed a bug and it has not been assigned. I beg you to fix that bug so I can upgrade my machines, or please port this fix to 135068. The bug number is 13255. If that SIP bug is going to take a month to fix, please port this fix to 1.4 so I can have something that works. Also, cdr_tds needs a keep-alive mechanism. I came back after a few hours of inactivity, placed a call and it did not get written by cdr_tds. Maybe the connection had already been closed by SQL Server. CDR_TDS needs not to make any assumtions about the state of the connection. The same is applicable for cdr_odbc by the way. If the SIP bug is not going to be fixed quickly, please send me a patch just to remove that ":0" so I can continue doing business.


Retransmitting #3 (NAT) to 67.135.78.165:5060:
INVITE sip:9544447408@67.135.78.165 SIP/2.0
Via: SIP/2.0/UDP 66.28.190.225:5060;branch=z9hG4bK318a6848;rport
Max-Forwards: 70
From: "2127532626" <sip:2127532626@66.28.190.225:0>;tag=as500e9512
To: <sip:9544447408@67.135.78.165>
Contact: <sip:2127532626@66.28.190.225:0>
Call-ID: 2ceaef1d631f58a91760bf343166c52e@66.28.190.225
CSeq: 102 INVITE
User-Agent: CiscoSystemsSIP-GW-UserAgent
Date: Tue, 12 Aug 2008 01:08:41 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 312

v=0
o=root 34665767 34665767 IN IP4 66.28.190.225
s=Cisco-SIPGateway/IOS-12.x
c=IN IP4 66.28.190.225
t=0 0
m=audio 7056 RTP/AVP 18 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
By: Sean Bright (seanbright) 2008-08-12 04:56:16

Closing as the cdr_tds problem had already been resolved as of revision 137203.  (See issue 13281).

falves11, the other bug that you mention posting will remain open until someone familiar with the SIP channel driver gets a chance to look at it.
By: Private Name (falves11) 2008-08-12 13:02:33

I keep getting my calls rejected due to "bad contact" reasons, and there is no rush to fix this bug in Trunk. Therefore Trunk is uselees for now, and I cannot even pay Digium to fix this, because they don't fix Trunk bugs. Please give a patch for Trunk so I can apply to revision 135068, which is the last version bug-free. I would think that bug which renders SIP useless should have some urgency.
By: Sean Bright (seanbright) 2008-08-12 13:12:40

When you say patch you mean the cdr_tds userfield change?

http://svn.digium.com/view/asterisk/trunk/cdr/cdr_tds.c?view=patch&r1=137203&r2=137202&pathrev=137203
By: Digium Subversion (svnbot) 2008-08-12 19:01:52

Repository: asterisk
Revision: 137348

U   branches/1.4/cdr/cdr_tds.c

------------------------------------------------------------------------
r137348 | seanbright | 2008-08-12 19:01:51 -0500 (Tue, 12 Aug 2008) | 8 lines

Bring cdr_tds in line with the other CDR backends and have it try to store
CDR(userfield) if it is set.  The new behavior is to check for the userfield
column on module load, and if it exists, we will store CDR(userfield) when
CDRs are written.  A similar patch already went into trunk and 1.6.0.

(closes issue ASTERISK-12567)
Reported by: falves11

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

http://svn.digium.com/view/asterisk?view=rev&revision=137348
By: Sean Bright (seanbright) 2008-08-12 19:06:05

falves11, the cdr_tds fix has been backported to 1.4.  If you are able to rollback to 1.4, please try the latest 1.4 svn.
By: Private Name (falves11) 2008-08-16 17:22:44

In version 1.4, cdr_tds does not compile. In Trunk, it does compile. Maybe we should make this useful app compile in version 1.4. I copies the tds*.h files to /usr/include and /usr/local/include but it fails to compile. Also, I am requesting that cdr_tds be suported in Asterisk Business Edition "C"
By: Sean Bright (seanbright) 2008-08-16 20:02:14

Could you attach the output of the 'make' command that shows the compile failure?
By: Private Name (falves11) 2008-08-16 20:21:58

There is no failure. the comand make menuselect shows the cdr_tds option unavailable, while it shows cdr_odbc available. That is nonsense because cdr_odbc is based on freetds, in my case, so cdr_tds should be available. I copied the tds*.h to the usual places, run ./configure again, and nothing. It should work. I want to use cdr_tds because it does the same job than cdr_odbc with less overhead. In my personal opinion, the whole odbc stack in Asterisk has a huge memory leak, while using cdr_tds is bug free.
By: Sean Bright (seanbright) 2008-08-16 20:24:01

Please attach your config.log file after running ./configure
By: Sean Bright (seanbright) 2008-08-16 20:53:43

You did not properly install FreeTDS:

configure:28397: checking for tds_version in -ltds
configure:28432: gcc -o conftest -g -O2   conftest.c -ltds    >&5
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: cannot find -ltds
collect2: ld returned 1 exit status

You need to run 'make install' in the FreeTDS source directory, run 'ldconfig' as root, and then re-run ./configure within the asterisk source directory.

Either way, this is not a bug within asterisk.  For any other problem, please open a new bug report, as this one has gotten well off track.