MushMal
commented
3 years ago No idea. Try to use different client ids first
Closed Mobe91 closed 3 years ago
MushMal
commented
3 years ago No idea. Try to use different client ids first
Mobe91
commented
3 years ago I am using different client ids (freshly generated UUIDs) on every run for every signaling channel.
MushMal
commented
3 years ago Interesting. Doesn't seem like it's related to #817
Could you attach verbose logs from the master so we can see whether the exchange on the master side was successful.
Most importantly, please try the test application on Firefox. Please include the Firefox version as well.
Please use the latest commit for the testing.
Mobe91
commented
3 years ago By test application you mean https://awslabs.github.io/amazon-kinesis-video-streams-webrtc-sdk-js/examples/index.html? I tried to create a master and a viewer both in different Firefox tabs. The transmission works but the test application uses only 1 remote video (and 1 local) so it's not directly comparable I think.
The Firefox version is included in my original question.
I have attached the verbose master logs as well as the matching logs form the Firefox browser console.
MushMal
commented
3 years ago Use the sample master application from this repository and open two bower tabs with different IDs with test js app
Mobe91
commented
3 years ago So here is what I did - not sure if this is what you meant:
./kvsWebrtcClientMasterGstSample <channel-name>Both tabs correctly showed the test image emitted by kvsWebrtcClientMasterGstSample. However, this setup has little to do with my application because I am not using different tabs.
MushMal
commented
3 years ago Try debugging into it since now you have a working solution. I am setting to resolved as this has nothing to do with C WebRTC SDK
Mobe91
commented
3 years ago I can clearly reproduce this issue with your example application so I ask you to reopen this. As I said, it only happens when you have multiple PeerConnection in the same browser tab. To reproduce this, I have slightly extended your example application to establish 2 viewer connections to the master instead of only 1. Find the git patch with my changes attached. Again, 2 viewer connections work fine in Chrome but only 1 can be established in Firefox.
What jumped into my eye was this warning in the master logs:
2021-01-21 01:43:25 WARN dtlsSessionProcessPacket(): SSL_read failed with error:14102412:SSL routines:dtls1_read_bytes:sslv3 alert bad certificateCould this be the issue? The Firefox bug I previously shared also mentions issues with DTLS in case of multiple PeerConnections.
MushMal
commented
3 years ago Looks like related. I would strongly suggest opening an issue against the Firefox in this case. I am not sure what the actionable items are in terms of opening an issue in C WebRTC SDK. Though, this might be a common scenario for some developers and they might share some insight into it. However, we would like to not keep issues in an "open" state which are not actionable.
Mobe91
commented
3 years ago This comment on the Firefox issue mentions that it works for them when all connections use the same DTLS certificate. How is the behavior in this regard in amazon-kinesis-video-streams-webrtc-sdk-c? Is there a way to get the same behavior (i.e. use the same DTLS cert for all connections)?
MushMal
commented
3 years ago @Mobe91 perhaps that's the root cause - not sure.
Here is the documentation link for the pre-generated certificates: https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c#use-pre-generated-certificates
This is intended to be used for lowering the latency of the connection on some low-powered devices where the self-signed cert generation takes considerable amount of time. The use case there is that the device would pre-generate the certs off of the "hot path" and use them when it actually needs them.
NOTE: Using the same certificate for the two different connections has certain security implications.
Mobe91
commented
3 years ago The problem is that you generate different DTLS certificates with the same CN and same Serial Number (SN).
From RFC 5280 and as mentioned in the Firefox bug report:
4.1.2.2. Serial Number
The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). ...
Note: Non-conforming CAs may issue certificates with serial numbers that are negative or zero. Certificate users SHOULD be prepared to gracefully handle such certificates.
Reading this, I am actually surprised that it works in Chrome because you are using a constant CN with a constant SN of 1 for all your generated DTLS certificates. This violates the RFC that says the tuple (CN, SN) MUST be unique.
For SNs <= 0 the RFC suggests that such certificates SHOULD be handled gracefully. However, when testing with Firefox it did not make a difference if the SN is changed to be <= 0.
Working configurations according to my testing are:
Since you suggested that using the same certificate for all PeerConnection has security implications I guess option 2 or 3 should be preferred. In my tests I just postfixed the CN with a timestamp but this may not be a perfect solution. It might be better to introduce a global atomic counter to count up the SN.
I am not a 100% fit in C so I am not sure if it's a good idea for me to raise a PR for this, though I have a working solution locally. Are you able to fix this issue?
MushMal
commented
3 years ago @Mobe91 Here is my understanding of the issue. The RFC refers to PKI infrastructure and indeed, a public authority issuing a certificates under it's CA should issue different serial numbers - hence the need for up-to 20 bytes of data space for SN.
However, the usage of self-signed certificates for the purpose of DTLS session establishment where the entire certificate fingerprint is evaluated is somewhat open for interpretation. In this case, the CA and SN are really irrelevant as the finterprint will include bits from public and private key that's just been generated and it has worked on Chrome previously.
In order to get this to work for FF, it seems that the best course of action is to simply increment the SN or use a random number.
Will need to do some investigation before pushing a PR>
Mobe91
commented
3 years ago Ok - can you reopen this issue then?
MushMal
commented
3 years ago Merged. Closing
We have a web client that uses multiple KVS signaling channels to open one PeerConnection per channel to receive a remote video stream. The client works fine in e.g. Chrome showing 2 video streams simultaneously. However, the same client only shows 1 of the 2 streams when opened in Firefox - there are no related error messages in the browser console.
We use the amazon-kinesis-video-streams-webrtc-sdk-c in our backend to produce the video streams.
Logs
Our client code is very much aligned to https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-js/blob/master/examples/viewer.js. I have enriched the log messages with the client ids so that it is possible to differentiate between the 2 connections. Here are the respective browser logs from Firefox:
Versions
amazon-kinesis-video-streams-webrtc-sdk-c version: Tried with both v1.4.0 and latest master (4dc2cfd98285ad63a498a24d4b393d3909409ce5) Firefox version: 78.6.1esr (64-bit) Chrome version: 87.0.4280.141 (64-bit)
Potentially related issues
I have found the following possibly related issues:
817
Not sure if this should be a BUG rather than a QUESTION - feel free to change. Also not sure if this should rather go into amazon-kinesis-video-streams-webrtc-sdk-js.