Summary: | iOS 12.3 and 12.4 emit PeerConnection SDP offer m-lines in random order | ||
---|---|---|---|
Product: | WebKit | Reporter: | Chad Phillips <webkit> |
Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | youennf |
Priority: | P2 | ||
Version: | Safari Technology Preview | ||
Hardware: | iPhone / iPad | ||
OS: | iOS 12 |
Description
Chad Phillips
2019-05-30 18:35:57 PDT
Hi Chad, Can you make sure to call addTrack(audio) first and addTrack(video) second? If you do not have a video track initially, I would think calling addTransceiver('audio') and then using sender.replaceTrack to do the trick to make sure to have the audio track first. If you handle only one audio and one video track, that should be ok to handle properly this way. I would think the munging should work as well though a slight typo sometimes make it hard to debug. If you have a jsfiddle, I can try to help further. Would it be possible you added an extra empty line somewhere during munging? youenn, Thanks for your replies, very helpful! Two things: 1. Adding the media tracks via addTrack() in the specific order I want does indeed fix the issue. 2. The munged SDP was failing because it was missing a trailing \r\n after the last line. This seems like a silly reason to fail SDP parsing, perhaps that can be rectified? At the very least, an SDP parsing error should include some more helpful output for the developer! 3. The adapter.js 'addStream' shim for Safari uses stream.getTracks() internally to then call addTrack() on all the tracks in the stream. Is it possible that the Webkit implementation of getTracks() returns the media tracks in random order? (In reply to Chad Phillips from comment #3) > youenn, > > Thanks for your replies, very helpful! > > Two things: > > 1. Adding the media tracks via addTrack() in the specific order I want does > indeed fix the issue. Nice > 2. The munged SDP was failing because it was missing a trailing \r\n after > the last line. This seems like a silly reason to fail SDP parsing, perhaps > that can be rectified? At the very least, an SDP parsing error should > include some more helpful output for the developer! You are not the first one caught up in this area. This error message is usually a signal of such kind of error, agreed it is not very clear though. > 3. The adapter.js 'addStream' shim for Safari uses stream.getTracks() > internally to then call addTrack() on all the tracks in the stream. Is it > possible that the Webkit implementation of getTracks() returns the media > tracks in random order? Tracks are stored in a map internally whose key is the stream id. But this is implementation dependent and the spec does not require any specific order, nor should implementations rely on that. adapter.js could be of some help there by doing getAudioTracks/getVideoTracks so as to preserve the old behavior. I'll close the bug, please reopen it if needed. FYI, a workaround landed in adapter.js, v7.2.4: https://github.com/webrtcHacks/adapter/commit/e823e5847a727c5e01862fd72eb5ed0091a3ac30 |