[MMUSIC] Thoughts on bundling mechanisms

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

After reading
    draft-alvestrand-one-rtp-01
    draft-holmberg-mmusic-sdp-mmt-negotiation-00
    draft-ietf-mmusic-sdp-bundle-negotiation-00
    draft-nandakumar-rtcweb-sdp-00
here are my thoughts on bundling:

1. Concept

Overall, we need to fix the concept that a bundle is a container for a
group of media streams, media streams as they are specified by m=
lines.  We need to be able to bundle multiple media streams in a way
that allows them to be demultiplexed accurately, even if different
streams share the same media types, codecs, etc.

In this regard, the transport protocol, transport ports, encryption
specifications, ICE specifications, and (less obviously) payload type
numbers are considered to be part of the transport mechanism and not
part of the media stream properties.

The m= line for a bundle should have all the "transport" attribues
needed for the bundle, while the m= lines for the constituent media
streams would have the attributes that describe the media stream
itself.

(This distinction gets undermined if we use payload types to
demultiplex the media streams, as the bundle m= line has to list the
payload types, and thus probably the codec names and parameters, which
are really constituent-level information.  One solution would be to
require that if a bundle payload type is demultiplexed to a particular
m= line, then that m= line must have the same payload type with the
same codec.  Indeed, there's no particular reason for the bundle m=
line to have a=fmtp attributes at all, though the m= line should
probably list all the payload types the bundle RTP is going to use.)

2. Configuration of m= lines

There needs to be a fallback mechanism if the answerer does not
understand the bundling mechanism.
draft-ietf-mmusic-sdp-bundle-negotiation (BUNDLE) specifies that a
bundle of m= lines all specify the same port number.  That is OK if
the answerer understands BUNDLE, but if the answerer does not
understand BUNDLE, the SDP is malformed (per RFC 4566 section 5.14),
and the answerer may reject it as such.  Because of this, we need to
adopt the mechanism of draft-alvestrand-one-rtp (TOGETHER), where each
m= line in the offer has a distinct port number.

There also needs to be a way for the answerer to individually accept
or reject media streams within the bundle, that is, the m= lines
within the bundle.  TOGETHER does not accomplish that, because the
first m= line in the bundle is the one used to send/receive media (if
the bundle is accepted), and so it cannot be rejected.  As
draft-alvestrand-one-rtp says

   The answerer cannot refuse the first m= section and establish the
   call.  [[NOTE IN DRAFT: This could be relaxed by allowing it when ICE
   is in use, or saying that the first non-zero port number is used.
   Both lead to nonobvious edge cases.  Is the extra complexity worth
   it?]]

draft-holmberg-mmusic-sdp-mmt-negotiation (MMT) avoids this problem by
associating with each bundle a "master" m= line with media type
"anymedia".  If the bundle is accepted, this m= line provides the
transport information.  If the bundle is rejected, then the answerer
accepts or rejects each constituent m= line separately, and that m=
lines attributes determine the transport mechanism.

However, MMT needs to be updated to match the concept that the
anymedia RTP stream multiplexes what would be the RTP streams of one
or more constituent media streams.  Currently, it assumes that
identifying the media type of an incoming RTP packet is sufficient
demultiplexing.  As a consequence of this, it needs to be modified so
that if the answerer accepts the MTT bundle (and thus, the anymedia m=
line), it still must accept or reject each constituent m= line
individually.

3. Demultiplexing RTP

MMT envisions that the media data is demultiplexed based on the
payload types:  The m=anymedia description contains a set of a=mmttype
attributes that (I think should) provide the mapping from the payload
types to the mid values of the constituent m= lines.  (The codec for
each payload type is provided by a=fmtp attributes of the m=anymedia
description as normal.)

Note that this does not allow recovery of the payload types that would
have been used for that codec and m= line (if multiple payload types
for that m= line have the same codec).  But we assume that payload
types are a transport matter and are of no interest to the higher
layers of media processing.

But perhaps instead, we should require that there be a matching
payload type for the constituent m= line and use its a=fmtp
attribute.  That allows us to not duplicate any codec specifications
from the constituent m= lines into the m=anymedia line, and does allow
recovering the "original" payload types.

4. RTCP

My knowledge of RTCP is very thin.  But it's clear that incoming RTCP
over the bundle transport must be demultiplexable to the point that we
can separate which RTCP information is applicable to which constituent
media stream.  My understanding is that RTCP information is identified
by the SSRC of the media source it is reporting on, and that it is
paired with the right media stream by examining the SSRC value in the
RTP packet headers.  If so, demultiplexing RTCP requires no new
protocol facilities.

In regard to bandwidth consumption, I assume that the bundle's RTCP
stream is essentially the union of the RTCP streams (or rather, the
RCTP packets thereof, which are packed into the transport-level RTCP
packets) that would be generated for each constituent m= line.  In
particular, the frequency of the RTCP packets for a particular media
stream is scaled to the needs of that media stream, rather than there
being RTCP reports at same frequency for all media streams.  Thus, as
long as the RTCP reports on each media stream are less than 5% of the
RTP bandwidth for that media stream, the aggregate RTCP bandwidth is
less then 5% of the aggregate RTP bandwidth.

5. Examples

Incorporating these suggestions into
draft-holmberg-mmusic-sdp-mmt-negotiation, I get this example:

   SDP Offer (MMT offered)

       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=mmtype:foo 0 8 97
       a=mmtype:bar 31 32

   SDP Answer (MMT accepted, including both constituent streams)

       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=mmtype:foo 0
       a=mmtype:bar 32

   SDP Answer (MMT not accepted, but both constituent streams accepted)

       v=0
       o=bob 2808844564 2808844564 IN IP4 host.biloxi.com
       s=
       c=IN IP4 host.biloxi.com
       t=0 0
       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
       a=mid:zoe
       [The a=mid attributes may be missing if the answerer does not
       understand SDP grouping.]

   SDP Offer with ICE (multiplexed media types offered)

       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
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
       m=video 20000 RTP/AVP 31 32
       a=mid:bar
       b=AS:1000
       a=rtpmap:31 H261/90000
       a=rtpmap:32 MPV/90000
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 20000 typ host
       m=anymedia 30000 RTP/AVP 0 8 97 31 32
       a=mid:zoe
       a=mmtype:foo 0 8 97
       a=mmtype:bar 31 32
       a=candidate:1 1 UDP 1694498815 host.atlanta.com 30000 typ host

Dale