PSA: RTCRtpTransceiver shipping in M69 behind sdpSemantics:'unified-plan'
hb...@webrtc.org
The RTCRtpTransceiver (spec) is shipping in M69 for applications opting in to use Unified Plan SDP format. We strongly encourage you to experiment with the transceiver model due to the possible incompatibilities and change of behavior between Plan B (current behavior) and spec’s agreed-upon SDP format and behavior, Unified Plan. Please try it out, file bugs, and prepare for migration! This bridges the gap between Chrome and the spec and Chrome and browsers supporting the transceiver model (such as Firefox).
A transceiver is a sender-receiver pair corresponding to an “m=” section in the SDP. It gives you more control of what is negotiated between peer connections, and it makes the peer connection behave in accordance with the spec. See RTP Media API.
How do I enable Unified Plan and RTCRtpTransceiver?
When constructing an RTCPeerConnection, have sdpSemantics:’unified-plan’ present in the RTCConfiguration argument. Example: new RTCPeerConnection({sdpSemantics:'unified-plan'}).
By default, sdpSemantics:’plan-b’ is implicitly passed in. This can be passed in explicitly to guard against the default changing in upcoming releases (migration plan to be announced) if your application needs to be backwards compatible with Plan B clients.
You can also change the default to ‘unified-plan’ by a command line switch:
--enable-blink-features=RTCUnifiedPlanByDefault
What’s shipping?
RTCRtpTransceiver: { mid, sender, receiver, stopped, direction, currentDirection }
RTCRtpTransceiverInit
RTCPeerConnection.addTransceiver()
Only available in ‘unified-plan’; throws an exception if invoked in ‘plan-b’.
RTCPeerConnection.getTransceivers()
In ‘plan-b’ there are no transceivers and this always returns an empty set.
RTCTrackEvent (RTCPeerConnection.ontrack) gets a transceiver attribute.
In ‘plan-b’, transceiver is null.
What’s not shipping yet?
RTCRtpTransceiver.stop()
If you want to stop a transceiver, set it’s direction to “inactive” instead.
RTCRtpTransceiver.setCodecPreferences()
sendEncodings of RTCRtpTransceiverInit is currently ignored by RTCPeerConnection.addTransceiver()
How does Unified Plan behave different from Plan B?
The SDP format generated by createOffer() and createAnswer(), and the SDP format expected to be passed in to setLocalDescription() and setRemoteDescription(), is different between Plan B and Unified Plan. This may cause incompatibilities between clients using different formats, see below.
Behavioral changes primarily include changes to the lifetime of senders and receivers.
In Plan B, adding a track creates a sender, receiving a track creates a receiver. These exist independently of one another, and when a track is removed it’s sender or receiver is removed from the peer connection. This is reflected in getSenders() and getReceivers().
addTrack() creates a sender.
removeTrack() removes the sender.
setRemoteDescription() may create or remove receivers.
In Unified Plan, adding a track creates a transceiver. That is, senders and receivers are always created in pairs; every transceiver is capable of both sending and receiving. The transceiver’s direction controls the direction (“sendrecv”, “sendonly”, “recvonly”, “inactive”) we are willing to offer, and currentDirection is the direction currently negotiated. Removing a track means not sending or receiving it, and while a transceiver can become “inactive” it is never removed from the peer connection. This is reflected in getTransceivers(), getSenders() and getReceivers(). Use currentDirection to figure out which tracks are actively in-use.
addTrack()/addTransceiver() creates a transceiver (sender & receiver).
removeTrack() changes the direction of a transceiver.
setLocalDescription() may change the currentDirection of transceivers.
setRemoteDescription() may create transceivers or change their currentDirection.
When are Plan B clients and Unified Plan clients incompatible?
When multiple “m=” sections of the same media type (audio/video) are present in the SDP. In other words, when multiple audio tracks or multiple video tracks are used by a peer connection, or when tracks are added, removed and added again. In such cases, Plan B clients would reject remote Unified Plan SDP and Unified Plan clients would reject remote Plan B SDP.
Philipp Hancke
--
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/deff8c83-ed90-4567-a127-99158ed25a52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.