sipcapture / homer-api

HOMER 5: Back-End (API) DEPRICATED - use sipcapture/homer-app
http://sipcapture.org
27 stars 67 forks source link

Cannot read property 'id' of undefined. #69

Closed AlessioCasco closed 8 years ago

AlessioCasco commented 8 years ago

Hello.

I just noticed, that for a very small amount of calls, HOMER returns me blank results on the details page, even when looks like the DB has all the info on it (at least the data db):

This is what I see: homer2

reloading
resultCtrl.js:37 AUTH TRUE
resultCtrl.js:299 modal1 opened from url trans-1870421790
resultCtrl.js:299 modal1 opened from url trans-1870421790
dialogCtrl.js:296 Get call duration....
dialogCtrl.js:229 modal1 message opened from url message1070437127
dialogCtrl.js:229 modal1 message opened from url message1070437127
angular.js:12520 TypeError: Cannot read property 'id' of undefined
    at dialogCtrl.js:73
    at angular.js:14792
    at r.$eval (angular.js:16052)
    at r.$digest (angular.js:15870)
    at r.$apply (angular.js:16160)
    at g (angular.js:10589)
    at T (angular.js:10787)
    at XMLHttpRequest.w.onload (angular.js:10728)(anonymous function) @ angular.js:12520(anonymous function) @ angular.js:9292(anonymous function) @ angular.js:14800r.$eval @ angular.js:16052r.$digest @ angular.js:15870r.$apply @ angular.js:16160g @ angular.js:10589T @ angular.js:10787w.onload @ angular.js:10728
*************************** 1. row ***************************
              id: 5013880
            date: 2016-01-22 08:34:48
        micro_ts: 1453451687295576
          method: INVITE
    reply_reason: 
            ruri: sip:*****@*****
       ruri_user: ***********2
     ruri_domain: 
       from_user: ********6
     from_domain: 
        from_tag: xxxxxxxx
         to_user: **********2
       to_domain: 
          to_tag: 
        pid_user: 
    contact_user: yyyyyyyy
       auth_user: ***********6
          callid:*********@*************:5060
     callid_aleg: 
           via_1: SIP/2.0/UDP a.b.c.d:5060;branch=xxxxxxxxxxx
    via_1_branch: *********
            cseq: 103 INVITE
       diversion: 
          reason: 
    content_type: application/sdp
            auth: 
      user_agent: USER_AGENT_1
       source_ip: a.b.c.d
     source_port: 5060
  destination_ip: d.e.f.g
destination_port: 5060
      contact_ip: a.b.c.d
    contact_port: 5060
   originator_ip: 
 originator_port: 0
  correlation_id: *****@*******:5060
   custom_field1: 
   custom_field2: 
   custom_field3: 
           proto: 1
          family: 2
        rtp_stat: 
            type: 1
            node: node1:1012
             msg: INVITE [...]

Call was made on the 22nd, query on homer on the 24th, we keep the data for more than 2 days in the db

-----
$maxparts = $ARGV[3] // 7; #7 days How long keep the data in the DB
$newparts = 2; #new partitions for 2 days. Anyway, start this script daily!
@stepsvalues = (86400, 3600, 1800, 900);
$partstep = $ARGV[2] // 0; # 0 - Day, 1 - Hour, 2 - 30 Minutes, 3 - 15 Minutes 
------
#Make new table rotate. Homer5 Style. 10 days for calls, 7 days for registrations, 5 days for rest
$new_table 0 10,7,5

Any idea why is this happening?

Thanks Alessio

adubovikov commented 8 years ago

the time between your capture box and capture server are not synced. please use ntpdate for this.

AlessioCasco commented 8 years ago

They are bot synced with same date, and were synced back on the 22nd and 24th:

web server~# date Tue Jan 26 11:09:13 UTC 2016

DB machine~# date Tue Jan 26 11:09:13 UTC 2016

same on the capture machine

giavac commented 8 years ago

Hi Alessio, I'd suggest you take a trace of the DB queries performed by Homer, then try them manually on the DB. It's been useful in some cases to check the data consistency.

Messages are looked up not just with the ID but also with a reference to the timestamp, so there may be an issue in that area even though the host clocks are well sync'd.

If it's not a time issue, again those queries will show you what Homer is trying to look up and you can compare with the actual data stored.

Giacomo

On 26 January 2016 at 12:13, Alessio Casco notifications@github.com wrote:

They are bot synced with same date, and were synced back on the 22nd and 24th:

web server~# date Tue Jan 26 11:09:13 UTC 2016

DB machine~# date Tue Jan 26 11:09:13 UTC 2016

— Reply to this email directly or view it on GitHub https://github.com/sipcapture/homer-api/issues/69#issuecomment-174960083 .

AlessioCasco commented 8 years ago

Thanks guys!

Will have a look and let you know!

Alessio

adubovikov commented 8 years ago

any progress ?

AlessioCasco commented 8 years ago

Not yet sorry, will try to have a look into it tomorrow

Sorry for the late

AlessioCasco commented 8 years ago

Hello Guys,

I'm unable to reproduce this issue, so will close it for now, and update with the findings as soon as it happens again.

Thanks for your help, will keep you posted

Alessio