Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03
"Roni Even" <ron.even.tlv@gmail.com> Sun, 05 May 2013 09:16 UTC
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639A921F8FFB for <avt@ietfa.amsl.com>; Sun, 5 May 2013 02:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.642
X-Spam-Level:
X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SARE_SUB_6CONS_WORD=0.356]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehI-hyr3Tno3 for <avt@ietfa.amsl.com>; Sun, 5 May 2013 02:16:26 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id B3B1621F8D2E for <avt@ietf.org>; Sun, 5 May 2013 02:16:25 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id m15so2751281wgh.29 for <avt@ietf.org>; Sun, 05 May 2013 02:16:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=IJqay5cwTPPkI67CbOALHPoCOH7/ScsAkKmGrN7133Q=; b=ZP/oB8u3HsADKBopdwKPfSvl5gOUPwYv1KW0h89Lzi59zY8AviEZGB+GB5qoJ3LrvZ m0xgSPlE3WvBbwBWzzvTgj8Xy9tJN5h11CvkK5ukUHl0Yu0FMSwoulfdqHdJoJJjS4cp moVMWs9iERSCpFTkKoZMM2se6pM75mbGIEs6zs93psGQSVBzp8SZjHyzzgFN+cJcGFmT xvqeaJg3MmsuglP64SUtggOHKQtXze3pE0nBHL40OoQcw6oOa6NBWNalN+DEbloJ0wMw 253WkvunyR+HQ7fB0F2jqlrHqWBr7wzVP7QxS/qIT47kMKOdcYnuNBrr1W1FjXV/LBpz vwZg==
X-Received: by 10.194.7.68 with SMTP id h4mr20595634wja.49.1367745384768; Sun, 05 May 2013 02:16:24 -0700 (PDT)
Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id g4sm7720800wib.11.2013.05.05.02.16.18 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 05 May 2013 02:16:23 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Kevin Gross' <kevin.gross@avanw.com>
References: <5163DF09.7050606@ericsson.com> <CALw1_Q08JKDV9W8yCiTa_+thX1NodzUojbrPjTzt4vAR9wKLrw@mail.gmail.com> <02d601ce40f4$2e765d30$8b631790$@gmail.com> <CALw1_Q3pEvKiMD1Qch7V9dEbVoNYmLJ8BrmuJNTwMXqwEJyo2Q@mail.gmail.com>
In-Reply-To: <CALw1_Q3pEvKiMD1Qch7V9dEbVoNYmLJ8BrmuJNTwMXqwEJyo2Q@mail.gmail.com>
Date: Sun, 05 May 2013 12:15:37 +0300
Message-ID: <020401ce4971$20defda0$629cf8e0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0205_01CE498A.462F69F0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ5HC9wvVjoQVUfIZENIsmmA9Bo8wEz1q+HAk9T2m4CUdmWBJdyAXxA
Content-Language: en-us
Cc: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, 'IETF AVTCore WG' <avt@ietf.org>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 May 2013 09:16:33 -0000
Hi Kevin, On comment 2. The syntax is timestamp-refclk = "a=ts-refclk:" clksrc CRLF clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext ntp = "ntp=" ntp-server-addr ntp-server-addr = host [ ":" port ] ntp-server-addr =/ "traceable" this is why I expected a host address Roni From: Kevin Gross [mailto:kevin.gross@avanw.com] Sent: 05 May, 2013 7:03 AM To: Roni Even Cc: Magnus Westerlund; IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 Roni, Thanks for the review. See below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com <http://www.avanw.com/> , www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even <ron.even.tlv@gmail.com> wrote: 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 negotiation. What we're trying to say is that you're allowed to list multiple clock sources with the understanding that all listed clocks deliver the same time. Any of the clocks can be used interchangeably and synchronization is assured. This capability is intended to support fault-tolerant clock distribution scenarios. 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 For backwards compatibility, when no clock attribute is specified in a description, it has a specific meaning (e.g. local time reference or free-running media clock). For this reason, the answer must echo the offer's clock attribute. This is acknowledgement to the offerer that answerer recognises and supports the clksrc attributes. Other comments 1. ptp-domain-name = "domain-name=" 16ptp-domain-char did you mean exactly 16 charaters? Basically, yes, although I admit it is a bit strange. IEEE 1588-2002 (clause 6.2.5.1) domain names are 16 character fixed-length strings. Shorter-looking names can be used but they are padded out with null characters. 2. In figure 2 a=ts-refclk:ntp=traceable do you need also to specify the server address? Traceable sources imply TAI-based time. Any TAI source of a particular technology (e.g. GPS, NTP) is assumed to be equivalent to any other TAI source using the same technology. We appreciate that this is a crude simplification but trying to go further takes us down a rabbit hole. 3. In figure 3 a=ts-refclk:ntp=203.0.113.10 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. This is a timestamp left over from a previous "clock quality" proposal that has since been removed from the draft. I had already made note to remove this if no one caught in WGLC :) 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 Another issue I had already noted for correction. 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 We will review RFC 5226 again and correct this. 6. The IANA section is not fully compliant with the requirements from RFC4566 you can look at examples in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-13 IANA section or other MMUSIC RFCs We will review RFC 4566 and correct this. Thanks for a pointer to examples. Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin Gross Sent: 18 April, 2013 1:41 AM To: Magnus Westerlund Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 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. 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 +1-303-447-0517 <tel:%2B1-303-447-0517> Media Network Consultant AVA Networks - www.AVAnw.com <http://www.avanw.com/> , www.X192.org On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: Hi, 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 information. 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 signalling: 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 needs. 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. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 <tel:%2B46%2010%207148287> Färögatan 6 | Mobile +46 73 0949079 <tel:%2B46%2073%200949079> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _____
- [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 Magnus Westerlund
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Kevin Gross
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Magnus Westerlund
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Roni Even
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Kevin Gross
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Kevin Gross
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Roni Even
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Roni Even
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Magnus Westerlund
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Kevin Gross
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Roni Even
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Magnus Westerlund
- Re: [AVTCORE] Comments on draft-ietf-avtcore-clks… Kevin Gross