[MMUSIC] Comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00

[[e-mail] (Dale R. Worley)]

generally

Conceptually, this draft looks on the task as being:  we either
establish a set of media streams defined by a set of m= lines, or we
establish a RTP stream that contains multiple media types.  I think
this is slightly incorrect, the MMT RTP stream should be seen as a
container that encapsulates several media streams -- the anymedia m=
line describes the container and its properties, and the constituent
m= lines describe the constituent media streams.  (And it is possible
that two constituent media streams have the same media type -- one can
easily have more than one audio or video stream in a session.)

Within that change, an answer that accepts the MMT m= line should be
allowed to also accept/reject the constituent m= lines, to indicate
whether or not it wants to process those particular media streams
within the bundle.  (The port numbers for the constituent m= lines in
the answer would be dummies, only significant as to whether they are
zero or not, just as the port numbers for the constituent m= lines in
the offer become dummies if the MMT is accepted.)

abstract

"5-tuple" should be defined; it is not commonly used in RFCs.

section 4

Is there any reason to restrict MMT from being used in non-O/A
situations?  Of course, there would have to be out-of-band knowledge
that the interpreter of the SDP understands MMT, but out-of-band
knowledge (e.g., of the media types and codecs supported) is required
in non-O/A situations already.

section 5.2.1

   A "MMT" group MUST contain a "anymedia" SDP Media Description, and at
------------------------------^
should be "exactly one"
   least one SDP Media Description for a specific SDP Media Type (audio,
   video, etc).

   From a "MMT" group the SDP
   Answerer [RFC3264] will accept either the SDP Media Descriptions for
   the specific SDP Media Types, or the "anymedia" SDP Media
   Description.

This doesn't allow the answerer to reject all of the media in the
group.  A more complete phrasing:

   From a "MMT" group, the SDP
   Answerer [RFC3264] will either (1) accept the "anymedia" SDP Media
   Description and reject the specific SDP media types, (2) reject the
   "anymedia" SDP Media Description and accept some or all of the
   specific SDP media types, or (3) reject both the "anymedia" SDP Media
   Description and the specific SDP media types (to reject all the
   media streams in any form).

However, that would change if the answerer was allowed to
accept/reject specific media streams even when they were bundled into
the anymedia stream.

section 5.2.2.1

   1) Include a "anymedia" SDP Media Description; and
--------------^

should be "exactly one"

section 5.2.2.2

   2) Reject the "anymedia" SDP Media Description, and accept some or
   all of the other SDP Media Descriptions associated with the MMT
   group.

But the answerer must be allowed to reject *both* the anymedia m= line
and all of the contained m= lines (if it doesn't like any of the media
streams involved).  So it would be easier to specify:

      When an SDP Answerer generates an SDP Answer, for each "MMT" group
      in the associated SDP Offer, if it accepts the "anymedia" SDP Media
      Description, it MUST reject all of the other SDP Media Descriptions
      associated with the MMT group.

Within this dichotomy, it would be useful to spell out the
consequences for the a=group:MMT line, viz.:

      1) [...]  Consequently, the mid values of the rejected lines are
      removed from the a=group:MMT line in the answer. Or,

      2) [...]  Consequently, the a=group:MMT line is removed from the
      answer.

However, that would change if the answerer was allowed to
accept/reject specific media streams even when they were bundled into
the anymedia stream.

   NOTE: As described in [RFC3264], an SDP Media Description can be
-------------------------------------------------------------^^^^^^
This probably should be "is", as there is no other way to reject a
media description.
   rejected by setting the port value of the associated m- line to zero
   in the SDP Answer.

... and remove that m= line's mid value from the group attribute.
RFC 5888 section 9.2

section 6.1

   It
   allows, if both endpoints support the mechanism, multiple media typex
   to be multiplexed on a single 5-tuple.

More exactly stated, it allows multiple media *streams* to be
multiplexed on a single 5-tuple.  (In some cases, all of the streams
may have the same media *type*, but we still want to be able to
distinguish them.)

   [...] the SDP mmtype
   attribute will be used to map each PT to a specific media type (e.g.
   audio, video, etc).

