Difficulty configuring HEPSUB for RTPEngine

[spacetourist]

I'm working on an implementation for call tracing based on two external platforms - opensips and RTPEngine, a common setup I believe. First my servers:

192.168.181.241 - Homer server (docker hom7-prom-all, last updated December 1st) 192.168.180.201 - RTPEngine server (also running HEPSUB via https://github.com/sipcapture/hepsub-rtpengine)

My ambition is to have all SIP collected and to implement a system which invokes RTP recording on a minority of calls, for those calls where RTP has been recorded I want to use HEPSUB subscription to trigger the retrieval from the RTP server where the capture occurs and to make this downloadable for the UI user allowing review of the SIP and collection of the PCAPs via the browser.

The OpenSIPs component is complete and functioning - I use external REST to decide when to record SIP and/or RTP for a dialog and this is successfully triggering the recording on the RTP server and pushing all SIP and logs into Homer - all working great. As a minor point I needed to use the homer5 syntax as shown in the params below, this isn't problematic for me but with v7 the data didn't appear.

 modparam("proto_hep", "hep_id", "[hep_dst] 192.168.181.241:9060; transport=udp; version=3")
 modparam("proto_hep", "homer5_on", 1)
 modparam("proto_hep", "hep_capture_id", 1)

I use a stock installation of Homer UI at this point and the SIP is easy to search and navigate - brilliant. Next I'll describe the pain point with the HEPSUB setup. Firewalls are open for all ports involved, I have performed traces that confirm no request is issued towards the hepsub agent from Homer.

The config for hepsub-rtpengine is shown below - I've struggled to decipher the purpose of all the values so want to be clear that these are best guesses only - in particular I'm not clear of the significance/use of gid/type:

{
  backend: "http://192.168.181.241:9080/api/v3/agent/subscribe",
  token: "LuLKnyOqCHdLioGpmBIvwuJWZmVCVOLgyINMitnRnFxXZQFSaOevpQUOuViaGGtcfaWOAdNbXXmRvaoL",
  rtpengine: {
    "path" : "/var/spool/rtpengine",
        "download" : true,
        "insecure" : true
  },
  service: {
    "uuid": "7cfa86a6-367e-4138-9941-6f4141b9110c",
    "host":"192.168.180.201",
    "port": 18088,
    "protocol": "http",
    "path": "/get",
    "type": "pcap;download",
    "ttl": 300,
    "node": "HR-P-RTP-1",
    "gid": 10
  },
  "debug": true
};

The HEPSUB agent exposes an API with path /get/:id which expects id to be either pcap OR download, not clear what logic there is in the Homer App whcih may or may not make this work however at this point I'm not seeing any requests so I'd like to tackle that first, just trying to be clear.

When starting the agent the token is accepted by Homer and a session is started, visible via the UI and in the database as shown below:

homer_config=# select * from agent_location_session;
 id  |                 guid                 | gid |      host       | port  | protocol | path |    node    |     type      |          create_date          |          expire_date          | active 
-----+--------------------------------------+-----+-----------------+-------+----------+------+------------+---------------+-------------------------------+-------------------------------+--------
 479 | aac3d1e0-7255-11ed-9767-19b080ed87f8 |  10 | 192.168.180.201 | 18088 | http     | /get | HR-P-RTP-1 | pcap;download | 2022-12-02 15:39:48.442856+00 | 2022-12-02 15:44:48.442857+00 |      1

With this registration active I am expecting to see requests being placed to the agent any time I click on a call on the UI which provide the call ID and check if the agent has the file, not sure if this is how it works? Also if that did work, I'm not clear on how to get the results to appear on the UI - I'd like a RTP PCAP download button to be added when its detected a recording - I believe I've seen similar implementations with additional UI objects whilst working on this.

I won't post my attempts at setting up mappings/correlations for this, these have all be stabs in the dark and haven't achieved anything that I can see so I'm hoping someone who is more familiar with the platform can request the specific/relevant parts.

I hope that all makes sense, I've run short on ideas and am really keen to get this moving again so will appreciate any input! Thanks for reading.

[github-actions[bot]]

Please star this repository to motivate the developers and to get higher priority! :star:

[spacetourist]

Just a few more database dumps in case useful.

Mappings:

homer_config=# select id, guid, profile, hepid, hep_alias, partid, version, retention, partition_step, create_index, create_table, schema_settings, create_date from mapping_schema;
 id |                 guid                 |   profile    | hepid | hep_alias | partid | version | retention | partition_step | create_index |               create_table                | schema_settings |          create_date          
----+--------------------------------------+--------------+-------+-----------+--------+---------+-----------+----------------+--------------+-------------------------------------------+-----------------+-------------------------------
  1 | fb101637-a59f-4a70-b063-4cedc3d183f8 | default      |     1 | SIP       |     10 |       1 |        10 |             10 | {}           | CREATE TABLE test(id integer, data text); | {}              | 2022-10-04 08:26:49.252435+00
  2 | 885361a0-6569-455e-92ad-69e0263a2074 | call         |     1 | SIP       |     10 |       1 |        10 |             10 | {}           | CREATE TABLE test(id integer, data text); | {}              | 2022-10-04 08:26:49.252436+00
  3 | 0b8bd0e1-022d-4c67-8eed-2e6bbc465997 | registration |     1 | SIP       |     10 |       1 |        10 |             10 | {}           | CREATE TABLE test(id integer, data text); | {}              | 2022-10-04 08:26:49.252436+00
  4 | b3447b82-e602-4599-9b80-a8935ecbf972 | default      |   100 | LOG       |     10 |       1 |        10 |             10 | {}           | CREATE TABLE test(id integer, data text); | {}              | 2022-10-04 08:26:49.252437+00
  5 | c3a06146-cb92-4044-9e05-58948076c326 | default      |  2000 | LOKI      |     10 |       1 |        10 |             10 | {}           | CREATE TABLE test(id integer, data text); | {}              | 2022-10-04 08:26:49.252438+00
  6 | a790e4d5-3b30-422a-b20a-77ff0c74e37c | call         |    10 | RTP       |     10 |       1 |         1 |             10 | {}           | CREATE TABLE                              | {}              | 2022-12-02 15:19:36.017954+00
(6 rows)

Hepsub mappings:

homer_config=# select * from hepsub_mapping_schema;
 id |                 guid                 |   profile    | hepid | hep_alias | version |                                                                                                                                            mapping                                                                                                                                            |          create_date          
----+--------------------------------------+--------------+-------+-----------+---------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------
  1 | 1111a345-e2d9-4fe1-8d94-1cc36da4781d | default      | 1     | SIP       | 1       | {"lookup_id": 0, "lookup_type": "pubsub", "lookup_field": "{\"data\":$source_field,\"fromts\":$fromts,\"tots\":$tots}", "lookup_range": [-300, 200], "source_fields": {"sid": "data_header.sid", "source_ip": "data_header.srcIp"}, "lookup_profile": "cdr"}                                  | 2022-10-04 08:26:49.252427+00
  2 | 09251a54-37a5-4a34-a000-3402f8adc1fa | call         | 1     | SIP       | 1       | {"lookup_id": 0, "lookup_type": "pubsub", "lookup_field": "{\"data\":$source_field,\"fromts\":$fromts,\"tots\":$tots}", "lookup_range": [-300, 200], "source_fields": {"sid": "data_header.sid", "source_ip": "data_header.srcIp"}, "lookup_profile": "cdr"}                                  | 2022-10-04 08:26:49.252428+00
  3 | d1d06860-9d89-4f8b-ab36-44a924432cae | registration | 1     | SIP       | 1       | {"lookup_id": 0, "lookup_type": "pubsub", "lookup_field": "{\"data\":$source_field,\"fromts\":$fromts,\"tots\":$tots}", "lookup_range": [-300, 200], "source_fields": {"sid": "data_header.sid", "source_ip": "data_header.srcIp"}, "lookup_profile": "cdr"}                                  | 2022-10-04 08:26:49.252428+00
  4 | 819ea405-224e-41df-9fdf-834d04a0bdbe | call         | 10    | RTP       | 1       | {"lookup_id": 0, "lookup_type": "pubsub", "lookup_field": "{\"data\":$source_field,\"fromts\":$fromts,\"tots\":$tots}", "lookup_range": [-300, 200], "source_fields": {"sid": "data_header.sid", "callid": "data_header.callid", "source_ip": "data_header.srcIp"}, "lookup_profile": "pcap"} | 2022-10-13 08:56:25.343463+00

[adubovikov]

So, homer5_on=1 is ok, this you need to send plain text data and not json to the homer collector. (heplify-server)

So, if you click on any callid you should see a Log tab with HepSub session. Do you have it ?

[lmangani]

When you select a Session in HOMER do you see any requests/responses to/from the HEPSUB worker? When there is a response, you should see the following in the Logs Tab

Make sure you configure rtpengine to actually perform the task and for the config to match its hepsub:

• https://github.com/sipcapture/hepsub-rtpengine/blob/main/docker/rtpengine/rtpengine-recording.conf

You can find a full example here: https://github.com/sipcapture/hepsub-rtpengine/tree/main/docker

[spacetourist]

Thanks both - I can confirm that RTPEngine is setup correctly and capturing the PCAPs. These are detected and cached by the hepsub agent on launch of that application.

I do not have the HEPSUB tab - Logs just shows Loki at this time.

I believe the main issue is that the UI/app is not firing any requests towards the subscribed agents at any time - that leads me to suspect that the subscription/mapping is incorrect and Homer doesn't know to attempt to load the data. Can anyone explain that mechanic for how Homer uses the subscription records to determine whether a lookup is required when a call is accessed?

[lmangani]

Ok then it must be missing mapping.

• Please confirm all the steps were considered for all involved elements
• Please confirm the HEPSub mapping has been created as per example

  {
  "lookup_id": 0,
  "lookup_type": "pubsub",
  "lookup_field": "{\"data\":$source_field,\"fromts\":$fromts,\"tots\":$tots}",
  "lookup_range": [
      -300,
      200
  ],
  "source_fields": {
      "sid": "data_header.sid",
      "callid": "data_header.callid",
      "source_ip": "data_header.srcIp"
  },
  "lookup_profile": "pcap"
  }

[lmangani]

@adubovikov is any other setting needed for the lookup profile to work?

[adubovikov]

@adubovikov is any other setting needed for the lookup profile to work?

checking

[spacetourist]

I'm going to look at that mapping in a moment - I wanted to provide an example of a manual request from the Homer server to the agent so dropping that before taking a look at the mappings:

[10:26] 🔥 root HR-P-HOMER-1 /opt/homer7-docker/heplify-server/hom7-prom-all # ccurl -d '{"data": {"sid":["0_701540296@10.0.0.10"]}}' -H "Content-Type: application/json" -X POST http://192.168.180.201:18088/get/pcap | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   338  100   295  100    43   9218   1343 --:--:-- --:--:-- --:--:-- 10903
{
  "0_701540296@10.0.0.10": {
    "pcap": "/var/spool/rtpengine/pcaps/0_701540296%4010.0.0.10-b0cdfcb14c9fbc04.pcap",
    "cid": "0_701540296@10.0.0.10",
    "t_sec": 1669909272,
    "u_sec": 16000,
    "__hep__": {
      "token": "d83ef260-7554-11ed-a3b0-6930d9968a5f",
      "type": "download",
      "uuid": "68f32490-74ae-11ed-a3b0-6930d9968a5f"
    }
  }
}

[adubovikov]

so, the only HEPSUB mapping should be corrected for your pcap in the lookup_profile. The rest have to be worked.

[lmangani]

@spacetourist please share your full mapping. Make sure you only have one to ease troubleshooting (replace default)

[spacetourist]

Here is the HEPSUB mapping - I believe it matches the example:

I'm not clear what items such as lookup_profile refer to, similarly I've seen references to protocol but can't see where I'd add RTP for example.

[adubovikov]

it's wrong - the profile should be for call, SIP, HEPID: 1 (you click on call :-) not on rtp)

[spacetourist]

For general mapping I've possibly made a mess by trying anything I could think of over the last few days - I'll post what seems most relevant but please understand that I've been a but lost during the process so it could be totally wrong.

I added a mapping for HEP Alias "RTP", HEP ID "10", Profile "call" (not clear how profiles fit into it). Correlation section is as follows:

[
    {
        "source_field": "data_header.callid",
        "lookup_id": 100,
        "lookup_profile": "default",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "data_header.callid",
        "lookup_id": 10,
        "lookup_profile": "default",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "data_header.callid",
        "lookup_id": 5,
        "lookup_profile": "default",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "protocol_header.correlation_id",
        "lookup_id": 1,
        "lookup_profile": "call",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "protocol_header.correlation_id",
        "lookup_id": 10,
        "lookup_profile": "call",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "data_header.callid",
        "lookup_id": 1,
        "lookup_profile": "call",
        "lookup_field": "data_header->>'callid'",
        "lookup_range": [
            -300,
            200
        ],
        "input_function_js": "var returnData=[]; for (var i = 0; i < data.length; i++) { returnData.push(data[i]+'_b2b-1'); }; returnData;"
    }
]

In addition I amended the correlation for HEP Alias "SIP", HEP ID "1", Profile "call" to include lookup_id 10 - hoping that'd link it to the agent subscription via the "gid" value (straws were clutched, possily a dumb thing to do):

[
    {
        "source_field": "data_header.callid",
        "lookup_id": 100,
        "lookup_profile": "default",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "data_header.callid",
        "lookup_id": 10,
        "lookup_profile": "default",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "data_header.callid",
        "lookup_id": 5,
        "lookup_profile": "default",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "protocol_header.correlation_id",
        "lookup_id": 1,
        "lookup_profile": "call",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "protocol_header.correlation_id",
        "lookup_id": 10,
        "lookup_profile": "call",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "data_header.callid",
        "lookup_id": 1,
        "lookup_profile": "call",
        "lookup_field": "data_header->>'callid'",
        "lookup_range": [
            -300,
            200
        ],
        "input_function_js": "var returnData=[]; for (var i = 0; i < data.length; i++) { returnData.push(data[i]+'_b2b-1'); }; returnData;"
    }
]

Is this the information you require?

[spacetourist]

it's wrong - the profile should be for call, SIP, HEPID: 1 (you click on call :-) not on rtp)

Thanks for this pointed - apologies for my misunderstanding, I'll try amending that by changing RTP>SIP HEP ID 10>1

[adubovikov]

it's wrong - the profile should be for call, SIP, HEPID: 1 (you click on call :-) not on rtp)

Thanks for this pointed - apologies for my misunderstanding, I'll try amending that by changing RTP>SIP HEP ID 10>1

more important - Profile=call, HEP ID: 1, Alias can be any

[spacetourist]

OK - I've made that change and haven't noticed any effect. I'll drop some screenshots to help show what I have.

The updated HEPSUB mapping:

The general mappings:

To clarify - is it when I click on a call ID in the search results that a lookup might be performed?

[adubovikov]

In HepSub mapping, for call please leave only ONE record for same HEPID and Prolfile (in you case: 1, call)

[lmangani]

To clarify - is it when I click on a call ID in the search results that a lookup might be performed?

That's correct. The trigger for the lookup is opening a session.

[adubovikov]

[spacetourist]

Thanks - I've deleted the mapping I created and am left with:

The correlation for the remaining mapping of call profile for HEPID 1:

[
    {
        "source_field": "data_header.callid",
        "lookup_id": 100,
        "lookup_profile": "default",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "data_header.callid",
        "lookup_id": 10,
        "lookup_profile": "default",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "data_header.callid",
        "lookup_id": 5,
        "lookup_profile": "default",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "protocol_header.correlation_id",
        "lookup_id": 1,
        "lookup_profile": "call",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "protocol_header.correlation_id",
        "lookup_id": 10,
        "lookup_profile": "call",
        "lookup_field": "sid",
        "lookup_range": [
            -300,
            200
        ]
    },
    {
        "source_field": "data_header.callid",
        "lookup_id": 1,
        "lookup_profile": "call",
        "lookup_field": "data_header->>'callid'",
        "lookup_range": [
            -300,
            200
        ],
        "input_function_js": "var returnData=[]; for (var i = 0; i < data.length; i++) { returnData.push(data[i]+'_b2b-1'); }; returnData;"
    }
]

I believe the only modification I made to this is to add in lookup_id 10 - I suspect this can be removed as I was using that to relate to the "gid" value provided by the agent during subscription (still not clear what this refers to)

[adubovikov]

Thanks - I've deleted the mapping I created and am left with:

Oh, please check that I wrote - HEPSUB MAPPING :-) I even posted a screenshot to avoid missunderstandig :-)

[spacetourist]

My apologies!

Mapping:

{
    "lookup_id": 0,
    "lookup_type": "pubsub",
    "lookup_field": "{\"data\":$source_field,\"fromts\":$fromts,\"tots\":$tots}",
    "lookup_range": [
        -300,
        200
    ],
    "source_fields": {
        "sid": "data_header.sid",
        "source_ip": "data_header.srcIp"
    },
    "lookup_profile": "cdr"
}

[adubovikov]

and change "lookup_profile": "cdr", to "lookup_profile": "pcap"

[spacetourist]

and change "lookup_profile": "cdr", to "lookup_profile": "pcap"

Thanks, I have made this change:

{
    "lookup_id": 0,
    "lookup_type": "pubsub",
    "lookup_field": "{\"data\":$source_field,\"fromts\":$fromts,\"tots\":$tots}",
    "lookup_range": [
        -300,
        200
    ],
    "source_fields": {
        "sid": "data_header.sid",
        "source_ip": "data_header.srcIp"
    },
    "lookup_profile": "pcap"
}

Here is the current subscription - can you confirm the logic used to pick up this record when it decides if the client might have some data for the session? Should type be "call" for example?

homer_config=# select * from agent_location_session;
 id  |                 guid                 | gid |      host       | port  | protocol | path |    node    |     type      |         create_date          |          expire_date          | active 
