Troubleshoot sending RTCP-XR to Homer via Kamailio about homer HOT 6 OPEN

I did a pcap and see Kamailio is sending the PUBLISH message to Homer on port 9060.

I am attaching it here.

capture.zip

from homer.

After consideration, I think the issue is with Homer and/or Heplify.

I recall being told SIP messages need to be encapsulated into HEP to be Read by Homer.

From using sngrep, I now see the Asterisk is sending SIP PUBLISH messages encapsulated into HEP because I have HEP enabled on Asterisk.

What I have tried:

1. SIP Phone with RTCP=XR (192.168.1.105) <->Asterisk w/HEP (192.168.174 ) <-> Homer (192.168.1.24:9060)

2. SIP Phone with RTCP=XR (192.168.1.105 [indicating on phone to send packets to 192.168.1.24:5060) <->Asterisk w/HEP (192.168.174 ) <-> Homer(192.168.1.24:9060)/Kamailio Homer (192.168.1.24:9060)

So what is going on? Why is RTXP-XR not getting into Homer?

I am thinking this is a bug.

from homer.

Thanks for opening an issue to discuss this.

I recall being told SIP messages need to be encapsulated into HEP to be Read by Homer.

I think there's quite a bit of confusion here. HEP is our encapsulation format and its used by our integrtations. RTCP-XR are out-of-band messages, not part of the SIP session. Sending them to HOMER as HEP will only have them ingested, and not interpreted. HOMER is not a collector of RTCP messages.

In the past I ran Negbie's hepify-xrcollector-test in which that table is filled with RTCP-XR data from the test program.

That's right. You can use the heplify-xrcollector to extract the XR values into a native format. Have you tried doing so?

TODO

• Update Documentation with an actually working recipe!

from homer.

RTCP-XR may not be SIP, but I can see they are sent as PUBLISH messages within SIP. So this is really confusing.

I recall seeing this proclaiming Homer can do it, but there really was no explanation how it was done, and this presentation was done before HEP even existed.

https://youtu.be/N76odN3z9iU?si=Of0jxfipBSOQ5Gcz.

That's right. You can use the heplify-xrcollector to extract the XR values into a native format. Have you tried doing so?

Yes, I have, but I saw no RTCP-XR being displayed in Homer

I can do another test and present the results here.

However, what do you mean by "extract the XR values into a native format"?

from homer.

Let's go step by step to get this working

RTCP-XR may not be SIP, but I can see they are sent as PUBLISH messages within SIP. So this is really confusing.

Right. SIP PUBLISH/NOTIFY out-of-band messages are used as "transport" to deliver the RTCP statistics from the client inside the message body. Unlike other SIP messages, those are usually handled "destructively" by extracting the values and converting them to a HEP TYPE 5 media report correlated to the originating session(s) and discarding the vector message(s).

As you know - HOMER is NOT a SIP server and it cannot receive SIP messages directly and provide a response to a public client - this is why we prefer the gateway approach as a parallel service (which can be done in many ways, including xrcollector or by using Kamailio/OpenSIPS to form the media report) into a HEP TYPE 5 (RTCP) report which can be received, stored and used by our stack. This allows scaling the approach and controlling resources without exposing HEP services, etc.

I can do another test and present the results here.

Yes please! Let's see where this fails - if its our fault a fix will be in order and if the instructions are inaccurate we'll fix them up.

Thanks!

from homer.

Here are my current test results based on Asterisk still sending to Kamailio, with Kamailio still sending to Homer, and the telephone sending to the heplify-xrcollector.

Asterisk: 192.168.1.74
Homer: 192.168.1.24:9060
heplify-xrcollector: 192.168.1.24:9064
Kamailio: 192.168.1.24:5060
Telephone: 192.168.1.105

Results from heplify-xrcollector

./heplify-xrcollector -xs :9064
2024/05/06 10:28:36 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:28:36 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:28:37 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:28:37 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:28:38 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:28:38 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:28:40 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:28:40 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:28:44 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:28:44 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:28:48 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:28:48 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:28:52 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:28:52 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:28:56 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:28:56 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:29:00 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:29:00 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:29:04 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:29:04 Sent back OK with 335 bytes to 192.168.1.105:5060
2024/05/06 10:29:08 Received packet with 1727 bytes from 192.168.1.105:5060
2024/05/06 10:29:08 Sent back OK with 335 bytes to 192.168.1.105:5060

Looking inside table hep_proto_35_default:

homer_data=# select * from hep_proto_35_default;
id | sid | create_date | protocol_header | data_header | raw
----+----------------------------+-------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------+-----------------------------------------------------------------------------------------------------------------------
1 | [email protected] | 2024-05-06 14:37:58.303236+00 | {"dstIp": "2.2.2.2", "srcIp": "1.1.1.1", "dstPort": 2222, "srcPort": 1111, "protocol": 17, "captureId": "3333", "payloadType": 35, "timeSeconds": 1715006278, "timeUseconds": 303236, "correlation_id": "[email protected]", "protocolFamily": 2} | {"node": "3333", "proto": "rtcpxr"} | PUBLISH sip:[email protected]:9064 SIP/2.0\r +
| | | | | Via: SIP/2.0/UDP 192.168.1.105:5060;branch=z9hG4bK1313213143\r +
| | | | | From: "3003" sip:[email protected]:5060;tag=332807475\r +
| | | | | To: sip:[email protected]:9064\r +
| | | | | Call-ID: [email protected]\r +
| | | | | CSeq: 1 PUBLISH\r +
| | | | | Contact: sip:[email protected]:5060\r +
| | | | | Content-Type: application/vq-rtcpxr\r +
| | | | | Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE\r+
| | | | | Max-Forwards: 70\r +
| | | --More--

Looking at Homer:

So, where is the RCTP-XR data supposed to be shown?

P.S. "and if the instructions are inaccurate..." What instructions?

from homer.