call sip search with capture id is not working

[hvspa]

hi, i am trying to do sip call search based on capture ID, however the result is empty, when the capture ID is not specified during the search, but after search you applying the filter based on capture id in search results window, the records are present:

i am running homer app on docker v 7.8.1 prod. any ideas what i am doing wrong during search?

Best, Art

[adubovikov]

I am not sure about your issue, because capture_id is an integer field and should contain only number and not string. How do you insert data to your homer node ?

[hvspa]

this is how i do it:

./heplify -hs heplify_server:9060 -hn sip_intercon -pr "5060-5200"

[adubovikov]

ok, please use integer

[hvspa]

do you mean use hi instead of hn?

-hi uint HEP node ID (default 2002) -hn string HEP node Name

[adubovikov]

yep

[hvspa]

still the same :( result empty when putting capture id criteria in the search:

[adubovikov]

maybe you will remove INVITE and just make search by captureID ?

[hvspa]

still the same: no rows to show

[adubovikov]

can you check in the debug that query you generate ?

On Fri, 7 Aug 2020 at 20:31, hvspa notifications@github.com wrote:

still the same: no rows to show

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sipcapture/homer-app/issues/378#issuecomment-670651589, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCN2JITIF5ACHECLTQJ7ULR7RB6TANCNFSM4PW2ZQQA .

[hvspa]

sure, if you can tell me how to check, i can do that...

[hvspa]

is this what you are looking for? or what/

{"config":{},"lokiSort":null,"param":{"limit":200,"location":{},"search":{"1_call":[{"hepid":1,"name":"protocol_header.captureId","type":"integer","value":"2200"}]},"timezone":{"name":"Local","value":-180},"transaction":{}},"timestamp":{"from":1596822725000,"to":1596826325000}}

[adubovikov]

No, i am asking for SQL query. This you can find in the debug log of homer-app

On Fri, 7 Aug 2020 at 20:53, hvspa notifications@github.com wrote:

is this what you are looking for? or what/

{"config":{},"lokiSort":null,"param":{"limit":200,"location":{},"search":{"1_call":[{"hepid":1,"name":"protocol_header.captureId","type":"integer","value":"2200"}]},"timezone":{"name":"Local","value":-180},"transaction":{}},"timestamp":{"from":1596822725000,"to":1596826325000}}

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sipcapture/homer-app/issues/378#issuecomment-670660432, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCN2JO2BLAE2HGKRYNKZS3R7RETDANCNFSM4PW2ZQQA .

[hvspa]

i logged into sipcapture/webapp container, but could not find any logs in var log location. can you tell me where exactly i can find mentioned log?

[hvspa]

ok, i found this issue in github: https://github.com/sipcapture/homer-app/pull/343

so do i add ""HOMER_LOGLEVEL=debug"" to following section and then bounce web-app container like "docker restart sipcapture/webapp"?

homer-webapp: container_name: homer-webapp image: sipcapture/webapp environment:

• "LOKI_HOST=loki"
• "PROM_HOST=prometheus"
• "DB_HOST=db"
• "DB_USER=root"
• "DB_PASS=homerSeven"

[hvspa]

hi Alexandr, hope you had great weekend. can you please tell me where i can find that sql query?

[adubovikov]

you have to run the homer-app with debug and after check the log file for SQL queries.

https://github.com/sipcapture/homer-app/blob/master/etc/webapp_config.json#L64-L65

[hvspa]

here you go:

{"level":"info","msg":"Claims","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"\u0026{admin true false { 1597142620 0 0 }}","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"Claims","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"\u0026{admin true false { 1597142620 0 0 }}","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"Claims","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"\u0026{admin true false { 1597142620 0 0 }}","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"Claims","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"\u0026{admin true false { 1597142620 0 0 }}","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"Claims","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"\u0026{admin true false { 1597142620 0 0 }}","time":"2020-08-10T14:45:57Z"} {"level":"info","module":"gorm","msg":"SELECT FROM \"mapping_schema\" WHERE (partid = $1)","time":"2020-08-10T14:45:57Z","type":"sql"} {"level":"info","module":"gorm","msg":"SELECT FROM \"alias\" WHERE (status = true)","time":"2020-08-10T14:45:57Z","type":"sql"} {"level":"info","module":"gorm","msg":"SELECT count() FROM \"mapping_schema\" WHERE (partid = $1)","time":"2020-08-10T14:45:57Z","type":"sql"} {"level":"info","module":"gorm","msg":"pq: invalid input syntax for integer: \"ast_intercon\"","time":"2020-08-10T14:45:57Z","type":"log"} {"level":"info","module":"gorm","msg":"SELECT FROM \"hep_proto_1_call\" WHERE (create_date between $1 AND $2 AND (protocol_header-\u003e\u003e'captureId')::int=2200) LIMIT 200","time":"2020-08-10T14:45:57Z","type":"sql"} {"level":"info","msg":"Claims","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"\u0026{admin true false { 1597142620 0 0 }}","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"Claims","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"\u0026{admin true false { 1597142620 0 0 }}","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"Claims","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"\u0026{admin true false { 1597142620 0 0 }}","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"Claims","time":"2020-08-10T14:45:57Z"} {"level":"info","msg":"\u0026{admin true false { 1597142620 0 0 }}","time":"2020-08-10T14:45:57Z"} {"level":"info","module":"gorm","msg":"SELECT FROM \"mapping_schema\" WHERE (partid = $1)","time":"2020-08-10T14:45:57Z","type":"sql"} {"level":"info","module":"gorm","msg":"SELECT count() FROM \"mapping_schema\" WHERE (partid = $1)","time":"2020-08-10T14:45:57Z","type":"sql"}

[hvspa]

@adubovikov did you have time to look into this one? also, i have another question, since it is possible to insert the capture id in db as string, why it is impossible to query the capture id as string as well? why the variable is integer?

[adubovikov]

you can insert it as string, but in this case you have to also change in the mapping this field from int to string and it will work. Setting->Mapping

[hvspa]

i changed the mapping as per your suggestion, but still pg is complaining:

{
    "id": "protocol_header.captureId",
    "name": "Capture ID",
    "type": "string",
    "index": "none",
    "form_type": "input",
    "position": 17,
    "skip": false,
    "hide": true
},

log:

{"level":"info","msg":"\u0026{admin true false { 1597312326 0 0 }}","time":"2020-08-12T20:57:22Z"} {"level":"info","module":"gorm","msg":"SELECT FROM \"alias\" WHERE (status = true)","time":"2020-08-12T20:57:22Z","type":"sql"} {"level":"info","module":"gorm","msg":"pq: invalid input syntax for integer: \"ast_intercon\"","time":"2020-08-12T20:57:22Z","type":"log"} {"level":"info","module":"gorm","msg":"SELECT FROM \"hep_proto_1_call\" WHERE (create_date between $1 AND $2 AND (protocol_header-\u003e\u003e'captureId')::int=0) LIMIT 200","time":"2020-08-12T20:57:22Z","type":"sql"} {"level":"info","msg":"Claims","time":"2020-08-12T20:57:22Z"} {"level":"info","msg":"\u0026{admin true false { 1597312326 0 0 }}","time":"2020-08-12T20:57:22Z"}

[adubovikov]

protocol_header-\u003e\u003e'captureId')::int

