[MMUSIC] On RFC2326-biz

[Julius Friedman <[e-mail]>]

Reading further into the new draft I had some more feedback and questions
which I feel should be addressed.

I see that the re-transmission text has been moved elsewhere and that
various nomenclature regarding 're-transmission' has been either removed or
it's location and context has changed to totally oppose the previous
concepts put forth... It seems that re-transmission is now only acceptable
under UDP which the standard goes to remove support for?

What about TCP? How should a RTSP 2 system deal with legacy RTSP 1
connection with that regard? I think there are several other places this
mistake was made also.


Appendix G <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#appendix-G>.
Requirements for Unreliable Transport of RTSP

   This appendix provides guidance for those who want to implement RTSP
   messages over unreliable transports as has been defined in RTSP 1.0
   [RFC2326 <http://tools.ietf.org/html/rfc2326>].  RFC 2326
<http://tools.ietf.org/html/rfc2326> defined the "rtspu" URI scheme
and provided some
   basic information for the transport of RTSP messages over UDP.  The
   information is being provided here as there has been at at least one
   commercial implementation and compatibility with that should be
   maintained.

   The following points should be considered for an interoperable
   implementation:

   o  Requests shall be acknowledged by the receiver.  If there is no
      acknowledgement, the sender may resend the same message after a
      timeout of one round-trip time (RTT).  Any retransmissions due to
      lack of acknowledgement must carry the same sequence number as the
      original request.

   o  The round-trip time can be estimated as in TCP (RFC 6298
<http://tools.ietf.org/html/rfc6298>)
      [RFC6298 <http://tools.ietf.org/html/rfc6298>], with an initial
round-trip value of 500 ms.  An
      implementation may cache the last RTT measurement as the initial
      value for future connections.

   o  The Timestamp header (Section 18.53
<http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-18.53>)
is used to avoid the
      retransmission ambiguity problem [Stevens98
<http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#ref-Stevens98>].

   o  The registered default port for RTSP over UDP for the server is
      554.

   o  RTSP messages can be carried over any lower-layer transport
      protocol that is 8-bit clean.

   o  RTSP messages are vulnerable to bit errors and should not be
      subjected to them.

   o  Source authentication, or at least validation that RTSP messages
      comes from the same entity becomes extremely important, as session
      hijacking may be substantially easier for RTSP message transport
      using an unreliable protocol like UDP than for TCP.


Bullet 5 - *TCP is too, what does this statement add?*


*This information in the header seems to contradict what information
is given later on in Appendix I.*


*Additionally the information related to re-transmission and Timestamp
is still ambiguous IMHO as the Timestamp header plays no role TCP
re-transmissions, furthermore since it's syntax [The Timestamp header]
only has meaning to a Client the Server has no way of measuring or
comparing the previous Timestamp unless they attempt parsing of
various ways of conveying the information. *


*There needs to be more definite syntax related to Timestamp and it
needs to further be indicated that TCP re-transmissions can cause
partial data to appear to a receiver and that when using TCP and how
to handle this as I previously indicated. *


*Some text about minimum packet size with respect to Blocksize
utilized would also be beneficial so there is no reason for clients to
attempt to verify data which cannot be verified by a packet with no
Timestamp header (Rtsp or Rtp or otherwise e.g. a Rtcp packet)*


*The contradicting text from Appendix I is listed below.*


"

 *  The description on how rtspu works is not part of the core
         specification and will require external description.  Only that

         it exists is defined here and some requirements for the
         transport is provided.

"


*Additionally this section seems to further contradict the above paragraphs.*


4.2 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-4.2>.
RTSP IRI and URI

   RTSP 2.0 defines and registers or updates three URI schemes "rtsp",
   "rtsps" and "rtspu".  The usage of the last, "rtspu", is unspecified
   in RTSP 2.0, and is defined here to register the URI scheme that was
   defined in RTSP 1.0.  The "rtspu" scheme indicates unspecified
   transport of the RTSP messages over unreliable transport (UDP in RTSP
   1.0).  An RTSP server MUST respond with an error code indicating the
   "rtspu" scheme is not implemented (501) to a request that carries a
   "rtspu" URI scheme.


Lastly wouldn't that also mean that a client can still use UDP but their
requests simply can't have a 'rtspu' scheme? I am not sure if that wan
intended or not but it seems silly to indicate that the scheme of the
location means anything when in fact the protocol of the connection is what
really matters. Why would anyone care if a client used a different scheme
in their request?

Sincerely,
Julius Friedman