Subject: Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc

From: Julius Friedman <[email-masked]>
Date: Mon, 15 Dec 2014 09:53:05 -0500

I'll check out that section and re-write in if necessary.

One thing on your response I have to clarify.
The sr allowed this synchronization.

The reference clock is virtually set to the time difference between the ntp
timestamp in the sender report and the receiver.

That's seems synchronized to me.

What difference does it make if his clock is wrong? Furthermore if sender
uses a clock on mars.

Can you succinctly state why we need to know more details about clock rate
than already available 20 years later?

How does my application benefit from this?

Furthermore it seems dynamic clock rates are not addressed.

Thanks for responding.
On Dec 15, 2014 3:11 AM, "Brandenburg, R. (Ray) van" <
[email-masked]> wrote:

>  Hi Julius,
>
>  Thanks for your constructive and positively-formulated feedback.
>
>  I advise you to read section 2 on Applications. It will answer most of
> your questions.
>
>  Furthermore, you seem to have missed a number of aspects:
>
>  - There is a difference between a media clock and a reference clock. I
> don’t see how any RTP profile or current SDP is going to help you to know
> which reference clock you’re using. Without that information, how are you
> going to synchronize two different receivers?
> - There is a difference between specifying a media clock rate (which is
> done in an RTP profile) and specifying how that clock rate is determined.
>
>  If you have any more questions, I encourage you to voice your opinion on
> the AVT mailing list.
>
>  Best regards,
>
>  Ray
>
>
>   From: Julius Friedman <[email-masked]>
> Date: Sunday 14 December 2014 18:37
> To: "[email-masked]" <
> [email-masked]>
> Subject: Mail regarding draft-ietf-avtcore-clksrc
> Resent-To: "[email-masked]" <[email-masked]>, <
> [email-masked]>, Kevin Gross <[email-masked]>, Ray van
> Brandenburg <[email-masked]>
>
>   What is the purpose of this rfc?
>
> After reading it several times I just cannot come to terms with anything
> it suggests.
>
> Rfc 3550 conveys the ntp time information via rtcp et al.
>
> There is no reason to signal rate of media in sdp beyond where each rtp
> profile registered has a default clock rate assigned especially when the
> document provides no mechanism to align the clocks in which it declared
> might not be synchronized. (Even though that is the purpose of ntp... )
>
> Here is a simple explanation.
> http://www.cs.columbia.edu/~hgs/rtp/faq.html#sr-timestamp
>
> Furthermore each implementation already has the clock rate as a parameter
> of the rtpmap or fmtp or the profile default is used.
>
> This document makes sdp content longer and more complex without any added
> benefit or explanation of the mechanism introduced.
>
> Lastly Video walls wouldn't need a specified rate to work as they would
> have their own rate and update displays based on that rate.
>
> Any such required information would be an optimiZation to their display
> driver through the operating system, do you really want a rtp sender to be
> able to control the clock rate of your display? If you do use snmp or
> something else.
>
> Things have worked like this for as long as rtp has been specified and
> thus this rfc only allows information to be given which is redundant given
> the fact a profile which would be required for playback through
> depacketization anyway.
>
> This document also makes no change to any calculation used by a receiver
> or sender.
>
> It is for all intents and purposes useless.
>
> Please feel free to correct me.
>
> Sincerely,
> Julius Friedman.
>
>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>

---

From: Julius Friedman <[email-masked]>
Date: Mon, 15 Dec 2014 11:36:30 -0500

This literally makes no sense because even if I knew what clock the sender
was using I might not be able to access it.

What if there is confusing information about a source?  E.g. its true
identity.

How is this any better then just adjusting to the sender's time any why..

After all the sender could just as well switch clocks again.

Multiple streams are combined by a mixer and hence the mixer accounts for
the rate adjusting if required to mix each sample.

This doesn't really help a mixer perform that function any easier for the
reasons stated and only would under situations where it was designed to.

Receivers using legacy algorithms or profiles would still be able to do
this if required by their system when required based on better information
than conveyed as indicated in this draft.