ditto

   In addition, as it might not always be possible to
   retreive the media type from the "rtpmap" SDP Attribute value, [...]
---^^^^^^^^

I think "determine" is better here.

section 6.3

   NOTE: Additional extensions are needed in order to specify SDP
   Attribute values for individual media types, or individual media
   sources, associated with the "anymedia" SDP Media Description.

Perhaps the attributes given on the constituent m= lines would specify
the attributes for the constituent media streams.

Alternatively, we could define:

      a=mmtattr:<mid-value>:<attribute>:<value>

to provide "a=<attribute>:<value>" for the constituent media stream
identified by "a=mid:<mid-value>".

section 7

If mmtype is to properly demultiplex received RTP, it has to specify
which of the constituent m= lines that particular PT is mapped to --
just knowing the media type and codec name is not necessarily
sufficient, since more than one constituent m= line use a single
codec.

Also, how is RTCP to be demultiplexed?  (Probably throught SSRCs.)

section 7.2

   a=mmtype: format media

Presumably the space after ":" is a typo.  (Given the syntax rules of
SDP, a space appearing in that location is significant.)

A better syntax would be:

      a=mmtype:<format> <mid> <media>

That would specify the mid value of the constituent media stream.  But
of course, once we know the mid value, we can determine the media type
from the corresponding m= line.  Which would suggest a syntax like:

      a=mmtype:<format> <mid>

Or all the formats for a single mid could be specified together:

      a=mmtype:<mid> <format> <format> ...

It would be useful to mention here that the format number in the
anymedia m= line does not have to be the same as the format number in
the constituent m= line for the same codec, but that the codec does
have to appear in the constituent m= line.  (Or do we wish to require
that the format numbers be the same, for sanity's sake?)

section 9

   SDP Answer (multiplexed media types accepted)
       [...]
       a=group:MMT foo bar

This is backwards; it must be "a=group:MMT zoe" based on RFC 5888
section 9.2.  (Though I'm proposing to change what this attribute
value would be; see below.)

   SDP Answer (multiplexed media types not accepted)
       [...]
       a=group:MMT foo bar

This attribute is incorrect, as the group does not contain one m= line
for anymedia.  This attribute should be omitted.

Incorporating the above suggestions into the examples (changes
indicated by ">"), the offer becomes:

       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
       s=
       c=IN IP4 host.atlanta.com
       t=0 0
       a=group:MMT foo bar zoe
       m=audio 10000 RTP/AVP 0 8 97
       a=mid:foo
       b=AS:200
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       m=video 20000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       m=anymedia 30000 RTP/AVP 0 8 97 31 32
       a=mid:zoe
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:97 iLBC/8000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
>      a=mmtype:foo 0 8 97
>      a=mmtype:bar 31 32

The answer accepting the MMT group (and both constituent streams)
becomes:

       v=0
       o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
       s=
       c=IN IP4 host.biloxi.com
       t=0 0
>      a=group:MMT foo bar zoe
>      m=audio 1 RTP/AVP 0
       a=mid:foo
       a=rtpmap:0 PCMU/8000
>      m=video 1 RTP/AVP 32
       a=mid:bar
       a=rtpmap:32 MPV/90000
       m=anymedia 60000 RTP/AVP 0 32
       a=mid:zoe
       a=rtpmap:0 PCMU/8000
       a=rtpmap:32 MPV/90000
>      a=mmtype:foo 0
>      a=mmtype:bar 32

The answer rejecting the MMT group (but accepting both constituent
streams independently) becomes:

       v=0
       o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
       s=
       c=IN IP4 host.biloxi.com
       t=0 0
>      [a=group:MMT omitted]
       m=audio 40000 RTP/AVP 0
       a=mid:foo
       a=rtpmap:0 PCMU/8000
       m=video 50000 RTP/AVP 32
       a=mid:bar
       a=rtpmap:32 MPV/90000
       m=anymedia 0 RTP/AVP 0 32
       a=mid:zoe
       [The a=mid attributes may be missing if the answerer does not
       understand SDP grouping.]

Dale