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

Magnus Westerlund <> Mon, 13 May 2013 08:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CEC621F9051 for <>; Mon, 13 May 2013 01:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.949
X-Spam-Status: No, score=-103.949 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wemRpEcoQKCL for <>; Mon, 13 May 2013 01:45:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4F0E221F8F6E for <>; Mon, 13 May 2013 01:45:20 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f536d000006e05-0c-5190a81fd2e8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E2.88.28165.F18A0915; Mon, 13 May 2013 10:45:20 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 13 May 2013 10:45:19 +0200
Message-ID: <>
Date: Mon, 13 May 2013 10:45:19 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3VldhxYRAg+sTGS1e9qxkt5j0dTur A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxoPchW8FMxYqdt9tYGxgvSXUxcnJICJhI fPrynBnCFpO4cG89WxcjF4eQwClGibvPVrKCJIQEljNKPPoiAmLzCmhLTHi1hR3EZhFQlTi3 agMTiM0mYCFx80cjUDMHh6hAsMTW1hiIckGJkzOfsIDYIgJWEmtO7gIrFxZwluj+B7ILZLyj xPF518BGcgo4Sfz4OwPqHkmJLS/aweLMAnoSU662MELY8hLNW2czQ/RqSzQ0dbBOYBSchWTd LCQts5C0LGBkXsXInpuYmZNebriJERiQB7f81t3BeOqcyCFGaQ4WJXHeJK7GQCGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MGgcfFgsvy4tZs3xWAsvRKfHsJzM+RH44/mhJUobKseMLL1zY uWeFHL/wZb3DZXsPKHFYifm4lNZnBrmcidw82/bgi0K3OT9fvL+d4LCZ50DMywWLmRRenXdd nBQeVKTwl21Pf/xD42XnVtzuuz7/Z6PMJec4rkXrp2X++nZxz8L6WZPCPNZnr1ViKc5INNRi LipOBAALlBItFgIAAA==
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 May 2013 08:45:35 -0000


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.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: