You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a scenario where I'm trying to connect a client (browser) to a server using Elixir WebRTC. The PeerConnection on the server side does not accept any video codecs; the server is audio only. I noticed problems with negotiation in a specific scenario where we first add only video and negotiate for it, which rejects the video track (audio-only server), and then we add audio (to the same PeerConnection) and start negotiation again, which fails (the browser does not accept the SDP answer, or an ICE candidate).
In the case of the Chrome browser, the reason seems to be sending a value of 0 in the m-line port in response to the first negotiation. As a result, the second SDP offer does not contain the video track that was sent in the first offer.
For comparison, Chrome in the SDP answer sets the m-line port value to 9, thanks to which the second offer contains both tracks.
In the case of the Firefox browser, after applying the second SDP answer, the next ICE candidate from the server causes an error. Firefox sends the correct SDP offer (unlike Chrome) hence accepts the SDPAnswer. It seems to me that the problem with the error during the candidate application is that in the first SDP answer the m-line port was set to 0 by the server and it should not then send ICE candidates for that m-line.
Interestingly, Firefox (unlike Chrome) returns in the SDP answer an m-line port equal to 0 for video (just like Elixir WebRTC).
Code used to check how browsers behave in a similar situation:
I have a scenario where I'm trying to connect a client (browser) to a server using Elixir WebRTC. The PeerConnection on the server side does not accept any video codecs; the server is audio only. I noticed problems with negotiation in a specific scenario where we first add only video and negotiate for it, which rejects the video track (audio-only server), and then we add audio (to the same PeerConnection) and start negotiation again, which fails (the browser does not accept the SDP answer, or an ICE candidate).
In the case of the Chrome browser, the reason seems to be sending a value of 0 in the m-line port in response to the first negotiation. As a result, the second SDP offer does not contain the video track that was sent in the first offer.
For comparison, Chrome in the SDP answer sets the m-line port value to 9, thanks to which the second offer contains both tracks.
In the case of the Firefox browser, after applying the second SDP answer, the next ICE candidate from the server causes an error. Firefox sends the correct SDP offer (unlike Chrome) hence accepts the SDPAnswer. It seems to me that the problem with the error during the candidate application is that in the first SDP answer the m-line port was set to 0 by the server and it should not then send ICE candidates for that m-line.
Interestingly, Firefox (unlike Chrome) returns in the SDP answer an m-line port equal to 0 for video (just like Elixir WebRTC).
Code used to check how browsers behave in a similar situation:
The text was updated successfully, but these errors were encountered: