[MMUSIC] rfc8445, rfc8839 and multiple m= sections

[Michael Jones <[e-mail]>]

Quote from https://tools.ietf.org/html/rfc8839#section-5.1

   <component-id>:  is a positive integer between 1 and 256 (inclusive)

      that identifies the specific component of the data stream for

      which this is a candidate.  It MUST start at 1 and MUST increment

      by 1 for each component of a particular candidate.  For data

      streams based on RTP, candidates for the actual RTP media MUST

      have a component ID of 1, and candidates for RTCP MUST have a

      component ID of 2.  See Section 13 of [RFC8445]<https://tools.ietf.org/html/rfc8445#section-13> for additional

      discussion on extending ICE to new data streams.

And quote from https://tools.ietf.org/html/rfc8839#section-4.3.1
   When an offerer generates the initial offer, in each "m=" section it
   MUST include SDP "candidate" attributes for each available candidate
   associated with the "m=" section.  In addition, the offerer MUST
   include an SDP "ice-ufrag" attribute, an SDP "ice-pwd" attribute, and
   an SDP "ice-options" attribute with an "ice2" attribute value in the
   offer.  If the offerer is a full ICE implementation, it SHOULD
   include an "ice-pacing" attribute in the offer (if not included, the
   default value will apply).  A lite ICE implementation MUST NOT
   include the "ice-pacing" attribute in the offer (as it will not
   perform connectivity checks).

The two quotes above indicate that an ICE implementation which supports multiple m= sections where each m= section carries RTP / RTCP traffic in the SDP exchange must have the component ID set to 1 and 2 for RTP and RTCP respectively in each m= section.

Further, it's my belief (please correct me if I am mistaken) that each m= section must be negotiated separately. Specifically, m= section 1, component 1, should not attempt to conduct connectivity checks against candidates from m= section 2, component 1.

If that's the case, why does rfc8445 make few, if any, statements on how to handle checklists for multiple media/data streams simultaneously? Maybe more generally, rfc8445 doesn't even define what a media/data stream is, "data stream" is in rfc8445 104 times, and "media stream" 1 time.

Quote from https://tools.ietf.org/html/rfc8445#section-2.4

   Once ICE is concluded, it can be restarted at any time for one or all

   of the data streams by either ICE agent.  This is done by sending

   updated candidate information indicating a restart.

With that quote, and the text of https://tools.ietf.org/html/rfc8445#section-2.3 , it's clear that rfc8445 an ice implementation to be capable of handling multiple independent data streams, each with their own set of components.

Quote from https://tools.ietf.org/html/rfc8445#section-5.1.2

   The prioritization process results in the assignment of a priority to

   each candidate.  Each candidate for a data stream MUST have a unique

   priority that MUST be a positive integer between 1 and (2**31 - 1).

   This priority will be used by ICE to determine the order of the

   connectivity checks and the relative preference for candidates.

   Higher-priority values give more priority over lower values.

Is there any value in specifying each candidate "for a data stream"? Wouldn't saying "each candidate" ? Or is the intention of this clarification to specifically allow candidates from different data streams to have the same priority?

Am I just reading right past where the appropriate multi-datastream behavior is defined? That's certainly possible. I've been reading these rfcs for about 6 hours straight, so I might be staring right at the procedures and not realize.



Bonus questions:

First question: Why does rfc8445 have any details at all about RTP/RTCP ? That seems to be more appropriately documented in rfc8839 than rfc8445. Since the ICE protocol doesn't change it's behavior for a given set of component ids, regardless of the application layer data that's sent over the selected candidate pairs, including these protocol / usage specific details in rfc8445, and rfc5245 has been a great source of confusion for me.

Second question:
Quote from https://tools.ietf.org/html/rfc8445#section-4

      Selected Pair, Selected Candidate Pair:  The candidate pair used for

      sending and receiving data for a component of a data stream is

      referred to as the "selected pair".  Before selected pairs have

      been produced for a data stream, any valid pair associated with a

      component of a data stream can be used for sending and receiving

      data for the component.  Once there are nominated pairs for each

      component of a data stream, the nominated pairs become the

      selected pairs for the data stream.  The candidates associated

      with the selected pairs are referred to as "selected candidates".


Does rfc8445 expect application traffic (e.g. RTP/RTCP) to be sent on a valid pair prior to the selected pairs being determined? I have not seen any reference to this anywhere else in rfc8445.