you have to recreate the search widget (fields)

[hvspa]

i have created a brand new call sip search widget. and still getting the same:

{"level":"info","msg":"\u0026{admin true false { 1597312326 0 0 }}","time":"2020-08-12T22:17:46Z"} {"level":"info","module":"gorm","msg":"SELECT FROM \"alias\" WHERE (status = true)","time":"2020-08-12T22:17:46Z","type":"sql"} {"level":"info","module":"gorm","msg":"pq: invalid input syntax for integer: \"ast_intercon\"","time":"2020-08-12T22:17:46Z","type":"log"} {"level":"info","module":"gorm","msg":"SELECT FROM \"hep_proto_1_call\" WHERE (create_date between $1 AND $2 AND (protocol_header-\u003e\u003e'captureId')::int=2200) LIMIT 200","time":"2020-08-12T22:17:46Z","type":"sql"}

[adubovikov]

I have change the maping and for me it works, in any case, i think it something wrong with your current schema because even for int it works without any problem. Try to recreate it

{"config":{},"param":{"transaction":{},"limit":200,"search":{"1_call":[{"name":"data_header.method","value":"INVITE","type":"string","hepid":1},{"name":"protocol_header.captureId","value":"aaaa","type":"**string**","hepid":1}]},"location":{},"timezone":{"value":-180,"name":"Local"}},"timestamp":{"from":1596751200000,"to":1597355999000},"lokiSort":null}`

[hvspa]

true, i did re-create it from previous backups and it is working now. thanks very much. so this one also will be pushed to main so we dont have to manually edit it after git clone for docker?

[adubovikov]

Yes. It should be ok in the latest release (currently git only)

[hvspa]

thanks Alexandr, i also noticed another issue, sometimes, the same callid is shown twice in the results. is that normal? or do i need to open another issue?

[adubovikov]

if you have it twice - you have received it twice. Sorry, but you have to debug it your self, as a opensource project we can provide bug fix only, but not the troubleshooting of your networ or how you capture the data.

[adubovikov]

if you have it twice - you have received it twice. Sorry, but you have to debug it your self, as an opensource project we can provide bug fix only, but not the troubleshooting of your networ or how you capture the data.

[hvspa]

if you have it twice - you have received it twice. Sorry, but you have to debug it your self, as a opensource project we can provide bug fix only, but not the troubleshooting of your networ or how you capture the data. right, this is happening, bcoz in fact there are two invites, one is responded by 401 not auth, and then only second invite is passing. since if you click both callid and you see exactly same info(invite, 401, second invite), I was thinking, maybe it would make more sense to combine them and show as one, because they are really one to one. sorry, initially i did not explain why i mentioned that :(

[adubovikov]

probably yes, your patches will be more than welcome :-)

[hvspa]

yeah, that is something not my level of knowledge. iam a user :)

[adubovikov]

understood :-) there are always couple ways to help the project or be a subscribed user.