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

Being the author of Appendix B, I'm in favor of it :).

I think it makes more sense to wait until it's moved into BUNDLE and then
reference it there, but in general, yes, I think one copy of the rules that
everyone agrees on is better than two copies.

On Wed, Jan 18, 2017 at 8:52 AM Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> 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.
>
>
>