RTP capture

[Paul D (systemcrash)]

Hi - where would changes be required in the code-base for Homer/heplify-server to be able to handle/ingest RTP?

We see a use-case where Homer can help trouble-shooting if it is able to handle RTP also.

I see that heplify-server needs to understand HEP/RTP packets and marshal those to the correct DB table (requires new tables for RTP type 4).

Once DB has the tables, and heplify-server sends them to the right table, that's it? I'd be happy to try and make some PRs which implement these bits, put them behind config flags so that they're not ON by default, and come up with the appropriate JS for use in Homer - might need a few pointers there.

PS I know your organizational intention is not to capture media, because of your privacy aims - there are better platforms/protos for doing media capture and retention like SIPrec. We don't want to archive media.Instead, this is how we intend to use Homer only 'occasionally', but Homer/heplify-server would need to be extended slightly to be able to handle this.

[Lorenzo Mangani]

Hi Paul,

I can only speak for myself and loosely as one of the original authors and it won't surprise you, this is an feature lacking due to a specific decision rather than shortage of will or time - While we appreciate the ideas and interest, there is no intention or interest in using HEP for mirroring RTP or for using our encapsulation protocol to a database and/or enable HOMER components and sniffers to be used/forked as an interception tool for RTP payloads (headers are not the issue)

For the occasional usage, HEPlify is already able to dump RTP and perhaps you could point your attention there perhaps making it more granular, plus there are other projects providing this, such as the voipmonitor sniffer or rtp:ending recording you can interface already with HOMER 7.x through HEPsub without any code changes - have you tried to consider this way perhaps? There's no need to reinvent the wheel in my humble opinion in an open-source ecosystem where integration and interoperability should take precedence.

For transparency, we do offer RTP analytics and Lawful-Interception (with the accent on the Lawful part) features in our commercial stack HEPIC (which keeps HOMER indipendently sponsored) so we know intimately what it involves and even there, we do not mirror RTP data across with or without HEP unless specific warranties are applicable but rather use a more sophisticated method to report about them all. In a world heading towards end-to-end encryption, this feature would add very little and increase risks a lot.

With this said the interest is always appreciated and the platform is Open and definitely capable of hosting any type of content, but hopefully at no disappointment we won't be able to support this specific effort much, if at all,

Thanks for your time contributions to the project! They've been tremendously helpful already!

Kind Regards,

Lorenzo Mangani

Managing Director and Core Dev

QXIP BV - Capture Engineering

Amsterdam, The Netherlands

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or legally privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of this original message. 

--
You received this message because you are subscribed to the Google Groups "Homer Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to homer-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/homer-dev/9b8a37fc-2c25-4726-b209-c359d663bdd9o%40googlegroups.com.

[Lorenzo Mangani]

Reading again - apologies for the typos, i am on a mobile mini keyboard with big fingers :)

Kind Regards,

Lorenzo Mangani

Managing Director and Core Dev

QXIP BV - Capture Engineering

Amsterdam, The Netherlands

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or legally privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of this original message. 

[Paul D]

No sweat!

OK - so were we to go about this, we'd be "on our own". This part is understood. Are you saying that with PRs, you would not accept any for RTP handling? Or that you would? This part was less clear. 

We might take a look into voipmonitor - this is able to ingest HEP input also? I don't see this...

To view this discussion on the web visit https://groups.google.com/d/msgid/homer-dev/CAKN%2BpHbnf26tZxVOtQ6O2%2B%2BgKW7Umm-W4a1gBAomLSZKqbQXzw%40mail.gmail.com.

[Paul D]

On 2020-06-17 19:15, Lorenzo Mangani wrote:
... there is no intention or interest [to] enable HOMER components and

sniffers to be used/forked as an interception tool for RTP payloads
(headers are not the issue)

====


We'll take that as a "probably not" but clarification welcome :)

[Lorenzo Mangani]

Of course PRs are always welcome! This is real Open-Source, we never turned down a contribution but we might have to discuss certain types of functionality if privacy or performance are to be heavily impacted.

Thanks!

Kind Regards,

Lorenzo Mangani

Managing Director and Core Dev

QXIP BV - Capture Engineering

Amsterdam, The Netherlands

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or legally privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of this original message. 

--
You received this message because you are subscribed to the Google Groups "Homer Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to homer-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/homer-dev/f338d080-26d9-47e9-0303-ebbed82beaea%40gmail.com.