Open hector-chou opened 2 years ago
This is a very old issue. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.
This is a very old issue. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.
This is a very old issue. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.
This is a very old issue. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.
Describe the bug Does it make sense to have per-channel properties (RtcDataChannelInit) about order and reliability, but reference to the same value (SctpSession.packet[1]) indiscriminately while sending messages? https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/2dff44fea83a79336fda676ba2801d0d77417cd1/src/source/Sctp/Sctp.c#L180-L190
It leads to the consequence that we can't have any ordered/reliable channel if we want to have any unordered/unreliable channel, and vice versa.
And is it the reason why we just ignore those properties that comes with DATA_CHANNEL_OPEN message, for channels created by peer? This handler sets nothing about order and reliability. https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/2dff44fea83a79336fda676ba2801d0d77417cd1/src/source/Sctp/Sctp.c#L303
In the end, why didn't we have DATA_CHANNEL_ACK? https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/2dff44fea83a79336fda676ba2801d0d77417cd1/src/source/Sctp/Sctp.h#L32-L34
SDK version number v1.7.2
Expected behavior