Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-00

From: [email-masked] (Dale R. Worley)
Date: Fri, 1 Feb 2013 18:38:05 -0500 (EST)

general

I think the concept is that the various media streams are
demultiplexed out of the common RTP scheme by the fact that each
payload type (codec number) appears in at most one m= line of the
bundle.  (If so, the payload type values on each m= line must be
distinct, not just the *dynamic* payload type values.  section 7.2)
But that isn't stated explicitly anywhere.  In any case, the method
for demultiplexing the bundle should be stated explicitly.

Also, how the RTCP reports are to be demultiplexed needs to be made
explicit.  (Though I suspect that is via SSRCs.)

If one or more of the m= lines specifies encryption, how is encryption
coordinated between the various media streams?

What is the fallback if the offerer uses BUNDLE but the answerer does
not understand it?  RFC 4566 says that the use of multiple m= lines
with the same address/port is undefined, which means that a
non-understanding the answerer is allowed to reject the offer as
malformed.

section 1

"5-tuple" should be defined

   the group will share a single port number value

The group will also share a single address, so it would be clearer to
say "share a single address and port value".
Or you could phrase it as simply "share a single port".  But saying "a
single port number value" suggests that the addresses might be
different even though the port numbers are the same.

   there is no grouping defined by such means

I assume this means that sharing the port number does not imply
grouping.  Better to phrase this "sharing a port number does not imply
grouping".

section 6.1

   assign SDP media-
   level 'mid' attribute values to each "m=" line associated with the
   "BUNDLE" group.

'mid' attributes are required for all the m= lines.  RFC 5888 section 6

   NOTE: If an entity wants to disable specific media ("m=" line)
   associated with a "BUNDLE" group, it will use a zero port number
   value for the "m=" line associated with the media.

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

section 6.2

   If the SDP Answererer 

should be "Answerer"

   If the SDP Answererer indicates that it will not use bundled media,
   the SDP Offerer will still use the single port number value for each
   "m= line" associated with the offered "BUNDLE" group, and it will
-------------------------------------------------------------^^
   normally be able to separate each individual media.

should probably be specified as "the Offerer"

   The default
   mechanism for separating media received on a single IP address and
   port doing this is by using a 5-tuple based mapping for each
   individual media.

This would be clearer if it was phrased "The default mechanism for
separating media received on a single IP address and port is by using
the sending address/port to identify each media stream."  Although the
possibility of this requires symmetric media, which is very common,
but not required by RFC 326[1-5].  What do we do if symmetric media isn't
in use?

   If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has
----------------------------------------------^
   reasons to believe that the rejection is due to the usage of a single

I think you intended to insert "is rejected" here.

section 6.2 says:

   If the SDP Offerer is aware of the Synchronization
   Source (SSRC) [RFC3550] values that the SDP Answerer will use in the
   media it sends, and the SSRC values will be unique for each media,
   the SDP Offerer can separate media based on the SSRC values.

but section 7.2 says:

   When a single RTP Session is used, media associated with all "m="
   lines part of a bundle group share a single SSRC [RFC3550] numbering
   space.

Is multiple SSRC supported or not?

Or is the intention that the SSRC values have to be different from
each other?  Sometimes that is the implication of "sharing a space".
But by their very nature (RFC 3550 section 8), all SSRCs are from a
single numbering space of unsigned 32-bit integers.

section 7.2

   If transmission of multiple media types are done
   with time overlap RTP and RTCP fails to function.

I don't understand this sentence.  I suspect some words are missing.

Dale