Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03

Kevin Gross <> Sun, 05 May 2013 03:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04EA921F96C3 for <>; Sat, 4 May 2013 20:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.542
X-Spam-Status: No, score=0.542 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, RDNS_NONE=0.1, SARE_SUB_6CONS_WORD=0.356]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pQg8Zw4euaJ0 for <>; Sat, 4 May 2013 20:29:05 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe2d:43:76:96:30:16]) by (Postfix) with ESMTP id C65D421F96C0 for <>; Sat, 4 May 2013 20:29:05 -0700 (PDT)
Received: from ([]) by with comcast id Y3FR1l00C1wfjNsA13V5JF; Sun, 05 May 2013 03:29:05 +0000
Received: from ([IPv6:2607:f8b0:4001:c03::229]) by with comcast id Y3V41l00F4jVWYZ8j3V4V2; Sun, 05 May 2013 03:29:04 +0000
Received: by with SMTP id u16so1748724iet.0 for <>; Sat, 04 May 2013 20:29:04 -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=Snw44jjDDJydZFFRQC/FiVo85iE+a2KDWniZQYlZIT4=; b=VSMQBHTx5HbuMIx7pz+T02aGVYQBeESFxlCq2clWqh4r5uILiuaPJIHwwo7yymXAe1 4NBip1k2xQIBpO+lY5PbSct7HgxXQDuCuZA/BTc6wEQhVksTEbb6Oq0E5fVPL2nRseDP KqpccLMTrWthlR0ttPOydN9HkwbaPvr1D995Tox5OX+foxBE8iu9TwlPYq0lP2TF9ZkS p8Rk0BcV9Wr5S3UMQ0L9SYc6zUP83ommoiVpmDOrXEDVxkNv+7QTZifPeqkp+/u2p2XY ARJMNjrlCoALqCcrhX+hg+H+NF/yvh8gMwIXQWvbkj4BuBb8BBQlCctL1SCkSRAAzkKY a3iw==
MIME-Version: 1.0
X-Received: by with SMTP id ck5mr1127699igb.107.1367724544190; Sat, 04 May 2013 20:29:04 -0700 (PDT)
Received: by with HTTP; Sat, 4 May 2013 20:29:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sat, 04 May 2013 21:29:03 -0600
Message-ID: <>
From: Kevin Gross <>
To: Magnus Westerlund <>
Content-Type: multipart/alternative; boundary="047d7b10d03d9b744c04dbf02f15"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1367724545; bh=Snw44jjDDJydZFFRQC/FiVo85iE+a2KDWniZQYlZIT4=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=YGvyWXEbZUkqkADv1HkVnvfc6i5sG0cGJatQVvNq2ixalcH9ppUw6cbTuFj/YahL/ BYJVTbvgoqzg28POXEe1uizzGBJfL6YJIDks9OG05Dv8ss0XUtVVe8Dwut/jvaSSKg tVfOq/tcgVIZ2E0RcYNH9aTUewKKxshb6+HUsLo6WnuPkTxk3PfoD7wCXIjK19kNEl h+iuFGppftz4mS9JzCe8EFBpVaZTSaYLwDKI4E28xr+48uT7/hIRXCyqpQeWVAdr5Z HFoKYqS/Y3jzxFAj2g9YvvrFXkX/2s2BVXe5RHSX9AX5y87TKytmxOVmCJ61E9FbCi 2e4O4RnFhqZDQ==
Cc: IETF AVTCore WG <>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03
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: Sun, 05 May 2013 03:29:10 -0000


I believe what we have defined in the draft is the declarative model you
have minimally requested. I believe this gives more functionality than
you're assuming it does. When used on an engineered network, there will
generally be a well-known time source and as such, offers will be
compatible with answers. When used on less constrained networks, devices
may use a "traceable" clock where the specifics of the exact source of the
clock do not need to be exactly matched to make a successful connection.

You appear to be proposing that we invent our own multiple-choice
negotiation scheme. In writing the offer-answer description I assumed that
it would be preferable to use an existing and general scheme for this than
new attribute-specific SDP syntax and semantics. Is there something I am
missing? I appreciate that we can't assume all user agents will implement
RFC 5939 but 5939 is backwards compatible with a declarative fallback mode
for those agents.

RFC 5939 allows you to specify potential configurations as a collected set
of alternate attributes in the pcfg statements (section 3.5.1). The pcfg
syntax is rich enough to express potential interdependency
between reference and media clock attributes.

Kevin Gross
Media Network Consultant
AVA Networks - <>,

On Tue, Apr 23, 2013 at 1:23 AM, Magnus Westerlund <> wrote:

> On 2013-04-18 00:41, Kevin Gross wrote:
> > Magnus,
> >
> > Thanks for looking at this and sorry for the delay responding.
> >
> > I agree that mediaclk-ext is too restrictive. Your suggestion is
> > very accommodating  Something a bit more structured such as 'token "="
> > byte-string' might be more appropriate. I will check with my co authors
> > on this.
> Sure.
> >
> > As there is great precedent for it in SDP, we have implemented a simple
> > offer-answer model. I would propose that systems should use the
> > mechanisms defined in RFC 5939 if negotiation of clock configurations is
> > necessary. Perhaps adding some discussion and a reference to this RFC
> > would help.
> Yes, there are precedence for simple models. However, I think yours are
> over simplified and has unclear goals. Can you please comment on which
> of the goals I discuss below that you see needs to be meet? I think a
> purely declarative model would be better than what you have now, that
> would at least allow the answer to say, I use X when X is different from
> what is in the offer.
> When it comes to CAPNEG that is clearly a possible road, but likely will
> result that almost no one can actually determine your capability for
> clock sources. Instead they will be stuck with the your current proposal.
> I think even going to the model that the answer picks one for both out
> of the offerers capabilities would be better. That would at least enable
> the highest likelihood that both would use the same clocks.
> >
> > I don't think that independently negotiating reference and media clocks
> > as you have suggested will be adequate. Under some implementations,
> > while multiple clocks are supported, certain combinations of media and
> > reference clocks may not be allowed.
> Okay, that is an additional requirement. Which, might not even work well
> with CAPNEG. You will have two independent attributes that actually have
> dependencies. What you say, you appear to indicate that from each side
> you can have restrictions like this: This media-ref clock can only be
> used given that your wall clock source is either of these.
> Cheers
> Magnus