Until recently a customised or property extension could signal multiple media streams within an m-section of an SDP and experiment with media-level “msid” (Media Stream Identifier ) attribute used to associate RTP streams that are described in different media descriptions with the same MediaStreams. However, with the transition to a unified plan, they will experience breaking changes.
The previous SDP format implementation called “planB” was transitioned to “unified plan” in 2019.
Who it does effect ?
- Uses various media tracks within m line in SDP such as for video stream and screen sharing simultaneously
- Munges SDP, uses MCUs or SFUs
- used track-based APIs addTrack, removeTrack, and sender.replaceTrack or legacy addstream removeStream exposed senders and receivers to edit tracks and their encoding parameters
Who it does not affect ?
- This does not affect any application which has only single audio and video track.
{ iceServers: [], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "unified-plan" },
Plan B vs Unified Pan
Multiple media stream may be required for cases such as video and screen share stream in same SDP or in specific cases of SFU.
This implementation in Plan B will result in one “m=” line of SDP being used for video and audio. While within the video m= section multiple “a=ssrc” lines are listed for multiple media tracks.
In Unified Plan, every single media track is assigned to a separate “m=” section. Hence for video and screen sharing simultaneously two m sections will be created.
Interoperability between unified plan and plan B
A mismatch in SDP (between Plan B and Unified Plan) usually results :-
- only Unified Plan client receives an offer generated by a Plan B client – the Unified Plan client must reject the offer with a failed setRemoteDescription() error.
- only Plan B client receives an offer generated by a Unified Plan client – only first track in every “m=” section is used and other tracks are ignored
Reference :
- webrtc org – https://webrtc.org/getting-started/unified-plan-transition-guide#
- “Unified Plan” Transition Guide (JavaScript) – https://docs.google.com/document/d/1-ZfikoUtoJa9k-GZG1daN0BU3IjIanQ_JSscHxQesvU
- IETF Network Working group Internet draft – WebRTC MediaStream Identification in the Session Description Protocol draft-ietf-mmusic-msid-17
- IETF Network Working Group Internet Draft – A Unified Plan for Using SDP with Large Numbers of Media Flows draft-roach-mmusic-unified-plan-00
https://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00
NAT traversal using STUN and TURN
STUN and TURN server protocols handle session initiations with handshakes between peers in different network environments . In case of a firewall blocking a STUN peer-to-peer connection, the system fallback to a TURN server which provides the necessary traversing mechanism through the NAT.
continue : Streaming / broadcasting Live Video call to non webrtc supported browsers and media players
This blog is in continuation to the attempts / outcomes and problems in building a WebRTC to RTP media framework that successfully stream / broadcast WebRTC content to non webrtc supported browsers ( safari / IE ) / media players ( VLC )
SIP/VOIP transformation towards IMS (Total IP)
The telecommunications industry has been going through a significant transformation over the past few years. At the outset incumbent operators used to focus on mainly basic voice services and still remained profitable due to the limited number of players in the space and requirement of huge amounts as initial investment. However, with the advent of…
Something went wrong. Please refresh the page and/or try again.
Telecom R & D 