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

Capturing SIPS + RTP/SAVP with asterisk #439

Open
Yannik opened this issue Jun 24, 2023 · 3 comments
Open

Capturing SIPS + RTP/SAVP with asterisk #439

Yannik opened this issue Jun 24, 2023 · 3 comments

Comments

@Yannik
Copy link

Yannik commented Jun 24, 2023

Hi,

thanks for this great project!

To debug an issue, I would like to capture both SIPS & RTP/SAVP traffic.
Note: both are encrypted, which is why I am using HEP w/sngrep instead of tcpdump in the first place :-)

I have configured asterisk to send HEP traffic like this:

[general]
enabled = yes
capture_address = 127.0.0.1:6000
capture_id = 1234
uuid_type = call-id

I'm calling sngrep like this: sngrep--eep-listen udp:127.0.0.1:6000 --rtp.

SIP traffic is captured just fine, but for some reason, RTP is not. By tcpdumping the port 6000 traffic I was able to see that asterisk is not sending the rtp traffic along. According to the HEP3 spec, that should be possible (capture protocol type 0x04). However, I could not find any way to enable it.

I was able to capture RTP by adding -d any to the sngrep call, but now capturing to a pcap ( -O trace.pcap) is broken. The file is just not getting creating. Trying to save from the GUI results in an error message.

Is there some general issue with capturing RTP via HEP, or is this just an asterisk problem?

How would you recommend I proceed to capture encrypted SIP&RTP to pcap? Is there any solution for this issue?

@Yannik
Copy link
Author

Yannik commented Jun 24, 2023

I was also able to capture SIP+RTP using sngrep --device enp1s0 --keyfile <my-tls-key>, but again this results in Saving is not possible when multiple input sources are specified. when trying to save to pcap. (Which doesn't really make sense to me, as I am only specifying one single device!)

Actually, this was still using HEP due to .sngreprc. Unfortunately, sngrep --device enp1s0 --keyfile <my-tls-key> does not work, since the server is using TLS 1.3 which mandates PFS.

@Kaian
Copy link
Member

Kaian commented Jun 27, 2023

HI @Yannik !!

Is there some general issue with capturing RTP via HEP, or is this just an asterisk problem?

Nope, this is a common problem in sngrep using HEP. You can save HEP and you can save network traffic, but mixing them in the same PCAP is not supported.

The reason behind this limitation is that sngrep always tries to save each pcap exactly how it was captured, including any fragmentation or segmation and datalink layer data (Loopback device, Ethernet 100, ...). This is easy while saving packets from a single capture device, because libpcap input handle can be used to generate output file.

HEP packets are received in a socket, so this datalink info doesn't exists. We create a fake Ethernet 100Mb datalink layer and build each header manually, converting each received data into a Ethernet>IP>UDP packet to store it in a ethernet datalink pcap file.

In order to support saving from network and HEP at the same time, sngrep must use the network capture handle to create the output pcap and convert each HEP packet to the datalink used in that file by creating the appropiate fake datalink layer data (like it does right now for Ethernet).

Regards!

@Yannik
Copy link
Author

Yannik commented Jun 27, 2023

I see. Would love to see support for this!

Thanks for your reply @Kaian !

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

No branches or pull requests

2 participants