Re: [rtcweb] #15: Section 4.8: SSRC signaling

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

> From: Martin Thomson <[e-mail]>
> 
> >     Each SSRC is demultiplexed based on an RTCP SDES item that gives
> >     the mapping between the SSRC and the m= line via which it is
> >     presented to the application layer (that is, the constituent m=
> >     line sequence number).
> 
> It's been proposed.  I don't know exactly why it wasn't considered
> worth pursuing.
> 
> Maybe you can ask Peter Thatcher to share his document on demux.  It's
> a reasonable taxonomy of the available options. Better than what I'm
> able to write up in a short time.

What I can find is draft-pthatcher-mmusic-many-sources-00, but it
doesn't seem to describe demultiplexing.

That draft does contain a small error:

   o  With BUNDLE, use of RFC5576 a=ssrc attributes is required in order
      for the recipient to be able to properly demultiplex incoming RTP.
      Payload type isn't sufficient as a demux point, since RTCP packets
      don't contain RTP payload types.  Therefore, this approach
      requires both sides to understand RFC5576, just like the single-m-
      section approach.

a=ssrc attributes are not strictly needed, because RTCP packets
contain SSRC identifiers, and RTP packets contain both SSRC and PT.
So caching the SSRC/PT correspondence seen in the RTP packets allows
the RTCP packets to be assigned to the proper m= lines.

This matters because a=ssrc attributes are problematic; we want to
add, remove, and adjust video flows without additional offer/answer
cycles, which precludes adding or changing a=ssrc attributes in the
SDP to handle the new flow.  (This is requirement 3 in
http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-10.pdf,
"Add/remove one way video flows with minimal chance of glare on
non-legacy apps" and DES F11 in draft-worley-sdp-bundle.)

Dale