Hi Ian, Indeed, very strange..... Be sure you are using the latest 1.5 SVN branch version as in the last weeks there were several DB fixes....(some with the same behaviour / errors as in your case).
So, update from 1.5 SVN branch and if you still get the errors, please let me know. Regards, Bogdan Ian Blenke wrote: > My employer runs well over a dozen production opensips 1.5.1 servers > as a hub/spoke topology on Ubuntu Hardy based servers with mysql > 5.0.51a as a backend. > > On our busier (but not really high volume) hub servers, we are seeing > corrupted acc table rows. The dead giveaway of a corrupt acc table row > is a datestamp of '0000-00-00 00:00:00', though a query for "method != > 'INVITE' and method != 'BYE'" is just as effective. > > The oddest part is that it "comes and goes". Meaning, we will see days > without problems, and then a rash of invalid rows out of the blue. The > latest outbreak was this morning. > > There appear to be only a few variants of this problem: > > 1. When the method is the first 16 characters of the RURI, ie: > "sip:8669337...@1" > 2. When the method is "2.0 200 OK", the tailing part of the RURI > 3. When the method the trailing two characters of the method plus 13 > characters of the RURI, ie: "TE sip:866933732" > > Here is a sample row where the method looks to be part of the RURI: > > >> mysql> select * from acc where id = 873979 \G >> *************************** 1. row *************************** >> id: 873979 >> method: sip:8669337...@1 >> from_tag: SIP/2.0 >> Via: SIP/2.0/UDP 169.25 >> to_tag: 13.70;branch=z9hG4bKf913.fbf962a7.0 >> Via: SIP/ >> callid: .0/UDP 169.254.13.16:5060;branch=z9hG4bK1D0268F4 >> >> sip_code: rom >> sip_reason: 8...@reston.pstn.redacted.com>;tag >> time: 0000-00-00 00:00:00 >> cdr_id: NULL >> caller_id: 16 >> User-Agent: Cisc >> callee_id: Forwards: 69 >> Timest >> cseq: 0 >> contact_uri: NULL >> user_agent: 911de-8199a76f-59d0e...@169.254.12.16.16bye >> caller_domain: 0DE10DD0D- >> callee_domain: 12599 >> 1 row in set (0.01 sec) >> > > And here is an example where the method looks as if it's the end of > the request line: > > >> mysql> select * from acc where id = 873976 \G >> *************************** 1. row *************************** >> id: 873976 >> method: 2.0 200 OK >> From >> from_tag: y.lmno.tv>;tag=c7fb590f3e79b243;epid=04CEE460 >> Call-ID: 103102af >> to_tag: E >> Via: SIP/2.0/TCP 169.254.13.100:5060;received=169.254.12.100;e >> callid: >> pvrscom150;branch=z9hG4bKa64d965bd61826604ff352418c0432853138.95 >> sip_code: aac >> sip_reason: IP/2.0/TCP 127.0.0.1;branch=z9hG >> time: 0000-00-00 00:00:00 >> cdr_id: NULL >> caller_id: llow: MESSAGE, INVIT >> callee_id: FY, BYE >> Record-Rout >> cseq: 9223372036854775807 >> contact_uri: NULL >> user_agent: 69337...@169.254.13.20:5060 >> User-Agent: DyLogic PSE.M >> caller_domain: 4.13.100:5060;transport=tcp;lr> >> Contact: "8669337321" <s >> callee_domain: 943353961 >> 1 row in set (0.00 sec) >> > > And finally, the last case: > > >> mysql> select * from acc where id = 873912 \G >> *************************** 1. row *************************** >> id: 873912 >> method: TE sip:5507330670 >> from_tag: >> =on;ftag=DLb761cbe188;vsf=AAAAAGVkdB1ud3Z2AAB4HAkMAAgCAAMGLjIw;d >> to_tag: 9.254.13.72> >> Call-ID: dl2bd3eab...@dl-cz-3598 >> Fr >> callid: m: "2654831750" >> <sip:2654831...@169.254.13.20>;tag=DLb761cbe188; >> sip_code: Via >> sip_reason: 0/UDP 169.254.13.70;branch=z9hG4 >> time: 0000-00-00 00:00:00 >> cdr_id: NULL >> caller_id: hG4bK-13218ee492-DL >> callee_id: @169.254.13.20:5060 >> cseq: 0 >> contact_uri: NULL >> user_agent: p:reston.hub.sip.redacted.com;lr> >> >> v=0 >> o=8669337321 206167750 >> caller_domain: .MS 4.3.13 >> Content-Type: application/sdp >> Content-Length: 248 >> >> callee_domain: 1933320250 >> 1 row in set (0.00 sec) >> > > These were altered slightly to obscure the IP addresses, as well as > customer phone numbers, but are otherwise as they appear in that hub's > database. > > The problem does appear to be load based in that the busier the > server, the more of these seem to appear. > > We are getting a number of mysql errors in our logs that are also > unexplainable that roughly coincide with these events (repeated many > times): > > >> /usr/sbin/opensips[11190]: ERROR:db_mysql:db_mysql_do_prepared_query: >> mysql_stmt_bind_param() failed: Using unsupported buffer type: 808333624 >> (parameter: 3) >> ... >> /usr/sbin/opensips[11188]: ERROR:db_mysql:db_mysql_do_prepared_query: >> mysql_stmt_execute() failed(2): (1210) Incorrect arguments to >> mysql_stmt_execute >> ... >> /usr/sbin/opensips[11190]: >> ERROR:db_mysql:re_init_statement: failed while mysql_stmt_prepare: (1243) >> Unknown prepared statement handler (1) given to mysql_stmt_close >> > > A previous occurrence of this problem reported a different unsupported > buffer type: > > >> /usr/sbin/opensips[11209]: ERROR:db_mysql:db_mysql_do_prepared_query: >> mysql_stmt_bind_param() failed: Using unsupported buffer type: 51 >> (parameter: 8) >> /usr/sbin/opensips[11209]: ERROR:dialog:update_dialog_dbinfo: could not >> update >> database info >> > > My employer does not bill off of these servers, so this isn't critical > to our business, but it is still something we want to address for > obvious reasons. > > Thank you for your time, > > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
