[rtcweb] JSEP Section 6

[Bernard Aboba <[e-mail]>]

Some comments.

      Construct a table mapping payload type to RtpReceiver for each
      RtpReceiver configured to receive from this transport and for each
      payload type that RtpReceiver is configured to receive.  The
      payload types of a given RtpReceiver are found in the m= section
      corresponding to that RtpReceiver in the local description.  If
      any payload type could map to more than one RtpReceiver, map to
      the RtpReceiver whose m= section appears earliest in the local
      description.


[BA] In the case where a payload type can map to  more than one
RtpReceiver, what if the earliest m-line is "send-only" or "inactive"?
 Wouldn't you want to map to the  RtpReceiver whose m-line is
"recv-only" or "send-recv" and is earliest?


      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 RtpReceiver for that payload type.  In
      addition, deliver the packet to the associated RtpReceiver and
      stop.


[BA] I believe that PT-based SSRC latching breaks two of Cullen's
proposed use cases (see:
https://mailarchive.ietf.org/arch/msg/rtcweb/cvcpy-Rnj4ntL66haNnKHy2_Yvw
):


Codec change, case 1: The PTs are all unique, and no SSRCs were signaled in
SDP  There is no RID, MID, FEC or RTX. Sender switches codecs, and the PT
changes (but SSRC stays the same).  The packet goes to the receiver that
matches the new PT.

Codec change, case 2:  The PTs are all unique and SSRCs are signaled in
SDP.  There is no RID, MID, FEC or RTX. Sender switches codecs and the PT
changes (but SSRC stays the same).  SSRC does not match any signaled ones.
The packet goes to the receiver that matches the new PT.

[BA] For the RTCP routing, it is more clear to use the RFC 3550 terms
for the various SSRC fields.  For exchange, change:

      "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 RtpReceiver 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 RtpSender
      associated with that SSRC."

To:


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



[BA] Change:


      "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 RtpSender associated with that SSRC."


To:


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



[BA] The RTCP SDES packet has no "SSRC of packet sender" field, so change:


      "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
      RtpReceiver associated with that SSRC.  In addition, for each
      chunk in the packet that contains a MID that is in the table
      mapping MID to RtpReceiver, update the incoming SSRC mapping table
      to include an entry that maps the SSRC for that chunk to the
      RtpReceiver associated with that MID.  (This case can occur when
      RTCP for a source is received before any RTP packets.)"


To:


      "If the packet is of type SDES, for each chunk containing

      an "SSRC/CSRC" field found in the incoming SSRC table,

      deliver the packet to the RtpReceiver associated with that SSRC.

      In addition, for each chunk in the packet that contains a MID
that is in the table
      mapping MID to RtpReceiver, update the incoming SSRC mapping table
      to include an entry that maps the SSRC for that chunk to the
      RtpReceiver associated with that MID. (This case can occur when
      RTCP for a source is received before any RTP packets.)"


[BA] Change:



      "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 RtpReceiver associated with that SSRC."


To:



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


[BA] Change:


      "If the packet is of type RTPFB or PSFB, as defined in [RFC4585
<https://tools.ietf.org/html/rfc4585>],
      and the media source SSRC for the packet is found in the outgoing
      SSRC table, deliver the packet to the RtpSender associated with
      that SSRC."


To:


      "If the packet is of type RTPFB or PSFB, as defined in [RFC4585
<https://tools.ietf.org/html/rfc4585>],
      and the "SSRC of media source" for the packet is found in the outgoing
      SSRC table, deliver the packet to the RtpSender associated with
      that SSRC."


[BA] Since FIR feedback messages can contain multiple FCI fields, I think you

need to add the following text (see RFC 5104 Section 4.3.1.1):


      "In addition, for FIR feedback messages, as defined in [RFC5104],

      for each "SSRC" indicated in an FCI entry, deliver a copy of the

      packet to the RtpSender associated with that SSRC.