DTLS Server Hello sent to wrong candidate

[Enrico Marocco]

Hi all,

I've just bumped into another subtle case that causes interop failures (and that will be a nightmare to debug).

TL;DR: the DTLS client (not Chrome) sends the Client Hello from the (relay) candidates it believes have been selected. Chrome, rather than sending Server Hellos back to the candidates the Client Hellos came from, picks them nondeterministically (not allowing the other party to free TURN resources). Worse than all, it sometimes picks the wrong ones.

Long story below.

Chrome's the offerer, another multihomed (wanna-be) WebRTC endpoint the answerer. Only way for the two to talk is through the answerer's TURN server. Offer skipped, here's the answer:

v=0

o=- 1401371863390 2 IN IP4 127.0.0.1

s=-

t=0 0

m=audio 1 RTP\/SAVPF 0 8 126

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

a=ice-ufrag:1upp7

a=ice-pwd:3av6sojnepgk1tirp4ggbn9es9

a=sendrecv

a=fingerprint:sha-256 6D:84:A5:89:3B:95:65:56:AD:2E:B4:AC:E0:CC:8A:A2:1D:0D:67:61:2A:D8:08:49:96:B4:F7:34:04:06:C1:67

a=setup:active

a=mid:audio

a=rtpmap:0 PCMU\/8000\/1

a=rtpmap:8 PCMA\/8000\/1

a=rtpmap:126 telephone-event\/8000\/1

a=candidate:1 1 udp 2130706431 172.16.82.34 10740 typ host

a=candidate:2 1 udp 2130706431 192.168.1.3 10740 typ host

a=candidate:3 1 udp 2113932031 163.162.173.15 10740 typ host

a=candidate:5 1 udp 1677724415 87.25.43.201 10740 typ srflx raddr 192.168.1.3 rport 10740

a=candidate:6 1 udp 2815 163.162.173.95 63814 typ relay raddr 163.162.173.15 rport 10740

a=candidate:6 1 udp 2815 163.162.173.95 54844 typ relay raddr 87.25.43.201 rport 10740

a=candidate:1 2 udp 2130706430 172.16.82.34 10741 typ host

a=candidate:2 2 udp 2130706430 192.168.1.3 10741 typ host

a=candidate:3 2 udp 2113932030 163.162.173.15 10741 typ host

a=candidate:5 2 udp 1677724414 87.25.43.201 10741 typ srflx raddr 192.168.1.3 rport 10741

a=candidate:6 2 udp 2814 163.162.173.95 56206 typ relay raddr 163.162.173.15 rport 10741

a=candidate:6 2 udp 2814 163.162.173.95 62100 typ relay raddr 87.25.43.201 rport 10741

m=video 1 RTP\/SAVPF 100

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

a=ice-ufrag:1upp7

a=ice-pwd:3av6sojnepgk1tirp4ggbn9es9

a=sendrecv

a=fingerprint:sha-256 6D:84:A5:89:3B:95:65:56:AD:2E:B4:AC:E0:CC:8A:A2:1D:0D:67:61:2A:D8:08:49:96:B4:F7:34:04:06:C1:67

a=setup:active

a=mid:video

a=rtpmap:100 VP8\/90000

a=rtcp-fb:100 ccm fir

a=rtcp-fb:100 goog-remb

a=rtcp-fb:100 nack

a=candidate:1 1 udp 2130706431 172.16.82.34 10742 typ host

a=candidate:2 1 udp 2130706431 192.168.1.3 10742 typ host

a=candidate:3 1 udp 2113932031 163.162.173.15 10742 typ host

a=candidate:5 1 udp 1677724415 87.25.43.201 10742 typ srflx raddr 192.168.1.3 rport 10742

a=candidate:6 1 udp 2815 163.162.173.95 57094 typ relay raddr 163.162.173.15 rport 10742

a=candidate:6 1 udp 2815 163.162.173.95 60876 typ relay raddr 87.25.43.201 rport 10742

a=candidate:1 2 udp 2130706430 172.16.82.34 10743 typ host

a=candidate:2 2 udp 2130706430 192.168.1.3 10743 typ host

a=candidate:3 2 udp 2113932030 163.162.173.15 10743 typ host

a=candidate:5 2 udp 1677724414 87.25.43.201 10743 typ srflx raddr 192.168.1.3 rport 10743

a=candidate:6 2 udp 2814 163.162.173.95 59854 typ relay raddr 163.162.173.15 rport 10743

a=candidate:6 2 udp 2814 163.162.173.95 52324 typ relay raddr 87.25.43.201 rport 10743

After ICE completes, the answerer, that elected itself for the DTLS client role, sends Client Hello messages from the following relay's ports:

• 59854 (VIDEO RTCP)
• 57094 (VIDEO RTP)
• 56206 (AUDIO RTCP)
• 63814 (AUDIO RTP)

Chrome responds with Server Hello messages to the following ports:

• 59854 (VIDEO RTCP)
• 57094 (VIDEO RTP)
• 56206 (AUDIO RTCP)
• 62100 (AUDIO RTP) ?!?!?!?!?!

I know this isn't of much help. If it doesn't seem related to any known issue, I will be happy to help with the troubleshooting.

The DTLS handshake is attached for anyone to double check.

 

Enrico

[Enrico Marocco]

Fixing my text below, the issue is still valid.

The lists at the bottom of the email should read like this:

• 59854 (VIDEO RTCP)
• 57094 (VIDEO RTP)
• 56206 (AUDIO RTCP)

• 62100 (AUDIO RTCP) ?!?!?!?!?!

62100 is the relay candidate for AUDIO RTCP. This is the weird part.