AWS kinesisvideostreams-webrtc-dg documentation change
Summary
Added troubleshooting details for channel-stream mapping errors, transceiver direction requirements, and ICE candidate handling logic
Security assessment
Changes focus on error handling and implementation guidance for WebRTC storage sessions. While they improve reliability, there's no evidence of addressing vulnerabilities or security weaknesses. The ICE candidate notes clarify protocol behavior but don't introduce security controls.
Diff
diff --git a/kinesisvideostreams-webrtc-dg/latest/devguide/troubleshoot-establish-storage.md b/kinesisvideostreams-webrtc-dg/latest/devguide/troubleshoot-establish-storage.md index 78906bdfb..bdd919428 100644 --- a//kinesisvideostreams-webrtc-dg/latest/devguide/troubleshoot-establish-storage.md +++ b//kinesisvideostreams-webrtc-dg/latest/devguide/troubleshoot-establish-storage.md @@ -5 +5 @@ -Controlling and controlled peersReview supported codecs +Controlling and controlled peersReview supported codecsIf channel is not mapped to a stream, will also throw 400 InvalidArgumentException @@ -16,0 +17,2 @@ This section provides guidance on troubleshooting issues related to setting up a + * If channel is not mapped to a stream, will also throw 400 InvalidArgumentException + @@ -26 +28,5 @@ Upon calling [JoinStorageSession](https://docs.aws.amazon.com/kinesisvideostream -For a sequence diagram, see [Understanding WebRTC ingestion and storage](./getting-started-ingestion.html#understanding-ingestion). +For a sequence diagram, see Understanding WebRTC ingestion and storage. + +###### Important + +Signaling messages received from the storage session do not have a senderClientId field in the JSON, which differs from the peer-to-peer master, which always receives senderClientId field with the SDP offer and ICE candidates. @@ -54,0 +61,68 @@ See [JoinStorageSession](https://docs.aws.amazon.com/kinesisvideostreams/latest/ +## If channel is not mapped to a stream, will also throw 400 InvalidArgumentException + +### Review transceiver directions + +In the SDP answer, review the directionality of the video and audio transceivers. The lines in the SDP look like this: + + + a=sendrecv + a=recvonly + +For master participants, the following requirements are in place: + + * H.264 video: sendonly + + * Opus audio: sendonly or sendrecv + + + + +For viewer participants, the following requirements are in place: + + * H.264 video: recvonly + + * Opus audio: recvonly or sendrecv + + + + +If the service requirements are not met, a statusResponse with 400 IllegalArgumentException will be returned if the correlationId is provided when the answer was sent. + +When using the KVS-provided WebRTC ingestion sample applications: + + * Master participants: Ensure the "send video" and "send audio" settings are both enabled + + * Viewer participants: Ensure "send video" setting is disabled + + + + +### Review ICE candidate conversion + +When receiving ICE candidates from the KVS Signaling SDK, the application may need to convert the string into the ICE candidate object. + +ICE candidates received from the storage session do not contain an SDPMID property, and do not come with a senderClientId. + +Review your application logic for adding the ICE candidates received from remote into your application's RTCPeerConnection object. + +### Review ICE candidate queuing logic + +All ICE candidates received from the storage session need to be added to the RTCPeerConnection via the addIceCandidate API. + +Even though the storage session sends the SDP offer before the ICE candidates, due to the asynchronous nature of the Signaling message delivery, the application may receive the ICE candidates before receiving the offer. + +In this case, you will need to implement a temporary buffer to hold the ICE candidates. + +The logic implemented in the KVS sample applications is as follows: + + 1. The samples maintain a map of the senderClientId to its RTCPeerConnection. + + 2. The samples maintain another map of the senderClientId to a list of pending Ice Candidates. + + 3. When an ICE candidate is received, check the PeerConnection map. If the PeerConnection map does not have a connection yet, add it to the pending list. Otherwise, add the ICE candidate to the PeerConnection. + + 4. When the offer is received, it creates the RTCPeerConnection and add it to the PeerConnection map. Then, add all ICE candidates from the pending queue to this PeerConnection. + + + +