Subject: [AVTCORE] Errata 4192 RFC 3550

From: Julius Friedman <[email-masked]>
Date: Fri, 5 Dec 2014 16:13:34 -0500

Hello All.

There is definitely some confusion related to the errata I submitted for
RFC3550.

The RFC clearly states:

sender's octet count: 32 bits
      The total number of payload octets (i.e., not including header or
      padding) transmitted in RTP data packets by the sender since
      starting transmission up until the time this SR packet was
      generated.  The count SHOULD be reset if the sender changes its
      SSRC identifier.  This field can be used to estimate the average
      payload data rate.

Just because it CAN be used for an average does not mean it should.

Further it is the total number of octets in the payload besides the header
because the header is always 12 octets.

Since csrc and extension octets are included then padding should be also.

Since rtcp also reflects the count with padding this is obviously correct.

Any padding only packet would not change the counter for rtp and is thus a
security issue as well as a redundantly conveyed piece of information
because each packet contains the number of padding bytes which can be
accounted for in the implementation when required.

To account for padding when padding is not required and would be 0 is also
contradictory.

Please read and re read the errata if required.

Please advise.  ( intelligently )

Sincerely,
Julius Friedman

---

From: Stephen Casner <[email-masked]>
Date: Mon, 8 Dec 2014 14:36:53 -0800 (PST)

> There is definitely some confusion related to the errata I submitted for

I believe the confusion is within your interpretation of the standard,
not in our interpretation of your proposed errata.  Perhaps you would
like RTP to have some functions that are different than those that
were specified, but those do not constitute errata.

> Just because it CAN be used for an average does not mean it should.

Let me clarify.  When we wrote that sentence, we were stating why this
field was included.  It was included so that receivers would be able
to know the sender's average payload data rate over various time
intervals by taking the value of this field from two sender reports
and dividing by the difference in time of the two sender reports.  The
receiver might want to compare that result with the average of the
data as received (perhaps with some losses).

> Further it is the total number of octets in the payload besides the
> header because the header is always 12 octets.
>

The CSRC and extension octets part of the RTP header and the phrase
"not including header" means that they would not be included in the
sender's octet count.  What text in RFC 3550 led you to believe that
the header is always just the first 12 octets and that therefore the
CSRC and extension octets would be included in the sender's octet
count?

> Since rtcp also reflects the count with padding this is obviously

I am not sure what you are referring to here.  In another email you
said "Rtcp counters include this value anyway."  What RTCP counters
include a count of padding bytes?  Perhaps you are referring to the
fact that the legnth field in the RTCP header includes padding on the
RTCP compound packet.  That is irrelevant to the question of whether
the sender's octet count, which is a count of payload octets, should
or should not include padding octets.

> Any padding only packet would not change the counter for rtp and is
> thus a security issue as well as a redundantly conveyed piece of
> information because each packet contains the number of padding bytes
> which can be accounted for in the implementation when required.

I do not see a security issue.  Please explain how there would be an
added security risk for an application that does send RTP data packets
with padding compared to an application does does not send RTP data
packets with padding, even if sometimes those applications send RTP
data packets containing no payload data.

The sender's octet count is an aggregate count of the payload octets
over some number, often a large number, of RTP data packets.  If the
receiver gets all of the data packets with no loss, then that same
count could be calculated.  However, some packets may be lost.  RTP is
designed to help implementations be tolerant of packet loss.

> To account for padding when padding is not required and would be 0
> is also contradictory.

I don't understand this sentence.  The sender's octet count does not
include padding octets, so for implementations that do not send
padding the number of excluded padding octets is zero, but that does
not form any contradiction.

> Please advise.  ( intelligently )

I suggest that careful reading and understanding of RFC 3550 is what
is required here.

                                                        -- Steve

---

From: Julius Friedman <[email-masked]>
Date: Wed, 10 Dec 2014 01:22:17 -0500