-----+--------------------------------------+-----+-----------------+-------+----------+------+------------+---------------+------------------------------+-------------------------------+--------
 976 | 94956790-7556-11ed-99d7-fb5dac09191e |  10 | 192.168.180.201 | 18088 | http     | /get | HR-P-RTP-1 | pcap;download | 2022-12-06 11:19:24.11774+00 | 2022-12-06 11:24:24.117741+00 |      1

[adubovikov]

No, all good, because it will do lookup for hepsub with type "pcap" - as your hepsub agent did:

type: pcap;download

now, check if you get any request on port 18088 (i.e. ngrep -W byline -d any -l -t port 18088)

[spacetourist]

OK super - here is the current sessions record, note i changed "gid" to 1:

 id  |                 guid                 | gid |      host       | port  | protocol | path |    node    |     type      |          create_date          |          expire_date          | active 
-----+--------------------------------------+-----+-----------------+-------+----------+------+------------+---------------+-------------------------------+-------------------------------+--------
 980 | 87441ac0-7559-11ed-9dcd-6147712559b3 |   1 | 192.168.180.201 | 18088 | http     | /get | HR-P-RTP-1 | pcap;download | 2022-12-06 11:31:30.056249+00 | 2022-12-06 11:36:30.056249+00 |      1

I can confirm that running that trace on the server is showing exactly zero requests out to 18088 on the RTP server (or anywhere else!)

# ngrep -W byline -d any -l -t port 18088
interface: any
filter: ( port 18088 ) and (ip || ip6)

(searched for a call on the UI, clicked an ID, selected a few tabs, nothing!)

[adubovikov]

can you check the api request to hepsub in F12 (Webconsole) ?

[spacetourist]

Ah, I wonder if this is part of the confusion - I had been expecting that the UI would drive the Homer server to perform those requests - do I gather that the browser client will be the one attempting to reach out to the HEPSUB agent/subscriber?

Either way I'm only seeing requests to the Homer server, here I've clicked around search and opened a call:

[adubovikov]

UI will send request to your hepsub clients once you opened the transaction window. So, as you see - it still send to "cdr" and not to "pcap". Can you reload your UI ?

[spacetourist]

Thanks for the advice, I feel like we are getting closer to the issue - I completed a reload and could not get it to send to pcap.

As an experiment I modified the hepsub client to declare type as "cdr" and can see that it retrieved the agent subscription and performed an API call to that as an IP discovery service:

{
  data: {
    sid: [ 'avpb8it9f1onr5rk8ns7' ],
    source_ip: [
      '192.168.183.108',
      '192.168.183.41',
      'pub.lic.ip.1',
      'pub.lic.ip.2'
    ]
  },
  fromts: 1669986139000,
  tots: 1669987239000
}

