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

Kevin Gross <> Mon, 13 May 2013 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63C9221F9003 for <>; Mon, 13 May 2013 13:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.142
X-Spam-Level: *
X-Spam-Status: No, score=1.142 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RDNS_NONE=0.1, SARE_SUB_6CONS_WORD=0.356]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e7QAxB69oogE for <>; Mon, 13 May 2013 13:40:22 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe2d:44:76:96:27:243]) by (Postfix) with ESMTP id 7A18221F8733 for <>; Mon, 13 May 2013 13:40:21 -0700 (PDT)
Received: from ([]) by with comcast id bV5D1l0061vN32cADYgMDu; Mon, 13 May 2013 20:40:21 +0000
Received: from ([]) by with comcast id bYeL1l00Q3sr69M8iYeLwi; Mon, 13 May 2013 20:38:21 +0000
Received: by with SMTP id c13so13016573ieb.24 for <>; Mon, 13 May 2013 13:38:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lPQr8W6dHSvLanGiHMGW+bXduFjWyUg9ZGb+DXRssbQ=; b=LlrQEzoQDg1mBrF1ZcaeCqlfn9o7QXWDi+3w7zwjKWBsIcFyRlTc6VdPbR5nVBTPWX 8poRkbiTwyh4qwJttovu24qHsDllNUi65Im3E+V+B7bUUVcU2FY6di26hxEUrzHoc/Pg 47Ftp2Dei5YmPd8TqsCR3lhuy8vdaD6CSkuUiY42IG7ZM6prSAumQYb7KWrOMPdnfQ0l iggZlBj51imXXrr5pPHubmpfEBv9dTxXvcaqpPcFa4tKTtGqcVX8WHM4WDKfLEfGSNTx 3tZkeNpnYWSnE90l3Ze6HP5sxIRVM2icf56yJhJpXy3+yo5tbT7mQ4e7Q1p27YpnJzdy XM6w==
MIME-Version: 1.0
X-Received: by with SMTP id ck5mr10739014igb.107.1368477500277; Mon, 13 May 2013 13:38:20 -0700 (PDT)
Received: by with HTTP; Mon, 13 May 2013 13:38:20 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 13 May 2013 14:38:20 -0600
Message-ID: <>
From: Kevin Gross <>
To: Magnus Westerlund <>
Content-Type: multipart/alternative; boundary="047d7b10d03d498fa904dc9f7fdd"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1368477621; bh=lPQr8W6dHSvLanGiHMGW+bXduFjWyUg9ZGb+DXRssbQ=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=J8mZ6d20X2A7eCRoWskXKoV3dZKId/eiasmRFfXBBwHqX6fS6pfQv30h9Z+fd8ePW j8TLOJkPoQ1Jtrj3HxEvhynN6b3OGN+OVFoByV52KODZJylLqhfCE+GYEUhDjaFTlw igqnBzMYAxLSqgAscZ1mjtw7MHLQsgue8jwVHL9++xw+3PuL4gha8pVQJh78VoXkri 9Hzs2RiTe0kFPu3Y4dSFUPg2VDRxXsYWhmMeASY1H2foaG3leA/iTAXf5kbxpxnfNL tlorLRRRNzY2y1P+snbmyJXI8glrTA0MavfR/ex7vk01T4f0K0qYdmF42Ll01UoXa8 2gPlXgdLIFNBQ==
Cc: "" <>, "" <>
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 20:40:26 -0000

Thanks for your continued help improving this. Let me know what you think
about my answers and proposed revisions below.

Kevin Gross
Media Network Consultant
AVA Networks - <>,

On Mon, May 13, 2013 at 2:45 AM, Magnus Westerlund <> wrote:

> 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.

Reference clock requirements are discussed in parallel with media clock in
the paragraphs that follow.

> 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.

The meaning of multiple reference clock specifications is described in
section 4.2 and now also 4.3. I think it would be useful to reiterate and
expand on the meaning of this in the context of offer/answer as you have

> 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?

I don't think it is useful for an answer to contain a reference clock
specification that is not in the offer. This proposed semantic doesn't fit
the normal offer/answer paradigm where the answer describes the connection
that will actually be made. When there is no common reference clock, the
connection that is made is without a reference clock.

> 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]."
> I think this already covered in the second paragraph of section 6.1. I
don't think we want to describe media clock and reference clock
offer/answer as separate topics because there are interactions: some media
clock modes do not require a reference clock, others do.

> 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.

The answerer options we're trying to document are:

   1. Include the same media and reference signaling - establish connection
   as offered - expected behavior for an answerer supporting Clksrc
   2. Omit media and reference signaling - establish asynchronous
   connection - expected behavior for a legacy device
   3. Reject the offer - establish no connection - always an option under
   the offer/answer model

The offer/answer examples I was working from treat this in a manner similar
to what's currently in the draft. There will some restating of RFC 3264
involved but I can revise to be more explicit about these options.

>    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.

I guess this is getting tangled because it is describing two different
types of offer:

   1. Stream-reference media clock with reference clock
   2. Stream-referenced media clock without reference clock

Perhaps splitting this into separate paragraphs or subsections would
clarify things.

> Cheers
> 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:
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Core Maintenance