Matching rules: IETF RTCWEB WG Last Call on JSEP Appendix B

The IETF RTCWEB WG has announced WG last call on draft-ietf-rtcweb-jsep, including the RTP/RTCP matching rules (now in Appendix B): 
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-18#appendix-B

So as to ensure compatibility of ORTC with WEBRTC (e.g. proper functioning of WEBRTC over ORTC shims), I believe that the ORTC RTP/RTCP matching rules need to be compatible with the WEBRTC RTP/RTCP matching rules. 

Therefore the RTP/RTCP matching rules proposed in JSEP Appendix B are relevant to the disposition of a number of ORTC API open issues, including: 

https://github.com/w3c/ortc/issues/368 : Algorithm in "RTP matching rules" ignores FEC/RTX/RED packets
https://github.com/w3c/ortc/issues/546 : RTP matching rules when no encoding.rtx.ssrc is given
https://github.com/w3c/ortc/issues/547 : RTP matching rules: don't remove pt_table[packet.pt]

Looking at the proposed RTP/RTCP matching rules, I believe that they address the above issues. 

For example, the proposed RTP matching rules cover all SSRC uses including FEC/RTX/RED, do not involve removal of pt_table entries, and would allow RTX packets to be routed based on PT if no encodings[].rtx.ssrc is given.

I would therefore like to understand whether the ORTC CG would support replacing the most or all of the current text in the ORTC API specification in Section 8.3 (RTP matching rules,  http://draft.ortc.org/#rtpmatchingrules* ) and Section 13.3 (RTCP matching rules, http://draft.ortc.org/#rtcpmatchingrules*) with references to JSEP Appendix B (or an equivalent section in BUNDLE once the text is moved there).  

The proposed RTP/RTCP matching rules in JSEP Appendix B are provided below (along with some notes): 

Appendix B.

   The following text is meant to completely replace section
   "Associating RTP/RTCP Streams With Correct SDP Media Description" of
   [I-D.ietf-mmusic-sdp-bundle-negotiation].

   As described in [RFC3550], RTP/RTCP packets are associated with RTP
   streams as defined in [RFC7656].  Each RTP stream is identified by an
   SSRC value, and each RTP/RTCP packet carries an SSRC value that is
   used to associate the packet with the correct RTP stream.  An RTCP
   packet can carry multiple SSRC values, and might therefore be
   associated with multiple RTP streams.

   In order to be able to process received RTP/RTCP packets correctly it
   must be possible to associate an RTP stream with the correct "m="
   line, as the "m=" line and SDP attributes associated with the "m="
   line contain information needed to process the packets.

   As all RTP streams associated with a BUNDLE group use the same
   address:port combination for sending and receiving RTP/RTCP packets,
   the local address:port combination cannot be used to associate an RTP
   stream with the correct "m=" line.  In addition, multiple RTP streams
   might be associated with the same "m=" line.

   An offerer and answerer can inform each other which SSRC values they
   will use for an RTP stream by using the SDP 'ssrc' attribute
   [RFC5576].  However, an offerer will not know which SSRC values the
   answerer will use until the offerer has received the answer providing
   that information.  Due to this, before the offerer has received the
   answer, the offerer will not be able to associate an RTP stream with
   the correct "m=" line using the SSRC value associated with the RTP
   stream.  In addition, the offerer and answerer may start using new
   SSRC values mid-session, without informing each other using the SDP
   'ssrc' attribute.

   In order for an offerer and answerer to always be able to associate
   an RTP stream with the correct "m=" line, the offerer and answerer
   using the BUNDLE extension MUST support the mechanism defined in
   [I-D.ietf-mmusic-sdp-bundle-negotiation] section 14.  where the
   offerer and answerer insert the identification-tag associated with an
   "m=" line (provided by the remote peer) into RTP and RTCP packets
   associated with a BUNDLE group.

   The mapping from an SSRC to an identification-tag is carried in RTCP
   SDES packets or in RTP header extensions
   ([I-D.ietf-mmusic-sdp-bundle-negotiation] section 14).  Since a
   compound RTCP packet can contain multiple RTCP SDES packets, and each
   RTCP SDES packet can contain multiple chunks, an RTCP packet can
   contain several SSRC to identification-tag mappings.  The offerer and
   answerer maintain tables used for routing that are updated each time
   an RTP/RTCP packet contains new information that affects how packets
   should be routed.

   To prepare for demultiplexing RTP packets to the correct "m=" line,
   the following steps MUST be followed for each BUNDLE group.

      Construct a table mapping MID to "m=" line for each "m=" line in
      this BUNDLE group.  Note that an "m=" line may only have one MID.

      Construct a table mapping incoming SSRC to "m=" line for each "m="
      line in this BUNDLE group and for each SSRC configured for
      receiving in that "m=" line.

      Construct a table mapping outgoing SSRC to "m=line" for each "m="
      line in this BUNDLE group and for each SSRC configured for sending
      in that "m=" line.

      Construct a table mapping payload type to "m=" line for each "m="
      line in the BUNDLE group and for each payload type configured for
      receiving in that "m=" line.  If any payload type is configured
      for receiving in more than one "m=" line in the BUNDLE group, do
      not it include it in the table.

[BA] This effectively requires that SSRC or MID be used to route RTP packets when PTs overlap.
Also, if overlap is created via a new call to receive() this would effectively require removal of a pt_table entry created by a previous receive() call. 
However, the SSRC latching functionality (see below) would keep existing RTP streams flowing until an SSRC change occurs. 

      Note that for each of these tables, there can only be one mapping
      for any given key (MID, SSRC, or PT).  In other words, the tables
      are not multimaps.

   As "m=" lines are added or removed from the BUNDLE groups, or their
   configurations are changed, the tables above MUST also be updated.

   For each RTP packet received, the following steps MUST be followed to
   route the packet to the correct "m=" section within a BUNDLE group.
   Note that the phrase 'deliver a packet to the "m=" line' means to
   further process the packet as would normally happen with RTP/RTCP, if
   it were received on a transport associated with that "m=" line
   outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd),
   including dropping an RTP packet if the packet's PT does not match
   any PT in the "m=" line.

      If the packet has a MID and that MID is not in the table mapping
      MID to "m=" line, drop the packet and stop.

      If the packet has a MID and that MID is in the table mapping MID
      to "m=" line, update the incoming SSRC mapping table to include an
      entry that maps the packet's SSRC to the "m=" line for that MID.

      If the packet's SSRC is in the incoming SSRC mapping table, route
      the packet to the associated "m=" line and stop.

      If the packet's payload type is in the payload type table, update
      the the incoming SSRC mapping table to include an entry that maps
      the packet's SSRC to the "m=" line for that payload type.  In
      addition, route the packet to the associated "m=" line and stop.

