Subject: [MMUSIC] Comments on draft-alvestrand-mmusic-msid-01

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Oct 2012 17:05:40 -0400

Harald,

I looked this over, and have a few observations:

Section 2, 1st paragraph

OLD:

    This document extends the Source-Specific Media Attributes framework
    [RFC5576] by adding a new "msid" attribute that can be used with the
    "a=ssrc" SDP attribute.  This new attribute allows endpoints to
    associate RTP media streams that are carried in different RTP
    sessions, as well as allowing application-specific information to the
    association.

The above suggests the mechanism is only for associating media streams 
in *different* sessions. But they can also be in the *same* session. So 
I would suggest:

NEW:

    This document extends the Source-Specific Media Attributes framework
    [RFC5576] by adding a new "msid" attribute that can be used with the
    "a=ssrc" SDP attribute.  This new attribute allows endpoints to
    associate RTP media streams that are carried in the same or
    different RTP sessions, as well as allowing application-specific
    information to the association.

Syntax:

      ; "attribute" is defined in RFC 4566.
      ; This attribute should be used with the ssrc-attr from RFC 5576.
      attribute =/ msid-attr
      msid-attr = "msid:" identifier [ " " appdata ]
      identifier = 1*64 ("0".."9" / "a".."z" / "-")
      appdata = 1*64 ("0".."9" / "a".."z" / "-")

Do you *really* want to allow identifiers like "-----", "---abc--" and 
"0---0--0-0"??? If these seem silly and error prone then the syntax 
could be made more restrictive.

If you *do* want to be this flexible, why not go further, and use 
<token> as defined in 4566 for both <identifier> and <appdata>?

Since it is recommended to generate the identifier via a random number 
generator, then why not define a representation that is a common 
encoding of an integer, such as hex or base64? The examples are 
obviously not generated this way. So maybe RECOMMENDED is too strong for 
use of random numbers. (It was offered as a possibility, but not 
recommended, in the prior version. Why the change?)

Section 3 - Msid-Semantic:

    The ABNF of msid-semantic is:

      attribute =/ msid-semantic-attr
      msid-semantic-attr = "msid-semantic:" " " identifier token
      token = <as defined in RFC 4566>

Above appears broken - there is no separator between identifier and 
token. Presumably you meant:

      attribute =/ msid-semantic-attr
      msid-semantic-attr = "msid-semantic:" " " identifier " " token
      token = <as defined in RFC 4566>

Also, the text isn't clear on the relationship between
a=msid-semantic:
a=ssrc-group:
a=group:

Are these all just *analogous* but independent mechanisms for grouping? 
Or is it intended that these can be used together to group things of all 
these types together?

RFC 5576 makes it clear that ssrc-group and group are analogous but 
independent with independent registries.

I find in the iana considerations section that msid-semantic is reusing 
the "Semantics for the "ssrc-group" SDP Attribute" registry, and 
registers "WMS" in that registry. So apparently one can use WMS with 
a=ssrc-group. That suggests it is intended that can be used together.

BUT, ssrc-group is a media level attribute. That implies that the 
namespace for ssrc-group tokens is independent for each media section in 
the SDP. But msid-semantic is session-wide. Using it would couple the 
namespaces of different media sections.

I don't know the answer here, but it at least needs clarification and 
may require some changes.

Section 4:

This section feels like it belongs in a separate draft. If it were 
non-normative then it might be ok as an example. But it is normative. 
The following clearly is:

    When an SDP description is updated, a specific msid continues to
    refer to the same media stream; an msid value MUST NOT be reused for
    another media stream within a PeerConnection's lifetime.

It isn't clear if that is intended only for WebRTC media streams. 
Hopefully so, since it is in a section scoped that way, and might not be 
desirable for all uses.

Even for this use that limitation is problematic. Anything that requires 
the generation of new SDP in a session to be aware of all the historical 
SDP in that session is problematic. It is easy to get situations 
(transfer, federation) where contributors to the SDP come and go without 
knowledge of history prior to their joining.

(This is already a problem in SDP with the requirement that a payload 
number can never be reused for a different codec within an RTP session. 
It is my impression that this is often violated, usually without problem.)

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 21 Oct 2012 21:54:49 +0200

Thanks for the review!

On 10/15/2012 11:05 PM, Paul Kyzivat wrote:
> in *different* sessions. But they can also be in the *same* session. 
> So I would suggest:
>
> NEW:
>

Thanks, I'll change that. (Needed in the abstract too).

> <token> as defined in 4566 for both <identifier> and <appdata>?

The list of "token" characters is

    token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                          / %x41-5A / %x5E-7E

or !#$%&'*+-./^_`{|}~ in addition to A-Za-z0-9.

Some of these are metacharacters in Javascript.
However, metacharacter exploits was the only reason I could see for 
restricting the syntax - "allows stuff that looks silly" doesn't seem to 
merit extra constraints.
Your mileage may vary; to some degree, it's a matter of taste.

> encoding of an integer, such as hex or base64?
The reason for this particular pick was that I couldn't see a reason to 
disallow either hex or UUIDs.
There's a few characters missing for Base64 (+ and /), so I obviously 
wasn't thinking of Base64 whenI wrote this text - if people want base64, 
we can add them.
> The examples are obviously not generated this way. So maybe 
> RECOMMENDED is too strong for use of random numbers. (It was offered 
> as a possibility, but not recommended, in the prior version. Why the 
> change?)
Because the more I thought about it, the more it seemed that collisions 
were a bad idea, and collisions are more likely for non-random IDs than 
for randomly generated IDs (for reasonable quality random number 
generators).

>      token = <as defined in RFC 4566>
Thanks - I missed that.
> Are these all just *analogous* but independent mechanisms for 
> grouping? Or is it intended that these can be used together to group 
> things of all these types together?
That's because I'm not clear on what it should be.

There's a good reason to say that one can generate an SDP offer with 
both a=msid-semantic and  a=ssrc-group for the same semantic in the same 
offer, because this offers one-round-trip negotiation with both 
endpoints that understand a=msid-semantic and endpoints that only 
understand a=group, but since msid-semantic is able to express the 
semantics of a=ssrc-group, I don't see why a response should reply with 
both ssrc-group and msid-semantic for the same semantic.
> I find in the iana considerations section that msid-semantic is 
> reusing the "Semantics for the "ssrc-group" SDP Attribute" registry, 
> and registers "WMS" in that registry. So apparently one can use WMS 
> with a=ssrc-group. That suggests it is intended that can be used 
> together.
>
> namespace for ssrc-group tokens is independent for each media section 
> in the SDP. But msid-semantic is session-wide. Using it would couple 
> the namespaces of different media sections.
I'm not clear what you want to say here. What namespaces would be 
coupled by msid-semantic?
Since ssrc-group doesn't have tokens (it's just ssrcs), it doesn't seem 
to define a namespace.
> may require some changes.

At least some clarification.
> The following clearly is:
It was the original purpose of the draft - the split into a general 
mechanism and a specific usage was done at the behest of MMUSIC. So yes, 
it's definitely intended to be normative.
> Hopefully so, since it is in a section scoped that way, and might not 
> be desirable for all uses.
The limitation is defined in terms of WebRTC MediaStreams, not RTP media 
streams, so yes. I'll make sure to make the casing right, and add the 
qualifier.
>
> Even for this use that limitation is problematic. Anything that 
> requires the generation of new SDP in a session to be aware of all the 
> historical SDP in that session is problematic. It is easy to get 
> situations (transfer, federation) where contributors to the SDP come 
> and go without knowledge of history prior to their joining.

I don't think that it requires one to be aware of history in practice. 
It just requires that you either record history, or that the identifier 
contains enough randomness, and that the random number generator is run 
once for every new MediaStream.

> number can never be reused for a different codec within an RTP 
> session. It is my impression that this is often violated, usually 
> without problem.)

I don't know the rules for that - can one renegotiate the codec 
parameters for a payload type, or are those too supposed to be locked down?

Of course this is much more problematic in multiparty sessions than in 
offer/answer negotiated sessions....
>
>     Thanks,
>     Paul
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2012 15:55:39 -0400