On Dec 15, 2014 11:25 AM, "Kevin Gross" <[email-masked]> wrote:
>
> The timestamp in SRs is NTP format but RFC 3550 does not require you to
get those time stamps from a specific clock. This RFC (7273) allows you to
signal what clock you're using so senders and receivers can synchronize.
Prior to RFC 7273, receivers made undisclosed assumptions about clocks or
simply adjusted empirically to whatever clocking the sender is doing. The
improvement here is to have a common clock for multiple senders so that
streams can be readily combined at a receiver that is receiving multiple
streams from different senders.
>
> Kevin Gross - AVA Networks
>
> On Mon, Dec 15, 2014 at 7:53 AM, Julius Friedman <[email-masked]>
wrote:
>> The reference clock is virtually set to the time difference between the
ntp timestamp in the sender report and the receiver.
>> What difference does it make if his clock is wrong? Furthermore if
sender uses a clock on mars.
>>
>> Can you succinctly state why we need to know more details about clock
rate than already available 20 years later?
your questions.
>>>
>>> If you have any more questions, I encourage you to voice your opinion
on the AVT mailing list.
>>> Resent-To: "[email-masked]" <[email-masked]>,
<[email-masked]>, Kevin Gross <[email-masked]>, Ray van
Brandenburg <[email-masked]>
>>> After reading it several times I just cannot come to terms with
anything it suggests.
>>> Furthermore each implementation already has the clock rate as a
parameter of the rtpmap or fmtp or the profile default is used.
>>>
>>> This document makes sdp content longer and more complex without any
added benefit or explanation of the mechanism introduced.
>>>
>>> This document also makes no change to any calculation used by a
receiver or sender.
>>> This message may contain information that is not intended for you. If
you are not the addressee or if this message was sent to you by mistake,
you are requested to inform the sender and delete the message. TNO accepts
no liability for the content of this e-mail, for the manner in which you
use it and for damage of any kind resulting from the risks inherent to the
electronic transmission of messages.
>>>
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/avt
>>

---

From: Julius Friedman <[email-masked]>
Date: Tue, 16 Dec 2014 11:35:14 -0500

Unfortunately I disagree.

Rtp connected speakers dont have to be synchronized to each other. If they
did each speaker would adhere to the spec as it's own reciever and handle
loss as indicated in the standard.  They could also have their own
mechanism for synchronicity as provided by the transport layer.

The scenario is no different than a conference where all the participants
are spread out over vast distances or routes with congestion.

There is no reason to obtain or know the clock rate other than how it had
already been specified because the senders report provides this
functionality for multiple streams and single streams.

Doing so in the manner specified by this draft is not backwards compatible
and provides nothing to prevent the clock rate from changing right after it
has been conveyed.

There is no benefit, we didn't need this mechanism 20 years ago and we
certainly dont now.

Because of those reasons as well as the others i have cited my position is
firm until a succinctly defined scenario is defined in which prior
mechanisms fail or it is shown a clear and hassle free benefit of complying
with this draft.

After all if I ignored it I would play data the exact same way as if it was
in use.

The sr would adapt receiver losses as it always has.

This might be better as some informational document and even then I
question its applicability in face of existing mechanisms which are better
defined and more reliable.

Sincerely,
Julius Richard Friedman
On Dec 16, 2014 11:02 AM, "Brandenburg, R. (Ray) van" <
[email-masked]> wrote:

>  Hi Julius,
>
>
>
> I think we’re talking about two different use cases. The use you seem to
> have in mind is one where the issue at hand is synchronization of two or
> more streams on a single device. For that purpose, you’re right that it
> doesn’t matter which clock you’re using (as you mention, it might as well
> be a Mars-based one).
>
>
>
> The use case that is discussed in the RFC is where you have multiple
> receivers and where the goal is to make sure that the streams being played
> out are synchronized between the various receivers. Imagine a stadium where
> you have multiple RTP-connected speakers. In that case, it is very
> important that the reference clock they are using is the same, or at least
> that you know the offset between those clocks.
>
> > This literally makes no sense because even if I knew what clock the
> sender was using I might not be able to access it.
>
> Well, this draft solves the former problem, knowing which clock the sender
> was using. Not having access to that particular server is another problem
> altogether. As long as that is not the case in the overwhelming majority of
> the cases, I don’t think that is reason to disqualify this work.
>
>
>
> Ray
>
>
>
> *From:* avt [mailto:[email-masked]] *On Behalf Of *Julius Friedman
> *Sent:* maandag 15 december 2014 17:37
> *To:* Kevin Gross; [email-masked]
> *Subject:* Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc
>
>
>
> > On Mon, Dec 15, 2014 at 7:53 AM, Julius Friedman <
> [email-masked]> wrote:
> >>
> >>> - There is a difference between specifying a media clock rate (which
> is done in an RTP profile) and specifying how that clock rate is
> determined.
> >>>
> >>> There is no reason to signal rate of media in sdp beyond where each
> rtp profile registered has a default clock rate assigned especially when
> the document provides no mechanism to align the clocks in which it declared
> >>> Lastly Video walls wouldn't need a specified rate to work as they
> would have their own rate and update displays based on that rate.
> >>>
> >>> Any such required information would be an optimiZation to their
> display driver through the operating system, do you really want a rtp
> sender to be able to control the clock rate of your display? If you do use
> snmp or something else.
> >>>

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 17 Dec 2014 13:51:50 +0000

Hi Julius,

>Disagree all you like, until you can articulate a succinctly defined scenario which also handles the issues I cite then I will file errata for them and will not comply with them until such time.

The decision whether to comply or implement this RFC is completely up to you. Nobody is forcing you to implement something you don’t think is necessary. Implementing any RFC is optional, including this one. If you don’t agree with the use case or solution provided, no problem, don’t implement it

>The latter scenario is made up

No, it’s not. As an example: http://en.wikipedia.org/wiki/AES67. This is an A/V Networking  specification that is implemented and used by a number of companies, as announced in various public press releases. The clock source RFC that we’re discussing here is a normative reference in that specification. Another example is RFC7272, which present a solution for synchronising playback on different receivers.

Ray

From: Julius Friedman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 17 December 2014 14:29
To: Ray van Brandenburg <[email-masked]<mailto:[email-masked]>>
Subject: RE: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc

Ray / AVT

On Dec 17, 2014 4:10 AM, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>> wrote:
> Rtp connected speakers dont have to be synchronized to each other. If they did each speaker would adhere to the spec as it's own reciever and handle loss as indicated in the standard.  They could also have their own mechanism for synchronicity as provided by the transport layer.
>
> This is not about loss. This is not about the transport layer. This is about making sure that if I have a room in which I have multiple RTP-connected speakers, they all play out the audio or video at exactly the same time. How would the transport layer help with that?

Ntp helps with this.  Each speaker would recieve data from a mixer and would play out.

How will knowing the clock rate of the media prevent a unit from malfunction?

What if someone spilled something?  Or there was interference?

What is knowing the clock rate going to do for you then?

Lastly how come that scenario isnt made use of in the draft and instead we have examples with video walls and iptv systems which have their own mechanism for clocks.

>
> The scenario is no different than a conference where all the participants are spread out over vast distances or routes with congestion.
>
> No, it’s not. There is a difference between a scenario where the primary goal is low-delay (conference systems) and a scenario where the primary goal is high quality and synchronicity, in which adding a few seconds of delay to make sure everything is synchronized is acceptable. You seem to be focused on the former, without considering the latter scenario.
>

The latter scenario is made up, and if I didn't consider it I wouldn't feel so strongly about it.

Just because your proprietary system benefits from this doesn't mean mine will nor that I will want to take measures to comply with something which raises several concerns which are not addressed.

> There is no reason to obtain or know the clock rate other than how it had already been specified because the senders report provides this functionality for multiple streams and single streams.
>
> No, it doesn’t. The SR doesn’t specify a reference clock, not its source. All it does  is specify at what time a specific sample was sent.
>

The ntp tells you a reference clock of the sender and also tells you that the rtptimestamp belongs to that time.

How are you calculating jitter and transit?

Wont those still be applied?

> Doing so in the manner specified by this draft is not backwards compatible and provides nothing to prevent the clock rate from changing right after it has been conveyed.
>

The clock source which may not be accessible,  correct or ever change reference or rate?

> That is _exactly_ the reason why we don’t convey the clock rate but communicate the clock source. And I don’t see how making use of this RFC has any impact on backwards compatibility.
>

Its easy,  if I didn't need to look for or account for the source now and now I need to this is not compatible.

Also since you don't specifically define how changes are handled in the clock among other issues i brought up.

> There is no benefit, we didn't need this mechanism 20 years ago and we certainly dont now.
>
> Thanks for sharing your opinion. I disagree.
>

The facts are still the facts.

I have worked with several types of video walls and iptv systems.

In no aspect did a source clock ever come up or present itself as an issue.

I would have loved to hear how this solves an issue in real life rather then made up scenarios.

I could also argue that each speaker could have it's own dynamic content and due to handicap or special content not require the same play out as other speakers.

Disagree all you like, until you can articulate a succinctly defined scenario which also handles the issues I cite then I will file errata for them and will not comply with them until such time.

Sincerely,
Julius Richard Friedman

> Ray
>
> Because of those reasons as well as the others i have cited my position is firm until a succinctly defined scenario is defined in which prior mechanisms fail or it is shown a clear and hassle free benefit of complying with this draft.
>
> After all if I ignored it I would play data the exact same way as if it was in use.
>
> This might be better as some informational document and even then I question its applicability in face of existing mechanisms which are better defined and more reliable.
>
> Sincerely,
> Julius Richard Friedman
>
> On Dec 16, 2014 11:02 AM, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Julius,
>
>
>
> I think we’re talking about two different use cases. The use you seem to have in mind is one where the issue at hand is synchronization of two or more streams on a single device. For that purpose, you’re right that it doesn’t matter which clock you’re using (as you mention, it might as well be a Mars-based one).
>
>
>
> The use case that is discussed in the RFC is where you have multiple receivers and where the goal is to make sure that the streams being played out are synchronized between the various receivers. Imagine a stadium where you have multiple RTP-connected speakers. In that case, it is very important that the reference clock they are using is the same, or at least that you know the offset between those clocks.
>
> > This literally makes no sense because even if I knew what clock the sender was using I might not be able to access it.
>
> Well, this draft solves the former problem, knowing which clock the sender was using. Not having access to that particular server is another problem altogether. As long as that is not the case in the overwhelming majority of the cases, I don’t think that is reason to disqualify this work.
>
>
>
> Ray
>
>
>
> From: avt [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Julius Friedman
> Sent: maandag 15 december 2014 17:37
> To: Kevin Gross; [email-masked]<mailto:[email-masked]>
> Subject: Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc
>
>
>
> This literally makes no sense because even if I knew what clock the sender was using I might not be able to access it.
>
> What if there is confusing information about a source?  E.g. its true identity.
>
> Multiple streams are combined by a mixer and hence the mixer accounts for the rate adjusting if required to mix each sample.
>
> This doesn't really help a mixer perform that function any easier for the reasons stated and only would under situations where it was designed to.
>
> Receivers using legacy algorithms or profiles would still be able to do this if required by their system when required based on better information than conveyed as indicated in this draft.
>
> On Dec 15, 2014 11:25 AM, "Kevin Gross" <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > The timestamp in SRs is NTP format but RFC 3550 does not require you to get those time stamps from a specific clock. This RFC (7273) allows you to signal what clock you're using so senders and receivers can synchronize. Prior to RFC 7273, receivers made undisclosed assumptions about clocks or simply adjusted empirically to whatever clocking the sender is doing. The improvement here is to have a common clock for multiple senders so that streams can be readily combined at a receiver that is receiving multiple streams from different senders.
> >
> > On Mon, Dec 15, 2014 at 7:53 AM, Julius Friedman <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >> The reference clock is virtually set to the time difference between the ntp timestamp in the sender report and the receiver.
> >>
> >> What difference does it make if his clock is wrong? Furthermore if sender uses a clock on mars.
> >>
> >> Can you succinctly state why we need to know more details about clock rate than already available 20 years later?
> >>
> >> On Dec 15, 2014 3:11 AM, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>> wrote:
> >>>
> >>> Hi Julius,
> >>>
> >>> I advise you to read section 2 on Applications. It will answer most of your questions.
> >>>
> >>> - There is a difference between a media clock and a reference clock. I don’t see how any RTP profile or current SDP is going to help you to know which reference clock you’re using. Without that information, how are you going to synchronize two different receivers?
> >>> - There is a difference between specifying a media clock rate (which is done in an RTP profile) and specifying how that clock rate is determined.
> >>>
> >>> If you have any more questions, I encourage you to voice your opinion on the AVT mailing list.
> >>>
> >>> Best regards,
> >>>
> >>> Ray

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 17 Dec 2014 09:04:20 -0500

On Wed, Dec 17, 2014 at 8:51 AM, Brandenburg, R. (Ray) van <
[email-masked]> wrote:
>
> until you can articulate a succinctly defined scenario which also handles
> the issues I cite then I will file errata

Until now I never thought that errata could be wielded as a weapon...

"Clear that DISCUSS or I will file errata!" :D

Simon

---

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

Ntp synchronized receivers.

This mechanism is additional and allows for more error for the reasons I
already stated.

You can synchronize with rtcp alone.

Additionally if my speakers are not ip compatible then your notion and
reference makes little sense.

There is no reason for a new sdp line and new semantics for clocks without
properly defining the scenarios i have outlined and their resulting effects
on existing systems.

Hence my position is unchanged.
On Dec 17, 2014 8:51 AM, "Brandenburg, R. (Ray) van" <
[email-masked]> wrote:

>  Hi Julius,
>
>  >Disagree all you like, until you can articulate a succinctly defined
> scenario which also handles the issues I cite then I will file errata for
> them and will not comply with them until such time.
>
>  The decision whether to comply or implement this RFC is completely up to
> you. Nobody is forcing you to implement something you don’t think is
> necessary. Implementing any RFC is optional, including this one. If you
> don’t agree with the use case or solution provided, no problem, don’t
> implement it
>
>  No, it’s not. As an example: http://en.wikipedia.org/wiki/AES67. This is
> an A/V Networking  specification that is implemented and used by a number
> of companies, as announced in various public press releases. The clock
> source RFC that we’re discussing here is a normative reference in that
> specification. Another example is RFC7272, which present a solution for
> synchronising playback on different receivers.
>
>  Ray
>
>
>
> To: Ray van Brandenburg <[email-masked]>
> On Dec 17, 2014 4:10 AM, "Brandenburg, R. (Ray) van" <
> > Rtp connected speakers dont have to be synchronized to each other. If
> they did each speaker would adhere to the spec as it's own reciever and
> handle loss as indicated in the standard.  They could also have their own
> > This is not about loss. This is not about the transport layer. This is
> about making sure that if I have a room in which I have multiple
> RTP-connected speakers, they all play out the audio or video at exactly the
> same time. How would the transport layer help with that?
>
> Lastly how come that scenario isnt made use of in the draft and instead we
> have examples with video walls and iptv systems which have their own
> mechanism for clocks.
>
> >
> > The scenario is no different than a conference where all the
> participants are spread out over vast distances or routes with congestion.
> >
> > No, it’s not. There is a difference between a scenario where the primary
> goal is low-delay (conference systems) and a scenario where the primary
> goal is high quality and synchronicity, in which adding a few seconds of
> delay to make sure everything is synchronized is acceptable. You seem to be
> focused on the former, without considering the latter scenario.
> >
>
> Just because your proprietary system benefits from this doesn't mean mine
> will nor that I will want to take measures to comply with something which
> raises several concerns which are not addressed.
>
> > There is no reason to obtain or know the clock rate other than how it
> had already been specified because the senders report provides this
> > No, it doesn’t. The SR doesn’t specify a reference clock, not its
> source. All it does  is specify at what time a specific sample was sent.
> >
>
> > Doing so in the manner specified by this draft is not backwards
> compatible and provides nothing to prevent the clock rate from changing
> right after it has been conveyed.
> >
>
> > That is _exactly_ the reason why we don’t convey the clock rate but
> communicate the clock source. And I don’t see how making use of this RFC
> has any impact on backwards compatibility.
> >
>
> I could also argue that each speaker could have it's own dynamic content
> and due to handicap or special content not require the same play out as
> other speakers.
>
> Disagree all you like, until you can articulate a succinctly defined
> scenario which also handles the issues I cite then I will file errata for
> them and will not comply with them until such time.
>
> Sincerely,
> Julius Richard Friedman
>
> > Ray
> >
> > Because of those reasons as well as the others i have cited my position
> is firm until a succinctly defined scenario is defined in which prior
> > Well, this draft solves the former problem, knowing which clock the
> sender was using. Not having access to that particular server is another
> problem altogether. As long as that is not the case in the overwhelming
> majority of the cases, I don’t think that is reason to disqualify this work.
> >
> >
> >
> > Ray
> >
> >
> >
> > From: avt [mailto:[email-masked]] On Behalf Of Julius Friedman
> > To: Kevin Gross; [email-masked]
> > Multiple streams are combined by a mixer and hence the mixer accounts
> for the rate adjusting if required to mix each sample.
> >
> > This doesn't really help a mixer perform that function any easier for
> the reasons stated and only would under situations where it was designed to.
> >
> > > The timestamp in SRs is NTP format but RFC 3550 does not require you
> to get those time stamps from a specific clock. This RFC (7273) allows you
> to signal what clock you're using so senders and receivers can synchronize.
> > >> The reference clock is virtually set to the time difference between
> the ntp timestamp in the sender report and the receiver.
> > >>
> > >>> - There is a difference between a media clock and a reference clock.
> I don’t see how any RTP profile or current SDP is going to help you to know

---

From: Julius Friedman <[email-masked]>
Date: Wed, 17 Dec 2014 09:20:35 -0500

Well I didn't know that we could define rfc documents for things which
break others.

I also didn't realize that we published them either without determining
applicability and appropriateness in ALL use cases.

Its not my fault no one used the standard tools available.

Its also not my fault basic changes which allow correct operations  are
turned away but proprietary documents which outline incomplete mechanisms
are indeed accepted.

Get on the ball / with the times already.

If you understood the topics at hand as well as you elude to then I
obviously wouldn't have any issues and wouldn't be urged to clean up a mess
I see which provides no benefits and incomplete information.

Obviously rtp has had this problem from the beginning and rather then just
make a new protocol we all agree on we bastardize standards existing and
convoluted the implementation so much rtp systems are more complex then
mpeg which is transported under rtp.

The points have been made and its not a threat its a promise.

Sincerely,
Julius Richard Friedman

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 17 Dec 2014 07:21:33 -0700

On 12/17/2014 07:04 AM, Simon Perreault wrote:
> 
> On Wed, Dec 17, 2014 at 8:51 AM, Brandenburg, R. (Ray) van <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     until you can articulate a succinctly defined scenario which also handles the issues I cite then I will file errata
> 
> 

IMO the errata process is broken.  It's not a bug tracking system and each time someone fills a bogus errata it adds burden on protocol implementers.

Follow-up on [email-masked]

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 17 Dec 2014 14:22:19 +0000

> Additionally if my speakers are not ip compatible then your notion and reference makes little sense.
I sincerely hope this is a joke and not a serious argument…

Ray

From: Julius Friedman [mailto:[email-masked]]
Sent: woensdag 17 december 2014 15:10
To: Brandenburg, R. (Ray) van; [email-masked]
Subject: Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc

This mechanism is additional and allows for more error for the reasons I already stated.

Additionally if my speakers are not ip compatible then your notion and reference makes little sense.

There is no reason for a new sdp line and new semantics for clocks without properly defining the scenarios i have outlined and their resulting effects on existing systems.

Hence my position is unchanged.
On Dec 17, 2014 8:51 AM, "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Julius,

Ray

Ray / AVT

Sincerely,
Julius Richard Friedman

---

From: "Stokking, H.M. (Hans)" <[email-masked]>
Date: Wed, 17 Dec 2014 14:39:45 +0000

Hi Julius,

Just a question: where does all this come from?

You are being quite aggressive in the e-mails to this list (at least, that’s how your language comes across to me), somewhat out-of-the-blue. All these RFCs have gone through the processes within the IETF, and thus quite some knowledgable people have done extensive reviews on them.

I’m just trying to understand why you are acting the way you are: you are being quite rude (again, that’s how you come across to me) to people who take the time and effort to work together in the IETF process. This is not helping you, in that it doesn’t make people want to help you (again, that is just my guess, if this is true, I don’t know).

Cheers, Hans

Ray

Ray / AVT

Sincerely,
Julius Richard Friedman