I've switched it back to register as type "pcap;download" and now wish to establish how to get the UI performing lookups against type pcap - is that controlled by the mapping changes we made earlier? To recap I have the following HEPSUB mapping for profile call:

{
    "lookup_id": 0,
    "lookup_type": "pubsub",
    "lookup_field": "{\"data\":$source_field,\"fromts\":$fromts,\"tots\":$tots}",
    "lookup_range": [
        -300,
        200
    ],
    "source_fields": {
        "sid": "data_header.sid",
        "source_ip": "data_header.srcIp"
    },
    "lookup_profile": "pcap"
}

[spacetourist]

The only mentions of "cdr" I can see are those in the HEPSUB mappings for the default items present after installation.

As a test I've modified all to use "pcap" and reloaded the browser, I continue to only see "cdr" lookups in the network logs.

Do i need to restart Homer itself on the server?

[adubovikov]

let me check the code :-)

[adubovikov]

can you show me the response of /api/v3/agent/subscribe ?

[adubovikov]

from webconsole

[spacetourist]

Here is a capture from the web console against the subscript method, formatted:

{
    "data": [{
        "active": 1,
        "create_date": "2022-12-06T12:23:16.678198Z",
        "expire_date": "2022-12-06T12:28:16.678198Z",
        "gid": 1,
        "host": "192.168.180.201",
        "node": "HR-P-RTP-1",
        "path": "/get",
        "port": 18088,
        "protocol": "http",
        "ttl": 0,
        "type": "pcap;download",
        "uuid": "2204bf00-7560-11ed-a530-456abec774f8"
    }],
    "message": "successfully created agent record"
}