Dear Mr. Casner / Audio Video Working Group.

Sincerely thank you for responding in a manner which clearly shows that you
have taken the time to acknowledge my inquiry. I know my previous emails
were hastily written and this one is probably not much better but I will
endeavor to express my concerns and points and then in summary ask you
respond at least once again.

I would like to first start of by saying that if I did have functions which
are not specified they would not be standard and hence not relevant for
errata, the reason I wrote this errata is because I know that others have
also had issues when reading that sentence (and multiple others in the Rtp
RFC [3550]) and I would like to clarify if nothing else why I believe it is
errata and why it can potentially be a security risk.

I don't mean to pick apart your answer but I would like to take some of
your response and ensure I understand it correctly.

"
field was included.

It was included so that receivers would be able to know the sender's
average payload data rate over various time intervals by taking the value
of this field from two sender reports and dividing by the difference in
time of the two sender reports.

The receiver might want to compare that result with the average of the data
as received (perhaps with some losses).
"

Advising by your statement, particularly the bit about how one could
possibly calculate the data rate over various time intervals, if I were to
disagree I would first have to ascertain the exact meaning of such a term
[payload data rate] thus first we must look at your wording, "sender's
average payload data rate".

To answer this, and some of the latter questions in your email.

What is a payload before we can talk about it's data rate? Well it is
EVERYTHING that is not the header.

What is the header? The header (in terms of Rtp Packets) consists of the
first 3 words (12 octets) which indicate the version, padding, extension,
contributing source count, payload type, marker, sequence number, ssrc and
timestamp.

Before I continue my arguement I will make a statement to show my line of
thinking;

Since each transmission of a "valid" rtp packet might consist of ONLY a
header the payload size in such a case would be 0.

A valid rtp packet may have a contributing source counter <= 15, this
implies that another csrc words following the 12 required header octets.

A valid rtp packet may have an extension, when present will follow
immediately after the csrc words indicated by the csrc nibble in the header.

A valid rtp packet may contain padding, when present it will follow any
"payload data" and such padding must define a count which is set in the
final octet of the raw binary sequence which is defined as the rtp packet.

Because of the above given restraints it can be seen that a receiver must
have a valid RTP Header consisting of 12 octets to properly determine if
the data received is valid / complete.

Given those notions I will continue my arguments;

While the header is technically extended by the presence of csrc, extension
and the payload is proceeded by padding it makes sense to think of them as
contained in the payload section and such calculations regarding their
length (especially padding) can only be made after reception of at least 12
octets.

No matter if RTP Lite is used and the Rtp Header is not 12 octets or ROHC
is employed and the header is not 12 octets, and thus may be re-constructed
or de-compressed the amount of header bytes can explicitly be calculated to
12 octets.

