Open drakos74 opened 11 years ago
A screen-sharing application can fail to establish peer connection if:
Other issues can be NAT traversing; audio in the same media request; or non-SSL domain.
"Crashes" usually occurs by setting local/remote descriptions; out of invalid/unexpected sdp parameters/lines/values.
I've not faced any crash on both canary and stable releases. (latest) — Logs are most welcome!
I found out it was indeed in the sdp , like you said. I changed in the SetBandwidth function the lines //sdp = sdp.replace(/a=mid:audio\r\n/g, 'a=mid:audio\r\nb=AS:' + (bandwidth.audio || 50) + '\r\n'); //sdp = sdp.replace(/a=mid:video\r\n/g, 'a=mid:video\r\nb=AS:' + (bandwidth.video || 256) + '\r\n'); that i had applied to every way of communication blindly... Now both video and audio , as well as screen-sharing work fine. I used chrome, so i don t know why they are not working. I hope this helps some people... Anyway, what are the benefits of using AS in chrome?
I already removed application specific bandwidth lines in RTCMultiConnection-v1.4:
https://www.webrtc-experiment.com/RTCMultiConnection-v1.4.js
Though, it increases the bandwidth usage; however, chrome is unable to support it accurately; 70% of the tests fails; especially on android devices. AFAIK, firefox has no support of it, yet.
min/max frame-rate is a better option.
b=AS
for data is also deprecated with SCTP (on chrome) where 64kb/s is max bandwidth limit.
Hello, i noticed that by trying to establish a screen-sharing session in chrome 29 (both machines are Mac). The one of the two browsers crashes and of course no peerconnection is established. Do others have also this issue. Is this a coding issue, or is it something with chrome?