I need help to analyze WebRTC packets

[celsoannes]

I did the packet capture of a call between two extensions that use WebRTC, but I can’t open them in Wireshark, nor can sngrep catch the INVITE even though I point to the key to be used:

sngrep -c --keyfile asterisk.key

I tried to use the asterisk.key file in Wireshark in Edit > Preferences > Protocols > TLS.
I put the key in (Pre)-Master-Secret log filename but I still can’t get the calls in Telephony > Voip Calls, I can only get the RTP packets.

Can someone explain to me how to do it?

[Chano]

I don’t believe using just the private key of the keypair, is working on recent versions of the SSL/TLS specs. There’s an option of dumping the actual encryption keys I’ve seen for some browsers, using an environment variable, if this is a feature of the SSL library, it should work for Asterisk, provided the same SSL/TLS library is used, if it’s a feature of the browser, you’re out of luck.

(The above assumes asterisk.key is the private key used for the certificate.)

I have, however, had some log by using the pcap feature of the pjsip module.

pjsip set logger pcap /path/to/pcap/file.pcap
pjsip set logger on

Should do the trick, that assumes, you just want the SIP traffic. If you want the RTP traffic decrypted, I’ve got no idea at how to do this. But unless you need to listen to the actual audio, you can still use the encrypted RTP packets for analysis.

[TheMark]

for the key to work you need to capture from when the phone send the first tls package
(when it registre and until the call)

best option is to capture via hep interface (decrypted)

Examples: Asterisk

Examples: sngrep

[TheMark]

Asterisk PJSIP + HEP

[celsoannes]

Thank you, this will be very helpful in understanding what is happening during the INVITEs and registrations.

[celsoannes]

Asterisk 20 already comes with the hep.conf file; I will have to study to understand how it works, but from what I gathered, I will need a HOMER server to interpret the created packets.

Thank you.

[InnovateAsterisk]

You are correct, yes, you can export sip messages directly to a homer server.

I have done this successfully, however… since you are posting this in WebRTC section, and since you seem interested in the sip messages (not the RTP), I would also like to point out that you can inspect the SIP messages on the CLI and at the client too.

This page shows you how to inspect SIP messages (in plain text) as they are sent to and from the server:

WebRTC SIP Trace Capture

Because of the nature of the configuration (web site connects directly to asterisk), there cannot be any devices in between altering the packets.

Also Asterisk has an option to do a “spot” check of the sip messages (in plain text) on the console. Simply issue the command at the CLI> pjsip set logger on. This will output the SIP messages to the CLI, allowing you a real-time view into what is being sent or received. There is also pcap a option like pjsip set logger pcap /tmp/packets.cap. More here: New PJSIP Logging Functionality ⋆ Asterisk

I only mention this as keeping a Homer Server can be a lot ot of PT, and mainly used “when something isn’t working” and when something isn’t you are often happy to be proactively looking at the CLI or something.

[celsoannes]

I appreciate you pointing out the possibility of doing this in the console. I was already aware of this option; however, it is impractical to perform on the client side, as there are many extensions and numerous simultaneous calls. It is impossible for me to understand, and if you have any tips on how to filter the logs in an organized way, I would appreciate it. The current format makes it difficult for me to distinguish between different calls and understand which call corresponds to which log entry.

I kind of need both, as I don’t know where the issue is located, INVITE or RTP.

I will try to explain the problem I am facing:

In WebRTC extensions, when making an outbound call to an external number and it is answered by an IVR, the WebRTC caller cannot hear the IVR options; it remains silent. Additionally, I’ve observed that RTP packets cease to be sent. However, this only occurs in IVRs where there is a delay of 4 seconds or more before the audio is played after the call is answered. In IVRs where the audio starts immediately upon answering, there are no issues.

On the same Asterisk server, extensions using PJSIP do not experience audio problems when calling this IVR with delayed audio playback.

Regarding the WebRTC scenario, I’ve noticed that the behavior changes based on DNS resolution. Let’s assume the domain is webrtc.site.com, with its public IP being 200.200.200.200 (this is not an actual IP, and I apologize if it belongs to someone here), and the internal IP is 10.1.1.100.

Instead of directing to the public IP (200.200.200.200), when the registration is made on webrtc.site.com, the DNS is sending it to 10.1.1.100. If an extension within the same network as the server, with IP 10.1.1.2 for example, registers directly on 10.1.1.100, when it is answered by an IVR with delayed audio playback, the call becomes silent for the caller. However, if any extension registers from a public IP, such as 200.200.200.200, there are no audio issues when answered by an IVR with delayed audio playback.

I don’t know if I was clear.

If you’ve had this experience or know how to resolve it, I appreciate it.
Thanks