[MMUSIC] Comments on draft-ietf-mmusic-msid-08

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed draft-ietf-mmusic-msid-08 and have some comments.

1. Section 3: ABNF:

I think usage of "  " for a space is easy to result in errors, and
considering that the ABNF in section 2 uses SP I think this one can also
use SP for space.

OLD:
     msid-semantic-value = msid-semantic msid-list
     msid-semantic = token ; see RFC 4566
     msid-list = *(" " msid-id) / " *"

NEW:

     msid-semantic-value = msid-semantic msid-list
     msid-semantic = token ; see RFC 4566
     msid-list = *(SP msid-id) / SP "*"

2. Section 3: ABNF
Considering how good you have on limiting the length of the MSID and
MSID appdata to 64 characters, shouldn't the semtantics token also be
limited?

I could see one change
OLD:
    msid-semantic = token ; see RFC 4566

NEW:
    msid-semantic = 1*64token-char ; see RFC 4566

3. Section 4:

This section fails to discuss a=msid completely.

4. Section 4:

What are the rules for directionality for the two attributes? Is that
given by the semantics? The issue I have is that I am not certain that
if the identifier and application date for an MSID is limited in scope
to the offer or answer only, and thus only label the media description,
or if it actually are depending on direction. Thus, having different
interpretation depending on if the media description is a sendrecv,
sendonly, recvonly?

To me it appears reasonable that it is actually semantics defined,
otherwise any future user of this mechanism will run into the issue that
it is the wrong direction. Because I can clearly see that some have a
need for something that applies to the receiving direction whiles other
need to work with the send direction.

I note that the offer for anything in the sending direction is actually
making a shot in the dark. The offerer can't know what the answer will
say and if that is compatible with the offered MSID-semantics.

5. Section 5.
"  The value of the "identifier" field in the msid consists of the "id"
   attribute of a MediaStream, as defined in its WebIDL specification.

   The value of the "appdata" field in the msid consists of the "id"
   attribute of a MediaStreamTrack, as defined in its WebIDL
   specification."

First, it is not clear what WebIDL specification is, missing reference.

However, the point I like to make it is in relation to the previous
issue. To my understanding the MediaStream and MediaStreamTrack id is
generated on the sender side, thus the values in this case are for the
send direction. Thus, it only makes sense to add them for media
descriptions where directionality is sendrecv or sendonly from the point
of the agent who is generating the SDP to send, be it an offer or answer.

6. Section 5.1:

   Entities that do not use the WMS semantic will not send "msid-
   semantic:WMS".  This means that there will be some incoming RTP
   packets that the recipient has no predefined MediaStream id value
   for.

I think this needs to state the assumption that the SDP is interpreted
in a context where one expect to receive WMS semantics. If one does not
expect I don't see the point in following these and applying them.

7. Section 5.1:
  "Handling will depend on whether or not the msid-semantic:WMS
   attribute is present."

Is present where, in the Offer or Answer? Is there actually a difference
here depending of if this is in the answer or offer?
If it is answer to an offer that included WMS semantics, then it is
clearer that you are in a SDP session context where WMS is expected.

I wonder if we will run into issues around this when we get "smarter"
gateways that attempt to provide a view that the endpoint actually is
closer to a WebRTC browser than not.

8. Section 5.2:

Should there be an actual discussion of what conclusions one can draw
from actually seeing the semantics in both offer and answer. This is not
without meaning?

Also, is there a point of allowing declaration of the semantics even if
one has no msid identifiers to group, simply for capability declaration
or indicate desire to use?


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------