Thus any time the 'sender's packet count' increases one receiver can
multiply that number [sender's packet count] by 12 to receive the amount of
bytes related to rtp headers in transmissions, this would reveal a payload
data rate of 0 in such cases as the sender is sending "rtp header" only
packets to a receiver.

Taking the same example, if I add ONLY padding to the payload and I
followed your recommendation I would still have data rate of 0 in such a
case.

The same would apply for csrc and extensions of combinations of all 3
regardless of their length and contribution to the overall rate of data
(and their subsequent effects on the network [regardless how small they
are]).

When middle boxes receive rtp packets and remove extensions or a mixer
combined several sources and indicates so in the csrc field the payload
data rate technically doesn't change but the overall data rate does, while
when using your recommended count the receiver will not be able to
determine if the path between the two changes due to a mixer or middle box
performing any modification of the data packets from the sender because the
data is "hidden" using your recommended count. While this may be desirable
for some reasons as it would keep the size the same and the count the same,
it removes information which would be able to be used for various purposes
such as determining if alternates routes are followed etc; while a receiver
is very well able to keep on their own of the amount of total bytes they
are receiving, and they as well can calculate the amount of padding and
bytes related to csrc, extensions the problem arises if and when packets
are lost.

In such a case the receiver will not be able to calculate the amount of
data or other bytes because the packet was not received, while the standard
allows for also calculating how much was lost there needs to be a reference
point; This is where [sender's packet count] is needed and using it one can
then indicate roughly how many bytes were missing using the amount of
packets indicated there minus the amount received to determine the exact
amount of packets lost (but I suppose would not be needed if you were JUST
determining payload data rate, it would simply be lower or higher given the
two differences in the [senders octet count] value and the time received).

Finally, the security risk of indicating the amount of bytes related to
payload data (especially considering now your explicitly stating to remove
the extension and csrc data from) versus just bytes for counting purposes
is simply this.

Over a time (regardless if padding only packets are sent or not) one can
quickly determine if extensions, csrc or padding is then in used in rtp
just by monitoring the value in the senders report versus what was actually
sent on the wire.

This also reveals the congruence of the padding with respect to the
payload, and thus reduces complexity in determining the key (by knowing the
padding length using it to lower the amount of attempts required to derive
the correct key) by the amount of bytes not relevant to the portion being
ciphered.

Even though the extension and csrc are probably encrypted  the senders
octet count again reveals the amount of bytes only related to DATA so the
length of these values can be extracted and thus the amount of data which
is probably the same and in any such case not related to the payload can
thus be derived and used to shorten the amount of time in deriving a
correct key.

With my proposed changes (which is simply just using the entire length of
the binary payload - 12 for the header length) one will make the derivation
of bytes related to csrc / extension and padding much more difficult if not
impossible to derive.

It will also increase the accuracy of your given calculation because more
bytes are being included in the value which allow a higher degree of
accuracy when related to the other factors given (e.g. jitter takes into
account the whole packet, not just the payload data rate) It is important
to realize that no distinction should be made after transport of the "rate"
with anything other than whole and valid packets because of middle boxes
and other such devices (mixers) which may alter the end contents of the
packet, and by doing so does not break compatibility in the standard only
allows for more accurate and useful information to be derived without
chaining anything besides removing additional subtraction from a place
where is is not required and poses no benefit and citing my explanations
thus constitutes it as errata from my perspective.

In short, it makes sense to use the property as it was named and give the
receiver the ability to determine average / total or whatever else they
want to by simply giving them the information as required, removing
information serves no positive purpose in this case and let me also point
out that not many (if not all) implementations I can find already are just
giving the "payload" count, there are very very few which actually take
into account extensions and csrcs and slightly more that account for
padding including the software 'rtp tools' which was developed by Mr.
Schulzrinne.

This will actually make software existing more correct in those cases while
not changing anything in the standard although that is not a reason to
change it I hope you also can see there is no negative effect with my
proposed change, e.g. if a person forgets to set extension, csrc or padding
my implementation will see no different but yours will.

If your application changes to include the count as I indicated and
performs the same calculations it performs today, (taking padding into
account as well as extension and csrc) it will not change the result of any
existing algorithm.

Therefore I strongly recommend that you base your decision on those points
and additionally the fact it weakens security is an issue as well.

If you are going to reject it I would at least like an indication of WHY it
needs to be rejected.

E.g. it would break this or that as well as an brief explanation.

If no such argument can be made on how it will cause a problem with
existing implementations then then how can one argue against it especially
considering the security questions which I have given?

I at the very least expect the wording to changed to indicate explicitly
that the extension, csrc should also not be included in the count.

Lastly, what about the errata related to RFC2435 and RFC2326 which I have
submitted?

They have not been responded to, are they being looked into?

Sincerely,
Julius

---

From: Stephen Casner <[email-masked]>
Date: Wed, 10 Dec 2014 10:17:06 -0800 (PST)

Julius,

You are contemplating reasons for having the SR packet convey
different information than is currently part of the design.  You could
propose that RTP be modified to create a new version, or you could
propose a profile of RTP that extends the SR packet.  However, you
have not identified an error in RFC 3550.

I believe it is not necessary to add any text clarifying the content
of the sender's octet count because the definition of the RTP header
clearly shows that the CSRC words are included.  The header extension,
by its very name, indicates that it is part of header, and this is
reinforced by the fact that it is positioned between the SSRC and the
CSRC.

Therefore, I recommend that your proposed erratum be rejected.

I have not read the errata related to RFC2435 and RFC2326 as I am not
an author of those RFCs.

This is my last message on the topic.

                                                        -- Steve

---

From: Julius Friedman <[email-masked]>
Date: Wed, 10 Dec 2014 13:45:33 -0500

Thank you for your "suggestions" and your response.

It is not my intention to argue but if you would be so kind as to PLEASE
acknowledge this email or have another member acknowledge it I would be
very appreciative and I do believe that it would benefit the community as a
whole.

It is unfortunate you see things as such because clearly your calculation
is then magically determining your defined payload data rate using the time
including padding, csrc and extensions when this is in fact not your
intention.

Beliefs are not really relevant here, while I believe quite a few things
the science and the math speaks for itself. The loss of information and
apparent mis-calculation of data rate in all circumstances as well as
unnecessary subtraction which is revealing information which is not really
necessary to reveal at such a level is more then a belief it is a fact.

Since beliefs are being conveyed, I do believe since you or no one else
seems to be able to indicate what this "change" breaks, when I have easily
determined several things which can be better observed (while actually
allowing your "data rate" calculation with the extra information) then
something MUST occur, either change the name of the property to indicate
payload octets or accept my suggestion because it proposes no change that
would effect any calculations, only fix calculations existing even your own
by your own definition not mine.

The error is that "Jitter" and other times includes those values in the
calculated value anyway, e.g. the data  delay and other rates cannot be
determined without knowing the amount of bytes actually sent thus this
number is providing something which is not what is indicated and SHOULD be
changed either name wise to indicate your "logic" or my way to support the
name and use of it and correct existing implementations in use without
changing their code.

I do have proposals for RTP Version 3 as a special profile would not fix
this issue which needs to be addressed before we can move onto version 3
unless you would like to acknowledge that this standard has ambiguous
terminology and a new version is required. I actually have already tested a
version 3 prototype and would be happy to share implementation details but
I need to have my other erratta checked first so I can ensure this as well
as that is on the correct train of thought.

An extension would be outside the scope of this issue because the change
would need to occur at the client level, although it could be done it would
be more cumbersome and break the chain of responsibility of the RtpClient
which is already required to handle things like STUN, TCP ALF etc, although
I will say my version 3 prototype is version 2 compatible with (de)muxing
and extensions and requires a version 2 packet with an extension.

The version 3 updates really relate to a few other things which I will not
endeavor into a tangent about since they are not relevant to this
discussion.

I have a few other issues I would also like to address.

Padding, when it is used it is only used for encryption as packetization
and rtcp have their own mechanisms when required for such. When a block is
transformed for encryption if the padding used is removed there is no
change in the length of the payload and thus padding would not be set in
such an encryption mechanism.

E.g. a encryption which has extra data added which is removed totally
before decoding the packet.

Lastly when padding is used there is no way to determine if the packet has
been completely received if the encryption uses random data as padding and
the last byte becomes truncated, also when using 0 padded data it is
possible to incorrectly detect padding if using that method because 0 data
could occur in the payload.

Thus I suggest that the location of padding be changed to be directly after
the extension, this would constitute errata.

If such a change is made then I would be happy to change the implementation
as a ROUGH calculation would then be determinable given your variables
because the overhead would be able to be determined off the "top" of the
packet and reliably without errors of mis-calculating it's size.

Given these notions what is your response?

Should a vote be taken?

I do believe I am being flexible and I do believe I have highlighted enough
reasons to change the location of the padding and make my previous errata
accepted but either will suffice at this point.

Thank you as well as the members for your "time" and "effort" in this
matter.

Sincerely,
Julius Richard Friedman.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Dec 2014 13:50:18 -0500

Stephen's point is that you are proposing a protocol change. That cannot 
be done by way of an erratum. If you want to write an Internet Draft 
with your proposals, they can be debated. I wonder if you could use the 
XR capability to get the information you want?

Tom Taylor

On 10/12/2014 1:22 AM, Julius Friedman wrote:
>...

---

From: Julius Friedman <[email-masked]>
Date: Wed, 10 Dec 2014 14:00:27 -0500

Thank you Mr. Taylor.

The bottom line is that even given the verbiage existing that it is simply
invalid to calculate the rate of just the payload using the time including
other data.

That itself is errata.

If the change is made as I suggested then existing hardware (even if it not
updated with the new logic) will be able to be at least detected using my
change.

Some implementations already use this information in the count anyway and
would thus be valid instead of invalid (with no change).

There are bigger fish to fry such as the location and content of the
padding, of which the location is the most important for detection of
completion of the packet.

We need to address one or the other and then it can validate your equations
existing (but would still require a change to the location of the offset of
the padding) or as I suggested for this errata to change the wording or the
name.

Both are really in order it's just a matter of how its done and not hastily
but after consideration I would suggest that if "compatibility" with
existing hardware is most important then to update just the name and
indicate my errata as a name change only and why so that it can be adjusted
for as best as possible where required; then to file more errata to change
the location of the padding or just start work on a new version of the rtp
standard with ambiguous definitions removed.

Thank you for your time and effort and I look forward to your dialog in
this matter!

Can you also please check my RFC2435 Errata and RFC2326 Errata so I can
discuss those as well?

Sincerely,
Julius Richard Friedman

On Wed, Dec 10, 2014 at 1:50 PM, Tom Taylor <[email-masked]>
wrote:

> be done by way of an erratum. If you want to write an Internet Draft with
> your proposals, they can be debated. I wonder if you could use the XR
> capability to get the information you want?
>
> Tom Taylor
>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Dec 2014 14:26:02 -0500

We are saying that regardless of considerations of implementation, the 
IETF requires that changes of this sort be achieved using certain 
procedures. The current wording of RFC 3550 was achieved through Working 
Group consensus, and that is what would be required for further changes. 
The way to achieve that is through the writing of an Internet Draft and 
list discussion. So far there has been no indication of Working Group 
interest in your interpretation, but who knows?

I have not seen your errata for the other two documents, presumably 
because they went to a different E-mail list, but the same procedural 
considerations apply.

Tom Taylor

...

---

From: Julius Friedman <[email-masked]>
Date: Wed, 10 Dec 2014 14:52:33 -0500

Dear Mr. Taylor, AVT.

Thus it was my reasons for explicitly opening this discussion.

Possibly the errata name and notes and focus could be shifted but as is the
case with many things in science, not to diverge but the points are simple:

The instructions given for calculating transit time, jitter inter arrival
and all other "times" in the "real time" protocol take account data
transferred on the medium of transfer, this time calculation MUST include
the time taken to receive CSRC, Extensions and Padding. Thus the Senders
Octet Count not including these values goes against these calculations to
form a value which is both detrimental to the given standard algormithmic
calculations for those values as well as  security in cases where
encryption is used.

This does not take into account "middle boxes" which are one of Mr.
Casner's areas of other modifications to internet drafts, in most of his
modifications the middle boxes are allowed to remove extensions which when
occurs causes information to be hidden under the current verbiage for no
reason when allowing for it's detection is both beneficial and accurate
given the description and taking into account its relationship to the data
rate.

In short if my total octet count is X I can manually determine what my
packet overhead is (csrc, extension or padding) and if i have the total
numbers (X) I can also remove time for the padding and csrc and extension
because I will have the total rate given by the time at which the packet
was received.

Simply if I determine X is 100 I can determine X is made from csrc total Y,
extension total Z and then X - (Y + Z) would come out to exactly what the
existing senders octet count is given the standard today and create a valid
calculation of "jitter" and the other calculated values which would then
finally no longer be saturated by the presence of extra data (regardless if
the middle box removes it which causes additional delay which is just seen
as jitter in the network anway)

This should be easy to achieve consensus on since the change basically says
instead of performing subtraction for data not part of the "data" of the
payload just increment for the "payload" section (which may include csrc,
and extension and padding).

This removes a calculation which is also mostly 0 all of the time when none
of the values are used and only causes issues when there are mediums in
between anyway such as mixers, hence it is VERY VERY important to use the
values such as jitter in the way they were designed and as indicated in the
standard and to acknowledge that your already taking those values into
account (even if you don't know it because they were removed by a middle
box).

It is also very very easy to detect that the sender is keeping count a
different way than you are and thus would indicate a middle box or older
version of the standard being implemented which would also subsequently be
able to be detected and accounted for giving the change.

That is what I would like to address however, the problem is that this does
not even take into account that padding at the end of the packet can be
truncated and is another issue itself.

Hence the location of padding ALSO needs to really be changed to make
reception more reliable, that will probably harder to specify in errata and
thus will require a protocol change but obviously consensus needs to be
attained.

I would love to focus on the new draft but I think that we need to fix some
things in the existing version with errata first because it will both
justify the nature of new version and explain the nuisances with the
previous version which can then be adjusted for if required.

I also notice that RFC3551 specified that DVI be dropped but it specified
NO other default VIDEO transfer mechanism.

Since PCM is sometimes required and thus it was named for audio I do
believe that uncompressed / raw should also be specified as a minimum
mandatory requirement for implementations.

This would enable audio and video transfer in a uncompressed manner which
is standardly defined in https://tools.ietf.org/html/rfc4175.

How the consensus could be taken to remove a required video format but not
specify a standard replace would also be errata in my opinion but
apparently it's not...

There are probably other issues and I would be glad to help address them
but I need to determine what needs to be addressed and where and ensure
that consensus is achieved to write a draft.

I have found my errata for RFC2435 @
http://www.rfc-editor.org/errata_search.php?rfc=2435

I will re-submit my errata for RFC2326 today or tomorrow.

Hopefully we can all take some time to focus on the content here and decide
the path to take but I hope we can at least agree that its very clear to me
something needs to be done.

Thank you again for your time!

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Dec 2014 15:09:11 -0500

I wasn't explicit enough. You should take the ideas you present below 
and put them into an Internet Draft, then submit it for publication and 
discussion.

Have a look at the tutorials at http://www.ietf.org/edu/tutorials.html 
to help you get started. And welcome to the IETF as a new participant.

Tom Taylor

---

From: Julius Friedman <[email-masked]>
Date: Wed, 10 Dec 2014 15:40:14 -0500

Thank you, I appreciate being a part of something which will enable the
improvement of the quality of software engineered the world over.

I will create a draft for both rtp and the others,  I will ever go as far
to address the draft of rtsp.

However,  before beginning I would like there to be an acknowledgement of
the given errata so it can be justified that time be spent working on the
draft.

Even if its held for update, (which it seems there are already at least one
without my additions) it would allow me to address these issues and outline
both the relationship and determine if a new version be specified in the
draft or if just the same version be specified but with changes given or to
make the draft correct for the initial standard (which would involve
keeping track of the entities in question to properly calculate the given
terms)of which options is the very least desirable to me.

If a new version is specified I even will go as far to acknowledge all the
back to rtp 1 to ensure that all variations are specified partly because I
have identified version 0 as potentially another version (4) or explicitly
marking it as reserved for compatibility with VAT.

I will also address that uncompressed video be supported abd pcm be
supported at a minimum.

I also have changes which can remove dependence on media clock rate which
will simplify overall general calculations for jitter and the like, since
again they would be know or determinate and also incorrect which shouldn't
make calculations invalid.

Hopefully you and everyone else sees that I have a lot of considerations /
ideas and that I don't want to flood the working group with such problems
if they can be avoided however with web rtc becoming mainstream I believe
we need to address these issues today rather than tomorrow and I will do
whatever work is necessary to ensure the standards are correct and
encompass the best possible principles of engineering possible but I need
to know that the work is both utilized and understood otherwise it will be
for nothing.

Hopefully it's not too much to ask and thanks again and I appreciate your
time and effort in this matter as well as that of the committees.

Sincerely,
Julius Richard Friedman
On Dec 10, 2014 3:09 PM, "Tom Taylor" <[email-masked]> wrote:

> I wasn't explicit enough. You should take the ideas you present below and
> put them into an Internet Draft, then submit it for publication and
> discussion.
>
> Have a look at the tutorials at http://www.ietf.org/edu/tutorials.html to
> help you get started. And welcome to the IETF as a new participant.
>
> Tom Taylor
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 11 Dec 2014 11:54:53 -0500

> the given errata so it can be justified that time be spent working on the

You've already been told that the erratum will be rejected, since the
RFC does, in fact, correctly describe what the working group intended
for it to describe.

You believe that the information the protocol carries is not the
information that it *should* carry.  That is a complex technical
judgement that can only be made by the working group as a whole.  The
way to get the working group to consider the question is to write an
Internet-Draft and then raise the question on the appropriate working
group mailing list.

> time and effort in this matter as well as that of the committees.

All of these matters can only be handled by the working group as a
whole.  They are excellent items to address in an Internet-Draft.

Dale

---

From: Julius Friedman <[email-masked]>
Date: Thu, 11 Dec 2014 12:20:18 -0500

How can the items be excellent for a draft but not consideration for
errata?

After all I have proven transit times account for the data I am proposing
should be included, why cute shortcuts were taken to allow a calculation
which is much more accurate and straightforward otherwise.

Transit and jitter already account for the data in question as I have also
shown.

Since no breaking change occurs I believe that errata is the best way to
sort this initial problem out.

To reject it at this point is ignorant based on the fact so many other
edits are being looked at for rtp.

The padding issues is important but not as important as rtp has worked for
so long already.

The draft I will write will address this but should also cite the reasons
why it was needed to draft a newer version.

In that version I am going to regard this as an error and indicate the
basic mathematical principals I have cited here as well as the error in
logic in calculating payload data rate without the header and padding but
including those values in jitter and transit calculations which also can
effect rtcp.

I will also address the fact that video support was eliminated for no
apparent reason and never updated to include raw support.

Those are two items which need to be addressed (as well as the other edits)
in both errata and the new draft.

I am also changing how media clockrate is tied to calculations for jitter
and transit because of the issues with timestamps being the same when
multiple packets have the same timestamp in a frame among other issues
cited and not.

Padding location and content will also be addressed for security and
delivery protection as well as easier parsing.

I am also sure others have a few things to add to this as well (multi
pathing etc) which should also be addressed in the new draft.

There is a lot of things which can be improved but since that is outside
the scope of the proposed errata I need to address that first.

There is no protocol change for the proposed changes though (senders octet
count and raw video support) and the other edits are similar to reduce
ambiguity so unless it can be shown specifically why this is rejected I am
insisting that it be included with the 'final edits' to the rtp spec
already proposed.

I will begin work on the draft for version 3 regardless.

There is a lot of content which needs to be included for the smaller
existing standards which popped up e.g. rfc4751, Rtsp, feedback inter alia.

Since that will likely take time I highly suggest we correctly revise 3550
appropriately.

At this point we have 1889, 3551, 355x its already a nightmare researching
rtp and this new draft needs to fix that rather than repeat it and to make
a draft for this change alone when other changes are also being made is not
only ineffective its enneficient and displays instability in the standard.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 11 Dec 2014 10:30:38 -0700

> How can the items be excellent for a draft but not consideration for

Errata is appropriate when an RFC doesn't reflect what the working group
meant.
A draft is appropriate when an RFC does reflect what the working group
meant, but the working group was wrong.

Simon

---

From: Julius Friedman <[email-masked]>
Date: Thu, 11 Dec 2014 13:10:22 -0500

So then are you implying that it would be correct to change the definition
of timestamp and other such proposed changes while not allowing this one?

Have I not show that it is incorrect to take the transit time including the
header but then send only the "payload" count in the report?

Even when the definition and calulcations just explicitly given show that
the times taken include ANY data transfer including non rtp?

Making the change in text makes this calulcations correct and unambiguous
just as the other proposed changes which are being contemplated.

It also allows for more than correctness by showing when a route is
altered.

What reason is there to acknowledge this but reject the errata only to
propose a new draft?
On Dec 11, 2014 12:30 PM, "Simon Perreault" <[email-masked]> wrote:

>
> On Thu, Dec 11, 2014 at 10:20 AM, Julius Friedman <
> [email-masked]> wrote:
>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 11 Dec 2014 14:22:40 -0500

Your choice: follow IETF procedure or get nowhere. The first part of 
your draft should state the requirements you are trying to fulfill. 
These are clearly different from the requirements seen by the authors of 
RFC 3550 and its predecessor. Again I suggest that you look at the RTCP 
XR related RFCs to see if any of them fulfill your requirements.

Tom Taylor

...

---

From: Julius Friedman <[email-masked]>
Date: Thu, 11 Dec 2014 22:17:16 -0500

And I see that 3551 obsolete 3550.

This is also a trivial change just as are the suggestions which are
outlined in the latest changes which have not yet made it into the rfc e.g.
the -new documents which bears the same rfc number but changes wording.

Anyway we have other problems to worry about  besides this.

All I know is that my application will not comply with this old way of
thinking and without having the source code one person won't even really be
able to tell why the calculation is giving anyway.

I have already shown in my own server implementation that existing software
works the same if not better using my values as recommended.

I will write a new draft regardless of what you do with this errata but I
suggest it is not rejected without proper reason.

...

Please also check out the errata related to rfc2326 and lets try to get
somewhere with that...

Sincerely,
Julius Friedman.
On Dec 11, 2014 10:07 PM, "Tom Taylor" <[email-masked]> wrote:

> RFCs are not updated (with the exception of errata, which are more in the
> nature of trivial corrections); they are replaced. As a present example,
> the original RTP specification was RFC 1889, published 18 years ago. If you
> go to the RFC Editor database,
>
>
> http://www.rfc-editor.org/search/rfc_search_detail.php?
> rfc=3550&pubstatus[]=Any&pub_date_type=any
>
> you'll see that RFC 3550 obsoletes RFC 1889.
>
> Tom Taylor
>
> On 11/12/2014 4:33 PM, Julius Friedman wrote:
>
>> Thanks for taking time to... inform me...
>>
>> And so then what are the modifications to the standard proposed
>> considered? Is a modification not performed because of errata?
>>
>> This is not about xr reports or anything else besides the simple
>> calculations which obviously are not consistent.
>>
>> This is basic math and indeed proves if nothing else that the sender
>> octet count becomes USELESS when csrc, extension or padding is used.
>>
>
> [PTT] Useless for your purpose. I am telling you that your purpose is
> different from that of the people who accepted the calculations in RFCs
> 1889 and 3550 for the last 18 years. As a result, a proposal to replace RFC
> 3550 for this reason won't, honestly, get anywhere, but if you really need
> that information you can probably get it using the RTCP XR framework.
> ...
>