Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt

[Magnus Westerlund <[e-mail]>]

Hi,

I have reivewed the changes and I don't think Section 6.1 nor 6.2 is clear.

Intro and the clarification of the relationship between media clock and
reference clock is good.

"Usage of reference clock and media clock signalling in offer/answer
   allows the offerer to declare the reference clock and media clock in
   use and allows the answerer to acknowledge that a connection
   according to these declarations will be successful or, in limited
   cases described below, specify a simplified synchronization mode."

This implies that the rules also for reference clock handling is to be
specified. That is not the case. There is no explanation what an
Reference clock offer means and what the limiations on that offer is,
nor what the answerer should send back.

To my understanding something like this is needed.

An offer MAY include multiple a=ts-refclk attributes, however if there
is more than one attribute, they MUST be for multiple instances of the
same clock type and reference type and be possible to use
interchangeable. If an answerer supports and can access the proposed
reference clock it SHALL include all reference clock attributes offered
that it supports. If none are supported and accessible then the
a=ts-refclk attribute SHALL NOT be included in the answer.

Question: Should as alternative to no a=ts-refclk in the answer
a=ts-refclk:private be allowed as indication that the answer will run on
its clock?

And in this case when it is not supported, are there no benefit in the
answerer identifying the clock it will actually use, despite that a
common clock sync was not achieved?

Then I think it makes sense to follow this by:

  "While full negotiation of reference clock and media clock attributes
   is not directly supported in the clock source signalling defined in
   this document, negotiation MAY be accomplished using capabilities
   negotiation procedures defined in [RFC5939]."


Then we have  the use of SHOULD:

   An answer to an offer with direct-referenced media clock SHOULD
   include the same media clock and reference clock signalling in which
   case a connection is established using the specified synchronisation.
   Alternatively the answer MAY omit both signals or include only the
   reference clock specified in the offer.  In this case, a connection
   with asynchronous media clock is established.


What are the exceptions for this SHOULD? Using SHOULD allows for other
cases of excluding it then specified. If there are a one or few
exceptions, it is much better to write SHALL, except for ...

At least make clear what the exceptions are and how to interpret when it
not present. So what does it mean to the answerer to receive an OFFER
with different Media clock and reference clock. How should it answer it.

   An answer to an offer with stream-referenced media clock signalling
   SHOULD include the same media clock specification.  If the offer
   contains reference clock signalling, the answer SHOULD include the
   same reference clock specification.  The answer MAY omit reference
   clock signalling.  If reference clock signalling is not present in
   the answer, either due to not being present in the offer or due to
   being dropped in the answer, the stream may be established as rate
   synchronised but not time synchronised.


I also think this above section mixes up reference clock signalling
(a=ts-refclk) with a=mediaclk. I think it would better with a clearer
full spec for just the reference clock, like my proposal above, then
followed by the a=mediaclk rules, especially in relation to the ts-refclk.

It might be also good to write more rules on what applies for the
Offerer constructing the offer.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------