Re: [MMUSIC] Thoughts on bundling mechanisms

[Harald Alvestrand <[e-mail]>]

On 02/02/2013 12:38 AM, Dale R. Worley wrote:
> 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 is an interesting concept - if I understand you correctly, you say 
that instead of having an m-line describe one or more media streams + a 
set of transport attributes, you have two kinds of m-lines, one of which 
describes transport attributes and the other one of which specifies 
media information.

This is a new concept - I think it would be an interesting evolution of 
SDP - but I have problems seeing how to make any kind of one-exchange 
compatibility mode function with this model. I may be misunderstanding 
your suggestion.



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

I think we all agree that multiplexing different media streams using 
payload type is a horrible idea, and nobody should do that.

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

I disagree with that characterization. All of MMT, BUNDLE and TOGETHER 
agree that demultiplexing is based on SSRC. The payload type tells you 
what type the payload is.

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

I don't understand this sentence.
The payload type is "recovered" by looking at the 7-bit field called 
"payload type" in the RTP header of each RTP packet. It's hardly a 
transport matter at all.

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

This seems to indicate that zoe "incorporates by reference" the foo and 
bar m-lines.
A better name in this case might be "m=transport" rather than "m=anymedia".

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

Query: Are you making the port number 1 in the m=audio and m=video lines 
carry special meaning?

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

Based on this offer, I don't quite see what this offer buys you above 
the MMT proposal.