Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling

[Christer Holmberg <[e-mail]>]

Hi,

Nobody has objected to Colin¹s text, so my suggested is to now merge the
PR.

Regards,

Christer



On 18/07/17 16:42, "Colin Perkins" <[e-mail]> wrote:

>Hi Christer,
>
>As discussed - pull request submitted.
>Colin
>
>
>
>> On 9 Apr 2017, at 08:54, Christer Holmberg
>><[e-mail]> wrote:
>> 
>> Hi Colin,
>> 
>> Thanks for your input!
>> 
>> Would it be possible for you to create a pull request with your
>>suggested changes?
>> 
>> BUNDLE can be found at: https://github.com/cdh4u/draft-sdp-bundle
>> 
>> Regards,
>> 
>> Christer
>> 
>> -----Original Message-----
>> From: mmusic [mailto:[e-mail]] On Behalf Of Colin Perkins
>> Sent: 07 April 2017 20:06
>> To: mmusic (E-mail) <[e-mail]>
>> Subject: [MMUSIC] Comments on BUNDLE -37 - RTP handling
>> 
>> I have some comments on BUNDLE -37 - apologies that I wasn¹t able to
>>participate fully in the mailing list discussion before the meeting.
>> 
>> The current text is generally reasonably clear, and is certainly
>>precisely written, but I do think it has some problems. Most of these
>>relate to the issue of whether RTP packets or RTP streams are being
>>processed. I think it¹s important that this draft is written in terms of
>>how to associate RTP streams with m= lines, rather than how to route and
>>demultiplex RTP packets, since RTP packet routing and demultiplexing is
>>already specified by the various RTP specifications. In particular,
>>there are some places where the draft as written conflates the two
>>layers in ways that conflict with the RTP and RTCP specifications, that
>>I¹ve tried to correct by more cleanly separating the layers.
>> 
>> I¹ve tried to write my suggestions in a prescriptive manner, keeping to
>>the style of the existing text where possible. Hopefully the result is
>>clear and understandable.
>> 
>> Comments line below:
>> 
>>> 10.2.  Associating RTP/RTCP Streams With Correct SDP Media Description
>>> 
>>>   NOTE: The text in this section is copied from Appendix B of JSEP.
>>>   The community has not yet agreed on the text.
>>> 
>>>   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 includes an SSRC field that is used to associate
>>>   the packet with the correct RTP stream.  RTCP packets also use SSRCs
>>>   to identify which RTP streams the packet relates to.  However, a RTCP
>>>   packet can contain multiple SSRC fields, in the course of providing
>>>   feedback or reports on different RTP streams, and therefore can be
>>>   associated with multiple such 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="
>>> 
>>> 
>>> 
>>> Holmberg, et al.         Expires October 2, 2017               [Page
>>>20]
>>> Internet-Draft                Bundled media                   March
>>>2017
>>> 
>>> 
>>>   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
>>>   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.
>>> 
>>>   When using this mechanism, the mapping from an SSRC to an
>>>   identification-tag is carried in RTP header extensions or RTCP SDES
>>>   packets, as specified in section 14.  Since a compound RTCP packet
>>>   can contain multiple RTCP SDES packets, and each RTCP SDES packet can
>>>   contain multiple chunks, a single 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.
>> 
>> The text above looks good. In particular, it correctly focusses on
>>associating RTP streams with m= lines, which is the correct level of
>>abstraction. 
>> 
>>>   However, some implementations of may not include this identification-
>>>   tag in their RTP and RTCP traffic when using the BUNDLE mechanism,
>>>   and instead use a payload type based mechanism for demuxing.  In this
>> 
>> The term ³demuxing² is unclear. For precision, I suggest changing ³use
>>a payload type based mechanisms for demuxing² to ³use a payload type
>>based mechanism to associate RTP streams with SDP m= lines².
>> 
>>>   situation, each "m=" line MUST use unique payload type values, in
>>>   order for the payload type to be a reliable indicator of the relevant
>>>   "m=" line for the RTP stream.  Note that when using payload type
>>>   based demuxing,
>> 
>> Similarly, for precision, I suggest changing ³when using payload type
>>based demuxing² to ³when using the payload type to associate RTP streams
>>with m= lines².
>> 
>>>                   an SSRC will be mapped to an ³m=³ line
>> 
>> Suggest changing to ³an RTP stream, identified by SSRC, will be
>>mappedŠ² to be clear what¹s being done.
>> 
>>>                                                          by the first
>>>   packet with that SSRC, and the mapping will not be changed even if
>> 
>> Suggest changing to ³when the first RTP packet of that RTP stream is
>>received, andŠ² to be clear, since there could be RTCP packets with the
>>same SSRC.
>> 
>>>   the same SSRC is received with a different payload type.  In other
>> 
>> Suggest changing to ³the payload type used by that RTP stream changes.
>>In other² to be precise.
>> 
>>>   words, the SSRC cannot to "move" to a different "m=" line simply by
>>>   changing the payload type.
>>> 
>>> Holmberg, et al.         Expires October 2, 2017               [Page
>>>21]
>>> Internet-Draft                Bundled media                   March
>>>2017
>>> 
>>> 
>>>   Applications can implement RTP stacks in many different ways.  The
>>>   algorithm below details one way that demultiplexing can be
>>>   accomplished, but is not meant to be prescriptive about exactly how
>> 
>> To be clear about what is being demultiplexed, I suggest changing ³one
>>way that demultiplexing can be accomplished² to ³one way that RTP
>>streams can be associated with m= lines².
>> 
>>>   an RTP stack needs to be implemented.  Applications MAY use any
>>>   algorithm that achieves equivalent results to those described in the
>>>   algorithm below.
>>> 
>>>   To prepare for demultiplexing RTP/RTCP packets to the correct "m="
>>>   line, the following steps MUST be followed for each BUNDLE group.
>> 
>> I suggest changing ³Šprepare for demultiplexing RTP/RTCP packets to the
>>correctŠ² to ³Šprepare to associate RTP streams with the correctŠ². RTP
>>and RTCP packets are not demultiplexed to m= lines, they¹re
>>demultiplexed into RTP streams, and then those RTP streams are
>>associated with m= lines. The distinction is important, in order to
>>implement RTCP correctly.
>> 
>>>      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.
>> 
>> The SSRC is a property of an RTP stream, so I suggest changing ³mapping
>>incoming SSRC to² to ³mapping SSRCs of incoming RTP streams to².
>> 
>>>      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.
>> 
>> Similarly, change ³mapping outgoing SSRC² to ³mapping the SSRC of each
>>outgoing RTP stream²
>> 
>>>      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, as it cannot be used to uniquely
>>>      identify a "m=" line.
>>> 
>>>      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.
>> 
>> The goal is not to route RTP packets to m= lines, but rather to
>>associate the corresponding RTP streams with m= lines. This keeps the
>>distinction between RTP and RTCP processing that has to happen
>>irrespective of the m= line, and the application level processing that
>>depends on the choice of m= line. I suggest changing this sentence to:
>>³When an RTP packet is received, it MUST be delivered to the RTP stream
>>corresponding to its SSRC. That RTP stream MUST then be associated with
>>the correct m= line within a BUNDLE group, according to the following
>>steps.²
>> 
>>>   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.
>> 
>> Dropping RTP packets with unknown payload type breaks RTCP. The RTP
>>packet must be processed by the RTP layer as normal, updating the
>>statistics that are maintained by RTCP. The payload is then discarded,
>>because there¹s no decoder associated with the payload type. I suggest
>>removing this part of the paragraph entirely.
>> 
>>>      If the packet has a MID, and that MID is not in the table mapping
>>>      MID to ³m=" line, drop the packet and stop.
>> 
>> Dropping the RTP packet will break the RTCP reports. The RTP packet has
>>to be processed as normal, but the corresponding RTP stream is not
>>decoded if it¹s not associated with an ³m=³ line (i.e., you drop the
>>payload, not the RTP packet). I suggest replacing the above with
>>something like:
>> 
>>   If the MID associated with the RTP stream is not in the table mapping
>>   MID to ³m=³ line, then the RTP stream is not decoded and the payload
>>   data is discarded.
>> 
>>>      If the packet has a MID, and the packet's extended sequence number
>>>      is greater than that of the last MID update, as discussed in
>>>      [RFC7941], Section 4.2.6, update the incoming SSRC mapping table
>>>      to include an entry that maps the packet's SSRC to the "m=" line
>>>      for that MID.
>> 
>> There are two things that need to be done here: update the MID
>>associated with the RTP stream to match that in the newly received RTP
>>packet, and update the mapping table. I suggest changing ³update the
>>incoming SSRC mapping table to include an entry that maps the packet¹s
>>SSRC to the ³m=³ line for that MID² to ³update the MID associated with
>>the RTP stream to match the MID carried in the RTP packet, then update
>>the mapping tables to include an entry that maps the SSRC of that RTP
>>stream to the ³m=³ line for that MID².
>> 
>>>      If the packet's SSRC is in the incoming SSRC mapping table, check
>>>      that the packet's PT matches a PT included on the associated "m="
>>>      line.  If so, route the packet to that associated "m=" line and
>>>      stop; otherwise drop the packet and stop.
>> 
>> Dropping the packet breaks RTCP. The RTP packet is processed as normal,
>>but the corresponding RTP stream is not decoded if it¹s not associated
>>with an ³m=³ line. I suggest replacing the above with:
>> 
>>   If the SSRC of the RTP stream is in the incoming SSRC mapping table,
>>   check that the payload type used by the RTP stream matches a payload
>>   type included on the matching ³m=³ line. If so, associate the RTP
>>   stream with that ³m=³ line. Otherwise, the RTP stream is not decoded
>>   and the payload data is discarded.
>> 
>>>      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.
>> 
>> RTP packets correspond to RTP streams, and those RTP streams are
>>associated with m= lines. Suggest changing to:
>> 
>>   If the payload type used by the RTP stream is in the payload type
>>   table, update the incoming SSRC mapping table to include an entry
>>   that maps the RTP stream¹s SSRC to the ³m=³ line for that payload
>>   type. Associate the RTP stream with the corresponding ³m=³ line.
>> 
>>>      Otherwise, drop the packet.
>> 
>> The packet cannot be discarded without breaking RTCP. I suggest
>>replacing the above with:
>> 
>>   Otherwise, mark the RTP stream as not for decoding and discard the
>>   payload. 
>> 
>>>   For each RTCP packet received (including each RTCP packet that is
>>>   part of a compound RTCP packet), the packet MUST be routed to the
>>>   ³m=³ line for the RTP streams it contains information about.  This
>>>   routing is type-dependent, as each kind of RTCP packet has its own
>>>   mechanism for associating it with the relevant RTP streams.
>> 
>> The first sentence might be clearer written ³For each RTCP packet
>>received (including each RTCP packet that is part of a compound RTCP
>>packet), the packet is processed as usual by the RTP layer, then is
>>passed to the ³m=³ lines corresponding to the RTP streams it contains
>>information about for further processing.²
>> 
>>>   Packets for which no appropriate "m=" line can be identified (i.e.,
>>>   for unknown RTP streams) are not relevant in the context of this
>>>   algorithm and MAY be dropped.  This situation may occur with certain
>>>   multiparty RTP topologies.
>> 
>> These packets can¹t be dropped. They setup state at the RTP layer that
>>might become relevant when further RTP/RTCP packets are received (RTCP
>>packets can round-robin SDES items, such as the MID, in some cases, so
>>these can potentially be important). I suggest changing this to:
>> 
>>   RTCP packets for which no appropriate ³m=³ line can be identified
>>   MUST be processed as usual by the RTP layer, updating the metadata
>>   associated with the corresponding RTP streams, but are not passed
>>   to any ³m=³ line. This situation can occur with certain multiparty
>>   RTP topologies, or when RTCP packets are sent containing a subset
>>   of the SDES information.
>> 
>>>   Rules for handling the various types of RTCP packets are explained
>>>   below.
>> 
>> Perhaps change to ³Rules for additional processing of the variousŠ², to
>>make it clear that this doesn¹t replace the usual RTCP processing.
>> 
>>>      If the packet is of type SDES, for each chunk in the packet whose
>> 
>> "If the RTCP packet isŠ²
>> 
>>>      SSRC is found in the incoming SSRC table, deliver a copy of the
>>>      packet to the "m=" line associated with that SSRC.  In addition,
>> 
>> ³a copy of the SDES packet² presumably, since otherwise it¹s ambiguous
>>if the entire compound RTCP packet is delivered or just the SDES packet.
>> 
>>>      for any SDES MID items contained in these chunks, if the MID is
>>>      found in the table mapping MID to "m=" line, update the incoming
>>>      SSRC table to include an entry that maps the chunk¹s SSRC to the
>> 
>> ³Šmaps the RTP stream associated with the chunk¹s SSRC toŠ²
>> 
>>>      "m=" line associated with that MID, unless the packet is older
>>>      than the packet that most recently updated the mapping for this
>>>      SSRC, as discussed in [RFC7941], Section 4.2.6.
>>> 
>>>      Note that if an SDES packet is received as part of a compound RTCP
>>>      packet, the SSRC to "m=" line mapping may not exist until the SDES
>>>      packet is handled (e.g., in the case where RTCP for a source is
>>>      received before any RTP packets).  Therefore, when processing a
>>>      compound packet, any contained SDES packet MUST be handled first.
>> 
>> It might be worth referencing RFC 3550 section 6.1, which says:
>> 
>>   Each individual RTCP packet in the compound packet may be processed
>>   independently with no requirements upon the order or combination of
>>   packets.  
>> 
>> as justification for this.
>> 
>>> Holmberg, et al.         Expires October 2, 2017               [Page
>>>23]
>>> Internet-Draft                Bundled media                   March
>>>2017
>>> 
>>> 
>>>      If the packet is of type BYE, it indicates that the RTP streams
>> 
>> ³If the RTCP packet isŠ²
>> 
>>>      referenced in the packet are ending.  Therefore, for each SSRC
>>>      indicated in the packet that is found in the incoming SSRC table,
>> 
>> ³Šin the BYE packetŠ²
>> 
>>>      first deliver a copy of the packet to the ³m=" line associated
>> 
>> ³Ša copy of the BYE packetŠ²
>> 
>>>      with that SSRC, but then remove the entry for that SSRC from the
>>>      incoming SSRC table after an appropriate delay to account for
>>>      "straggler packets", as specified in [RFC3550], Section 6.2.1.
>>> 
>>>      If the packet is of type SR or RR, for each report block in the
>> 
>> ³If the RTCP packet isŠ²
>> 
>>>      report whose "SSRC of source" is found in the outgoing SSRC table,
>>>      deliver a copy of the RTCP packet to the ³m=" line associated with
>> 
>> ³the RTCP packet² or ³the SR or RR packet²? To avoid confusion when
>>compound RTCP packets are used, I suggest the latter phrasing here, and
>>in the later sections.
>> 
>>>      that SSRC.  In addition, 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
>> 
>> ³a copy of the SR packet²?
>> 
>>>      SSRC.
>>> 
>>>      If the implementation supports RTCP XR and the packet is of type
>>>      XR, as defined in [RFC3611], for each report block in the report
>>>      whose "SSRC of source" is is found in the outgoing SSRC table,
>>>      deliver a copy of the RTCP packet to the ³m=" line associated with
>> 
>> ³the RTCP packet² or ³the XR packet²?
>> 
>>>      that SSRC.  In addition, if the sender SSRC for the packet is
>>>      found in the incoming SSRC table, deliver a copy of the packet to
>> 
>> ³the packet² -> ³the RTCP packet² or ³the XR packet²?
>> 
>>>      the "m=" line associated with that SSRC.
>>> 
>>>      If the packet is a feedback message of type RTPFB or PSFB, as
>> 
>> ³If the RTCP packet isŠ²
>> 
>>>      defined in [RFC4585], it will contain a media source SSRC, and
>>>      this SSRC is used for routing certain subtypes of feedback
>>>      messages.  However, several subtypes of PSFB messages include
>>>      target SSRC(s) in a section called Feedback Control Information
>>>      (FCI).  For these messages, the target SSRC(s) are used for
>>>      routing.
>>> 
>>>      If the packet is a feedback message that does not include target
>> 
>> ³If the RTCP packet isŠ²
>> 
>>>      SSRCs in its FCI section, and the media source SSRC is found in
>>>      the outgoing SSRC table, deliver the packet to the ³m=" line
>> 
>> Which packet? 
>> 
>>>      associated with that SSRC.  RTPFB and PSFB types that are handled
>>>      in this way include:
>>> 
>>>      Generic NACK:  [RFC4585] (PT=RTPFB, FMT=1).
>>> 
>>>      Picture Loss Indication (PLI):  [RFC4585] (PT=PSFB, FMT=1).
>>> 
>>>      Slice Loss Indication (SLI):  [RFC4585] (PT=PSFB, FMT=2).
>>> 
>>>      Reference Picture Selection Indication (RPSI):  [RFC4585]
>>>         (PT=PSFB, FMT=3).
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Holmberg, et al.         Expires October 2, 2017               [Page
>>>24]
>>> Internet-Draft                Bundled media                   March
>>>2017
>>> 
>>> 
>>>      If the packet is a feedback message that does include target
>> 
>> ³If the RTCP packet isŠ²
>> 
>>>      SSRC(s) in its FCI section, it can either be a request or a
>>>      notification.  Requests reference a RTP stream that is being sent
>>>      by the message recipient, whereas notifications are responses to
>>>      an earlier request, and therefore reference a RTP stream that is
>>>      being received by the message recipient.
>>> 
>>>      If the packet is a feedback request that includes target SSRC(s),
>> 
>> ³If the RTCP packet isŠ²
>> 
>>>      for each target SSRC that is found in the outgoing SSRC table,
>>>      deliver a copy of the RTCP packet to the "m=" line associated with
>>>      that SSRC.  PSFB types that are handled in this way include:
>>> 
>>>      Full Intra Request (FIR):  [RFC5104] (PT=PSFB, FMT=4).
>>> 
>>>      Temporal-Spatial Trade-off Request (TSTR):  [RFC5104] (PT=PSFB,
>>>         FMT=5).
>>> 
>>>      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).
>>> 
>>>      If the packet is a feedback notification that include target
>>>      SSRC(s), for each target SSRC that is found in the incoming SSRC
>>>      table, deliver a copy of the RTCP packet to the "m=" line
>>>      associated with that SSRC.  PSFB types that are handled in this
>> 
>> ³deliver a copy of the RTCP packet to the ³m=³ line associated with the
>>RTP stream with matching SSRC²
>> 
>>>      way include:
>>> 
>>>      Temporal-Spatial Trade-off Notification (TSTN):  [RFC5104]
>>>         (PT=PSFB, FMT=6).  This message is a notification in response
>>>         to a prior TSTR.
>>> 
>>>      If the packet is of type APP, the only routing information
>>>      included is the source of the packet, and therefore the packet
>>>      could be related to any existing "m=" line.  Accordingly, deliver
>>>      a copy of the packet to each ³m=" line.
>> 
>> Are APP packets exposed in the WebRTC APIs? Given that we have the data
>>channel, it¹s not clear that we want to support arbitrary application
>>information passing via RTCP. It might be better to say that APP packets
>>are processed in an application specific manner, and if the application
>>doesn¹t understand them, they¹re not passed to any m= line?
>> 
>> Finally, I note that this section of the draft doesn¹t mention the CSRC
>>list anywhere, but should probably do so. As written, RTP packets with a
>>CSRC list will be delivered to the RTP stream matching their SSRC in the
>>usual way, then passed up to the m= line associated with that RTP
>>stream. That may well be sufficient, but if so it¹s likely useful to say
>>that, to make the intent clear.
>> 
>> Colin
>> 
>> 
>> 
>> 
>> -- 
>> Colin Perkins
>> https://csperkins.org/
>> 
>> 
>> 
>> 
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>-- 
>Colin Perkins
>https://csperkins.org/
>
>
>
>