Troubleshoot sending RTCP-XR to Homer via Kamailio

[tcreek]

I recall in version 5, there was installations of Homer with Kamailio and OpenSIPS so I hope one can help me here.

I have setup Homer 7 (Docker image) and Kamailio installed on the same server.

I managed to setup Kamailio to send SIP PUBLISH messages to Homer on Port 9060.

It appears to be set up correctly. Here is the kamailio.cfg

https://pastebin.com/fpKjC7DN

Doing a test with a telephone, I can see via sngrep a PUBLISH message is being sent from the PBX, and Kamailio log is reporting :

INFO: <script>: Tracing PUBLISH from (sip:3003@192.168.1.73:5060) to (sip:Homer@192.168.1.24:5060)

From my understanding RTCP-XR data should be in the database "homer_data" and in the table "hep_proto_35_default" using Homer 7 Docker image. At this time, I am seeing nothing there. In the past I ran Negbie's hepify-xrcollector-test in which that table is filled with RTCP-XR data from the test program.

Is any means to check if it really is getting a proper XR-RTCP PUBLISH SIP message, and seeing the reason it is not making it into the database?

[tcreek]

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

I am attaching it here.

capture.zip

[tcreek]

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.

[lmangani]

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!

[tcreek]

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"?

[lmangani]

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!

[tcreek]

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 | 0_2198158549@192.168.1.105 | 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": "0_2198158549@192.168.1.105", "protocolFamily": 2} | {"node": "3333", "proto": "rtcpxr"} | PUBLISH sip:Homer@192.168.1.24:9064 SIP/2.0\r +
| | | | | Via: SIP/2.0/UDP 192.168.1.105:5060;branch=z9hG4bK1313213143\r +
| | | | | From: "3003" sip:3003@192.168.1.73:5060;tag=332807475\r +
| | | | | To: sip:Homer@192.168.1.24:9064\r +
| | | | | Call-ID: 0_1682359844@192.168.1.105\r +
| | | | | CSeq: 1 PUBLISH\r +
| | | | | Contact: sip:3003@192.168.1.105: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?