Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Troubleshoot sending RTCP-XR to Homer via Kamailio #638

Open
tcreek opened this issue May 3, 2024 · 8 comments
Open

Troubleshoot sending RTCP-XR to Homer via Kamailio #638

tcreek opened this issue May 3, 2024 · 8 comments

Comments

@tcreek
Copy link

tcreek commented May 3, 2024

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:[email protected]:5060) to (sip:[email protected]: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
Copy link
Author

tcreek commented May 3, 2024

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
Copy link
Author

tcreek commented May 3, 2024

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.

@lmangani
Copy link
Member

lmangani commented May 4, 2024

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
Copy link
Author

tcreek commented May 6, 2024

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
Copy link
Member

lmangani commented May 6, 2024

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!

@tcreek
Copy link
Author

tcreek commented May 6, 2024

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?

@Dletta
Copy link
Collaborator

Dletta commented Sep 18, 2024

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)

@tcreek
Copy link
Author

tcreek commented Sep 19, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants