Subject: [payload] Problem with draft-ietf-payload-rtp-h265

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Oct 2014 15:46:48 -0700

Just noticed a bunch of problems introduced into the draft by the use of the "Single Stream Mode" and "Multiple Stream Mode" terminology. 
   Dependency of one RTP stream on another RTP stream is typically
   indicated as specified in [RFC5583].  When an RTP stream A
   depends on another RTP stream B, the RTP stream B is referred to
   as a dependee RTP stream of the RTP stream A.

[BA] The statement above is wrong. RFC 5583 dependency groups based on theuse of a=group:DDP and a=mid: lines and therefore can only deal with dependencies between m-lines (multiple RTP sessions).  If the RTP streamsare sent within the same RTP session, the dependency cannot be indicated as specified in RFC 5583.   
      Informative note: An MSM may involve one or more RTP sessions.
      Each RTP stream in an MSM may be in its own RTP session or a
      set of multiple RTP streams in an MSM may belong to the same
      RTP session, e.g. as indicated by the mechanism specified in
      the Internet-Draft [I-D.ietf-avtcore-rtp-multi-stream] or in
      [I-D.ietf-mmusic-sdp-bundle-negotiation].

   SSM SHOULD be used for point-to-point unicast scenarios, while
   MSM SHOULD be used for point-to-multipoint multicast scenarios
   where different receivers require different operation points of
   the same HEVC bitstream, to improve bandwidth utilizing
   efficiency.
[BA] This is also wrong. While it was accurate that Multi-Session-Transportshould be used for point-to-multipoint multicast scenarios, Single-Session-Transportof multiple streams can be used in point-to-point unicast scenarios. 
   The transmission mode is indicated by the tx-mode media parameter
   (see section 7.1).  If tx-mode is equal to "SSM", SSM MUST be
   used.  Otherwise (tx-mode is equal to "MSM"), MSM MUST be used.
[BA] This also does not make sense, because it will not allow for distinguishingbetween multi-stream within a single session, and multi-session-transport. Within SDP this is critical because RFC 5583 is not designed to deal withsingle session-multi stream transport, and therefore we will get negotiationfailures. 

   Receivers MUST support both SSM and MSM.

[BA] This is a nice statement, but by the above confusion created by bad terminology will make itmeaningless.  Overall, this document creates additional confusion above and beyond that which wealready had in RFC 6190.