[spacetourist]

As an aside I thought it could be sensible to reset my mapping data and retry. The UI provides a button for this which contacts /api/v3/mapping/protocol/reset however it receives HTTP 400 (Bad Request).

Looking into the code for homer-app I can see that this is firing method GetMappingAgainstGUID() which perform a direct lookup in mapping_schema with reset as the guid. This isn't correct, I'm wondering if that code was removed at some point?

Is there a clean way for me to reset the mapping data without losing all the SIP already captured?

[adubovikov]

[spacetourist]

This was the first thing I tried, see comment above.

When clicked it returns a 400 and the code itself GetMappingAgainstGUID() does not appear to contain any handling code for the when the guid arrives as reset

[spacetourist]

Code snippets:

acc.GET("/mapping/protocol/:guid", mpc.GetMappingAgainstGUID)

func (mpc *MappingController) GetMappingAgainstGUID(c echo.Context) error {

    guid := url.QueryEscape(c.Param("guid"))
    reply, err := mpc.MappingService.GetMappingAgainstGUID(guid)
    if err != nil {
        return httpresponse.CreateBadResponse(&c, http.StatusBadRequest, webmessages.MappingSchemaByUUIDFailed)
    }
    return httpresponse.CreateSuccessResponseWithJson(&c, http.StatusOK, []byte(reply))
}

func (mps *MappingService) GetMappingAgainstGUID(guid string) (string, error) {
    var mappingObject []*model.TableMappingSchema
    var count int
    if err := mps.Session.Debug().Table("mapping_schema").
        Where("guid = ?", guid).
        Find(&mappingObject).Count(&count).Error; err != nil {
        return "", err
    }
    if len(mappingObject) == 0 {
        return "", fmt.Errorf("data was not found")
    }
    data, _ := json.Marshal(mappingObject)
    response := fmt.Sprintf("{\"count\":%d,\"data\":%s}", count, string(data))
    return response, nil
}

[adubovikov]

[spacetourist]

These suffer the same issues I'm afraid...

I'll try to reset the data manually and/or attempt a full rebuild on a separate server - thanks to your help I have seen progress today, my test where the HEPSUB agent subscribed with type cdr confirmed that the systems are talking so I just need to understand why i'm not getting the type pcap requests and then hopefully it'll all be operational.

[adubovikov]

https://github.com/sipcapture/homer-app/commit/0f752004030608f1cee0bebf314d929880e29081

please check this commit

[adubovikov]

fixed - will push in prod soon

[adubovikov]

pushed WIP in homer-ui

[spacetourist]

Brilliant, thank you. I'll pursue my testing and let you know if I'm still baffled by this pcap lookup issue.

[spacetourist]

Morning @adubovikov - thanks for your work on the reset system, I've updated this morning and following the reset I am finally seeing requests to the pcap type for my HEPSUB subscription. Note that this is actually being requested with the joined type from my subscriber so I'm seeing requests to: /agent/type/pcap;download

This feels very close to working however I'm encountering what I believe to be a bug in that homer-app is URL encoding upon receipt and then performing the DB lookup with the encoded value and not finding a match - this error is shown in console:

{"data":"","message":"no agent subscription object found for type [pcap%3Bdownload]"}

I've produced a draft patch to correct this - I'd like feedback, if we agree that this needs fixing there are other examples in the same file which perform the encoding rather than decoding. I'll happily update them all as required:

https://github.com/sipcapture/homer-app/pull/502

I haven't been able to test immediately as I can't work out how to get my compiled binary into Docker to replace the one provided by the image - I'll work on that but any advice for testing would be appreciated.

[spacetourist]

I've expanded that PR to include patches for all the other methods processing received parameters in this manner.

[adubovikov]

Thank yoiu so much!

[adubovikov]

Probably it will require another patch for "download" button. (parse the "pcap" response and extract URL