Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03
Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 06 May 2013 14:45 UTC
Return-Path: <prvs=0838ce92b4=magnus.westerlund@ericsson.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 9F16121F93B9 for <avt@ietfa.amsl.com>; Mon, 6 May 2013 07:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.571
X-Spam-Level:
X-Spam-Status: No, score=-104.571 tagged_above=-999 required=5 tests=[AWL=-1.678, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100]
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 E4BKNOPS1vbe for <avt@ietfa.amsl.com>; Mon, 6 May 2013 07:45:27 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6121F938E for <avt@ietf.org>; Mon, 6 May 2013 07:45:26 -0700 (PDT)
X-AuditID: c1b4fb30-b7f3a6d0000007a4-9e-5187c205c499
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 14.92.01956.502C7815; Mon, 6 May 2013 16:45:25 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 6 May 2013 16:45:25 +0200
Message-ID: <5187C204.1060907@ericsson.com>
Date: Mon, 06 May 2013 16:45:24 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Kevin Gross <kevin.gross@avanw.com>
References: <5163DF09.7050606@ericsson.com> <CALw1_Q08JKDV9W8yCiTa_+thX1NodzUojbrPjTzt4vAR9wKLrw@mail.gmail.com> <517636E0.2020607@ericsson.com> <CALw1_Q3cAy3-9xHGQ0xOoig3ZCiP_O-4rDf0_nndCY2pMwxXrA@mail.gmail.com>
In-Reply-To: <CALw1_Q3cAy3-9xHGQ0xOoig3ZCiP_O-4rDf0_nndCY2pMwxXrA@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+JvrS7rofZAg4NNlhYve1ayW7w41M7m wOTx7+p2Zo8lS34yBTBFcdskJZaUBWem5+nbJXBnnP52h6nglm/FpM87WRoYv9p0MXJwSAiY SEx5kt7FyAlkiklcuLeeDcQWEjjFKNF1wK2LkQvIXsYocatjNliCV0Bb4uj+DUwgNouAisTB x5fYQWw2AQuJmz8a2UBmigoES2xtjYEoF5Q4OfMJC4gtIqAu8WjXQ7BWZgEliblLXzOD2MIC 9hJvLx9kgdh1lVHiTPNNVpAEp0CgxMtN79kgjpOU2PKinR2iWU9iytUWRghbXqJ562xmiKO1 JRqaOlgnMArNQrJ7FpKWWUhaFjAyr2Jkz03MzEkvN9/ECAzVg1t+G+xg3HRf7BCjNAeLkjhv MldjoJBAemJJanZqakFqUXxRaU5q8SFGJg5OEMEl1cA4k+uZZrXEoTk/pJylyz6uWZApY2ht f+pFf3S74s3mE3zhLy7xTWw6I2Ohum/ytMd/Xx7/88XjC1+82bw7G9e5q8dnPVsW9oFT8ZPN 7Ne8DN1a39KrH+xeHRxn+vtIeq7aa6OLPvw7i0uiXl7fd4nD/eohWT/XfxKc30Xf1duLplw+ MDu+vG61EktxRqKhFnNRcSIAve1v7ygCAAA=
Cc: 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: Mon, 06 May 2013 14:45:33 -0000
Hi, Rereading the O/A I think I understand what my misunderstandings are. However, that still makes me unclear if even the basic cases for a=ts-refclk can be announced by each side. Lets do an example: A: sends an Offer: v=0 o=jdoe 2890844526 2890842807 IN IP4 192.0.2.1 s=SDP Seminar i=A Seminar on the session description protocol c=IN IP4 233.252.0.1/64 t=2873397496 2873404696 a=ts-refclk:gps m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 Where A is simply telling that his reference clock is GPS based. The other party wants to inform similar that its clock is NTP based and uses the official swedish time from "ntp1.sp.se" is in the answer. The below O/A rules doesn't appear to answer if that can be done or not. 6.1. Usage in Offer/Answer An answer to an offer with direct-referenced media clock and reference clock specification must 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 the signals or return only the reference clock specification. In this case, a connection is established assuming an asynchronous media clock. An answer to an offer with media-referenced media clock specification must include the same media clock specification. The answer MUST include the same reference clock signalling or may drop the 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 by the answerer, the stream may be established as rate synchronized but not time synchronized. An asynchronous media clock is the default media clock mode. This mode may be explicitly signalled or presumed due to lack of signalling. Asynchronous media clocking does not require reference clock signalling. An offer with asynchronous media clocking MAY include reference clock signalling. Because the asynchronous media clock is the default mode, the answerer is not required to explicitly signal this even if it is explicitly signalled in the offer. Maybe I am misreading the above. There are some unclarity in the spec. First paragraph appears to say that an answer to an offer including both ts-refclk and mediaclk (direct-referenced) must include the same media clock and reference clock. If not both can be given (due to not being the same), then one can send only the reference clock or nothing. Then a default behavior that is unclear if it applies to both cases of alternative behavior. Second paragraph: If one uses media clock that is media-referecend then the answer MUST have the same clock or remove it. Then what happens if the reference-clock is not included in the answer is specified. However, no rules for if it is included. Third paragraph: The interpretation of not signalling explictly any media clock. And that it can be dropped in the answer even if explicitly given the default in the offer. My current understanding of the issue is that the O/A rules intended to describe the following: 1) When including a=mediaclk one MUST include also a reference clock. 2) If a mediaclock is provided the answer must support that same clock, (type and identity?) 3) If no media clock is provided then it is asynchronous, which is not required to be signalled. If included in offer, answer can rely on default and not include it. In addition to this I think some additional rules are missing. A) Regarding the values that can be included in each sides attribute. It might be indication elsewhere of this as I think I remember such rules but can't find it. Especially as it may be that a=ts-refclk works declarative, and each side can provide whatever clock it actually uses and simply declare it, while mediaclk requires to use the same. This must be made explicit for each of the attributes. B) Is it good to fallback to default, as it doesn't allow an offerer to determine if the peer supports clock signaling? Even if it uses default, maybe that should always be made explicit to indicate the support. Note, I am not saying that you don't need to define what default is. I am saying that a O/A agent that supports this signalling and uses the same clock as default shall make that explicit in the offer. Is this the authors intention and desire to have such capabilities in the signalling? The above issues are the most import to resolve as the signalling capabilities you intended to describe is not clear. At least not to me. The next question is do you intended to have any negotiation of which clock(s) should be used? From your answer I get the impression that you think not, and that media capneg will be sufficient to express the alternative combinations of mediaclk and ts-refclk that the offerer supports and thus enable selection of a common set? I don't have any strong views on this. My personal opinion is that I don't think media capneg will be particular well implemented and if one wants negotiation one needs to support that in the signalling one defines. IF the authors have no interest and there is no consensus for such requirements then I will hold my silence regarding this capability. Cheers On 2013-05-05 05:29, Kevin Gross wrote: > Magnus, > > 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 > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org > <http://www.X192.org> > > > On Tue, Apr 23, 2013 at 1:23 AM, Magnus Westerlund > <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>> > 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 > -- 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: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [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