[MMUSIC] How to offer a constituent media description

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

There are a lot of fussy details about how to offer a constituent
media description.  I've counted six different methods so far.  I've
written up an analysis of the pros and cons of the various methods.
The least troublesome methods (IMHO) are to offer a real address and
unique, non-zero port, with the offerer's choice of whether or not to
provide TURN candidates.  (Offering TURN candidates requires
preallocating TURN relays for the constituents which will not be
needed if the answerer supports bundling; not offering TURN candidates
requires an SDP update to communicate with a non-supporting answerer.)

Following is the text version of the comparison.  The HTML version is
accessible at
https://svn.resiprocate.org/rep/ietf-drafts/worley/draft-worley-sdp-bundle-04a.html#rfc.section.7.10
(You can also use the http: form of that URL, but for some reason, the
response won't be tagged as text/html.)

Dale


7.10.  How the Constituent MDs Are Offered

   There are a number of alternative ways that the offerer can configure
   the constituent media descriptions.

   +------------+------+--------+--------+---------+---------+---------+
   | Method     | 1    | 2      | 3      | 4       | 5       | 6       |
   +------------+------+--------+--------+---------+---------+---------+
   | Offered    | null | null   | real   | real    | real    | real    |
   | address    |      |        |        |         |         |         |
   |            |      |        |        |         |         |         |
   | Offered    | zero | non-   | zero   | non-    | non-    | non-    |
   | port       |      | zero   |        | zero,   | zero,   | zero,   |
   |            |      |        |        | unique  | unique  | shared  |
   |            |      |        |        |         |         |         |
   | TURN candi | no   | no     | no     | no      | yes     | yes     |
   | dates?     |      |        |        |         |         |         |
   |            |      |        |        |         |         |         |
   | Supporting | yes  | yes    | yes    | yes     | yes     | yes     |
   | answerer   |      |        |        |         |         |         |
   | accepts?   |      |        |        |         |         |         |
   |            |      |        |        |         |         |         |
   | Update     | no   | no     | possib | yes     | yes     | no      |
   | needed for |      |        | ly     |         |         |         |
   | supporting |      |        |        |         |         |         |
   | answerer?  |      |        |        |         |         |         |
   |            |      |        |        |         |         |         |
   | Non-       | no   | probab | no     | yes     | yes     | yes     |
   | supporting |      | ly     |        |         |         |         |
   | answerer   |      |        |        |         |         |         |
   | accepts?   |      |        |        |         |         |         |
   |            |      |        |        |         |         |         |
   | Update     | yes  | yes    | yes    | yes     | no      | no      |
   | needed for |      |        |        |         |         |         |
   | non-       |      |        |        |         |         |         |
   | supporting |      |        |        |         |         |         |
   | answerer?  |      |        |        |         |         |         |
   |            |      |        |        |         |         |         |
   | Disadvanta | ACE  | CD     | ABCE   | BC      | BG      | BFG     |
   | ges        |      |        |        |         |         |         |
   +------------+------+--------+--------+---------+---------+---------+


   Offered address  This is the address offered for the MD.  There are
      two choices, a null address (0.0.0.0 for IPv4 or "invalid."  for
      IPv6 or mixed IPv4/IPv6) or a real address of the offerer.

   Offered port  This is the port that is offered.  It can be either
      non-zero or zero (which indicates a stream that is not being
      offered).  If the offered port is non-zero and the offered address
      is real, the port can be either unique, or shared with the other
      media descriptions in the bundle.

   TURN candidates?  If the offered address is real, are TURN candidates
      for the address provided (if they are needed)?

   Supporting answerer accepts?  If the answerer supports bundling, does
      it accept this media description?  We assume the answer is Yes, so
      that acceptance of the constituent media descriptions can be
      signaled to the offerer.

   Update needed for supporting answerer?  Is an SDP update needed to
      complete session setup if the answerer supports bundling?  If an
      update is needed, it is needed to inform intermediaries that there
      will be no media sent based on the connection information in this
      media description; the update is not needed to establish
      communications and does not delay the application.

   Non-supporting answerer accepts?  If the answerer does not support
      bundling, does it accept this media description (without a further
      update)?

   Update needed for non-supporting answerer?  Is an SDP update needed
      to complete session setup if the answerer does not support
      bundling?  If an update is needed, in all cases, it is needed to
      establish communication.

   Flaws  The disadvantages of each alternative:

      A     Media descriptions that are rejected (have zero ports) are
            not allowed to be members of a group (in the
            offer).[RFC5888]

      B     An SDP update is needed for a supporting answerer to prevent
            intermediaries from timing out the multimedia session.

      C     An SDP update is needed for a non-supporting answerer to
            establish communications.

      D     Although a media description with a non-zero port but a null
            address is formally offered (although shown as on-hold via
            the old method), it is possible that the answerer will not
            consider it to be offered and many not accept it even if it
            otherwise wood.

      E     If the offered port is zero, the media description is not
            formally offered and the answerer should not accept it.

      F     SDP offers with multiple media descriptions that use the
            same port number (for the same real address) may be rejected
            by intermediaries.

      G     A TURN relay must be allocated for the constituent media
            description before the offer is sent.

   In my estimation, the worst disadvantages are A (zero port in offer),
   E (acceptance of offer with zero port), and F (duplicate port
   numbers), because they involve violations of [RFC4566] or are known
   to trigger limitations of large numbers of intermediate devices.
   Disadvantage D (offering a MD with a null address) is nearly as
   severe, as we expect it to cause undesired behavior in many non-
   supporting answerers.  Disadvantages C (update needed to communicate
   with non-supporting answerer) and G (TURN relay must be preallocated)
   are moderate, and disadvantage B (updated needed to prevent
   intermediaries from timing out) is the least severe (because it never
   delays the establishment of communication).

   Applying these priorities to the possible solutions, methods 4 and 5
   (offer real address, non-zero unique port, with/without TURN
   candidates) are tied for the best choices, with the choice made based
   on the relative importance of minimizing preallocation of TURN relays
   compared to quickly establishing communication with non-supporting
   answerers.