lynckia
Sender Bandwidth Estimation fails at subscriber side for safari VP8 calls
Description Sender Bandwidth estimation fails for safari calls because of missing RTCP REMB packets despite goog-remb negotiated over SDP successfully
Steps to reproduce the issue:
- set log4j.logger.rtp.SenderBandwidthEstimationHandler to TRACE in log4cxx.prperties
- Start one call leg from Chrome and one from Safari
- iCheck the logs
- Network trace/tcpdump also shoing REMB feed backs are not received.
Describe the results you received: Logs shows REMB feedback packets received from chrome. but not from safari subscriber stream.
Describe the results you expected: Logs should show the REMB packet received messages with bitrate from both chrome and safari subscriber streams.
Additional information you deem important (e.g. issue happens only occasionally): I also ran network trace at server to see what all RTCP packets are sent by Safari. Still not receiving any REMB from Safari side despite playing the remote video. This causes sender b/w estimation failure for all safari subscriber streams.
Licode commit/release where the issue is happening latest
Additional environment details (Local, AWS, Docker, etc.): installed on local server.
I'm able to reproduce it. But I don't know how to solve it unless we try implementing an alternative like transport-cc. 😞
it's because safari subscriber send an offer with sendrecv instead of recvonly stream! ;)
