WebRTC network tracing / flow?


We have an Asterisk (18.5.1) deployment that has traditionally used UDP for SIP / RTP communications with our customers SIP phones.

To assist them when there are problems, we typically run a network trace (tcpdump) on the Asterisk server and then use Wireshark to review the network flow / headers / etc.

We have now deployed a WebRTC client using secure WebSockets, as per:

We are now having problems performing the same network tracing capabilities.

The first issue I hit was decrypting the TLS 1.3 packets. Eventually I found this tool:
which enables us to collect the keys required by Wireshark.

My first two questions are:

  1. Does Asterisk have any native debugging option for collecting the keys, rather than having to preload the tool?
  2. With the keys collected, Wireshark decrypts the packets sent from Asterisk to the client, but from the client to Asterisk. Is this expected, and is there any way to decrypt the packets sent from the client and collected in the trace on the server (Note : we have no way to run a trace on the client)?

Although I can only decrypt half the conversation, I can effectively see the SIP traffic for a call being initiated from the client.

When the media starts to flow, the packets in Wireshark show as RTP not SRTP. Shouldn’t the “webrtc=yes” option on the endpoint definition enforce media encryption (which I assume is SRTP)?

Lastly, when using Asterisk with WebRTC, what defines the port to be used in the SDP header Media Descriptions (“m=”) on the INVITE?:

Please note that WebRTC is all new to me, and I’m not really a network specialist, so apologies if some of the terms I’ve used are incorrect.

Thanks in advance.

Asterisk has no way to export the keys, it does provide the ability to produce an unencrypted pcap[1] with the SIP traffic itself.

RTP, while being encrypted, still appears as RTP as only the payload itself is encrypted. The header is fine. SRTP is negotiated using DTLS-SRTP[2].

The m= and c= lines are not used for the media path. ICE is used to negotiate it[3].

WebRTC is a differently world.

[1] New PJSIP Logging Functionality ⋆ Asterisk
[2] rfc5764
[3] rfc5245

Many thanks for the very helpful response.

I will now spend some time familiarising myself with DTLS-SRTP and ICE.

Another issue that has arisen is that our customers need to know the inbound (Asterisk → WebRTC clients) firewall requirements. With a traditional SIP phone I know that the signalling and media address / port / protocol configured on the client needs to be opened.

Hopefully this will become clear after my familiarising of DTLS-SRTP and ICE.

A question regarding the RTP encryption when using WebRTC.

Shouldn’t I see the TLS handshake (eg. ClientHello / ServerHello) in the trace?

Also, in the SDP header I don’t see any “crypto” Media Attributes in the same way I do when using UDP, plus the RTP packets for WebRTC just show “Payload” whereas they show “Encrypted Payload” for UDP.

Thanks again.

The DTLS-SRTP negotiation would be done after ICE is done on the UDP ports chosen. Keys are not exchanged in SDP and do not appear there. The DTLS-SRTP negotiation produces the keying material.

Thanks again.

It’s going to take a bit of time for me to get my head around DTLS-SRTP.

Re ICE, I think I’ve got to grips with this (or as much as I need to). I can see the numerous address candidates in the SDP headers.

Hopefully my last question is, what do the agents use to determine the candidate port to use?

Does ICE have a fixed range of ports to use?
Does it use the IANA Registered / Dynamic port ranges?
Is it configured on the agent (in which case, where for Asterisk and clients such as Chrome / Firefox)?
Is it something else, if so what?

There is no fixed range of ports, it can be whatever. It’s up to them. In Asterisk it uses the configured RTP port range. I have no idea for the browser what or even if it is configurable.

For reference, I raised this with Google for Chrome and their response was as follows:

1- There are no specific ports used by the browser and therefore, there is not a list that can be allowlisted. Basically WebRTC is allowed to use any available local UDP port.
2- On the other hand, it seems like there is a local policy that can be used to force specific ones, more details in this URL Chrome Enterprise Policy List & Management | Documentation

To test on my Linux client I created a json file in /etc/opt/chrome/policies/managed/ that contained:

  "WebRtcUdpPortRange": "10000-20000"

and then checked in Chrome using:

The same would appear to apply in Microsoft Edge: