support rtp/rtcp over tcp

[mmaatuq]

Please sign (check) the below before submitting the Pull Request:

• I have signed the ntop Contributor License Agreement at https://github.com/ntop/legal/blob/main/individual-contributor-licence-agreement.md
• I have read the contributing guide lines at https://github.com/ntop/nDPI/blob/dev/CONTRIBUTING.md
• I have updated the documentation (in doc/) to reflect the changes made (if applicable)

Link to the related issue:

Describe changes:

• support rtp/rtcp over tcp as per rfc4571.
• will be in draft for now so i can add test case and fix other tests.

[mmaatuq]

regarding

  /* NDPI_PROTOCOL_RTP */
   u_int32_t rtp_stage:2;
   u_int8_t rtp_seq_set[2];
   u_int16_t rtp_seq[2];

   /* NDPI_PROTOCOL_RTCP */ 
   u_int32_t rtcp_stage:2;

I'm not so sure if declaring them direct inside ndpi_flow struct is the right place to define them
I tried to make them part of the protos union,
but this caused some issues discovered during fuzz testing,
for example when we have rtp_stage = 1
but after this the protocol identified as tls,quic
and it doesn't have server_names but as rtp_stage is set
the below check passed

      if(flow->protos.tls_quic.server_names)
	ndpi_free(flow->protos.tls_quic.server_names);

which caused segfault.

also, i'm not completely sure if that was the reason for trying to free an object that wasn't allocated, the above explanation is my analysis.

[IvanNardi]

Overall it is quite good!
Just some minor issues below.
Furthermore:

• try to merge together the 2 RTP traces, if possible
• rebase

[IvanNardi]

flow->protos

You got it right: you can write to flow->protos union only after set a proper classification

[mmaatuq]

Overall it is quite good! Just some minor issues below. Furthermore:

* try to merge together the 2 RTP traces, if possible

* rebase

for merging 2 rtp traces, here there are 3 traces 2 of them have the same rtp flow and the third one has fragmented packets (that are not covered in this PR)

[IvanNardi]

Overall it is quite good! Just some minor issues below. Furthermore:

* try to merge together the 2 RTP traces, if possible

* rebase

for merging 2 rtp traces, here there are 3 traces 2 of them have the same rtp flow and the third one has fragmented packets (that are not covered in this PR)

@mmaatuq , sorry, I have not been clearer: I was asking to merge "rtp_tcp.pcapng" that you added to the PR and the existing "rtp.pcapng" already in the repository. This way we have only one RTP trace in the tests directory...

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[IvanNardi]

@mmaatuq, thanks for this work