Dtls state is always connecting

Maybe it’s not a mediasoup problem.But I can’t find out the cause of the mistake.

My program works well in the local environment.

When deployed to the public network, my program uses turn to forward, ice connects successfully, but dtls state is always connecting.

Some logs:

...
[transport: 14933706-d31d-446d-a921-5798f31ec6a8] iceSelectedTupleChange:  { localIp: '172.17.44.107',
  localPort: 10019,
  protocol: 'udp',
  remoteIp: '172.17.44.107',
  remotePort: 56515 }
[transport: 14933706-d31d-446d-a921-5798f31ec6a8] dtlsStateChange: connecting
13711111112 producer connect is ok!
[transport: 542ac6de-c0ff-4e65-9bf1-d5a8bbd52e40] iceSelectedTupleChange:  { localIp: '172.17.44.107',
  localPort: 10009,
  protocol: 'udp',
  remoteIp: '172.17.44.107',
  remotePort: 49369 }
[transport: 542ac6de-c0ff-4e65-9bf1-d5a8bbd52e40] dtlsStateChange: connecting
13711111112 [video] produce is ok...
13711111112 [audio] produce is ok...
13711111111 consumer connect is ok!
[transport: f26092f7-a70c-424b-afcc-32853d10324a] iceSelectedTupleChange:  { localIp: '172.17.44.107',
  localPort: 10018,
  protocol: 'udp',
  remoteIp: '172.17.44.107',
  remotePort: 52862 }
[transport: f26092f7-a70c-424b-afcc-32853d10324a] dtlsStateChange: connecting
13711111112 consumer connect is ok!
[transport: 51140a6c-6a88-438f-b6bd-55b855d793f6] iceSelectedTupleChange:  { localIp: '172.17.44.107',
  localPort: 10062,
  protocol: 'udp',
  remoteIp: '172.17.44.107',
  remotePort: 61863 }
[transport: 51140a6c-6a88-438f-b6bd-55b855d793f6] dtlsStateChange: connecting

I hope to get some help to check the mistakes.:pray:

Enable DTLS debugging in mediasoup, otherwise it’s impossible to help. Also specify whether you are using mediasoup-client or what in client side.

I’m use mediasoup-client.

Debug logs:

  mediasoup:worker[pid:17118] RTC::DtlsTransport::Run() | running [role:server] +1ms
  mediasoup:worker[pid:17118] RTC::DtlsTransport::OnSslInfo() | DTLS handshake start +0ms
  mediasoup:worker[pid:17118] RTC::DtlsTransport::OnSslInfo() | [role:server, action:'before SSL initialization'] +0ms
  mediasoup:worker[pid:17118] RTC::DtlsTransport::OnSslInfo() | role: server, waiting:'before SSL initialization'] +1ms

Program stop at waiting:'before SSL initialization'.

I don’t know much about dtls. Why does it stop at SSL?

There is no issue in such a “stop at SSL”. Please let’s not invent issues just by reading logs.

Does the issue happen in the online mediasoup-demo using the same browser (which you didn’t specify BTW)?

OK, maybe I’m too anxious.

I did not encounter the same problem , when using mediasoup-demo online with the same browser.

I found out through the packet capturing tool:

client -> server : Client hello
server -> client: Server hello, Change Cipher Spec, Encrypted Handshake Message // miss Certifcate
clinet -> server: Change Cipher Spec, Encrypted Handshake Message // miss Client key Exchange

And viewing the log information:

  mediasoup:worker[pid:3569] RTC::WebRtcTransport::MayRunDtlsTransport() | running DTLS transport in local role 'client' +2s
  mediasoup:worker[pid:3569] RTC::WebRtcTransport::OnDtlsTransportConnecting() | DTLS connecting +0ms
[transport: 2b3803b6-e4b4-4fe1-a190-dc9462b7275c] dtlsStateChange: connecting
  mediasoup:worker[pid:3569] RTC::DtlsTransport::Run() | running [role:client] +1ms
  mediasoup:worker[pid:3569] RTC::DtlsTransport::OnSslInfo() | DTLS handshake start +0ms
  mediasoup:worker[pid:3569] RTC::DtlsTransport::OnSslInfo() | [role:client, action:'before SSL initialization'] +0ms
  mediasoup:worker[pid:3569] RTC::DtlsTransport::OnSslInfo() | [role:client, action:'SSLv3/TLS write client hello'] +0ms
  mediasoup:worker[pid:3569] RTC::DtlsTransport::OnSslInfo() | role: client, waiting:'SSLv3/TLS write client hello'] +0ms

I don’t quite understand what caused this, I need some help.

By the way: the nginx proxy I use, the certificate is configured on nginx, and the local server accesses http://127.0.0.1.

This is not about nginx or any other HTTP/WebSocket stuff, but about WebRTC DTLS connection between the client and mediasoup.

Those traces are ok even if they say “miss cert”. You see the same by capturing traces with the mediasoup demo, right?

Yes, Such is the case.

I seem to find out where the problem is. The localip and remoteip I get are server addresses, not remote IP addresses.

{ 
  localIp: '172.17.44.107',
  localPort: 10062,
  protocol: 'udp',
  remoteIp: '172.17.44.107',
  remotePort: 61863 
}

What’s the reason for this? Because this project runs locally and really gets remote IP.

No idea about your server network stuff, but just in case: https://mediasoup.org/faq/#running-mediasoup-in-hosts-with-private-ip

Thank you very much. The problem is solved perfectly!

I saw the introduction at that time, but I didn’t pay attention to it.

But I’m curious, because I still view the logs as local IP. How does createWebrtcTransport work?

Which logs? which local IP? Please be specific.

BTW open the online demo, click on the stats icon and check the iceSelectedTuple in the “Send Transport Remote Stats” section. Paste it here.

The online demo logs:

bytesReceived 12243421
bytesSent 51069
dtlsState "connected"
iceRole "controlled"
iceSelectedTuple
{
  "localIp": "62.210.59.78",
  "localPort": 51228,
  "protocol": "udp",
  "remoteIp": "210.12.6.230",
  "remotePort": 51667
}
iceState "completed"
maxIncomingBitrate 3500000
probationBytesSent 0
probationSendBitrate 0
recvBitrate 3792
rtpBytesReceived 11910836
rtpBytesSent 0
rtpRecvBitrate 3302
rtpSendBitrate 0
rtxBytesReceived 262559
rtxBytesSent 0
rtxRecvBitrate 0

rtxSendBitrate 0
sctpState "connected"
sendBitrate 0
timestamp 672313280
transportId "34c8e4e6-6664-41db-9fe8-578561e90e29"
type "webrtc-transport"

My online program log like this(the local ip same with remote ip):

iceSelectedTuple
{ 
  localIp: '172.17.44.107',
  localPort: 10062,
  protocol: 'udp',
  remoteIp: '172.17.44.107',
  remotePort: 61863 
}

Well, check your network topology. It seems that your when a packet arrives to your server, the origin IP is the one of the server. No idea, but a not a bug in mediasoup.