[MMUSIC] Requirements for bundling

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

Here are the requirements (desiderata, really) from the latest version
of my draft, draft-worley-sdp-bundle.  No doubt they're not complete.

3.  Desiderata

   This section lists desiderata for the bundle mechanism in SDP.  (I
   use the term "desiderata" -- "things that are desired" -- rather than
   "requirements", because we may discover that we can't optimally
   satisfy all of these criteria at the same time.)  The first section
   lists desiderata that are arise from considering the ways
   applications may wish to bundling.  The second section lists
   desiderata that arise from compatibility with existing Internet
   infrastructure.

3.1.  Feature Desiderata

   DES F1  For each bundle, there is a group of media descriptions which
      describe the application-level RTP sessions.  This specification
      must allow the same granularity of description as when the media
      flows were not multiplexed.  This description includes identifiers
      which connect the media flows with the application and with each
      other.

   This requirement is taken from draft-jennings-mmusic-media-req-00.

   DES F2  For each bundle, there is a media description that describes
      the transport-level RTP session.

   DES F1 and DES F2 do not specify whether the transport-level media
   description may or may not also be one of the application-level media
   descriptions.

   DES F3  There must be a uniform way to deal with new SDP parameters,
      so that newly defined SDP parameters do not require a specific
      updating of the bundling procedures.

   This desideratum is taken from slides-interim-2013-rtcweb-1-10.pdf.

   DES F4  Multiple separate bundles within one SDP must be supported.

   DES F5  Bundles may contain other bundles as constituents.

   Of course, no bundle may directly or indirectly contain itself.  (I
   don't expect any current implementation to implement bundles within
   bundles, but we should design the mechanism to allow this, as some
   day we will likely need it.)

   DES F6  A bundle may contain zero constituents.

   A bundle with no constituents serves no purpose for the transport of
   media, but we are likely to someday need to describe such a bundle.
   (Compare that an SDP m= line is syntactically constrained to specify
   at least one payload type.  When SDP was used only to specify
   multicast sessions, this constraint was common sense.  But once SDP
   offer/answer was invented, when a media description was rejected, the
   natural representation would be an m= line with a zero port and no
   payload types.  But a payload type was syntactically required, so we
   now have to provide at least one token payload type in rejected m=
   lines.)

   DES F7  If an answerer that does understand the bundle mechanism
      processes an offer that contains a bundle, it must be able to (1)
      accept the bundle and selectively accept or reject each
      constituent RTP session within it, (2) reject the bundle as a
      whole, or (3) reject the bundling and selectively accept or reject
      each constituent RTP session as separate RTP sessions.

   Presumably answer (3) resembles that which would be produced by an
   answerer that does not understand the bundle mechanism.  It is a
   lower priority that the answerer can distinguish between accepting
   the bundle while rejecting all of its constituents, and rejecting the
   bundle as a whole.  But those two conditions differ conceptually
   regarding whether any "framing" actions of the bundle are performed.

   DES F8  There must be a reliable way to demultiplex incoming RTP into
      the separate application-level RTP sessions.  Similarly, there
      must be a reliable way to demultiplex the associated RTCP
      information.

   The RTCP information for each media stream is tagged with the SSRC
   about which it reports, and the SSRC is used to correlate the RTCP
   reports with the RTP sessions containing media with the same SSRC.
   So regarding RTCP, this desideratum appears to be straightforward to
   satisfy.

   DES F9  The specification must specify any needed additional
      procedures for handling SSRC collisions between media sources
      within different application-level RTP sessions, as those can now
      collide.

   In the terminology of RFC 3550, the constituent media descriptions
   are now part of one RTP session.

   DES F10  When an offer is constructed, the offerer must not need to
      pre-allocate TURN relays for constituent media descriptions.  When
      both endpoints support bundling, the mechanism must not require
      the offerer to allocate TURN relays for constituent media
      descriptions.

   This desideratum was suggested by Andrew Hutton.

   DES F11  It must be possible to add and remove one way video flows
      within the bundle without requiring an additional offer/answer
      cycle.

   Presumably this can be accomplished as it is now, with a single media
   description carrying multiple video flows that are distinguished only
   by their SSRCs.  This desideratum is taken from slides-interim-2013-
   rtcweb-1-10.pdf.

   DES F12  Bundling must not interfere with ICE usage, and in
      particular, ICE's ability to negotiate both IPv4 and IPv6
      addresses simultaneously.

   This desideratum was suggested by Andrew Hutton.

3.2.  Compatibility Desiderata

   DES C1  In offer/answer usage, an endpoint using the bundle mechanism
      must interwork correctly with an endpoint that does not understand
      the bundle mechanism.

   DES C2  Interworking must continue when SDP endpoints are replaced
      with other endpoints during a sequence of offer/answer exchanges
      (such as happens in 3PCC or call transfers "behind an SBC"),
      including when a supporting endpoint is replaced by a non-
      supporting endpoint or vice-versa.

   SDP features (e.g., codec set and ICE) are generally designed so that
   an offerer offers every facility it is willing to support in the
   current instance.  Thus, if the answerer is a different endpoint than
   the previous answerer, the new answerer will negotiate a compatible
   set of facilities without needing knowledge of its predecessor's SDP.
   The offerer will smoothly transition to the new facilities.  This
   property is required to support 3PCC situations (e.g., RFC 3725 and
   draft-worley-service-example).  This desideratum was suggested by
   Richard Ejzak.

   DES C3  Avoid using media types in m= lines other than audio and
      video unless required for user media, as some SBCs reject SDP that
      uses other media types.

   This desideratum was suggested by Hadriel Kaplan.

   DES C4  Any additional m= lines prescribed by the bundle mechanism
      should be ordered after the constituent m= lines.

   Many devices that have only one audio or video channel accept the
   first m= line with that media type and reject any further ones

   non-DES C5  SBCs generally pass through attributes that they do not
      understand.  SBCs generally pass through codec specifications that
      they do not understand, even if they are configured to transcode
      certain specific codecs.

   This non-desideratum was suggested by Hadriel Kaplan.

   DES C6  After offer/answer processing is finished, if the exchanged
      SDP is examined by a non-supporting SBC, the set of transport
      associations that it sees being specified for media exchange
      should be the set that are actually used for media transfer.

   This is needed because SBCs monitor the packet traffic on the
   transport associations and if no media is seen on one of the
   associations for a significant period of time, the SBC will tear down
   the call.  This desideratum was suggested by Hadriel Kaplan.

   DES C7  In a session description, no endpoint of a transport
      association may be used multiple times.

   Such duplication is not defined by [sdp].  Some SBCs do not support
   such duplication (ultimately, because it was not supported by [RFC
   2327]), and they reject SDP specifying duplicated transport
   association endpoints.  This desideratum was suggested by Cullen
   Jennings.

   DES C8  Offer/answer processing between supporting processors must be
      completed in one exchange.  When interworking between supporting
      and non-supporting processors, it is less desirable but admissible
      that a second offer/answer exchange may be needed to complete
      configuring the multimedia session.

Dale