Closed AndreaPetrelli closed 8 months ago
Working on the issue we found that wakeLwsServiceEventLoop is called before the wait of the reply.
The problem is that the lwsHttpCallbackRoutine is not called immediatly but only at the next pong.
Can we add more information?
My fault, i used lws from meta-openembedded and it use libuv as a default. Removing libuv solve the issue.
Closing assuming resolved. Feel free to reopen / open a new issue if problem persists
Please confirm you have already done the following
Describe the bug
We are using the sdk in master mode with no problems with Trickle ICE enabled clients.
Working with Alexa (that does not support Trickle ICE) we discovered a random delay (from 0 to 10 seconds) waiting for the reply of function signalingClientSendMessageSync.
After some investigations we noted that this delay is produced by this code: https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/blob/74e7f6856b2d3bd71bf7f57374e009af9881ba70/src/source/Signaling/LwsApiCalls.c#L1929
Playing around the defined constants we found that lowering the constant SIGNALING_SERVICE_WSS_PING_PONG_INTERVAL_IN_SECONDS from 10 to 3 seconds, we experiment that the random delay never exceeds 3 seconds.
Expected Behavior
We expect that message is sent as soon as the function signalingClientSendMessageSync has been raised.
Current Behavior
The message is not sent immediatly but with a random delay between 0 and 10 seconds.
Reproduction Steps
For some reason this issue is not relevant when Trickle ICE is enabled. We have discovered this issue working with Alexa because Trickle ICE is not supported and the required 6 seconds timeout if often unsatisfied.
WebRTC C SDK version being used
branch release-1.10.0
Compiler and Version used
gcc (GCC) 12.3.0
Operating System and version
Linux 6.1.54-v7l
Platform being used
Raspberry CM4