Subject: [MMUSIC] MSID and AppID: solving different problems

From: Jonathan Lennox <[email-masked]>
Date: Thu, 13 Feb 2014 18:09:25 +0000

The chairs asked that the authors of the MSID and AppID drafts discuss the relationship between the two documents.

My personal opinion (which I mentioned in the RTCWeb Rejecting MediaStreamTracks thread, but folks might not have seen) is that they're solving different problems, and so are non-conflicting.

MSID provides an identifier for SDP m= lines.  Its primary use case is providing a Javascript-level handle in WebRTC.

AppID -- which needs a better name, suggestions welcome -- provides an indirection label for identifying individual RTP packet streams in SDP, in scenarios where the SSRC is unavailable to the signaling.

The scenarios we've identified so far for AppID where an SSRC might be unavailable are: "early media" race conditions where media outraces an SDP answer; SSRC collisions; applications which wish to dynamically switch which SSRC is fulfilling a higher-level application role; and architectures where the signaling stack can't control/doesn't have visibility onto the SSRC selection.

AppID should be applicable to anything using BUNDLE, I think, and certainly anything using it with a vaguely Unified-style semantic.  (I think it would apply to a "Plan B"-style semantic, as well, which I know some people are still advocating for some non-WebRTC contexts; however, I'm not positive all the syntax necessary for that is currently complete.)

The difference between AppID and MSID should be most clear in scenarios where an m= line group has more than one packet stream (my canonical example is a primary stream and a retransmission stream).  In this case, the m= line group has one msid attribute, but multiple appid attributes.

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 13 Feb 2014 14:43:57 -0800

On Thu, Feb 13, 2014 at 10:09 AM, Jonathan Lennox <[email-masked]>wrote:

> My personal opinion (which I mentioned in the RTCWeb Rejecting
> MediaStreamTracks thread, but folks might not have seen) is that they're
> solving different problems, and so are non-conflicting.
>
MSID provides an identifier for SDP m= lines.  Its primary use case is
> providing a Javascript-level handle in WebRTC.
>
> AppID -- which needs a better name, suggestions welcome -- provides an
> indirection label for identifying individual RTP packet streams in SDP, in
> scenarios where the SSRC is unavailable to the signaling.
>

[Suhas] How about the name SSID (Source Stream ID) to identify the
individual RTP packet streams

>
> The scenarios we've identified so far for AppID where an SSRC might be
> unavailable are: "early media" race conditions where media outraces an SDP
> answer; SSRC collisions; applications which wish to dynamically switch
> which SSRC is fulfilling a higher-level application role; and architectures
> where the signaling stack can't control/doesn't have visibility onto the
> SSRC selection.
>
> AppID should be applicable to anything using BUNDLE, I think, and
> certainly anything using it with a vaguely Unified-style semantic.  (I
> think it would apply to a "Plan B"-style semantic, as well, which I know
> some people are still advocating for some non-WebRTC contexts; however, I'm
> not positive all the syntax necessary for that is currently complete.)
>
> The difference between AppID and MSID should be most clear in scenarios
> where an m= line group has more than one packet stream (my canonical
> example is a primary stream and a retransmission stream).  In this case,
> the m= line group has one msid attribute, but multiple appid attributes.
>

[Suhas] +1 on the difference be made clear.

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 14 Feb 2014 08:14:32 +0100

On 02/13/2014 11:43 PM, Suhas Nandakumar wrote:
>
>
>
> On Thu, Feb 13, 2014 at 10:09 AM, Jonathan Lennox <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The chairs asked that the authors of the MSID and AppID drafts
>     discuss the relationship between the two documents.
>
>     MediaStreamTracks thread, but folks might not have seen) is that
>     they're solving different problems, and so are non-conflicting.
>
>     MSID provides an identifier for SDP m= lines.  Its primary use
>     case is providing a Javascript-level handle in WebRTC.
>
>     AppID -- which needs a better name, suggestions welcome --
>     provides an indirection label for identifying individual RTP
>     packet streams in SDP, in scenarios where the SSRC is unavailable
>     to the signaling.
>

I am certainly happy with drawing a distinction along these lines, and
let each find its own user base.

> individual RTP packet streams

I would advise against using such a frequently used acronym.
If inventing a new one, what about RTP Packet Stream Correlation Tag -
RPSCT?
I don't think I've encountered that in the IETF yet....

---

From: "Roni Even" <[email-masked]>
Date: Tue, 18 Feb 2014 18:22:58 +0200

Hi,
I agree with Jonathan description about where appId will be used and the
difference from MSID.
I think that a major advantage of appId is not only when the SSRC is not
known in the SDP but it is useful even if can be known in order to define
the SSRC in at the RTP level and not in the SDP level. 

For the SSRC collision case it is simpler to change the SSRC without a need
for re-invite to update the SDP since the appId does not hange but points to
the new SSRC

Roni Even

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Jonathan
> Lennox
> Sent: 13 February, 2014 8:09 PM
> To: mmusic
> Subject: [MMUSIC] MSID and AppID: solving different problems
> 
providing
> a Javascript-level handle in WebRTC.
> 
which
> SSRC is fulfilling a higher-level application role; and architectures
where the
> signaling stack can't control/doesn't have visibility onto the SSRC
selection.
> AppID should be applicable to anything using BUNDLE, I think, and
certainly
> anything using it with a vaguely Unified-style semantic.  (I think it
would apply
> to a "Plan B"-style semantic, as well, which I know some people are still
> advocating for some non-WebRTC contexts; however, I'm not positive all the
> syntax necessary for that is currently complete.)
> 
the
> m= line group has one msid attribute, but multiple appid attributes.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Feb 2014 10:04:18 -0800

> individual RTP packet streams

I was thinking that the really useful feature was the label applied by
the receiver, not the source.  Maybe something like "receiver SSRC ID"
(or "receiver SSRC label").  I think that hits the mark.