See Figure 3 on Page 21 https://tools.ietf.org/html/rfc6347#page-21

> Chrome stopped working at some update? 
> We really aren't sure since its basically a black-box from our end. 

To be clear, you're saying that this worked in some version of Chrome, but no longer works in Chrome 66?

This issue is MUCH more likely to be resolved if we can narrow down when this regressed. Is there a simple test URL endpoint we can use to bisect and determine what the final working build was?

I could get a server setup, but it wouldn't be until tomorrow morning at the earliest. I think this was also breaking in Chrome 65, but I cannot state that for certain.

I would assume the byte sequences in the attachment would yield a clue or two, is that not the case or was I not thorough enough?

I was unable to reproduce (also using Chrome 66.0.3359.117). I tried to reproduce using two instances of Chrome, but the SDP you provided, using these steps:

1. Create offer on side A.
2. Replace with the "Chrome offer" in your attachment, sticking in the a=fingerprint from the generated offer.
3. Apply as local description on side A, remote description on side B.
4. Create answer on side B.
5. Replace with the "Sever end-point answer" in your attachment, sticking in the a=fingerprint from the generated answer.
6. Apply as local description on side B, remote description on side A.
7. Exchange ICE candidates.

And I see a ClientHello from A (the active side), as expected.

Though maybe I'm misunderstanding the issue here. Is the issue that Chrome sends a bunch of ClientHellos and times out, then ignores the HelloRequest that comes later? From the discuss-webrtc thread (https://groups.google.com/forum/#!topic/discuss-webrtc/zHq1uwhGsv8) it sounded like Chrome wasn't sending a ClientHello in the first place.

A packet capture may be helpful here.

@deadbeef the issue is that Chrome sends 0 ClientHello and plenty of HelloRequest. Chrome receives HelloRequest and ClientHello from the server.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

elawrence@chromium.org I have a test server setup here: https://ipv6.red5.org/live/broadcast.jsp?host=ipv6.red5.org for publishing and https://ipv6.red5.org/live/subscribe.jsp?host=ipv6.red5.org for subscribing

Attached is my latest pcap, we found a bug in our ICE codec, so the original issue is now invalid. Any ideas on what the problem is now would be greatly appreciated.

Deleted: Chrome_66_0_3359_139_ICE312.pcapng 13.2 KB

Chrome_66_0_3359_139_ICE312.pcapng 13.2 KB Download

Something I noticed is that the CertificateRequest only lists the RSA certificate type, whereas Chrome will use ECDSA certificates by default from M52 onward: https://developers.google.com/web/updates/2016/06/webrtc-ecdsa

I'm not a DTLS expert but I assume this would be a problem.

You could quickly check if using generateCertificate to generate an RSA certificate makes things work.

The native log may also reveal some information: https://webrtc.org/native-code/logging/

Well, looks like you're responding to all ClientHello's. If that's correct, simply don't accept those connections once you have accepted one.

I'm also not a TLS expert but AFAIK the private key types of the certificates used by each peer do not need to match. For example, I can use an RSA key in RAWRTC and talk to Chrome in the default configuration (which will use an ECC key) and vice versa. Just verified that this works.

Thank you for checking that certs can differ, we were trying our best to match the type exactly.

> I'm also not a TLS expert but AFAIK the private key types of the certificates used by each peer do not need to match.

Correct, but the client's certificate *does* have to comply with the CertificateRequest. "Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_algorithms."

Good to know. :) It's probably best to enable (WebRTC) logging in this case.

I tested with logging enabled and it doesn't reveal much, other than that the DTLS association is closed with an error.

As per the latest update in the group mentioned in C#6, 
https://groups.google.com/forum/#!topic/discuss-webrtc/zHq1uwhGsv8. This was due to bug in ICE codec which seems to be resolved now.

mondain@/deadbeef@: Could you please confirm if this can be closed now.

Thank you!

Yes @phanindra, please go ahead and close this.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot