homer icon indicating copy to clipboard operation
homer copied to clipboard

Published 20 hours ago • verified publisher icon sipcapture

Troubleshoot sending RTCP-XR to Homer via Kamailio

Open tcreek opened this issue 9 months ago • 8 comments

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:

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 avatar May 03 '24 02:05 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 avatar May 03 '24 16:05 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.

image

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.

tcreek avatar May 03 '24 17:05 tcreek

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!

lmangani avatar May 04 '24 07:05 lmangani

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

tcreek avatar May 06 '24 00:05 tcreek

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 35 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!

lmangani avatar May 06 '24 08:05 lmangani

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:

image

image

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

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

tcreek avatar May 06 '24 15:05 tcreek

Per instructions here: https://github.com/sipcapture/homer/wiki/Example:-RTCPXR

You need to specify the address of homer via the -hs option inside the xr-collector command to send the HEP where it needs to go. (Unless of course the default is the same as where you would send it)

Dletta avatar Sep 18 '24 18:09 Dletta

Per instructions here: https://github.com/sipcapture/homer/wiki/Example:-RTCPXR

You need to specify the address of homer via the -hs option inside the xr-collector command to send the HEP where it needs to go. (Unless of course the default is the same as where you would send it)

Thanks for taking the time to respond, but I have been through all of that. As I reported before, I can see the RTCP-XR data in the database, but nothing is showing up in Homer. I even tried Homer 5 like the Dangerous Demo video, but still nothing

tcreek avatar Sep 19 '24 18:09 tcreek