Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description

["Cullen Jennings (fluffy)" <[e-mail]>]

So I much prefer the current text and think there are a bunch of problems with this text. If we actually had emails explaining what problems in the current text this was trying to fix, with individual PRs for those, this would be much easier to resolve each of them and get them fixed.

1) we have been trying to avoid the use of "RTP session" as it has been very unclear to implementors what it is. I think this would be better if we could rephrase to not use that

2) both the proposed and current text seem lacking in dealing with multiple bundle groups 

3) Stats are typically maintained by things after the packet is routed - not before. 

4) Need to explain how the SDES in compound RTCP causes updates 

5) given this removes the outgoing SSRC table, not clear how it routes RTCP reports. I think this needs to be clarified. 

6) I don't think most implementers are going to have a clue what to do for the "Third Party Targeted Reports or Feedback" section

I will try and take your PR and break it up into some bit size pieces so we can try and see if we can get the easy ones out of the way and focus on the parts that are key changes. 



> On Jan 30, 2017, at 6:18 AM, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi,
> 
> I have now generated a pull request for this text, with some very minor changes.
> 
> https://github.com/rtcweb-wg/jsep/pull/538
> 
> Cheers
> 
> Magnus
> 
> Den 2017-01-27 kl. 17:43, skrev Magnus Westerlund:
>> MMUSIC and RTCWEB,
>> 
>> Here is now a more complete text proposal that also considers the RTCP.
>> It also goes further than what Appendix B defines in one aspect, namely
>> explicitly considering third party RTCP reporting and what to do with it.
>> 
>> Feedback is much appreciated. I plan to put this into a PR towards JSEP
>> APPENDIX B on monday. If only to get the JSEP authors attention ;-).
>> However, the text is really intended for the next version of BUNDLE.
>> 
>> 
>> X.  Associating RTP/RTCP With Correct SDP Media Description
>> 
>>   As described in [RFC3550], RTP packets are associated with RTP
>>   streams [RFC7656].  Each RTP stream is identified by an SSRC value,
>>   and each RTP packet carries an SSRC value that is used to associate
>>   the packet with the correct RTP stream.  RTCP packets also uses SSRCs
>>   to identify on which RTP streams any report or feedback relate to.
>>   Thus, an RTCP packet will commonly carry multiple SSRC values, and
>>   might therefore be providing feedback or report on 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 are part of the
>>   same RTP session and using 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.
>> 
>>   Also, as described in Section 10.1.1, the same payload type value
>>   might be used by multiple RTP streams, in which case the payload type
>>   value cannot be used to associate an RTP stream with the correct "m="
>>   line.  However, there are cases where each "m=" line has unique
>>   payload type values, and then the payload type could serve as
>>   indicator to the relevant "m=" line the RTP stream is associated
>>   with.
>> 
>>   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
>> 
>> 
>> 
>> Name                      Expires July 31, 2017                 [Page 2]
>> 
>> Internet-Draft              Abbreviated-Title               January 2017
>> 
>> 
>>   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
>>   Section 14, where the offerer and answerer includes the
>>   identification-tag (provided by the remote peer) associated with an
>>   "m=" line in the RTP Streams and in RTCP SDES packets part of a
>>   BUNDLE group.
>> 
>>   The mapping from an SSRC to an identification-tag is carried in RTCP
>>   SDES packets or in RTP header extensions (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 mapping RTP streams identified by SSRC to
>>   "m=" lines identified by the identification-tag.  These tables are
>>   updated each time new information that affects how packets should be
>>   processed and routed are received.
>> 
>>   To prepare for demultiplexing RTP streams to the correct "m=" line,
>>   the following steps MUST be followed for each BUNDLE group based on
>>   the SDP signalling information.
>> 
>>      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 RTP streams (SSRCs) to their
>>      "m=" line for each "m=" line in this BUNDLE group and for each RTP
>>      stream explicitly signalled for receiving in that "m=" line.
>> 
>>      Construct a table mapping payload types 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.
>> 
>>   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.
>> 
>> 
>> 
>> Name                      Expires July 31, 2017                 [Page 3]
>> 
>> Internet-Draft              Abbreviated-Title               January 2017
>> 
>> 
>>   Received RTP packets that are syntactically correct are processed by
>>   the RTP/RTCP protocol implementation for statistics etc.  After this
>>   processing they need to be routed to the higher layer context
>>   associated with the "m=" line within the BUNDLE group.  Somewhere in
>>   the process where an received RTP packet is processed to be delivered
>>   to the higher layer by RTP the matching step below MUST be performed:
>> 
>>   1.  Reception of an RTP packet for an RTP stream that has an existing
>>       mapping in the RTP stream to m= line table.  Before proceeding in
>>       delivering the packet to the higher layer context according to
>>       the RTP stream to "m=" line mapping table the following checks
>>       MUST be performed:
>> 
>>       A.  If the packet carries an RTP header extension with a SDES MID
>>           value that is not in the table mapping MID to "m=" line, then
>>           do not deliver the RTP packet to higher layers.
>> 
>>       B.  If the packet carries an RTP header extension with a SDES MID
>>           value that is in the table mapping MID to "m=" line, and the
>>           value indicates a different "m=" line than the current RTP
>>           stream to "m=" line mapping table, then update the RTP stream
>>           to "m=" line mapping.
>> 
>>   2.  Reception of an RTP packet for an RTP stream that has no existing
>>       mapping to an m= line.  In this case the following actions MUST
>>       be performed:
>> 
>>       A.  If the packet carries an RTP header extension with a SDES MID
>>           value that is in the table mapping MID to "m=" line, then
>>           create an entry in the RTP stream to "m=" line mapping table
>>           for this RTP stream (SSRC).  Then deliver the RTP packet to
>>           the "m=" line context of the created mapping and stop.
>> 
>>       B.  If the packet carries a Payload Type that is in the payload
>>           type table, then create an entry in the RTP stream to "m="
>>           line mapping table for this RTP stream (SSRC).  Then deliver
>>           the RTP packet to the "m=" line context of the created
>>           mapping and stop.
>> 
>>       C.  Otherwise do not deliver the RTP packet to higher layers.
>>           Note, this includes unknown MID values.
>> 
>>   For each RTCP packet received (including each RTCP packet that is
>>   part of a compound RTCP packet), the RTCP packet needs to be
>>   processed by the RTP/RTCP implementation and relevant information and
>>   data from the RTCP packets needs to be routed to the appropriate
>>   handler for the related RTP streams.  The appropriate handler is
>>   determined by using the RTP stream to "m=" line mapping table.
>> 
>> 
>> 
>> Name                      Expires July 31, 2017                 [Page 4]
>> 
>> Internet-Draft              Abbreviated-Title               January 2017
>> 
>> 
>>   On reception of any compound RTCP packet prior to dispatching the
>>   received information and data, if there is an RTCP SDES packet
>>   included that SHOULD be processed first.  If that SDES packet
>>   contains SDES MID entries, this can results in updates and additions
>>   to the RTP stream to "m=" line mapping table.  Thus each of the SDES
>>   MID items are processed and the current table entries are checked if
>>   the corresponding MID value matches the current RTP stream to "m="
>>   line mapping, else the entry is updated.  If there is no RTP stream
>>   to "m=" line table mapping entry for the received SDES item's SSRC,
>>   such an entry is created.  Note, that in the process of updating the
>>   table entries, update flap suppression as discussed in Section 4.2.6
>>   of [RFC7941] should be considered.
>> 
>>   The various different RTCP packets as well as their various sub
>>   parts, such as the various RTCP Feedback message types, relates to
>>   the RTP streams in a couple of different ways.  The currently known
>>   patterns are the following:
>> 
>>   Reports on outgoing RTP streams:  For all RTP streams that this
>>      endpoint is the source of, it can expect to receive report blocks
>>      of several types identified as relating to an outgoing stream.
>>      The basic pattern for these blocks are that the RTCP packet header
>>      identifies the source of the reports, as identified by an SSRC,
>>      and containing one or more report blocks, where each report block
>>      identifies the RTP stream, using the SSRC, the report relates to.
>>      For this pattern the relevant report information is provided to
>>      the higher layer associated with the "m=" line the RTP Stream to
>>      "m=" line table identifies.  The source SSRC as identifier of the
>>      endpoint that the report originates are relevant for interpreting
>>      the information, but not necessarily for routing.  Example of this
>>      is pattern are:
>> 
>>      Sender Report (SR) and Receiver Report (RR)  The basic receiver
>>         report blocks from RFC3550 start with the SSRC of the RTP
>>         stream they report on.
>> 
>>      Extended Reports (XR):  RFC3611 is a framework that enables a
>>         large number of different reports.  However, a large number of
>>         these report formats are reporting on specific RTP streams and
>>         thus each individual report of these types contains a SSRC
>>         field to identify the RTP stream.
>> 
>>   RTCP Feedback Messages for outgoing RTP streams:  The RFC 4585 RTCP
>>      feedback messages allow for a number of different type of feedback
>>      messages.  However, the RTCP feedback message header contains the
>>      SSRC identifying the source of the feedback messages as well as
>>      the actual type of the feedback.  Some of the feedback messages
>>      also uses the target SSRC field in the header to identify which
>> 
>> 
>> 
>> Name                      Expires July 31, 2017                 [Page 5]
>> 
>> Internet-Draft              Abbreviated-Title               January 2017
>> 
>> 
>>      RTP stream the feedback is related to.  For these types all the
>>      FCI entries, if multiple ones are forwarded to the identified
>>      handler.  Examples of this pattern are:
>> 
>>      Picture Loss Indication (PLI):  RFC 4585 (PT=PSFB, FMT=1).
>> 
>>      Slice Loss Indication (SLI):  RFC 4585 (PT=PSFB, FMT=2).
>> 
>>      Reference Picture Selection Indication (RPSI):  RFC 4585 (PT=PSFB,
>>         FMT=3).
>> 
>>      Generic NACK:  [RFC4585] (PT=RTPFB and FMT=1).
>> 
>>      Other feedback messages includes the target SSRC in the Feedback
>>      Control Information (FCI).  Here each FCI needs to be processed
>>      and the SSRC field identified.  And the individual FCI combined
>>      with the RTCP packet header context needs to be forwarded to the
>>      identified handler.  Example of this pattern are:
>> 
>>      Full Intra Request (FIR):  [RFC5104] (PT=PSFB, FMT=4).
>> 
>>      Temporal-Spatial Trade-off Request (TSTR):  [RFC5104] (PT=PSFB,
>>         FMT=5).
>> 
>>      Temporal-Spatial Trade-off Notification (TSTN):  This [RFC5104]
>>         defined message (PT=PSFB, FMT=5) is actually a notifciation in
>>         response to a TSTR this endpoint sent using the SSRC the FCI
>>         identifies as source.
>> 
>>      H.271 Video Back Channel Message (VBCM):  [RFC5104] (PT=PSFB,
>>         FMT=7).
>> 
>>      Layer Refresh Request (LRR):  [I-D.ietf-avtext-lrr] (PT=PSFB,
>>         FMT=TBD).
>> 
>>   Descriptive or Notifications for an incoming RTP stream:  There exist
>>      some RTCP packet types that provides additional information or
>>      notifies about events related to the RTP stream identified.  In
>>      these cases the RTP stream is identified using the SSRC field
>>      value, and the information is provided to the higher layer
>>      associated with the "m=" line for the incoming RTP stream as
>>      identified by the current RTP stream to "m=" line table.  For this
>>      type of pattern it is common that the RTCP packets and information
>>      is repeated, either periodically (e.g.  SDES items), or for a
>>      duration (e.g.  BYE), thus suppression of repetitions can be
>>      considered.  Examples of these are:
>> 
>> 
>> 
>> 
>> 
>> Name                      Expires July 31, 2017                 [Page 6]
>> 
>> Internet-Draft              Abbreviated-Title               January 2017
>> 
>> 
>>      Source Description (SDES) RTCP Packet:  The base RTP/RTCP protocol
>>         [RFC3550] defines SDES RTCP packets as a way of providing per
>>         source (SSRC) specific information about the source.  An SDES
>>         packet contains zero or more chunks, where a chunk contains the
>>         SSRC for the source being described by the one or more items
>>         included in the chunk.  Forward the SDES items in each chunk to
>>         the RTP stream's handler.
>> 
>>      Goodbye (BYE) RTCP Packet:  This RTP/RTCP protocol [RFC3550]
>>         mechanism indicates that a particular RTP stream is leaving the
>>         RTP session.  Thus, a most relevant event to inform the handler
>>         for this RTP steam of.
>> 
>>   Third Party Targeted Reports or Feedback:  There exist some
>>      multiparty RTP Topologies that results in that an endpoint
>>      receives third party reports (SR [RFC3550], RR [RFC3550] or XR
>>      [RFC3611]) as well as Feedback Messages [RFC4585] that relates to
>>      or targets an SSRC that originates from another endpoint, and
>>      where the source of the RTCP packet is also another endpoint.
>>      This type of packets should be forwarded to the higher layer
>>      function dealing with the third party reporting.  And if none
>>      exist then they can be suppressed.  As the third party handler can
>>      be focused on determining the conditions for the source of the
>>      reports and feedback, or focused on how the RTP stream source
>>      progresses, or both recommendations can't be made.
>> 
>>   APP Packets:  The RTCP APP Packets [RFC3550] are a mechanism that
>>      enables experimentation.  The APP packet only specifies the source
>>      of the packet.  Thus this information can be related to any of the
>>      "m=" lines, thus deliver a copy of the packet to each "m=" line or
>>      an APP specific handler.
>> 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb