What does the MSID attribute in the SDP mean?

There is a work in progress in the IETF [1] to define a new MSID attribute to be used in the SDP. This attribute has been defined in the context of WebRTC and it is already being sent by WebRTC endpoints (Firefox and Chrome). This is a typical SDP generated by Chrome:

v=0
o=- 658899108507703479 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS FmJZgkjbR2gBS25U0hP3qoUSjvfDddQl4UjJ
m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126
...
a=ssrc:1400694016 cname:Yk4LvPXyWNZKkW6S
a=ssrc:1400694016 msid:FmJZgkjbR2gBS25U0hP3qoUSjvfDddQl4UjJ a228df45
a=ssrc:1400694016 mslabel:FmJZgkjbR2gBS25U0hP3qoUSjvfDddQl4UjJ
a=ssrc:1400694016 label:a228df45-515e-49b6-be8f-0d044b65de64
m=video 1 RTP/SAVPF 100 116 117
...
a=ssrc:1484622160 cname:Yk4LvPXyWNZKkW6S
a=ssrc:1484622160 msid:FmJZgkjbR2gBS25U0hP3qoUSjvfDddQl4UjJ 00f2f3d2
a=ssrc:1484622160 mslabel:FmJZgkjbR2gBS25U0hP3qoUSjvfDddQl4UjJ
a=ssrc:1484622160 label:00f2f3d2-974e-48a6-b8dc-0f70194949d5
 
But what is it for and why is it needed?

The purpose of the attribute is to group m lines that are related somehow. In the context of WebRTC the idea is to be able to group channels that belongs to the same MediaStream (a MediaStream is one of the WebRTC JavaScript objects) so that if the sender start sending two streams (one with the audio of the speaker and one with the video of shared screen) the recipient will know that those were 2 separate streams and not a single stream with audio and video. That way the number of streams and tracks in the sender (and the IDs of those streams and tracks) is preserved in the receiver.

So in case of webrtc this line:
a=msid-semantic: WMS FmJZgkjbR2gBS25U0hP3qoUSjvfDddQl4UjJ
means that there is a WebRTC Media Stream (WMS) group identified by that stream id.  

And the line: 
a=ssrc:1400694016 msid:FmJZgkjbR2gBS25U0hP3qoUSjvfDddQl4UjJ a228df45
means that there is a media stream with id FmJZ...jJ with an audio track with id a228df45. 


[1] http://tools.ietf.org/html/draft-ietf-mmusic-msid-05

Comments

  1. UnknownFebruary 18, 2016 at 9:31 PM

    Very good explanation...I am able to understand quickly...thanks a lot

    ReplyDelete

Post a Comment

Popular posts from this blog

Bandwidth Estimation in WebRTC (and the new Sender Side BWE)

Image
Bandwidth estimation is probably the most critical component in the video engine of WebRTC. The bandwidth estimation (BWE) module is responsible for deciding how much video* traffic you can send without congesting the network to prevent degradation of the video quality. In the past bandwidth estimation algorithms used to be very rudimentary and based mostly on packet loss. Basically we used to start increasing slowly the video bitrate until we detected packets being lost.  To detect the packet loss you use the standard RTCP feedback mechanisms where the receiver side reports packet loss periodically using RTCP Receiver Report (RR) messages. Modern bandwidth estimation algorithms are more advanced and try to detect congestion before it is bad enough to make routers discard packets. These algorithms predicts congestion analyzing the delay between packets. The idea is that when you start having some congestion, the buffers in the routers will start filling and the delay wil...
Read more

Improving Real Time Communications with Machine Learning

Image
When we talk about the applications of Artificial Intelligence / Machine Learning (AI/ML) for Real Time Communications (RTC) we can group them in two different planes: Service Level : There are many features that can be added to a videoconference service, for example identification of the participants, augmented reality, emotion detection, speech transcription or audio translation .  These features are usually based on image and speech recognition and language processing. Infrastructure Level : There are many ways to apply ML that do not provide new features but improve the quality and/or reliability of the audio/video transmission. Service level applications are fun, but they are more for Product Managers and I like technology more, so in the next sections I will try to describe possible applications of AI/ML for Real Time Communications at Infrastructure Level organizing those ideas in five different categories. Optimizing video quality Some of the ML algorithms use...
Read more

Controlling bandwidth usage in WebRTC (and how googSuspendBelowMinBitrate works)

Image
There are cases when we would like to limit the maximum bitrate being transmitted by WebRTC to avoid wasting resources in the user endpoints or save money reducing the bandwidth usage in our servers.   This is because the maximum bitrate by default in Chrome is around 2Mbps and for many use cases a much lower bitrate provides still pretty good quality.   BTW using a lower bitrate can also help with stability of quality in multiparty scenarios by reducing the amount of competition among different streams. There is no simple API to configure the maximum bitrate in WebRTC (although there is one in ORTC) but there are 3 ways to do this by mangling the SDP. 1. U se the standard  b=AS:BITRATE (Chrome) or b=TIAS:BITRATE  (Firefox) attributes in the SDP for the audio or video channel[1] 2. Use codec specific attributes (this work at least for opus audio codec with maxaveragebitrate property) [2] 3. Use the proprietary x-max-bitrate attribute in the video channel of the...
Read more