On 10/21/12 3:54 PM, Harald Alvestrand wrote:
...
> for randomly generated IDs (for reasonable quality random number

I don't understand what you are saying overall on the above.
ISTM that the draft should pick a direction. Either:

- mandate use of a random number. Then specify an encoding for it.
   I don't much care what encoding, but it would be helpful to
   specify one.

OR

- be flexible, allowing but not mandating use of a random number.
   Then perhaps be more flexible - perhaps go with <token>.

...

> That's because I'm not clear on what it should be.

:-)
Then its good to have a discussion about it.

> both ssrc-group and msid-semantic for the same semantic.

Reusing the ssid-group semantic registry for msid-semantic means that 
values defined for msid-semantic will be eligible for use with 
ssid-group. That might be confusing.

It's not clear to me that there is any meaningful overlap between the 
semantics useful for ssrc-group and those useful for msid-semantic. This 
needs to be analyzed from two perspectives:
- can a semantic defined for ssid-group be useful for msid-semantic?
- can a semantic defined for msid-semantic be useful for ssid-group?

I'm not seeing how the 'WMS' semantic would be useful with ssid-group.

But it is perhaps possible that 'FID' and 'FEC' *might* be useful with 
msid-group, to tie together RTP streams from different RTP sessions.

I *do* see how semantics from a=group might be useful with 
msid-semantics. E.g. 'LS', which is used as an example in section 3 of 
the msid-01 draft. But since LS is defined in the registry for a=group, 
and not in the registry for ssid-group, that isn't a valid example.

The logic (in 5576) for establishing a new registry for ssid-group 
(rather than reusing the one from 'group') was that meaningful semantics 
are different when grouping streams in a single session than when 
grouping together different sessions. Since msid-group is largely about 
grouping streams from separate sessions, maybe it would make more sense 
to share a registry with group, rather than with ssid-group. Or maybe 
all three registries should be disjoint.

> Since ssrc-group doesn't have tokens (it's just ssrcs), it doesn't seem

Sorry. Just muddled thinking on my part. There is no shared namespace 
except for the "semantic" namespace.

> once for every new MediaStream.

*If* the IDs must be random then I have no complaint.

Maintaining history can be a problem if one of the players is replaced 
by another that was never privy to the prior history. This may not come 
up with native RTCWEB, but it can arise fairly easily in SIP.

> parameters for a payload type, or are those too supposed to be locked down?

This is a little bit off subject for this discussion thread, but for 
completeness:

 From 8.3.2 of 3264:

    ... However, in the
    case of RTP, the mapping from a particular dynamic payload type
    number to a particular codec within that media stream MUST NOT change
    for the duration of a session. For example, if A generates an offer
    with G.711 assigned to dynamic payload type number 46, payload type
    number 46 MUST refer to G.711 from that point forward in any offers
    or answers for that media stream within the session. However, it is
    acceptable for multiple payload type numbers to be mapped to the same
    codec, so that an updated offer could also use payload type number 72
    for G.711.

         The mappings need to remain fixed for the duration of the
         session because of the loose synchronization between
         signaling exchanges of SDP and the media stream.

According to the words written it may be ok to renegotiate parameters 
other than the codec. But the reason given for this would seem to apply 
for at least some other parameters.

The logic given also doesn't really justify imposing this "for the 
duration of the session", if we interpret "session" here to mean the 
communications session established with SDP, not the RTP session. (I 
think that is the proper interpretation.) It would be more justifiable 
in the context of an RTP session.

In practice it will typically be sufficient to abstain from reusing the 
value for a brief interval around a new O/A. After that it should be 
possible to retire values that weren't mentioned in the most recent O/A 
and make them available for reuse in the future.

ISTM *that* would also be sufficient for msid IDs. (I realize it is 
harder to formalize than just saying they can never be reused.)

> offer/answer negotiated sessions....

It doesn't require an *obviously* multiparty session. It can be a 
problem when a an intermediary performs a transfer on one side while 
"hiding" it from the other side. And this is pretty common in SIP.

	Thanks,
	Paul