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

"Roni Even" <> Wed, 24 April 2013 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0B1821F8D79 for <>; Wed, 24 Apr 2013 07:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.389
X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SARE_SUB_6CONS_WORD=0.356]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ljYMEmGxMpvC for <>; Wed, 24 Apr 2013 07:01:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22b]) by (Postfix) with ESMTP id 9A50321F869A for <>; Wed, 24 Apr 2013 07:01:46 -0700 (PDT)
Received: by with SMTP id i48so1623188wef.2 for <>; Wed, 24 Apr 2013 07:01:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=1wDMAnqwissK6ihz/AG3a58wGbyRJH0vIE9BTHz+Tck=; b=POia8ybvhSM2U0bMH4kLllSKA8w2jUi3PoinugJC633Z7rirZU+rsr9ovD04QfWxQy vLcgmhFppAm615fra0myN4b+5h6fj2cWFEqiZXKDnyVYpGMjzuaaypOtWOjGkkluoRos eFkY0nJT0BqS4AYBqeLgyMWr0ssFch0x9ZC3OVbnAz6B5vfViWmC7acZSVT4VfVMws5U Hv8stV7B9PJjx+rf8dj743l8Zb+4BfQRDhKdInIJ+sbKglHXSZAs9YsC/FxfJrE7q0wa +N9gym3FclKnFf7dLfH/8a0N0aMjsA8dOPxBKM3h2Q70+Up28A7asQuwO427Jld/+UDb PnzA==
X-Received: by with SMTP id x1mr44982820wie.31.1366812105278; Wed, 24 Apr 2013 07:01:45 -0700 (PDT)
Received: from RoniE ( []) by with ESMTPSA id fz3sm4461892wib.0.2013. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Apr 2013 07:01:44 -0700 (PDT)
From: Roni Even <>
To: 'Kevin Gross' <>, 'Magnus Westerlund' <>
References: <> <>
In-Reply-To: <>
Date: Wed, 24 Apr 2013 17:01:09 +0300
Message-ID: <02d601ce40f4$2e765d30$8b631790$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D7_01CE410D.53C5B810"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ5HC9wvVjoQVUfIZENIsmmA9Bo8wEz1q+Hl4YJg/A=
Content-Language: en-us
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: Wed, 24 Apr 2013 14:01:52 -0000

Hi Kevin,

I looked at the document and at Magnus comment.


I am not sure if the document allows offering and two reference clocks. I am
not sure what is meant in section 4.2 

“Two or more NTP servers may be listed at the same level in the session
description to indicate that they are interchangeable.  RTP  senders or
receivers can use any of the listed NTP servers to govern a local clock that
is equivalent to a local clock slaved to a different server.” 

When you say interchangeable and how it relates to Magnus proposal to allow


I also assume that the information in offer/answer and in declarative SDP is
used to provide sender information and not receiver one so is there a reason
to have the same media clock in both direction when using conversional
(offer/answer) application



Other comments


1.       ptp-domain-name =  "domain-name=" 16ptp-domain-char – did you mean
exactly 16 charaters?

2.       In figure 2 a=ts-refclk:ntp=traceable – do you need also to specify
the server address?

3.       In figure 3 a=ts-refclk:ntp= 2011-02-19
21:03:20.345+01:00 – what is the last part with the date and time, I thought
the syntax only have server address.

4.       In section 6.1 the first sentence in the first and second paragraph
it look to me like the “must” is really a “SHOULD”