[BA] The above rule should enable basic audio scenarios where we have an audio codec (e.g. G.711) and CN and/or DTMF, but no SSRC or MID usage.
If the SSRC remains the same but PT changes from G.711 to CN or DTMF, then the RTP packets will be routed to the same RtpReceiver.

      Otherwise, drop the packet.

   For each RTCP packet received (including each RTCP packet that is
   part of a compound RTCP packet), the packet MUST be routed to the
   appropriate handler for the SSRCs it contains information about.
   Some examples of such handling are given below.

      If the packet is of type SR, and the sender SSRC for the packet is
      found in the incoming SSRC table, deliver a copy of the packet to
      the "m=" line associated with that SSRC.  In addition, for each
      report block in the report whose SSRC is found in the outgoing
      SSRC table, deliver a copy of the RTCP packet to the "m=" line
      associated with that SSRC.

      If the packet is of type RR, for each report block in the packet
      whose SSRC is found in the outgoing SSRC table, deliver a copy of
      the RTCP packet to the "m=" line associated with that SSRC.

      If the packet is of type SDES, and the sender SSRC for the packet
      is found in the incoming SSRC table, deliver the packet to the
      "m=" line associated with that SSRC.  In addition, for each chunk
      in the packet that contains a MID that is in the table mapping MID
      to "m=" line, update the incoming SSRC mapping table to include an
      entry that maps the SSRC for that chunk to the "m=" line
      associated with that MID.  (This case can occur when RTCP for a
      source is received before any RTP packets.)

      If the packet is of type BYE, for each SSRC indicated in the
      packet that is found in the incoming SSRC table, deliver a copy of
      the packet to the "m=" line associated with that SSRC.

      If the packet is of type RTPFB or PSFB, as defined in [RFC4585],
      and the media source SSRC for the packet is found in the outgoing
      SSRC table, deliver the packet to the "m=" line associated with
      that SSRC.

[BA] Some additional text appears to be needed to handle RTCP packets with multiple FCI entries, such as FIR and LRR.  
Also, the text should indicate how to handle RTCP packets that aren't recognized (e.g. APP).  A good rule might be to forward
those RTCP packets to all receivers and senders.

Received on Wednesday, 18 January 2017 16:51:22 UTC