Re: [MMUSIC] [AVTCORE] Question

[Julius Friedman <[e-mail]>]

@Dave & Stephan,

Well thanks for letting me know at least someone sees these messages.

I am not demanding anything, I had these inquiries for over 6 months and
when I received no response I filled the erratum. If there is a better way
so be it but respond and indicate such. I will retract erratum if I am
wrong or it is determined to not be applicable.

Right now basically when I use the advice I am given, the people that gave
it to me get offended, well how do you think I feel when it was told to me
the same things? e.g. "RTP has worked for 20 years" or "Mr. Casner is the
worlds leading expert" or "Collin Perkins didn't respond" Who cares? That
was not a scope of my issue and more spam then any of my inquires
contained. If they don't want to respond they don't have to, the issues are
still real.

I am open to writing a draft to correct things but there is nothing to
write about if people can't get over the fact that there are issues which I
attempted to openly addressed, weather or not people respond doesn't really
make a difference in the end I guess as I can't really DO anything to FORCE
you to address these issues, I can only file errata and if the errata is
accepted so be it. I have my own software to worry about and that's where
my focus will be, it will be unfortunate if I have to explain why I
explicitly chose not to be 'complaint' but its more so to just pretend like
it was 'intended' and hide behind the details.

That being said I do apologize if I stepped on any toes or hurt anyone's
`ego`, I don't intend to do that and I didn't bring the conversation in
those directions anyway. I just want to address the issues and move on.

Relating to my RFC2435 Errata.

YES, this is correct, I apologize for the backwards calculation.

The RFC only provided a way for certain sized images much lower then what
JPEG supports to be transferred, this erratum fixes this by specifying that
in some cases you may need to use a different fraction to obtain the height
(which might not be in a multiple of 16 anyway) additionally it allows one
to deal with the nuance that if the data is so large that the
FragmentOffset will probably overflow during this time and provides a way
to deal with that as well.

I just wanted to determine if there was any consensus around
my proposed change, do you recommend I add another erratum for the
`FragmentOffset` issue? And yes the 'Unmatched brace' is also my bad.

There are actually two others which can be seen here: (and possibly more
important)

http://www.rfc-editor.org/errata_search.php?rfc=2435&rec_status=15&presentation=records

They related to the types of JPEG which can be transferred under the RFC
and the tables used for quantization when quality is <=
50, specifically there are problems for black and white jpeg's and jpegs
with more then 2 quantization tables. My implementation handles all of this
but the code given in the RFC does not.  You can find my code @
http://net7mma.codeplex.com/SourceControl/latest#RtspServer/MediaTypes/RFC2435Media.cs
or the corrected code in the erratum.

Thank you for your input and I would appreciate taking the next steps on
those if possible so please let me know what to do next if anything.

I see that my 'RTSP' errata (4199) is `reported` and that it contains a
typo as I previously indicated, no one seems to have responded to that, I
can only imagine that it's known but no one really understand or knows what
to do about it and furthermore it seems that in the latest draft there have
been quite a few changes which remedy my questions in some regard but not
totally.

As for the updated RTSP Standard, I will say that the standard does seem
greatly improved as of the latest version @
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40

I will definitely be using some of the information present to deal with my
issues with 'Live' non-stored streams, such as the 'Media-Properties' and `
Seek-Style` header.

I do have a few questions related to the content however which hopefully
can be resolved before any further issue comes up.


