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

[Paul Kyzivat <[e-mail]>]

On 10/21/12 3:54 PM, Harald Alvestrand wrote:
...
>> 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>?
>
> 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.
>
>> 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 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).

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>.

...

>> 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?
> That's because I'm not clear on what it should be.

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

> 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.

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.

>> 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'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.

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

>> 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:
> 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.
>>
>>    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.
> 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.

*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.

>> (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.)
>
> 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?

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.)

> Of course this is much more problematic in multiparty sessions than in
> 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