5.       In section 8 when defining a new registry you need to say what is
the policy for adding values to the registry (I think here it will be
specification required” see RFC 5226 

6.       The IANA section is not fully compliant with the requirements from
RFC4566 you can look at examples in
IANA section or other MMUSIC RFCs


Roni Even




From: [] On Behalf Of Kevin
Sent: 18 April, 2013 1:41 AM
To: Magnus Westerlund
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03




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


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.


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.

Kevin Gross


Media Network Consultant

AVA Networks - <> ,


On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund
<> wrote:


I promised doing an review of the O/A section. I also found some other
issues to consider.

1. Section 5.4:

Figure 5 shows the ABNF [5] grammar for the SDP media clock source

          mediaclk-master = "a=ssrc:" integer SP clk-master-id

          clk-master-id = "mediaclk:master-id=" master-id

          timestamp-mediaclk = "a=mediaclk:" mediaclock

          mediaclock = sender / refclk / streamid / mediaclock-ext

          sender = "sender" sender-ext

          sender-ext = token

          refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext]

          rate = [ SP "rate=" integer "/" integer ]

          direct-ext = token

          streamid = "master-id=" master-id
          streamid =/ "IEEE1722=" avb-stream-id
          streamid =/ streamid-ext

          master-id = EUI48
          avb-stream-id = EUI64

          EUI48 = 5(2HEXDIG ":") 2HEXDIG
          EUI64 = 7(2HEXDIG ":") 2HEXDIG

          streamid-ext = token

          mediaclock-ext = token

I wonder if not the mediaclock-ext construction is to restrictive. As
the refclk produces a sting with white-spaces in it, why isn't other
mediaclock-ext allowed the same freedom? I think the mediaclock-ext can
be basically byte-string, i.e. any character allowed on an SDP line
should be possible to use. Likely the only resteriction should be that
it starts with a token. Thus using:

mediaclock-ext = token [SP byte-string]

This would require a token for identifying the method followed by a
space and then full freedom for anything that is allowed on an SDP
attribute value.

2. Section 6:

Purpose of signalling?

I think this type of signalling can select two levels of goals with

1) Declaring what each SDP O/A uses on its side

2) Negotiating to arrive at the best but available mechanism on both sides.

The currently proposed solution does neither of these. It enables the
offerer to express to declare I intended to use X and for the answer to
say I know that, or simply say I can't tell you because we are not
having the same clocks.

I think we need to be clear what our goals are here. And I will propose
some goals with the signalling based on my understanding of how these
defined timestamp reference clocks and media stream clocks can be used.
And we do need to be aware that different application may have different

Goal with signalling:

1. Enable each media sender to declare its actually used ts-refclk, i.e.
what clock is base for the RTCP SR NTP timestamps
2. Enable each media sender to identify what clock reference is used to
check/drive the media sampling, i.e. RTP timestamp advancement.
3. Enable two media sender using SDP O/A to determine what common clocks
they actually have so they can be used in either of ts-refclk or mediaclk.

The purpose of doing three (3) is really so that one can do the following.
A. has three ts-refclk  it can use. B has two ts-refclk available. They
are going to watch social TV. To make it at all possible for the social
TV service to play out content at A and B in sync they need to have
either of these two things be available.

a) Each has a common clock with the TV service
b) A and B has a common clock

In either of the scenario the TV service will be able to ensure that the
media is played out is sync.

As a technical solution to these issues there are two main solution tracks:

1) Change the respective SDP attributes to provide info on all possible
clocks for that it could be using and let the answer select the most
preferred that both are supporting

2) Leave the current SDP attributes as they are and only use them for
declaration that: I use this! Then add new SDP attributes to negotiate
the list of commonly supported clocks.

At this stage I think 2) is what is simplest and require the least
changes to what already exist.

I will note that this is likely to require a second round of O/A
messages to update used clocks if the arrived common clock(s) are not
the default used ones. But, I don't see a way around these. In SIP one
could use OPTIONS to provide a SDP which includes the negotiation
attribute to enable the other side to select using a clock that is
supported by both. But when that isn't done, it will take two rounds or
other a'priori knowledge.

So my proposal is simply that one create two new SDP attributes one for
each type of clock usage (ts-refclk and mediaclk) and include a list of
clock type and any ID of the clock in a priority order. The O/A is basic
negotiated and the answer removes all clocks it doesn't support and adds
all it supports. Hopefully there is someone in the list that is common.
The highest priority between the two parties should be used when common
clock is required. IF that is not, then these attributes should not be
included. This for example allows one to use a common ts-refclk, but not
require common mediaclk. We should also discuss if the answerer may
change the priority of commonly supported, and if it should or should
not add additional clocks it supports that are not common.

I really appreciate feedback on these comments and ideas.


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