13 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-13>.
Method Definitions

   The method indicates what is to be performed on the resource
   identified by the Request-URI.  The method name is case-sensitive.
   New methods may be defined in the future.  Method names MUST NOT
   start with a $ character (decimal 36) and MUST be a token as defined
   by the ABNF [RFC5234 <http://tools.ietf.org/html/rfc5234>] in the
syntax chapter Section 20
<http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-20>.
The methods
   are summarized in Table 7.

...

Why does it make sense to work around the issue that '$' is both the
framing character and now officially a 'SAFE' character?


Rather than change the framing method to something which would be
better for TCP since it's only used there we simply make it worse by
removing the ambiguity of '\$' and now saying that '$' is safe.


So now we can also have '$' Methods like "METHOD_$" that's not a great
feature... I think that 36 needs to be removed from the header section
all together. It should simply not appear in the header section under
any cases.


CSeq and Date (etc) should use Hex rather than Decimal notation which
would remove most of the issues with it's occurrence. The body section
is not an issue as it's length and encoding is given.



14 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-14>.
Embedded (Interleaved) Binary Data

Note that this mechanism does not support PDUs larger than 65535
      octets, which matches the maximum payload size of regular, non-
      jumbo IPv4 and IPv6 packets.  If the media delivery protocol
      intended to be used has larger PDUs than that, definition of a PDU
      fragmentation mechanism will be required to support embedded
      binary data.

...


TCP can technically be fragmented or overlapped without such large
packets so what does this statement provide?

The fact my network users larger packets would make no different as I
likely wouldn't be sending those packets outside my network.


How should one specify such as mechanism which is both compatible with
existing interleaving and this new mechanism? Without a better Binary
Interleaved Header it would be almost fruitless anyway since the TCP
protocol does not allow developers to take advantage of the
re-transmissions configuration per socket or disable receive
coalescing. (Although some Linux / Unix implementations do allow this
via TCP_USER_TIMEOUT on Windows these are per Machine or per Adapter
settings).



18.53 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-18.53>.
Timestamp

   The Timestamp general-header describes when the agent sent the
   request.  The value of the timestamp is of significance only to the
   agent and may use any timescale.  The responding agent MUST echo the
   exact same value and MAY, if it has accurate information about this,
   add a floating point number indicating the number of seconds that has
   elapsed since it has received the request.  The timestamp can be used
   by the agent to compute the round-trip time to the responding agent

   so that it can adjust the timeout value for retransmissions when
   running over an unreliable protocol.  It also resolves retransmission
   ambiguities for unreliable transport of RTSP.

   Note that the present specification provides only for reliable
   transport of RTSP messages.  The Timestamp general-header is
   specified in case the protocol is extended in the future to use
   unreliable transport.

...

I already support Rtsp over UDP, I am not going to disable just
because there was a 'lack of interest', if I am interested or my
clients are we are going to use it.


I think the verbiage here is misleading 'in case the protocol is
extended in the future to use  unreliable transport.'  How can it be
that in the future when it was supported in previous versions?
Furthermore what happened to the nomenclature about disabling
re-tranmissions? Is that no longer required?


Also I don't need this header to compute "Round Trip Time" no does
anyone else NOR should it be used in place of the actual round trip
time as locally calculated, only the delay portion added by the server
is even remotely relevant.


Section 18.54 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-18.54>.
Transport



...

ssrc: The ssrc parameter, if included in a SETUP response, indicates
         the RTP SSRC [RFC3550 <http://tools.ietf.org/html/rfc3550>]
value(s) that will be used by the media
         server for RTP packets within the stream.  It is expressed as
         an eight digit hexadecimal value.

         The ssrc parameter MUST NOT be specified in requests.  The
         functionality of specifying the ssrc parameter in a SETUP
         request is deprecated as it is incompatible with the
         specification of RTP in RFC 3550
<http://tools.ietf.org/html/rfc3550>[RFC3550
<http://tools.ietf.org/html/rfc3550>].  If the parameter is
         included in the Transport header of a SETUP request, the server
         SHOULD ignore it, and choose appropriate SSRCs for the stream.
         The server SHOULD set the ssrc parameter in the Transport
         header of the response.


Why is this not compatible? It would surely alleviate issues under TCP
where the first RTCP packet was received before the `PLAY` response.


Why should the client not be able to indicate it's 'ssrc' space to the
server to ensure a collision is not occurring?


Wouldn't it also be incompatible for the server to send the `ssrc` so
why is the semantic different for the client?



'RTCP-mux'

Can't a server just use a single client_port or use the same port twice?
e.g. "client_port=1234" OR "client_port=1234-1234"?

Can it at-least be stated that RTCP-mux would be equivalent to the above
syntax (since I do believe that's how it's achieved now anyhow)? If not
what is to be assumed if there is not a pair of ports? that Rtcp is
disabled?

Thank to those that are responding!