From csp@csperkins.org Fri May 3 10:28:31 2013 Return-Path: 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 B107F21F843A for ; Fri, 3 May 2013 10:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.644 X-Spam-Level: X-Spam-Status: No, score=-103.644 tagged_above=-999 required=5 tests=[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 w33E03rQlLiz for ; Fri, 3 May 2013 10:28:27 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7364021F8B16 for ; Fri, 3 May 2013 09:26:41 -0700 (PDT) Received: from [130.209.247.112] (port=65282 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UYIof-0002QN-LG; Fri, 03 May 2013 17:26:38 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> Date: Fri, 3 May 2013 17:26:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: avt@ietf.org, draft-ietf-avtcore-clksrc@tools.ietf.org Subject: Re: [AVTCORE] WGLC 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:28:31 -0000 On 21 Apr 2013, at 07:39, Roni Even wrote: > I would like to start a WGLC on = http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock = Source Signalling. > =20 > The WGLC will end on May 12th , 2013 > =20 > Please review the draft and send comments to the list. This generally looks good, and I had only one comment: if I'm reading = RFC 5576 correctly, this draft needs to include IANA registrations for = "att-field (source level)" for the SDP attributes, to allow them to be = used in the a=3Dssrc: lines. Making this change will probably also = requires changes to the ABNF, to cleanly separate the syntax for "a=3D..."= and "a=3Dssrc: ..." forms so they can be separately referenced. --=20 Colin Perkins http://csperkins.org/ From kevin.gross@avanw.com Sat May 4 20:29:10 2013 Return-Path: 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 04EA921F96C3 for ; Sat, 4 May 2013 20:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.542 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQg8Zw4euaJ0 for ; Sat, 4 May 2013 20:29:05 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id C65D421F96C0 for ; Sat, 4 May 2013 20:29:05 -0700 (PDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta01.emeryville.ca.mail.comcast.net with comcast id Y3FR1l00C1wfjNsA13V5JF; Sun, 05 May 2013 03:29:05 +0000 Received: from mail-ie0-x229.google.com ([IPv6:2607:f8b0:4001:c03::229]) by omta23.emeryville.ca.mail.comcast.net with comcast id Y3V41l00F4jVWYZ8j3V4V2; Sun, 05 May 2013 03:29:04 +0000 Received: by mail-ie0-f169.google.com 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; d=google.com; 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 10.50.92.69 with SMTP id ck5mr1127699igb.107.1367724544190; Sat, 04 May 2013 20:29:04 -0700 (PDT) Received: by 10.50.180.201 with HTTP; Sat, 4 May 2013 20:29:03 -0700 (PDT) In-Reply-To: <517636E0.2020607@ericsson.com> References: <5163DF09.7050606@ericsson.com> <517636E0.2020607@ericsson.com> Date: Sat, 4 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; d=comcast.net; 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-BeenThere: avt@ietf.org 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 --047d7b10d03d9b744c04dbf02f15 Content-Type: text/plain; charset=ISO-8859-1 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 , www.X192.org On Tue, Apr 23, 2013 at 1:23 AM, Magnus Westerlund < 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 > > --047d7b10d03d9b744c04dbf02f15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Magnus,

I=A0believe=A0what we hav= e defined in the draft is the declarative model you have minimally requeste= d. I=A0believe=A0this gives more functionality than you're assuming it = does. When used on an engineered network, there will generally be a well-kn= own time source and as such, offers will be compatible with answers. When u= sed on less constrained networks, devices may use a "traceable" c= lock where the specifics of the exact source of the clock do not need to be= exactly matched to make a=A0successful=A0connection.

You appear to be proposing that we invent o= ur own multiple-choice negotiation scheme. In writing the offer-answer desc= ription I assumed that it would be=A0preferable=A0to use an existing and ge= neral 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=A0= configurations=A0as a collected set of alternate attributes in the pcfg sta= tements (section 3.5.1). The pcfg syntax is rich enough to express potentia= l interdependency between=A0reference=A0and media clock attributes.

Kevin Gross
+1-303-447-0517
Media Network Consultant
A= VA Networks -=A0www.AVA= nw.com,=A0www.X192.or= g


On Tue, Apr 23, 2013 at 1:23 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wro= te:
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 =A0Something a bit more structured such as 'tok= en "=3D"
> byte-string' might be more appropriate. I will check with my co au= thors
> on this.

Sure.

>
> As there is great precedent for it in SDP, we have implemented a simpl= e
> 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<= br> > would help.

Yes, there are precedence for simple models. However, I think yours a= re
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 c= locks
> 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 w= ell
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

--047d7b10d03d9b744c04dbf02f15-- From kevin.gross@avanw.com Sat May 4 21:04:37 2013 Return-Path: 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 967BB21F8B3A for ; Sat, 4 May 2013 21:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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_16=0.6, RDNS_NONE=0.1, 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 yeb+w1yVmn27 for ; Sat, 4 May 2013 21:04:33 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 372B221F96C3 for ; Sat, 4 May 2013 21:04:33 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Y43u1l0051afHeLAC44ZUc; Sun, 05 May 2013 04:04:33 +0000 Received: from mail-ia0-f170.google.com ([209.85.210.170]) by omta17.emeryville.ca.mail.comcast.net with comcast id Y42Y1l00H3h86TV8d42ZXE; Sun, 05 May 2013 04:02:33 +0000 Received: by mail-ia0-f170.google.com with SMTP id k20so2410075iak.15 for ; Sat, 04 May 2013 21:02:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VOsxJj+D6RNvHdpxwqdnU9XQr4DcHeTNTOLf3VWSZJI=; b=F0fleugA3KrM0x7XTZhagevKuc1cY/UZVuZZM9FbaM3aGOz8S8zEpsx/Ujf5R/Q9Pa +AMXEUAgF/dKIs/4YWYKaH/1timHRtZhFf+pnwuvoR3g/AUxpPpNk8qQpRgK+iYED4n7 SAjye8qsVNXEGPC7Gw0IZZhAywFWtsxealBzok8cp9uvTxoMUoUzSu/9OSVESIJ1XJbs NHdQ1mc3YmISILLu6VsIJc+lbOZYvhlJgRCEYHf8Gfqgnt1OMvJOQmFVbggrqntZo2TF eWBcJyJpuKkh/bhVHl+SF9qZDqsoa5sKS6Qemkts/90WebCR5tHvqhkgWhsjcbik+q1x 6U/w== MIME-Version: 1.0 X-Received: by 10.50.237.71 with SMTP id va7mr1161688igc.88.1367726552316; Sat, 04 May 2013 21:02:32 -0700 (PDT) Received: by 10.50.180.201 with HTTP; Sat, 4 May 2013 21:02:32 -0700 (PDT) In-Reply-To: <02d601ce40f4$2e765d30$8b631790$@gmail.com> References: <5163DF09.7050606@ericsson.com> <02d601ce40f4$2e765d30$8b631790$@gmail.com> Date: Sat, 4 May 2013 22:02:32 -0600 Message-ID: From: Kevin Gross To: Roni Even Content-Type: multipart/alternative; boundary=f46d0447a2434da0a504dbf0a7e7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367726673; bh=VOsxJj+D6RNvHdpxwqdnU9XQr4DcHeTNTOLf3VWSZJI=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=sXssBbSXH/5VUfEL1XEEJHMW85iL6mvtcEHAChA+l8StBYAkz//yVGDhSnh8P72tb xQSC8GUh85gtt//qnf7qoszkkNZwzQ3D9kvoCmeqEs+C0LM5LHOuww4+97id1y4oTe 1QXW+zJWaPB4BgLvI2HUKFUGsxHUcKMpxRCtMhhmCM7d0Dr+WpIU2vn+KsH+k90YZs cfzTChJPnhks9YMkA+MnA/UQZs9SwOmvvFfeVE8KsaHqABcaxcNowpWZkhHIkfr06k U4shaS398Lx99sbrIWZ/eepZjcWBvDa9iBAJC54ANymLTPdzF3Qvx6Y7HHirwQq8Ef hm+cf5nLRkRww== Cc: Magnus Westerlund , IETF AVTCore WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 04:04:37 -0000 --f46d0447a2434da0a504dbf0a7e7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Roni, Thanks for the review. See below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even 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 **** > > =93Two 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.=94 **** > > 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 =3D "domain-name=3D" 16ptp-domain-char =96 = 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=3Dts-refclk:ntp=3Dtraceable =96 do you need al= so 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=3Dts-refclk:ntp=3D203.0.113.10 2011-02-19 > 21:03:20.345+01:00 =96 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 =93must=94 is really a =93SHOULD=94 > 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 wil= l > be specification required=94 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-1= 3IANA 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 "=3D" > byte-string' might be more appropriate. I will check with my co authors o= n > 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 mechanism= s > 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 a= s > you have suggested will be adequate. Under some implementations, while > multiple clocks are supported, certain combinations of media and referenc= e > clocks may not be allowed.**** > > > **** > > Kevin Gross**** > > +1-303-447-0517**** > > Media Network Consultant**** > > AVA Networks - 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 =3D "a=3Dssrc:" integer SP clk-master-id > > clk-master-id =3D "mediaclk:master-id=3D" master-id > > timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock > > mediaclock =3D sender / refclk / streamid / mediaclock-ext > > sender =3D "sender" sender-ext > > sender-ext =3D token > > refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-ext] > > rate =3D [ SP "rate=3D" integer "/" integer ] > > direct-ext =3D token > > streamid =3D "master-id=3D" master-id > streamid =3D/ "IEEE1722=3D" avb-stream-id > streamid =3D/ streamid-ext > > master-id =3D EUI48 > avb-stream-id =3D EUI64 > > EUI48 =3D 5(2HEXDIG ":") 2HEXDIG > EUI64 =3D 7(2HEXDIG ":") 2HEXDIG > > streamid-ext =3D token > > mediaclock-ext =3D 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 =3D 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 side= s. > > 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 track= s: > > 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 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > 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**** > > ** ** > ** > ------------------------------ > ** > --f46d0447a2434da0a504dbf0a7e7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Roni,

Thanks for the review.

See below.

Ke= vin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks -=A0www.= AVAnw.com,=A0www.X192= .org


On Wed, Apr 24, 2013 at 8:01 AM, Roni Ev= en <ron.even.tlv@gmail.com> wrote:

Hi Kevin,

I looked at the document and at Magnus comment.<= u>

<= u>=A0

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

=93Two or more NTP server= s may be listed at the same level in the session description to indicate th= at they are interchangeable.=A0 RTP=A0 senders or receivers can use any of = the listed NTP servers to govern a local clock that is equivalent to a loca= l clock slaved to a different server.=94

When you say interchangeable and how it relates to Magnus p= roposal to allow negotiation.=A0

What we're=A0trying=A0to say is that you&= #39;re allowed to list multiple clock sources with the understanding that a= ll listed clocks deliver the same time. Any of the clocks can be used inter= changeably and synchronization is assured. This capability is intended to s= upport fault-tolerant clock distribution scenarios.

I also assume that the information in offer/answer and in d= eclarative SDP is used to provide sender information and not receiver one s= o is there a reason to have the same media clock in both direction when usi= ng conversional (offer/answer) application

For backwards=A0compatibility,=A0when n= o 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, t= he answer must echo the offer's clock attribute. This is acknowledgemen= t to the offerer that answerer recognises and supports the clksrc attribute= s.

=A0

=A0

Other comments

<= /u>=A0

1.=A0=A0=A0=A0=A0=A0 ptp-domain-name =3D=A0 &quo= t;domain-name=3D" 16ptp-domain-char =96 did you mean exactly 16 charat= ers?

Basically, yes, although I admit it is = a bit strange. IEEE 1588-2002 (clause 6.2.5.1) domain names are 16 characte= r fixed-length strings. Shorter-looking names can be used but they are padd= ed out with null characters.

2.=A0=A0=A0=A0=A0=A0 In figure 2 a=3Dts-refclk:n= tp=3Dtraceable =96 do you need also to specify the serv= er address?

Traceable sources imply TAI-based time.= Any TAI source of a particular=A0technology (e.g. GPS, NTP)=A0is assumed t= o be equivalent to any other TAI source using the same technology. We appre= ciate that this is a crude simplification but trying to go further=A0takes = us down a rabbit hole.

3.=A0=A0=A0=A0=A0=A0 In figure 3 a=3Dts-refclk:n= tp=3D203.0.113.10 2011-02-19 21:03:20.345+01:00 =96 what is the last part w= ith the date and time, I thought the syntax only have server address.

This is a timestamp left over from a pr= evious "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.=A0=A0=A0=A0=A0=A0 In section 6.1 the first se= ntence in the first and second paragraph it look to me like the =93must=94 = is really a =93SHOULD=94

Another issue I had already noted for c= orrection.=A0

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

We will review RFC 5226 again and corre= ct this.=A0

<= p style=3D"margin-left:.5in">6.=A0=A0=A0=A0=A0=A0 The IANA section is not full= y 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<= /p>
We will review RFC 4566 and correct thi= s. Thanks for a pointer to examples.=A0

=A0

Roni Even

= =A0

=A0<= /p>

=A0

From: avt-bounces@ietf.org= [mailto:avt-boun= ces@ietf.org] On Behalf Of Kevin Gross
Sent: 18 April, 2013 1:41 AM
To: Magnus Westerlund
C= c: IETF AVTCore WG


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

=A0

Magnus,

=A0

Thanks for looking= at this and sorry for the delay responding.

=A0

I agree that mediaclk-ext is too restrictive. Your suggestio= n is very=A0accommodating=A0 Something a bit more structured such as 't= oken "=3D" byte-string' might be more appropriate. I will=A0c= heck=A0with my co authors on this.

=A0

As there is great=A0precedent for it in SDP, we have impleme= nted a simple offer-answer model. I would propose that systems should use t= he mechanisms defined in RFC 5939 if negotiation of clock configurations is= necessary. Perhaps adding some discussion and a=A0reference=A0to this RFC = would help.

=A0

I don't think that independently negotiating reference= =A0and=A0media clocks as you have suggested will be adequate. Under some im= plementations, while multiple clocks are supported, certain combinations of= media and reference clocks may not be allowed.

=

Kevin Gross=

Media Network Consultant

AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

= =A0

On Tue, Apr 9, 2013 at 3:27 A= M, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

Hi,

I promised doing an review of the O/A sec= tion. 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<= br> =A0 =A0information.

=A0 =A0 =A0 =A0 =A0 mediaclk-master =3D "a= =3Dssrc:" integer SP clk-master-id

=A0 =A0 =A0 =A0 =A0 clk-mast= er-id =3D "mediaclk:master-id=3D" master-id

=A0 =A0 =A0 = =A0 =A0 timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock

=A0 =A0 =A0 =A0 =A0 mediaclock =3D sender / refclk / streamid / mediacl= ock-ext

=A0 =A0 =A0 =A0 =A0 sender =3D "sender" sender-ext=

=A0 =A0 =A0 =A0 =A0 sender-ext =3D token

=A0 =A0 =A0 =A0 =A0= refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-e= xt]

=A0 =A0 =A0 =A0 =A0 rate =3D [ SP "rate=3D" integer "/&q= uot; integer ]

=A0 =A0 =A0 =A0 =A0 direct-ext =3D token

=A0 = =A0 =A0 =A0 =A0 streamid =3D "master-id=3D" master-id
=A0 =A0 = =A0 =A0 =A0 streamid =3D/ "IEEE1722=3D" avb-stream-id
=A0 =A0 =A0 =A0 =A0 streamid =3D/ streamid-ext

=A0 =A0 =A0 =A0 =A0 m= aster-id =3D EUI48
=A0 =A0 =A0 =A0 =A0 avb-stream-id =3D EUI64

= =A0 =A0 =A0 =A0 =A0 EUI48 =3D 5(2HEXDIG ":") 2HEXDIG
=A0 =A0 = =A0 =A0 =A0 EUI64 =3D 7(2HEXDIG ":") 2HEXDIG

=A0 =A0 =A0 =A0 =A0 streamid-ext =3D token

=A0 =A0 =A0 =A0 =A0 media= clock-ext =3D token

I wonder if not the mediaclock-ext construction = is to restrictive. As
the refclk produces a sting with white-spaces in i= t, 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
shou= ld be possible to use. Likely the only resteriction should be that
it st= arts with a token. Thus using:

mediaclock-ext =3D token [SP byte-string]

This would require a t= oken for identifying the method followed by a
space and then full freedo= m for anything that is allowed on an SDP
attribute value.


2. = Section 6:

Purpose of signalling?

I think this type of signalling can selec= t 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 avail= able mechanism on both sides.

The currently proposed solution does neither of these. It enables theofferer to express to declare I intended to use X and for the answer tosay 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 a= re here. And I will propose
some goals with the signalling based on my u= nderstanding of how these
defined timestamp reference clocks and media s= tream clocks can be used.
And we do need to be aware that different application may have differentneeds.

Goal with signalling:

1. Enable each media sender to = declare its actually used ts-refclk, i.e.
what clock is base for the RTC= P 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. Enabl= e two media sender using SDP O/A to determine what common clocks
they ac= tually 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 followi= ng.
A. has three ts-refclk =A0it can use. B has two ts-refclk available.= They
are going to watch social TV. To make it at all possible for the s= ocial
TV service to play out content at A and B in sync they need to have
eith= er 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 sc= enario the TV service will be able to ensure that the
media is played out is sync.


As a technical solution to these is= sues there are two main solution tracks:

1) Change the respective SD= P 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 attribut= es 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 clock= s.

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

I will note that this is likely to req= uire 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<= br>could use OPTIONS to provide a SDP which includes the negotiation
att= ribute to enable the other side to select using a clock that is
supporte= d 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 crea= te two new SDP attributes one for
each type of clock usage (ts-refclk an= d 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 add= s
all it supports. Hopefully there is someone in the list that is common= .
The highest priority between the two parties should be used when commo= n
clock is required. IF that is not, then these attributes should not be
i= ncluded. 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
no= t add additional clocks it supports that are not common.

I really ap= preciate feedback on these comments and ideas.

Cheers

Magnus = Westerlund

----------------------------------------------------------------------<= br>Multimedia Technologies, Ericsson Research EAB/TVM
------------------= ----------------------------------------------------
Ericsson AB =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
<= br>_______________________________________________
Audio/Video Transport= Core Maintenance
avt@= ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

=A0


--f46d0447a2434da0a504dbf0a7e7-- From ron.even.tlv@gmail.com Sun May 5 02:16:33 2013 Return-Path: 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 ; 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 ; 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 ; Sun, 5 May 2013 02:16:25 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so2751281wgh.29 for ; 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 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 05 May 2013 02:16:23 -0700 (PDT) From: "Roni Even" To: "'Kevin Gross'" References: <5163DF09.7050606@ericsson.com> <02d601ce40f4$2e765d30$8b631790$@gmail.com> In-Reply-To: Date: Sun, 5 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' , 'IETF AVTCore WG' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 09:16:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0205_01CE498A.462F69F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kevin, On comment 2. The syntax is =20 timestamp-refclk =3D "a=3Dts-refclk:" clksrc CRLF clksrc =3D ntp / ptp / gps / gal / local / private / clksrc-ext =20 ntp =3D "ntp=3D" ntp-server-addr ntp-server-addr =3D host [ ":" port ] ntp-server-addr =3D/ "traceable" =20 this is why I expected a host address Roni =20 From: Kevin Gross [mailto:kevin.gross@avanw.com]=20 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 =20 Roni, =20 Thanks for the review. =20 See below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 On Wed, Apr 24, 2013 at 8:01 AM, Roni Even = wrote: Hi Kevin, I looked at the document and at Magnus comment. =20 I am not sure if the document allows offering and two reference clocks. = I am not sure what is meant in section 4.2=20 =93Two 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.=94=20 When you say interchangeable and how it relates to Magnus proposal to = allow negotiation.=20 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. =20 =20 Other comments =20 1. ptp-domain-name =3D "domain-name=3D" 16ptp-domain-char =96 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=3Dts-refclk:ntp=3Dtraceable =96 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=3Dts-refclk:ntp=3D203.0.113.10 2011-02-19 21:03:20.345+01:00 =96 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 =93must=94 is really a =93SHOULD=94 Another issue I had already noted for correction.=20 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=94 see RFC 5226 We will review RFC 5226 again and correct this.=20 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-1= 3 IANA section or other MMUSIC RFCs We will review RFC 4566 and correct this. Thanks for a pointer to = examples.=20 =20 Roni Even =20 =20 =20 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 =20 Magnus, =20 Thanks for looking at this and sorry for the delay responding. =20 I agree that mediaclk-ext is too restrictive. Your suggestion is very accommodating Something a bit more structured such as 'token "=3D" byte-string' might be more appropriate. I will check with my co authors = on this. =20 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. =20 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 =20 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund 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 =3D "a=3Dssrc:" integer SP clk-master-id clk-master-id =3D "mediaclk:master-id=3D" master-id timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock mediaclock =3D sender / refclk / streamid / mediaclock-ext sender =3D "sender" sender-ext sender-ext =3D token refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-ext] rate =3D [ SP "rate=3D" integer "/" integer ] direct-ext =3D token streamid =3D "master-id=3D" master-id streamid =3D/ "IEEE1722=3D" avb-stream-id streamid =3D/ streamid-ext master-id =3D EUI48 avb-stream-id =3D EUI64 EUI48 =3D 5(2HEXDIG ":") 2HEXDIG EUI64 =3D 7(2HEXDIG ":") 2HEXDIG streamid-ext =3D token mediaclock-ext =3D 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 =3D 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 =20 F=E4r=F6gatan 6 | Mobile +46 73 0949079 =20 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 =20 _____ =20 =20 ------=_NextPart_000_0205_01CE498A.462F69F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kevin,

On comment 2.

The syntax is

 

timestamp-refclk =3D = "a=3Dts-refclk:" clksrc CRLF

=A0=A0=A0 = clksrc =3D ntp / ptp / gps / gal / local / private / = clksrc-ext

 

=A0=A0=A0 = ntp=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D=A0 "ntp=3D" = ntp-server-addr

=A0=A0=A0 ntp-server-addr =3D=A0 = host [ ":" port ]

=A0=A0=A0 = ntp-server-addr =3D/ "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, 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 =3D  "domain-name=3D" 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=3Dts-refclk:ntp=3Dtraceable – 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=3Dts-refclk:ntp=3D203.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”

<= p class=3DMsoNormal>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-capabi= lity-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

 <= /o:p>

Magnus,=

 <= /o:p>

Thanks for = looking at this and sorry for the delay = responding.

 <= /o:p>

I agree = that mediaclk-ext is too restrictive. Your suggestion is = very accommodating  Something a bit more structured such as = 'token "=3D" byte-string' might be more appropriate. I = will check with my co authors on = this.

 <= /o:p>

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.

 <= /o:p>

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 - www.AVAnw.com, www.X192.org

 <= /p>

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 =3D "a=3Dssrc:" integer SP = clk-master-id

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

    =       timestamp-mediaclk =3D "a=3Dmediaclk:" = mediaclock

          mediaclock =3D = sender / refclk / streamid / mediaclock-ext

      =     sender =3D "sender" sender-ext

  =         sender-ext =3D token

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

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

          direct-ext =3D = token

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

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

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

  =         streamid-ext =3D token

    =       mediaclock-ext =3D 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 =3D 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
F=E4r=F6gatan 6     =            | Mobile +46 73 = 0949079
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

 <= /o:p>

 

------=_NextPart_000_0205_01CE498A.462F69F0-- From ron.even.tlv@gmail.com Sun May 5 02:19:12 2013 Return-Path: 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 63BCE21F8FFB for ; Sun, 5 May 2013 02:19:12 -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 8rvvuYkgS+iT for ; Sun, 5 May 2013 02:19:06 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 016A521F8D2E for ; Sun, 5 May 2013 02:19:05 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id s43so2291994wey.20 for ; Sun, 05 May 2013 02:19:05 -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=dTz3NMEXRlqqNLKv1PvpUGb1Qz99+GYym+oCNFV8mYs=; b=WCuP30ep3FJ6IcNYRGRutW6hfFYKPEad5A3xIW/p/76nGSe4ZCOtbGtmxMmUBh7LUJ w9HzcGhVtlij+ZY896RbayG8zVXm0zntY2u0n6xH0lhP+rsZvOXYBEGnIL3xT17eWRIN ecVpOGNIDLD+2qZb+UtvbBJYv+mS61XnO2jGckRJ9NmndFwV47OfwGi1GFSTlkRbAiiV NRQYxi8J+Edvfe9m0qzX/EGl73eD0oXbXxYD8z8xWii7BQprW0PMDlDo6ujKvk+itGVY vIrtDVyABZJh/6e6LFhUg6/BTLXztyvoTJ/lw9y9bBSX+EJTSFU6bV1w9GQl+8ty7DCd xg/g== X-Received: by 10.180.76.103 with SMTP id j7mr4220130wiw.21.1367745544829; Sun, 05 May 2013 02:19:04 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id q18sm6939338wiw.8.2013.05.05.02.19.00 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 05 May 2013 02:19:03 -0700 (PDT) From: "Roni Even" To: "'Kevin Gross'" References: <5163DF09.7050606@ericsson.com> <02d601ce40f4$2e765d30$8b631790$@gmail.com> In-Reply-To: Date: Sun, 5 May 2013 12:18:22 +0300 Message-ID: <020901ce4971$80343400$809c9c00$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020A_01CE498A.A5840410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5HC9wvVjoQVUfIZENIsmmA9Bo8wEz1q+HAk9T2m4CUdmWBJdyAlMw Content-Language: en-us Cc: 'Magnus Westerlund' , 'IETF AVTCore WG' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 09:19:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_020A_01CE498A.A5840410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kevin, Also a=3Dts-refclk:ntp=3Dtraceable probably a=3Dts-refclk:ntp=3D host = /traceable Roni =20 From: Kevin Gross [mailto:kevin.gross@avanw.com]=20 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 =20 Roni, =20 Thanks for the review. =20 See below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 On Wed, Apr 24, 2013 at 8:01 AM, Roni Even = wrote: Hi Kevin, I looked at the document and at Magnus comment. =20 I am not sure if the document allows offering and two reference clocks. = I am not sure what is meant in section 4.2=20 =93Two 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.=94=20 When you say interchangeable and how it relates to Magnus proposal to = allow negotiation.=20 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. =20 =20 Other comments =20 1. ptp-domain-name =3D "domain-name=3D" 16ptp-domain-char =96 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=3Dts-refclk:ntp=3Dtraceable =96 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=3Dts-refclk:ntp=3D203.0.113.10 2011-02-19 21:03:20.345+01:00 =96 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 =93must=94 is really a =93SHOULD=94 Another issue I had already noted for correction.=20 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=94 see RFC 5226 We will review RFC 5226 again and correct this.=20 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-1= 3 IANA section or other MMUSIC RFCs We will review RFC 4566 and correct this. Thanks for a pointer to = examples.=20 =20 Roni Even =20 =20 =20 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 =20 Magnus, =20 Thanks for looking at this and sorry for the delay responding. =20 I agree that mediaclk-ext is too restrictive. Your suggestion is very accommodating Something a bit more structured such as 'token "=3D" byte-string' might be more appropriate. I will check with my co authors = on this. =20 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. =20 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 =20 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund 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 =3D "a=3Dssrc:" integer SP clk-master-id clk-master-id =3D "mediaclk:master-id=3D" master-id timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock mediaclock =3D sender / refclk / streamid / mediaclock-ext sender =3D "sender" sender-ext sender-ext =3D token refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-ext] rate =3D [ SP "rate=3D" integer "/" integer ] direct-ext =3D token streamid =3D "master-id=3D" master-id streamid =3D/ "IEEE1722=3D" avb-stream-id streamid =3D/ streamid-ext master-id =3D EUI48 avb-stream-id =3D EUI64 EUI48 =3D 5(2HEXDIG ":") 2HEXDIG EUI64 =3D 7(2HEXDIG ":") 2HEXDIG streamid-ext =3D token mediaclock-ext =3D 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 =3D 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 =20 F=E4r=F6gatan 6 | Mobile +46 73 0949079 =20 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 =20 _____ =20 =20 ------=_NextPart_000_020A_01CE498A.A5840410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Kevin,

Also a=3Dts-refc= lk:ntp=3Dtraceable probably a=3Dts-refclk:ntp=3D host = /traceable

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, 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 =3D  "domain-name=3D" 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=3Dts-refclk:ntp=3Dtraceable – 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=3Dts-refclk:ntp=3D203.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”

<= p class=3DMsoNormal>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-capabi= lity-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

 <= /o:p>

Magnus,=

 <= /o:p>

Thanks for = looking at this and sorry for the delay = responding.

 <= /o:p>

I agree = that mediaclk-ext is too restrictive. Your suggestion is = very accommodating  Something a bit more structured such as = 'token "=3D" byte-string' might be more appropriate. I = will check with my co authors on = this.

 <= /o:p>

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.

 <= /o:p>

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 - www.AVAnw.com, www.X192.org

 <= /p>

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 =3D "a=3Dssrc:" integer SP = clk-master-id

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

    =       timestamp-mediaclk =3D "a=3Dmediaclk:" = mediaclock

          mediaclock =3D = sender / refclk / streamid / mediaclock-ext

      =     sender =3D "sender" sender-ext

  =         sender-ext =3D token

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

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

          direct-ext =3D = token

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

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

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

  =         streamid-ext =3D token

    =       mediaclock-ext =3D 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 =3D 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
F=E4r=F6gatan 6     =            | Mobile +46 73 = 0949079
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

 <= /o:p>

 

------=_NextPart_000_020A_01CE498A.A5840410-- From internet-drafts@ietf.org Mon May 6 02:40:40 2013 Return-Path: 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 0E0F821F8FE3; Mon, 6 May 2013 02:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZFvxxMoIwKrd; Mon, 6 May 2013 02:40:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91421F8FDB; Mon, 6 May 2013 02:40:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p5 Message-ID: <20130506094039.7500.34911.idtracker@ietfa.amsl.com> Date: Mon, 06 May 2013 02:40:39 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-03.txt X-BeenThere: avt@ietf.org 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, 06 May 2013 09:40:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Options for Securing RTP Sessions Author(s) : Magnus Westerlund Colin Perkins Filename : draft-ietf-avtcore-rtp-security-options-03.txt Pages : 32 Date : 2013-05-06 Abstract: The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for developers on how to choose the appropriate security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-security-options-= 03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=0838ce92b4=magnus.westerlund@ericsson.com Mon May 6 02:48:45 2013 Return-Path: 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 BA69A21F8808 for ; Mon, 6 May 2013 02:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 OBZ8yI3UOMsV for ; Mon, 6 May 2013 02:48:40 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3129921F8E87 for ; Mon, 6 May 2013 02:48:40 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-14-51877c76c2df Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 98.5A.01956.67C77815; Mon, 6 May 2013 11:48:38 +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 11:48:38 +0200 Message-ID: <51877C75.8040805@ericsson.com> Date: Mon, 6 May 2013 11:48:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: avt@ietf.org References: <20130506094039.7500.34911.idtracker@ietfa.amsl.com> In-Reply-To: <20130506094039.7500.34911.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPJMWRmVeSWpSXmKPExsUyM+JvrW5ZTXugwf6JxhYve1ayOzB6LFny kymAMYrbJimxpCw4Mz1P3y6BO+PTApWC36IVk+fMYWlg3CHYxcjJISFgIvH12HlGCFtM4sK9 9WxdjFwcQgKnGCVuHt7DCuEsY5R4cb6HCaSKV0BbYtmZT8wgNouAisSPtqfsIDabgIXEzR+N QN0cHKICwRJbW2MgygUlTs58wgJiiwgISKzY/hfMFhYIlFg8/R3YSCEBB4m3re9YQWxOAUeJ 3jvP2SAOkpTY8qIdbDyzgJ7ElKstjBC2vETz1tnMEL3aEg1NHawTGAVnIVk3C0nLLCQtCxiZ VzGy5yZm5qSXm29iBIbfwS2/DXYwbrovdohRmoNFSZw3masxUEggPbEkNTs1tSC1KL6oNCe1 +BAjEwcniOCSamAUWshztNXUKEzby1flbbHmC4nNLLF+MRPy2LMev/FwF/V/Z38qOSSYhXPS tPo20e8C/RY89Rtjep4wPP7Ubnw6tjgyrCwglEv9+lOXvlNsZm9WLRc/Eh+mckxy4TJrn/A1 Tx/IzZmRs62pR89y7RanlgPXslw2XvXYfXln4oXLXxSEf3t3rlJiKc5INNRiLipOBAC74TYJ EgIAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-03.txt X-BeenThere: avt@ietf.org 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, 06 May 2013 09:48:45 -0000 WG, (as individual contributor) This update of the RTP security options has a number of improvements. 1. It discusses known usage or inclusion in standard specs of different choices. 2. It has two new examples, PSS and RTSP 2.0. 3. A section on identity. I think this is good enough for its purpose and would really appreciate some feedback on it. Both from people knowing security and people who don't. Cheers Magnus Westerlund On 2013-05-06 11:40, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Options for Securing RTP Sessions > Author(s) : Magnus Westerlund > Colin Perkins > Filename : draft-ietf-avtcore-rtp-security-options-03.txt > Pages : 32 > Date : 2013-05-06 > > Abstract: > The Real-time Transport Protocol (RTP) is used in a large number of > different application domains and environments. This heterogeneity > implies that different security mechanisms are needed to provide > services such as confidentiality, integrity and source authentication > of RTP/RTCP packets suitable for the various environments. The range > of solutions makes it difficult for RTP-based application developers > to pick the most suitable mechanism. This document provides an > overview of a number of security solutions for RTP, and gives > guidance for developers on how to choose the appropriate security > mechanism. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-security-options-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- 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 ---------------------------------------------------------------------- From prvs=0838ce92b4=magnus.westerlund@ericsson.com Mon May 6 07:45:32 2013 Return-Path: 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 ; 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 ; 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 ; 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, 6 May 2013 16:45:24 +0200 From: Magnus Westerlund 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 References: <5163DF09.7050606@ericsson.com> <517636E0.2020607@ericsson.com> In-Reply-To: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 , www.X192.org > > > > 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 > -- 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 ---------------------------------------------------------------------- From kevin.gross@avanw.com Mon May 6 16:34:09 2013 Return-Path: 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 418C221F92E1 for ; Mon, 6 May 2013 16:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.742 X-Spam-Level: *** X-Spam-Status: No, score=3.742 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1, 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 wTTA5qixh8CO for ; Mon, 6 May 2013 16:34:04 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id E225B21F92CB for ; Mon, 6 May 2013 16:34:04 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta01.emeryville.ca.mail.comcast.net with comcast id YemQ1l0040QkzPwA1na4hF; Mon, 06 May 2013 23:34:04 +0000 Received: from mail-ie0-f177.google.com ([209.85.223.177]) by omta02.emeryville.ca.mail.comcast.net with comcast id YnY31l00e3qFlUp8NnY35n; Mon, 06 May 2013 23:32:04 +0000 Received: by mail-ie0-f177.google.com with SMTP id 9so4859617iec.22 for ; Mon, 06 May 2013 16:32:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EqIcUN1yXatM9+n2FXwkba6IeddsFxLVvJrI2l+SDxA=; b=QTskZDHAlU045yFWnsNhPHfG9ZaUiZsr2ME/PZ/vHH8TbtbPQldHKDa/hAcdUVi1bV scusxsgOUkOm3eugFoilhjaNY5gbBvR2PVBsgj/wuz4vzHobq1NlNZT2lZ1MeGu9UWkJ uJNxHELjtWHb/OtWZvYA+4CYjr7nzNafXVzKxTcIrEQ6z+OiNrkVXmdLDtFratri+phU GR5bK8sscIskSrWAGbuMlpka1yt8im5MBR5M4UxXC13hk6mS9oR3lmuPdb/84VItZnr8 Gduu/f0i5POWh5rGgKbjdIjJOSYFWqrvDJn+Co4CvkQ3dGhr4xpZclm8iBaQIJVjfoGT 1PGQ== MIME-Version: 1.0 X-Received: by 10.42.64.69 with SMTP id f5mr7898228ici.29.1367883123105; Mon, 06 May 2013 16:32:03 -0700 (PDT) Received: by 10.50.180.201 with HTTP; Mon, 6 May 2013 16:32:03 -0700 (PDT) In-Reply-To: <020401ce4971$20defda0$629cf8e0$@gmail.com> References: <5163DF09.7050606@ericsson.com> <02d601ce40f4$2e765d30$8b631790$@gmail.com> <020401ce4971$20defda0$629cf8e0$@gmail.com> Date: Mon, 6 May 2013 17:32:03 -0600 Message-ID: From: Kevin Gross To: Roni Even Content-Type: multipart/alternative; boundary=90e6ba5bca8fa5a8a204dc151b37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367883244; bh=EqIcUN1yXatM9+n2FXwkba6IeddsFxLVvJrI2l+SDxA=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=HvWKDMWFlOmRisvPEP/n8MABbTdKzm+8hXq2XkRSi2tABZY5Qiz/JXpjY5YE2DTU4 hnsJFLIuZEA5JTpbhc6tcUzeSZkiZFvYMD+Je592mDklfmYlQ3l7qWjxPl9lUd41kD 7MzTAARWompOpfx+pj41qeqkOaAs34EuYMDLkNxclqiCPka0HHc0o7MUh6YnXIxivy KjHbIXSyvLvvQG8vhnIVCMm+b5e35yES+REJQqkGovzM0AadDyCUNDsOs/ZzN9GKyU QqYggvIlRWA74bADeNIS00RtxOOKXL4zcdYHaOd+FRJgILtM0PD13BiVpc/bm/foPj iCRdp4N4m2TGw== Cc: Magnus Westerlund , IETF AVTCore WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 23:34:09 -0000 --90e6ba5bca8fa5a8a204dc151b37 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The intention is that after "ntp=3D", there is EITHER a server address (wit= h optional port number) OR "traceable". I believe that's what the code (specifically =3D/) specifies. If not, please set me straight. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Sun, May 5, 2013 at 3:15 AM, Roni Even wrote: > Hi Kevin,**** > > On comment 2.**** > > The syntax is**** > > ** ** > > timestamp-refclk =3D "a=3Dts-refclk:" clksrc CRLF**** > > clksrc =3D ntp / ptp / gps / gal / local / private / clksrc-ext**** > > ** ** > > ntp =3D "ntp=3D" ntp-server-addr**** > > ntp-server-addr =3D host [ ":" port ]**** > > ntp-server-addr =3D/ "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 , www.X192.org**** > > ** ** > > On Wed, Apr 24, 2013 at 8:01 AM, Roni Even 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 **** > > =93Two 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.=94 **** > > 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 i= s > 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 =3D "domain-name=3D" 16ptp-domain-char =96 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=3Dts-refclk:ntp=3Dtraceable =96 do you need also t= o > 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=3Dts-refclk:ntp=3D203.0.113.10 2011-02-19 > 21:03:20.345+01:00 =96 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 =93must=94 is really a =93SHOULD=94**** > > 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=94 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-1= 3IANA 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 "=3D" > byte-string' might be more appropriate. I will check with my co authors o= n > 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 mechanism= s > 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 a= s > you have suggested will be adequate. Under some implementations, while > multiple clocks are supported, certain combinations of media and referenc= e > clocks may not be allowed.**** > > > **** > > Kevin Gross**** > > +1-303-447-0517**** > > Media Network Consultant**** > > AVA Networks - 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 =3D "a=3Dssrc:" integer SP clk-master-id > > clk-master-id =3D "mediaclk:master-id=3D" master-id > > timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock > > mediaclock =3D sender / refclk / streamid / mediaclock-ext > > sender =3D "sender" sender-ext > > sender-ext =3D token > > refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-ext] > > rate =3D [ SP "rate=3D" integer "/" integer ] > > direct-ext =3D token > > streamid =3D "master-id=3D" master-id > streamid =3D/ "IEEE1722=3D" avb-stream-id > streamid =3D/ streamid-ext > > master-id =3D EUI48 > avb-stream-id =3D EUI64 > > EUI48 =3D 5(2HEXDIG ":") 2HEXDIG > EUI64 =3D 7(2HEXDIG ":") 2HEXDIG > > streamid-ext =3D token > > mediaclock-ext =3D 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 =3D 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 side= s. > > 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 track= s: > > 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 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > 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**** > > **** > ------------------------------ > > ** ** > --90e6ba5bca8fa5a8a204dc151b37 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The intention is that after "ntp=3D", there is E= ITHER a server address (with optional port number) OR "traceable"= . I believe that's what the code (specifically =3D/) specifies. If not,= please set me straight.

Kevin Gross
+1-30= 3-447-0517
Media Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Sun, May 5, 2013 at 3:15 AM, Roni Eve= n <ron.even.tlv@gmail.com> wrote:

Hi Kevin,

On comment 2.

The syntax is

=A0<= /p>

timestamp-refclk = =3D "a=3Dts-refclk:" clksrc CRLF

=A0=A0=A0 clksrc =3D= ntp / ptp / gps / gal / local / private / clksrc-ext<= /p>

=A0=

=A0=A0=A0 ntp=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D=A0 "ntp=3D" ntp-server-addr=

=A0=A0=A0 ntp-server= -addr =3D/ "traceable"

=A0

this is why I expected a = host address

Roni

=A0<= /p>

From: Kevin= Gross [mailto:k= evin.gross@avanw.com]
Sent: 05 May, 2013 7:03 AM
To: Roni Even
Cc: Mag= nus Westerlund; IETF AVTCore WG


Sub= ject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03<= /u>

=A0

Roni,

=A0

Thanks for = the review.

=A0

See below.


Kevin Gross

Media Network Consultant

AVA Networks -=A0www.AV= Anw.com,=A0www.X192.o= rg

=A0

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.

=A0<= /p>

I am not sure if the d= ocument allows offering and two reference clocks. I am not sure what is mea= nt in section 4.2

=93Two or more NTP server= s may be listed at the same level in the session description to indicate th= at they are interchangeable.=A0 RTP=A0 senders or receivers can use any of = the listed NTP servers to govern a local clock that is equivalent to a loca= l clock slaved to a different server.=94

When you say interchangeable and how it relates to Magnus p= roposal to allow negotiation.=A0

What we're=A0trying=A0to say is that you're allowed to list multipl= e clock sources with the understanding that all listed clocks deliver the s= ame time. Any of the clocks can be used interchangeably and synchronization= is assured. This capability is intended to support fault-tolerant clock di= stribution scenarios.

I also assume that the information in offer/answer and in declarat= ive SDP is used to provide sender information and not receiver one so is th= ere a reason to have the same media clock in both direction when using conv= ersional (offer/answer) application

For backwards=A0compat= ibility,=A0when no clock attribute is specified in a description, it has a = specific meaning (e.g. local time reference or free-running media clock). F= or 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.

=A0

=A0

Other comments<= /span>

=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">1.=A0=A0=A0=A0=A0=A0 ptp-domain-name =3D=A0 "domain-name=3D" 16ptp-do= main-char =96 did you mean exactly 16 charaters?

Basically, yes, althou= gh I admit it is a bit strange. IEEE 1588-2002 (clause 6.2.5.1) domain name= s are 16 character fixed-length strings. Shorter-looking names can be used = but they are padded out with null characters.

2.=A0=A0=A0=A0=A0=A0 In figure 2 a=3Dts-refclk:ntp=3Dtr= aceable =96 do you need also to specify the server address?

Traceable sources impl= y TAI-based time. Any TAI source of a particular=A0technology (e.g. GPS, NT= P)=A0is assumed to be equivalent to any other TAI source using the same tec= hnology. We appreciate that this is a crude simplification but trying to go= further=A0takes us down a rabbit hole.

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

This is a timestamp le= ft over from a previous "clock quality" proposal that has since b= een removed from the draft. I had already made note to remove this if no on= e caught in WGLC :)

4.=A0=A0=A0=A0=A0=A0 In section 6.1 the first sentence = in the first and second paragraph it look to me like the =93must=94 is real= ly a =93SHOULD=94

Another issue I had al= ready noted for correction.=A0

5.=A0=A0=A0=A0=A0=A0 In section 8 wh= en defining a new registry you need to say what is the policy for adding va= lues to the registry (I think here it will be specification required=94 see= RFC 5226

We will review RFC 522= 6 again and correct this.=A0

6.=A0=A0=A0=A0=A0=A0 The IANA sectio= n 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 456= 6 and correct this. Thanks for a pointer to examples.=A0

<= /div>

=A0

Roni Even

=A0

=A0

=A0<= /p>

From: avt-bounces@ietf.org [mailto:avt-bo= unces@ietf.org] On Behalf Of Kevin Gross
Sent: 18 April, 2013 1:41 AM
To: Magnus Westerlund
C= c: IETF AVTCore WG

=
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03<= u>

=A0

Magnus,

=A0

Thanks for looking at this an= d sorry for the delay responding.

=A0

I agree that mediaclk-ext is too restrictive. Your suggestio= n is very=A0accommodating=A0 Something a bit more structured such as 't= oken "=3D" byte-string' might be more appropriate. I will=A0c= heck=A0with my co authors on this.

=A0

As there is great=A0precedent for it in SDP, we have impleme= nted a simple offer-answer model. I would propose that systems should use t= he mechanisms defined in RFC 5939 if negotiation of clock configurations is= necessary. Perhaps adding some discussion and a=A0reference=A0to this RFC = would help.

=A0

I don't think that independently negotiating reference= =A0and=A0media clocks as you have suggested will be adequate. Under some im= plementations, while multiple clocks are supported, certain combinations of= media and reference clocks may not be allowed.


Kevin Gross

Media Network Consultant

AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

=A0=

On Tue, Apr 9, 2013 at 3:27 A= M, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

Hi,

I promised doing an review of the O/A sec= tion. 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<= br> =A0 =A0information.

=A0 =A0 =A0 =A0 =A0 mediaclk-master =3D "a= =3Dssrc:" integer SP clk-master-id

=A0 =A0 =A0 =A0 =A0 clk-mast= er-id =3D "mediaclk:master-id=3D" master-id

=A0 =A0 =A0 = =A0 =A0 timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock

=A0 =A0 =A0 =A0 =A0 mediaclock =3D sender / refclk / streamid / mediacl= ock-ext

=A0 =A0 =A0 =A0 =A0 sender =3D "sender" sender-ext=

=A0 =A0 =A0 =A0 =A0 sender-ext =3D token

=A0 =A0 =A0 =A0 =A0= refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-e= xt]

=A0 =A0 =A0 =A0 =A0 rate =3D [ SP "rate=3D" integer "/&q= uot; integer ]

=A0 =A0 =A0 =A0 =A0 direct-ext =3D token

=A0 = =A0 =A0 =A0 =A0 streamid =3D "master-id=3D" master-id
=A0 =A0 = =A0 =A0 =A0 streamid =3D/ "IEEE1722=3D" avb-stream-id
=A0 =A0 =A0 =A0 =A0 streamid =3D/ streamid-ext

=A0 =A0 =A0 =A0 =A0 m= aster-id =3D EUI48
=A0 =A0 =A0 =A0 =A0 avb-stream-id =3D EUI64

= =A0 =A0 =A0 =A0 =A0 EUI48 =3D 5(2HEXDIG ":") 2HEXDIG
=A0 =A0 = =A0 =A0 =A0 EUI64 =3D 7(2HEXDIG ":") 2HEXDIG

=A0 =A0 =A0 =A0 =A0 streamid-ext =3D token

=A0 =A0 =A0 =A0 =A0 media= clock-ext =3D token

I wonder if not the mediaclock-ext construction = is to restrictive. As
the refclk produces a sting with white-spaces in i= t, 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
shou= ld be possible to use. Likely the only resteriction should be that
it st= arts with a token. Thus using:

mediaclock-ext =3D token [SP byte-string]

This would require a t= oken for identifying the method followed by a
space and then full freedo= m for anything that is allowed on an SDP
attribute value.


2. = Section 6:

Purpose of signalling?

I think this type of signalling can selec= t 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 avail= able mechanism on both sides.

The currently proposed solution does neither of these. It enables theofferer to express to declare I intended to use X and for the answer tosay 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 a= re here. And I will propose
some goals with the signalling based on my u= nderstanding of how these
defined timestamp reference clocks and media s= tream clocks can be used.
And we do need to be aware that different application may have differentneeds.

Goal with signalling:

1. Enable each media sender to = declare its actually used ts-refclk, i.e.
what clock is base for the RTC= P 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. Enabl= e two media sender using SDP O/A to determine what common clocks
they ac= tually 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 followi= ng.
A. has three ts-refclk =A0it can use. B has two ts-refclk available.= They
are going to watch social TV. To make it at all possible for the s= ocial
TV service to play out content at A and B in sync they need to have
eith= er 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 sc= enario the TV service will be able to ensure that the
media is played out is sync.


As a technical solution to these is= sues there are two main solution tracks:

1) Change the respective SD= P 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 attribut= es 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 clock= s.

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

I will note that this is likely to req= uire 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<= br>could use OPTIONS to provide a SDP which includes the negotiation
att= ribute to enable the other side to select using a clock that is
supporte= d 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 crea= te two new SDP attributes one for
each type of clock usage (ts-refclk an= d 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 add= s
all it supports. Hopefully there is someone in the list that is common= .
The highest priority between the two parties should be used when commo= n
clock is required. IF that is not, then these attributes should not be
i= ncluded. 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
no= t add additional clocks it supports that are not common.

I really ap= preciate feedback on these comments and ideas.

Cheers

Magnus = Westerlund

----------------------------------------------------------------------<= br>Multimedia Technologies, Ericsson Research EAB/TVM
------------------= ----------------------------------------------------
Ericsson AB =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockho= lm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
<= br>_______________________________________________
Audio/Video Transport= Core Maintenance
avt@= ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

=A0

=

=A0

<= /div>

--90e6ba5bca8fa5a8a204dc151b37-- From ron.even.tlv@gmail.com Mon May 6 16:42:59 2013 Return-Path: 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 1BB1921F9369 for ; Mon, 6 May 2013 16:42:59 -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 H5ikORG+e6rm for ; Mon, 6 May 2013 16:42:52 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4D77521F9299 for ; Mon, 6 May 2013 16:42:52 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id h11so3103227wiv.7 for ; Mon, 06 May 2013 16:42:50 -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=f6De2sL3EJiYdzLA+Lmo5MRSpBTkX1hhXhcEw2O7MSU=; b=x1NiFe38JIyDnJkyO4Ngs0RBD2/1F62m3YlJA5vCLd/jeAjW5Y8jPXGuNt1wT59t10 8E1JWNuPjnXuV1g0BtegsuiMkO/fh1SayxoQV4Q+mF/JRE5gGLipj6hyZjhuTYYs8UXU xpVrZt1XbtgooIz5OnvjE+P+0IjaNUzS3uyWCy9kw601790SNPyddYXX1EJ4OdWT/ONY iP75a+OMvxWO/eVmK7EsOS0AlcTZLMB42MndAaAYTL1ZdT4jyncjMlzjwL2rDbUnQ4er oKS3oY+5s8Mtb91SWP1xZOi2xJxcEfqTTFbx57TDMgFSGs0VoeRl6Hdc9BTzvJp1qLDT 1CoQ== X-Received: by 10.194.92.176 with SMTP id cn16mr27794404wjb.51.1367883770427; Mon, 06 May 2013 16:42:50 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id ge7sm18464770wib.6.2013.05.06.16.42.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 06 May 2013 16:42:49 -0700 (PDT) From: "Roni Even" To: "'Kevin Gross'" References: <5163DF09.7050606@ericsson.com> <02d601ce40f4$2e765d30$8b631790$@gmail.com> <020401ce4971$20defda0$629cf8e0$@gmail.com> In-Reply-To: Date: Tue, 7 May 2013 02:41:59 +0300 Message-ID: <000301ce4ab3$4f47a5a0$edd6f0e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CE4ACC.7498FC50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5HC9wvVjoQVUfIZENIsmmA9Bo8wEz1q+HAk9T2m4CUdmWBAI6cNqBAqa3GMOXTXzMUA== Content-Language: en-us Cc: 'Magnus Westerlund' , 'IETF AVTCore WG' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 23:42:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01CE4ACC.7498FC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kevin, My mistake. Roni =20 From: Kevin Gross [mailto:kevin.gross@avanw.com]=20 Sent: 07 May, 2013 2:32 AM To: Roni Even Cc: Magnus Westerlund; IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 =20 The intention is that after "ntp=3D", there is EITHER a server address = (with optional port number) OR "traceable". I believe that's what the code (specifically =3D/) specifies. If not, please set me straight. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 On Sun, May 5, 2013 at 3:15 AM, Roni Even = wrote: Hi Kevin, On comment 2. The syntax is =20 timestamp-refclk =3D "a=3Dts-refclk:" clksrc CRLF clksrc =3D ntp / ptp / gps / gal / local / private / clksrc-ext =20 ntp =3D "ntp=3D" ntp-server-addr ntp-server-addr =3D host [ ":" port ] ntp-server-addr =3D/ "traceable" =20 this is why I expected a host address Roni =20 From: Kevin Gross [mailto:kevin.gross@avanw.com]=20 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 =20 Roni, =20 Thanks for the review. =20 See below. Kevin Gross +1-303-447-0517 =20 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 On Wed, Apr 24, 2013 at 8:01 AM, Roni Even = wrote: Hi Kevin, I looked at the document and at Magnus comment. =20 I am not sure if the document allows offering and two reference clocks. = I am not sure what is meant in section 4.2=20 =93Two 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.=94=20 When you say interchangeable and how it relates to Magnus proposal to = allow negotiation.=20 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. =20 =20 Other comments =20 1. ptp-domain-name =3D "domain-name=3D" 16ptp-domain-char =96 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=3Dts-refclk:ntp=3Dtraceable =96 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=3Dts-refclk:ntp=3D203.0.113.10 2011-02-19 21:03:20.345+01:00 =96 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 =93must=94 is really a =93SHOULD=94 Another issue I had already noted for correction.=20 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=94 see RFC 5226 We will review RFC 5226 again and correct this.=20 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-1= 3 IANA section or other MMUSIC RFCs We will review RFC 4566 and correct this. Thanks for a pointer to = examples.=20 =20 Roni Even =20 =20 =20 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 =20 Magnus, =20 Thanks for looking at this and sorry for the delay responding. =20 I agree that mediaclk-ext is too restrictive. Your suggestion is very accommodating Something a bit more structured such as 'token "=3D" byte-string' might be more appropriate. I will check with my co authors = on this. =20 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. =20 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 =20 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund 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 =3D "a=3Dssrc:" integer SP clk-master-id clk-master-id =3D "mediaclk:master-id=3D" master-id timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock mediaclock =3D sender / refclk / streamid / mediaclock-ext sender =3D "sender" sender-ext sender-ext =3D token refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-ext] rate =3D [ SP "rate=3D" integer "/" integer ] direct-ext =3D token streamid =3D "master-id=3D" master-id streamid =3D/ "IEEE1722=3D" avb-stream-id streamid =3D/ streamid-ext master-id =3D EUI48 avb-stream-id =3D EUI64 EUI48 =3D 5(2HEXDIG ":") 2HEXDIG EUI64 =3D 7(2HEXDIG ":") 2HEXDIG streamid-ext =3D token mediaclock-ext =3D 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 =3D 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 =20 F=E4r=F6gatan 6 | Mobile +46 73 0949079 =20 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 =20 _____ =20 =20 =20 ------=_NextPart_000_0004_01CE4ACC.7498FC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Kevin,

My mistake.

Roni

 

From:= = Kevin Gross [mailto:kevin.gross@avanw.com]
Sent: 07 May, 2013 = 2:32 AM
To: Roni Even
Cc: Magnus Westerlund; IETF = AVTCore WG
Subject: Re: [AVTCORE] Comments on = draft-ietf-avtcore-clksrc-03

 

The = intention is that after "ntp=3D", there is EITHER a server = address (with optional port number) OR "traceable". I believe = that's what the code (specifically =3D/) specifies. If not, please set = me straight.


Kevin = Gross

+1-303-447-0517

Media Network Consultant

AVA Networks - www.AVAnw.com, www.X192.org

 

On Sun, May 5, 2013 at 3:15 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi Kevin,

On comment 2.

The syntax is

 

timestamp-refclk =3D "a=3Dts-refclk:" clksrc = CRLF

    clksrc =3D ntp / ptp / gps / gal / local / = private / clksrc-ext

 

    = ntp           &nbs= p; =3D  "ntp=3D" = ntp-server-addr

    ntp-server-addr = =3D  host [ ":" port ]

    ntp-server-addr = =3D/ "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

 <= /o:p>

Roni,

 <= /o:p>

Thanks for = the review.

 <= /o:p>

See = below.


Kevin = Gross

Media = Network Consultant

AVA = Networks - www.AVAnw.com, www.X192.org

 <= /p>

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 =3D  "domain-name=3D" 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=3Dts-refclk:ntp=3Dtraceable – 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=3Dts-refclk:ntp=3D203.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”

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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-capabi= lity-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


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

 <= /o:p>

Magnus,=

 <= /o:p>

Thanks for = looking at this and sorry for the delay = responding.

 <= /o:p>

I agree = that mediaclk-ext is too restrictive. Your suggestion is = very accommodating  Something a bit more structured such as = 'token "=3D" byte-string' might be more appropriate. I = will check with my co authors on = this.

 <= /o:p>

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.

 <= /o:p>

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 - www.AVAnw.com, www.X192.org

 <= /p>

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 =3D "a=3Dssrc:" integer SP = clk-master-id

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

    =       timestamp-mediaclk =3D "a=3Dmediaclk:" = mediaclock

          mediaclock =3D = sender / refclk / streamid / mediaclock-ext

      =     sender =3D "sender" sender-ext

  =         sender-ext =3D token

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

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

          direct-ext =3D = token

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

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

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

  =         streamid-ext =3D token

    =       mediaclock-ext =3D 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 =3D 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
F=E4r=F6gatan 6     =            | Mobile +46 73 = 0949079
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

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_0004_01CE4ACC.7498FC50-- From magnus.westerlund@ericsson.com Tue May 7 04:47:56 2013 Return-Path: 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 922B221F8EFE for ; Tue, 7 May 2013 04:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.892 X-Spam-Level: X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[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, NORMAL_HTTP_TO_IP=0.001, 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 LN+oN7nlbWXp for ; Tue, 7 May 2013 04:47:51 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1305821F8EB1 for ; Tue, 7 May 2013 04:47:50 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-35-5188e9e5d172 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6C.AB.01956.5E9E8815; Tue, 7 May 2013 13:47:50 +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; Tue, 7 May 2013 13:47:49 +0200 Message-ID: <5188E9E4.8050904@ericsson.com> Date: Tue, 7 May 2013 13:47:48 +0200 From: Magnus Westerlund 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 References: <5163DF09.7050606@ericsson.com> <517636E0.2020607@ericsson.com> <5187C204.1060907@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VvfZy45Ag80neCxe9qxkt3hxqJ3N gcnj39XtzB5LlvxkCmCK4rJJSc3JLEst0rdL4MroX3qdpWBBfMWmmYoNjI89uhg5OSQETCTm bTrBBGGLSVy4t56ti5GLQ0jgFKPE74f9zBDOMkaJT6dWs4BU8QpoS8x89gLI5uBgEVCR+P4t CiTMJmAhcfNHIxtIWFQgWGJrawxEtaDEyZlPwDpFBNQlHu16CLaLWUBJYu7S18wgtrCAvcTb ywdZIFbtYpLoX/WBDSTBKRAoceH7P2aI4yQltrxoZ4do1pOYcrWFEcKWl2jeOhusRgjotIam DtYJjEKzkOyehaRlFpKWBYzMqxjZcxMzc9LLzTcxAgP14JbfBjsYN90XO8QozcGiJM6bzNUY KCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExsdvX6bDd3q8PVHZqnC26lJ18PX41B9Oc7l1G uuudexl+T15zPUtjm5mm5+wPJguPbHZ8p6q4caou3/LMI+8+z3ZavGbjBdbZntv7JAT/ydku z70utu41i6RGjoh0PEfKJZMwjaPbN846EBv6qPbZvyM6V+c8lq+ddnyhV+f3jJWf5pi/lIyS UWIpzkg01GIuKk4EAEsn4AEiAgAA Cc: IETF AVTCore WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 11:47:56 -0000 Hi, see inline. On 2013-05-07 02:58, Kevin Gross wrote: > Hi Magnus, > > Thanks for the quick response. Please have a look at my answers below. > If it looks like we're on the right track, let me know and I'll prepare > some text changes for closer review. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > On Mon, May 6, 2013 at 8:45 AM, Magnus Westerlund > > > wrote: > > 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. > > > First thing to note about this offer is that it does not contain a media > clock specification. In this case an asynchronous media clock is assumed > - there is no predictable relationship between the reference clock > specified (gps in this case) and the media clock. The relationship is > announced as we go in sender reports. Yes, I know I didn't specify the mediaclk. This actually lets me add an additional question here. My understanding is that the offerer's a=ts-refclk above indicates which type of clock it has for determine the NTP timestamp in its RTCP SR packets. However, is it always clear who the offerer is. In the RTCP domain, the actual used clock is bound to one or even more CNAMEs. Should this be explicitly expressed? > > > 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. > > > First paragraph does not apply because the offer does not specify a > direct-referenced media clock (see section 5.2). Agreed. > > > 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. > > > There's a terminology error in this paragraph. "media-refereneced" > should read "stream-referenced". This paragraph does not apply because > the offer does not specify a stream-referenced media clock (see section > 5.3). Ok, lets fix this issue. Agree that it doesn't apply as no a=mediaclk is specified. > > > Third paragraph: > The interpretation of not signalling explicitly any media clock. And > that > it can be dropped in the answer even if explicitly given the default in > the offer. > > > This is the applicable paragraph. It does allow you to specify a > reference clock in the offer as your described answer does. It defines > media clock signaling options for the answer but does not discuss the > reference clock answer. We need to add a requirement that the answer > MUST include the same reference clock specification as the offer. Yes, but it doesn't say anything of what the rules are beyond deriving a default value. That needs to be changed as below discussion indicates. > > > > 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. > > > Correct with one exception: a=mediaclk:sender is the same as not > specifying a media clock. In this case, no reference clock signaling is > required. Please be explicit about this exception. > > > 2) If a mediaclock is provided the answer must support that same clock, > (type and identity?) > > > Yes. I suggest that you are very explicit, especially when discussing clocks that have identifiers on how they are to be compared. > > > 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. > > > Yes. > > > 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. > > > The answer must specify a reference clock compatible with the offer. > Compatible means offer and answer must be exactly the same or offer and > answer must both be some form of "traceable" clock. This is discussed in > general in section 4.6 but perhaps the offer/answer implications need to > be spelled out in section 6. Yes, please ensure that there are explicit rules. I also think you need to be explicit about when multiple attributes may occur. I see this being present in Figure 3 in Section 4.7.1. Is this only for expressing the multiple server instances of the same NTP clock, or? I understand that you have use-cases like IDMS where offer and answer needs to agree on which reference clock is used. Are there no use-cases for cases when the parties just informs and are explicit about which clock they are using. There is after all a big difference knowing that the reference clock is driven by good quality source or just a free running system clock in the endpoint. But, as I don't have an explicit requirement on this I guess we leave this for now, and can in the future define a variant of the attribute that simply informs about which clock one uses. > > > 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? > > > I believe it is safe for the offerer to assume the answerer supports > media clock signaling if it learns that the answerer > supports reference clock signaling. This issue does not exist > with reference clock signaling. But I appreciate that allowing a default > response (no mediaclk specification) to an explicit offer > (a=mediaclk:sender) is not useful flexibility and is a lost opportunity > for a sanity check. I propose to remove the last sentence of the third > paragraph in section 6.1. We'll also add some additional discussion of > answer requirements to clarify this as well as the things that we > touched on above. I think that is fine. > > > > 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? > > > Yes, that's my position. I need to check with my coauthors to be sure > they're in agreement with me on this. Ok, and just to be clear. There is no support for expressing in an offer, here are my set of supported clocks. Pick one in the answer. > > > 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. > > > It is a concern if RFC 5939 is a dead end. What is your reason for your > concern about capneg adoption? I think I have already proposed to add > a reference to RFC 5939 in section 6.2. I can also add some discussion > about the available functionality of one or both parties does not > support capneg. Usage of Capneg for profile negotiation that has been rejected by most standards bodies for appearing to complex. If that is applicable also for this type of usage I don't know. There has been spent a lot of energy avoiding capneg. Likely more than was required to actually implement it. But there is a significant perception problem here. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Tue May 7 05:21:18 2013 Return-Path: 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 C585721F86AE; Tue, 7 May 2013 05:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 QMwLvAuSLjpw; Tue, 7 May 2013 05:21:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A9E21F8529; Tue, 7 May 2013 05:20:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p6 Message-ID: <20130507122043.6866.3256.idtracker@ietfa.amsl.com> Date: Tue, 07 May 2013 05:20:43 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-13.txt X-BeenThere: avt@ietf.org 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: Tue, 07 May 2013 12:21:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Securing the RTP Protocol Framework: Why RTP Does Not Ma= ndate a Single Media Security Solution Author(s) : Colin Perkins Magnus Westerlund Filename : draft-ietf-avt-srtp-not-mandatory-13.txt Pages : 9 Date : 2013-05-07 Abstract: This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-srtp-not-mandatory-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Tue May 7 05:26:31 2013 Return-Path: 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 D901521F89E8 for ; Tue, 7 May 2013 05:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 gd1BiRt0GQUC for ; Tue, 7 May 2013 05:26:27 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 343F521F86D5 for ; Tue, 7 May 2013 05:26:27 -0700 (PDT) Received: from [130.209.247.112] (port=54298 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UZgyI-0000Ai-To for avt@ietf.org; Tue, 07 May 2013 13:26:26 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Colin Perkins In-Reply-To: <20130507122043.6866.3256.idtracker@ietfa.amsl.com> Date: Tue, 7 May 2013 13:26:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6FE1688A-06BE-4A6D-8BBA-FE0AF4EF3B0F@csperkins.org> References: <20130507122043.6866.3256.idtracker@ietfa.amsl.com> To: IETF AVTCore WG X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-13.txt X-BeenThere: avt@ietf.org 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: Tue, 07 May 2013 12:26:32 -0000 This version of the draft has some editorial fixes and makes various = minor clarifications. I believe it's ready for another WG last call, = along with draft-ietf-avtcore-rtp-security-options. Colin On 7 May 2013, at 13:20, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Securing the RTP Protocol Framework: Why RTP = Does Not Mandate a Single Media Security Solution > Author(s) : Colin Perkins > Magnus Westerlund > Filename : draft-ietf-avt-srtp-not-mandatory-13.txt > Pages : 9 > Date : 2013-05-07 >=20 > Abstract: > This memo discusses the problem of securing real-time multimedia > sessions, and explains why the Real-time Transport Protocol (RTP), > and the associated RTP control protocol (RTCP), do not mandate a > single media security mechanism. Guidelines for designers and > reviewers of future RTP extensions are provided, to ensure that > appropriate security mechanisms are mandated, and that any such > mechanisms are specified in a manner that conforms with the RTP > architecture. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-13 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-srtp-not-mandatory-13 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From prvs=5840aa5913=magnus.westerlund@ericsson.com Wed May 8 07:07:52 2013 Return-Path: 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 C7ECF21F8FB6 for ; Wed, 8 May 2013 07:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.41 X-Spam-Level: X-Spam-Status: No, score=-105.41 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 XBJUJJp9Yc4C for ; Wed, 8 May 2013 07:07:46 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 21EC621F8FA9 for ; Wed, 8 May 2013 07:07:45 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-e3-518a5c30ba09 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DB.AB.01956.03C5A815; Wed, 8 May 2013 16:07:44 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 8 May 2013 16:07:44 +0200 Message-ID: <518A5C25.4050204@ericsson.com> Date: Wed, 8 May 2013 16:07:33 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-avtcore-aria-srtp@tools.ietf.org, IETF AVTCore WG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAJMWRmVeSWpSXmKPExsUyM+Jvra5BTFegwayz2hYve1ayW0yeLODA 5LFkyU8mjy+XP7MFMEVx2yQllpQFZ6bn6dslcGdc3HCEpWCee8Xio9uZGhj/GXQxcnJICJhI LHs1gRnCFpO4cG89G4gtJHCKUWLlJO4uRi4gexmjxLpLJ1hAErwC2hJL5s0Ds1kEVCR6V/9m BLHZBCwkbv5oBGrm4BAVCJbY2hoDUS4ocXLmE7ByEYEgibWLu8B2CQPtXbn5BtReSYktL9rZ QWxmAT2JKVdbGCFseYnmrbOZIe7Rlmho6mCdwMg/C8nYWUhaZiFpWcDIvIqRPTcxMye93HwT IzDADm75bbCDcdN9sUOM0hwsSuK8yVyNgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4QQSXVANj cXT37+RNAYyyKUdn9N2YGVaoqvMzQmSBduje9i3TJHwZla7M89+/5dHWrdN2C/PYTjjyr+Fc Tb5E747j0/fNbFv5P+fw7AW/C79/FfIynGp3brpKfX771d46Nov9ya4F745pFShrWOW41rLy rNhoNXdPDP+tw6UXlhSH18c2RTBFLf2o0/pWiaU4I9FQi7moOBEAWndvVAMCAAA= Subject: [AVTCORE] Comments on draft-ietf-avtcore-aria-srtp-01 X-BeenThere: avt@ietf.org 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, 08 May 2013 14:07:53 -0000 Hi, I have reviewed draft-ietf-avtcore-aria-srtp-01 and have some comments. Please review these and don't hesitate to ask for clarification or disagree with them. 1) Section 2: (1) ARIA in Counter Mode, (2) ARIA in Counter with CBC-MAC (CCM) Mode and (3) ARIA in Galois/Counter Mode (GCM). As you in the next heading are using ARIA-CTR shouldn't (CTR) be added as acronym for (1)? 2) Section 2.1 and 4: What are the security implications of using a 256 bit key length for the crypto but have as weak integrity protection as SAH1 32 bits? I think you need to discuss the implications of this, it doesn't appear to be particular balanced. 3) Section 2.2: The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use of AES-GCM and AES-CCM with SRTP. The use of ARIA-CCM and ARIA-GCM with SRTP is defined the same as that of AES-CCM and AES-GCM. Looking in AES-GCM it appears to define a generic AEAD procedures for SRTP cipher suits. Can you please be more explicit and clear on how you use that generic procedure? 4) Section 2.1, 2.2: These procedures are define by reference to existing algorithms like these sentences: ARIA counter modes are defined in a similar manner, and are denoted by ARIA_128_CTR, ARIA_192_CTR and ARIA_256_CTR respectively, according to the key lengths. The plaintext inputs to the block cipher are formed as in AES-CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs are processed as in AES-CTR. The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use of AES-GCM and AES-CCM with SRTP. The use of ARIA-CCM and ARIA-GCM with SRTP is defined the same as that of AES-CCM and AES-GCM. I think using words as "similar" and not being very explicit about what procedures from the other specification that applies here provide some risk for misunderstanding. I hope you can be more explicit and clear on which procedures and usage are applicable. 5) Section 3): The ARIA- CTR PRF is defined in a similar manner, but with each invocation of AES replaced with an invocation of ARIA. Similar to the above comment, using "similar" rather than same. Please be normative defining here. 6) Cipher suit definitions: According to Section 8.2 of RFC 3711 the following parameters are defined and have the specified default values: Parameter Mandatory-to-support Default --------- -------------------- ------- SRTP and SRTCP encr transf. AES_CM, NULL AES_CM (Other possible values: AES_f8) SRTP and SRTCP auth transf. HMAC-SHA1 HMAC-SHA1 SRTP and SRTCP auth params: n_tag (tag length) 80 80 SRTP prefix_length 0 0 Key derivation PRF AES_CM AES_CM Key material params (for each master key): master key length 128 128 n_e (encr session key length) 128 128 n_a (auth session key length) 160 160 master salt key length of the master salt 112 112 n_s (session salt key length) 112 112 key derivation rate 0 0 key lifetime SRTP-packets-max-lifetime 2^48 2^48 SRTCP-packets-max-lifetime 2^31 2^31 from-to-lifetime MKI indicator 0 0 length of the MKI 0 0 value of the MKI Are really these default value correct for these cipher suits. For example is still a 112 bit salt used for 256 bits keylengts? For ARIA_256_CTR clearly the key derivation PRF is not AES_CM? Thus I would suggest that you include the actual tables for the different cipher suits that you define with their relevant values. 7) Section 5. A) I would suggest creating different sub-section for each registry that is being manipulated. B) You are not providing the explicit names for the IANA Registries that you are adding into. Please go to IANA and copy and paste the names from the relevant registries into IANA section. For example: IANA is requested to add the below crypto suites to the "SRTP Crypto Suite Registrations" created by [RFC4568], at time of writing located on the following IANA page: http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xml#sdp-security-descriptions-3 Thus making it very clear which registry the listed values should be added to. 8) Section 5: Looking in RFC 5764 in Section 4.1.2 the registered SRTP protection profiles for DTLS each have a block defined like this: SRTP_AES128_CM_HMAC_SHA1_80 cipher: AES_128_CM cipher_key_length: 128 cipher_salt_length: 112 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 80 See also the AES-GCM draft that also includes tehm including some AEAD specifics like this one: AEAD_AES_256_GCM_8 cipher: AES_256_GCM cipher_key_length: 256 bits cipher_salt_length: 96 bits aead_auth_tag_length: 8 octets auth_function: NULL auth_key_length: N/A auth_tag_length: N/A maximum lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets I would recommend that you add these. 9) Section 5: [RFC3830] and [RFC5748] define encryption algorithms and PRFs for the SRTP policy in MIKEY. In order to allow the use of the algorithms defined in this document in MIKEY, IANA is requested to allocate the following numbers in the MIKEY sub-registries. SRTP Enc. alg | Value ---------------------- NULL | 0 AES-CM | 1 AES-F8 | 2 SEED-CTR | 3 SEED-CCM | 4 SEED-GCM | 5 ARIA-128-CTR | 6 (NEW) ARIA-128-CCM | 7 (NEW) ARIA-128-GCM | 8 (NEW) ARIA-128-GCM-8 | 9 (NEW) ARIA-128-GCM-12| 10 (NEW) Figure 4: Figure 1 from RFC 5748 (revised) A) Please don't suggest new values that hasn't been formally assigned yet, better to write them as TBA or TBD (To Be Assigned / Decided). B) To my understanding with MIKEY's structure the above registry (Encryption algorithm (Value 0)) actually should not include the key-length as that is a separate parameter in MIKEY. See MIKEY Security Protocol Parameters on the http://www.iana.org/assignments/mikey-payloads/mikey-payloads.xml IANA page. C) You should definitely look at the AES-GCM drafts IANA section, especially Section 14.3: 14.3. MIKEY In accordance with "MIKEY: Multimedia Internet KEYing" [RFC3830], IANA maintains several Payload Name Spaces under Multimedia Internet KEYing (MIKEY). This document requires additions to two of the lists maintained under MIKEY Security Protocol Parameters. On the SRTP policy Type/Value list (derived from Table 6.10.1.a of [RFC3830]) we request the following addition: Type | Meaning | Possible values ---------------------------------------------------------------- TBD | AEAD authentication tag length | 8, 12, or 16 (in octets) On the Encryption Algorithm List (derived from Table 6.10.1.b of [RFC3830]) we request the following additions: SRTP encr alg. | Value | Default Session Encr. Key Length ----------------------------------------------------------- AES-CCM | TBD | 16 octets AES-GCM | TBD | 16 octets The SRTP encryption algorithm, session encryption key length, and AEAD authentication tag values received from MIKEY fully determine the AEAD algorithm (e.g., AEAD_AES_256_GCM_8). The exact mapping is described in section 15. 10) Test Vectors Have you considered including test vectors like RFC 6188? 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Wed May 8 15:49:37 2013 Return-Path: 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 C936221F9048; Wed, 8 May 2013 15:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.338 X-Spam-Level: X-Spam-Status: No, score=-98.338 tagged_above=-999 required=5 tests=[AWL=-4.070, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001, 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 YcdQka0Dfw9O; Wed, 8 May 2013 15:49:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D30121F8E98; Wed, 8 May 2013 15:49:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130508224937.21261.95132.idtracker@ietfa.amsl.com> Date: Wed, 08 May 2013 15:49:37 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt X-BeenThere: avt@ietf.org 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, 08 May 2013 22:49:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Clock Source Signalling Author(s) : Aidan Williams Kevin Gross Ray van Brandenburg Hans Stokking Filename : draft-ietf-avtcore-clksrc-04.txt Pages : 23 Date : 2013-05-08 Abstract: NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying timestamp reference clock sources and SDP signalling identifying the media clock sources in a multimedia session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-clksrc-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kevin.gross@avanw.com Wed May 8 16:03:05 2013 Return-Path: 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 E360D21F902D for ; Wed, 8 May 2013 16:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.442 X-Spam-Level: ** X-Spam-Status: No, score=2.442 tagged_above=-999 required=5 tests=[AWL=1.300, 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_16=0.6, RDNS_NONE=0.1, 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 EVheiMf36U0j for ; Wed, 8 May 2013 16:03:01 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3924E21F9026 for ; Wed, 8 May 2013 16:03:01 -0700 (PDT) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta01.emeryville.ca.mail.comcast.net with comcast id ZPsr1l00B1eYJf8A1b31rE; Wed, 08 May 2013 23:03:01 +0000 Received: from mail-ie0-f169.google.com ([209.85.223.169]) by omta19.emeryville.ca.mail.comcast.net with comcast id Zb101l00R3fuNmh01b11SF; Wed, 08 May 2013 23:01:01 +0000 Received: by mail-ie0-f169.google.com with SMTP id u16so4432685iet.0 for ; Wed, 08 May 2013 16:01:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PGU/QF2Fxfl+ZzjPG6JACpzvQH8j0vXFUEo0ouYy5Aw=; b=hrpArPdc6KcdZDh6u8zpRAz5k7Mh6LaU8pdkmItdK/p4MD7HaokkkWX4VC//r/fTgI ZC6ht9h1hqKxOtkbViqW2NmSCrxwsM7R/izVQmPTbDFNRReiFcOlPGdFykSh/RwLXBpL s+ZHHsJogstsspVFNB3vNdrDtizQr/FztVyBaYTWU15seA+gQcTBAahWFRr7A3wJ+vRT b/WnQQkyr43os84lQHAzJMmSTslbFoeE6ZG4baUGkk5oggfvEIqmYAS1zsPI0vMeGFrm vJEpkhZJ5G50Lw9mHF5PP/FoRDHxWj4Y2/qCOsIbUWUHVwXuTlp5eCYqrWU5hT3K2qbm rMzQ== MIME-Version: 1.0 X-Received: by 10.50.3.67 with SMTP id a3mr3422752iga.88.1368054060351; Wed, 08 May 2013 16:01:00 -0700 (PDT) Received: by 10.50.180.201 with HTTP; Wed, 8 May 2013 16:01:00 -0700 (PDT) In-Reply-To: <02d601ce40f4$2e765d30$8b631790$@gmail.com> References: <5163DF09.7050606@ericsson.com> <02d601ce40f4$2e765d30$8b631790$@gmail.com> Date: Wed, 8 May 2013 17:01:00 -0600 Message-ID: From: Kevin Gross To: Roni Even Content-Type: multipart/alternative; boundary=089e013cbd5e4d0a4f04dc3ce85b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368054181; bh=PGU/QF2Fxfl+ZzjPG6JACpzvQH8j0vXFUEo0ouYy5Aw=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=UufSLHoD+lWrUkcnd3mkG/poJErVF6QYhOGo687eD2NNI4cB/f1VC81pGPpGtYm0i WMyCC4UfeMi31cDj9N8splzPFHkP3+SuNMM87rTkw1PVyMjSfK+C8GdQXz1AHpbaE1 6n3NrdZiUwHb0eC8BsiYWX4I/5EXNXahFZRqsXI8FXd80IWGf0lsrMokdSics+eZYa LmDNRsDQodHjgTb+V9OYlyc56n4A92+Fzy27EhWvRmtxuaAfp2d7CvTp9u5JnQqo93 MUVU9OXbODCPQcHVkxkyfq8thOr/m/WoVocLB59jd/2LGYZjdciMx2MTPUHJaMnZaW a9FDs/J9V6CLg== Cc: Magnus Westerlund , IETF AVTCore WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 23:03:06 -0000 --089e013cbd5e4d0a4f04dc3ce85b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Roni, With regards to items 5 & 6. 5. Please review my changes to section 8 in the newly published version 04 of the draft. If these changes do not satisfy your request, please cite an example of a policy specification I can work from to improve this further. 6. While the formatting is slightly different, I believe our draft contains all the information in the example you cite and we have the requirements in RFC 5226 section 5.1 covered. I can reformat the section to look more the example you cite but I don't think that would be a material improvement. If we're going to make improvements here I need more specifics on what exactly is not in compliance. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even 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 **** > > =93Two 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.=94 **** > > When you say interchangeable and how it relates to Magnus proposal to > allow negotiation.**** > > ** ** > > 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 =3D "domain-name=3D" 16ptp-domain-char =96 = did > you mean exactly 16 charaters?**** > > **2. **In figure 2 a=3Dts-refclk:ntp=3Dtraceable =96 do you need al= so to > specify the server address?**** > > **3. **In figure 3 a=3Dts-refclk:ntp=3D203.0.113.10 2011-02-19 > 21:03:20.345+01:00 =96 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 =93must=94 is really a =93SHOULD=94**** > > **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 wil= l > be specification required=94 see RFC 5226 **** > > **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-1= 3IANA section or other MMUSIC RFCs > **** > > ** ** > > 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 "=3D" > byte-string' might be more appropriate. I will check with my co authors o= n > 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 mechanism= s > 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 a= s > you have suggested will be adequate. Under some implementations, while > multiple clocks are supported, certain combinations of media and referenc= e > clocks may not be allowed.**** > > > **** > > Kevin Gross**** > > +1-303-447-0517**** > > Media Network Consultant**** > > AVA Networks - 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 =3D "a=3Dssrc:" integer SP clk-master-id > > clk-master-id =3D "mediaclk:master-id=3D" master-id > > timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock > > mediaclock =3D sender / refclk / streamid / mediaclock-ext > > sender =3D "sender" sender-ext > > sender-ext =3D token > > refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-ext] > > rate =3D [ SP "rate=3D" integer "/" integer ] > > direct-ext =3D token > > streamid =3D "master-id=3D" master-id > streamid =3D/ "IEEE1722=3D" avb-stream-id > streamid =3D/ streamid-ext > > master-id =3D EUI48 > avb-stream-id =3D EUI64 > > EUI48 =3D 5(2HEXDIG ":") 2HEXDIG > EUI64 =3D 7(2HEXDIG ":") 2HEXDIG > > streamid-ext =3D token > > mediaclock-ext =3D 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 =3D 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 side= s. > > 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 track= s: > > 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 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > 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**** > > ** ** > ** > ------------------------------ > ** > --089e013cbd5e4d0a4f04dc3ce85b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Roni,

With regards to items 5 & 6.<= /div>

5. Please review my changes to section 8 in the ne= wly published version 04 of the draft. If these changes do not satisfy your= request, please cite an example of a policy specification I can work from = to improve this further.

6. While the formatting is slightly different, I believ= e our draft contains all the information in the example you cite and we hav= e the requirements in RFC 5226 section 5.1 covered. I can reformat the sect= ion to look more the example you cite but I don't think that would be a= material improvement. If we're going to make improvements=A0here I nee= d more specifics on what exactly is not in compliance.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks -= =A0www.AVAnw.com,= =A0www.X192.org


On Wed, Apr 24, 2013 at 8:01 AM, Roni Ev= en <ron.even.tlv@gmail.com> wrote:

Hi Kevin,

I looked at the document and at Magnus comment.<= u>

<= u>=A0

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

=93Two or more NTP server= s may be listed at the same level in the session description to indicate th= at they are interchangeable.=A0 RTP=A0 senders or receivers can use any of = the listed NTP servers to govern a local clock that is equivalent to a loca= l clock slaved to a different server.=94

When you say interchangeable and how it relates to Magnus p= roposal to allow negotiation.

=A0

I also assume that the information in offer/answer and in d= eclarative SDP is used to provide sender information and not receiver one s= o is there a reason to have the same media clock in both direction when usi= ng conversional (offer/answer) application

=A0

=A0

Other comments

<= /u>=A0

1.=A0=A0=A0=A0=A0=A0 ptp-domain-name =3D=A0 &quo= t;domain-name=3D" 16ptp-domain-char =96 did you mean exactly 16 charat= ers?

2.=A0=A0=A0=A0=A0=A0 In figure 2 a=3Dts-refclk:n= tp=3Dtraceable =96 do you need also to specify the serv= er address?

3.=A0=A0=A0=A0=A0=A0 In figure 3 a=3Dts-refclk:n= tp=3D203.0.113.10 2011-02-19 21:03:20.345+01:00 =96 what is the last part w= ith the date and time, I thought the syntax only have server address.

4.=A0=A0=A0=A0=A0=A0 In section 6.1 the first se= ntence in the first and second paragraph it look to me like the =93must=94 = is really a =93SHOULD=94

5.=A0=A0=A0=A0=A0=A0 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=94 see RFC 5226

6.=A0=A0=A0=A0=A0=A0 The IANA section is not ful= ly 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=

=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">Roni Even

=A0

=A0

=A0<= /p>

From: avt-bounces@ietf.org [mailto:avt-bo= unces@ietf.org] On Behalf Of Kevin Gross
Sent: 18 April, 2013 1:41 AM
To: Magnus Westerlund
C= c: IETF AVTCore WG


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

=A0

Magnus,

=A0

Thanks for looking= at this and sorry for the delay responding.

=A0

I agree that mediaclk-ext is too restrictive. Your suggestio= n is very=A0accommodating=A0 Something a bit more structured such as 't= oken "=3D" byte-string' might be more appropriate. I will=A0c= heck=A0with my co authors on this.

=A0

As there is great=A0precedent for it in SDP, we have impleme= nted a simple offer-answer model. I would propose that systems should use t= he mechanisms defined in RFC 5939 if negotiation of clock configurations is= necessary. Perhaps adding some discussion and a=A0reference=A0to this RFC = would help.

=A0

I don't think that independently negotiating reference= =A0and=A0media clocks as you have suggested will be adequate. Under some im= plementations, while multiple clocks are supported, certain combinations of= media and reference clocks may not be allowed.

=

Kevin Gross=

Media Network Consultant

AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

= =A0

On Tue, Apr 9, 2013 at 3:27 A= M, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

Hi,

I promised doing an review of the O/A sec= tion. 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<= br> =A0 =A0information.

=A0 =A0 =A0 =A0 =A0 mediaclk-master =3D "a= =3Dssrc:" integer SP clk-master-id

=A0 =A0 =A0 =A0 =A0 clk-mast= er-id =3D "mediaclk:master-id=3D" master-id

=A0 =A0 =A0 = =A0 =A0 timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock

=A0 =A0 =A0 =A0 =A0 mediaclock =3D sender / refclk / streamid / mediacl= ock-ext

=A0 =A0 =A0 =A0 =A0 sender =3D "sender" sender-ext=

=A0 =A0 =A0 =A0 =A0 sender-ext =3D token

=A0 =A0 =A0 =A0 =A0= refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-e= xt]

=A0 =A0 =A0 =A0 =A0 rate =3D [ SP "rate=3D" integer "/&q= uot; integer ]

=A0 =A0 =A0 =A0 =A0 direct-ext =3D token

=A0 = =A0 =A0 =A0 =A0 streamid =3D "master-id=3D" master-id
=A0 =A0 = =A0 =A0 =A0 streamid =3D/ "IEEE1722=3D" avb-stream-id
=A0 =A0 =A0 =A0 =A0 streamid =3D/ streamid-ext

=A0 =A0 =A0 =A0 =A0 m= aster-id =3D EUI48
=A0 =A0 =A0 =A0 =A0 avb-stream-id =3D EUI64

= =A0 =A0 =A0 =A0 =A0 EUI48 =3D 5(2HEXDIG ":") 2HEXDIG
=A0 =A0 = =A0 =A0 =A0 EUI64 =3D 7(2HEXDIG ":") 2HEXDIG

=A0 =A0 =A0 =A0 =A0 streamid-ext =3D token

=A0 =A0 =A0 =A0 =A0 media= clock-ext =3D token

I wonder if not the mediaclock-ext construction = is to restrictive. As
the refclk produces a sting with white-spaces in i= t, 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
shou= ld be possible to use. Likely the only resteriction should be that
it st= arts with a token. Thus using:

mediaclock-ext =3D token [SP byte-string]

This would require a t= oken for identifying the method followed by a
space and then full freedo= m for anything that is allowed on an SDP
attribute value.


2. = Section 6:

Purpose of signalling?

I think this type of signalling can selec= t 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 avail= able mechanism on both sides.

The currently proposed solution does neither of these. It enables theofferer to express to declare I intended to use X and for the answer tosay 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 a= re here. And I will propose
some goals with the signalling based on my u= nderstanding of how these
defined timestamp reference clocks and media s= tream clocks can be used.
And we do need to be aware that different application may have differentneeds.

Goal with signalling:

1. Enable each media sender to = declare its actually used ts-refclk, i.e.
what clock is base for the RTC= P 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. Enabl= e two media sender using SDP O/A to determine what common clocks
they ac= tually 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 followi= ng.
A. has three ts-refclk =A0it can use. B has two ts-refclk available.= They
are going to watch social TV. To make it at all possible for the s= ocial
TV service to play out content at A and B in sync they need to have
eith= er 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 sc= enario the TV service will be able to ensure that the
media is played out is sync.


As a technical solution to these is= sues there are two main solution tracks:

1) Change the respective SD= P 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 attribut= es 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 clock= s.

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

I will note that this is likely to req= uire 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<= br>could use OPTIONS to provide a SDP which includes the negotiation
att= ribute to enable the other side to select using a clock that is
supporte= d 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 crea= te two new SDP attributes one for
each type of clock usage (ts-refclk an= d 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 add= s
all it supports. Hopefully there is someone in the list that is common= .
The highest priority between the two parties should be used when commo= n
clock is required. IF that is not, then these attributes should not be
i= ncluded. 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
no= t add additional clocks it supports that are not common.

I really ap= preciate feedback on these comments and ideas.

Cheers

Magnus = Westerlund

----------------------------------------------------------------------<= br>Multimedia Technologies, Ericsson Research EAB/TVM
------------------= ----------------------------------------------------
Ericsson AB =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
<= br>_______________________________________________
Audio/Video Transport= Core Maintenance
avt@= ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

=A0


--089e013cbd5e4d0a4f04dc3ce85b-- From magnus.westerlund@ericsson.com Mon May 13 00:09:33 2013 Return-Path: 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 4FB1321F8FEC for ; Mon, 13 May 2013 00:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.318 X-Spam-Level: X-Spam-Status: No, score=-95.318 tagged_above=-999 required=5 tests=[FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_EQ_SE=0.35, 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 awP3D8l2Sn8R for ; Mon, 13 May 2013 00:09:28 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4228021F8FE8 for ; Mon, 13 May 2013 00:09:27 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-fe-519091a64909 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id AC.BC.32006.6A190915; Mon, 13 May 2013 09:09:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 13 May 2013 09:09:26 +0200 Message-ID: <519091A5.3040908@ericsson.com> Date: Mon, 13 May 2013 09:09:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: avt@ietf.org References: <20130508224937.21261.95132.idtracker@ietfa.amsl.com> In-Reply-To: <20130508224937.21261.95132.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre6yiRMCDZ53iVm87FnJ7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO3bTzIWXJWs2LGmma2BcZlIFyMnh4SAicS3i5vZIWwxiQv3 1rN1MXJxCAmcYpTYvecLI4SznFFi797trCBVvALaEmfmf2UEsVkEVCVW/rzNAmKzCVhI3PzR CNTNwSEqECyxtTUGolxQ4uTMJ2AlIgICEiu2/wWzhQWcJbr/gSzjBJrvKHF83jWwIzgFnCR+ /J3BDHGQpMSWF+1gcWYBPYkpV1sYIWx5ieats5kherUlGpo6WCcwCs5Csm4WkpZZSFoWMDKv YmTPTczMSS832sQIDL+DW36r7mC8c07kEKM0B4uSOG8yV2OgkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBka9U3ZH9kRp3HgpUrfBl3vK/eBWrr8V9bMUp/MmpVxV3TZ1+felC3aoyc1Y1+Xh 9fXYpy4Vn+jghxzrtPyZOKYb5WrOffmTt1NCxv/wiYL/5ZyK7DOm5WfMmWOmpVJRpq6aFLJu jttF9Y9dU2Ibo3kDP71sFRHoDEzS9vDJKGm+Kp//OP50ohJLcUaioRZzUXEiALjbMIENAgAA Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt X-BeenThere: avt@ietf.org 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 07:09:33 -0000 Due to some strange list issues, I forward this on behalf of Kevin. ---------- Forwarded message ---------- From: Kevin Gross Date: Wed, May 8, 2013 at 4:58 PM Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt To: "avt@ietf.org" This version addresses comments brought up in WGLC as well as issues identified by the authors. The following changes are included. 1. References changed to symbolic due to problems with numbered references in new xml2rfc tool 2. Capitalize normative language 3. Clarify meaning of interchangeable reference clocks 4. Allow specification of multiple 1588 clock sources as is allowed for NTP servers 5. Use consistent "Timestamp reference clock" terminology 6. Remove some lingering synchronization confidence discussion and example 7. Relax definition for mediaclk-ext to allow more complex extensions 8. Rework section 6 (Signalling Considerations) to address comments from Magnus and Roni 9. Specify extension policy for new registries defined in this document Magnus and Roni, please let us know if these changes address your recent comments. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com, www.X192.org On 2013-05-09 00:49, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : RTP Clock Source Signalling > Author(s) : Aidan Williams > Kevin Gross > Ray van Brandenburg > Hans Stokking > Filename : draft-ietf-avtcore-clksrc-04.txt > Pages : 23 > Date : 2013-05-08 > > Abstract: > NTP format timestamps are used by several RTP protocols for > synchronisation and statistical measurements. This memo specifies > SDP signalling identifying timestamp reference clock sources and SDP > signalling identifying the media clock sources in a multimedia > session. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-clksrc-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- 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 ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon May 13 01:45:35 2013 Return-Path: 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 2CEC621F9051 for ; Mon, 13 May 2013 01:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.949 X-Spam-Level: X-Spam-Status: No, score=-103.949 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 wemRpEcoQKCL for ; Mon, 13 May 2013 01:45:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0E221F8F6E for ; Mon, 13 May 2013 01:45:20 -0700 (PDT) X-AuditID: c1b4fb2d-b7f536d000006e05-0c-5190a81fd2e8 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E2.88.28165.F18A0915; Mon, 13 May 2013 10:45:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 13 May 2013 10:45:19 +0200 Message-ID: <5190A81F.1080700@ericsson.com> Date: Mon, 13 May 2013 10:45:19 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: avt@ietf.org, draft-ietf-avtcore-clksrc@tools.ietf.org References: <20130508224937.21261.95132.idtracker@ietfa.amsl.com> In-Reply-To: <20130508224937.21261.95132.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3VldhxYRAg+sTGS1e9qxkt5j0dTur A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxoPchW8FMxYqdt9tYGxgvSXUxcnJICJhI fPrynBnCFpO4cG89WxcjF4eQwClGibvPVrKCJIQEljNKPPoiAmLzCmhLTHi1hR3EZhFQlTi3 agMTiM0mYCFx80cjUDMHh6hAsMTW1hiIckGJkzOfsIDYIgJWEmtO7gIrFxZwluj+B7ILZLyj xPF518BGcgo4Sfz4OwPqHkmJLS/aweLMAnoSU662MELY8hLNW2czQ/RqSzQ0dbBOYBSchWTd LCQts5C0LGBkXsXInpuYmZNebriJERiQB7f81t3BeOqcyCFGaQ4WJXHeJK7GQCGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MGgcfFgsvy4tZs3xWAsvRKfHsJzM+RH44/mhJUobKseMLL1zY uWeFHL/wZb3DZXsPKHFYifm4lNZnBrmcidw82/bgi0K3OT9fvL+d4LCZ50DMywWLmRRenXdd nBQeVKTwl21Pf/xD42XnVtzuuz7/Z6PMJec4rkXrp2X++nZxz8L6WZPCPNZnr1ViKc5INNRi LipOBAALlBItFgIAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt X-BeenThere: avt@ietf.org 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 08:45:35 -0000 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. 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. 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? 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]." 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. 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. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From kevin.gross@avanw.com Mon May 13 13:40:26 2013 Return-Path: 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 63C9221F9003 for ; Mon, 13 May 2013 13:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7QAxB69oogE for ; Mon, 13 May 2013 13:40:22 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 7A18221F8733 for ; Mon, 13 May 2013 13:40:21 -0700 (PDT) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta13.emeryville.ca.mail.comcast.net with comcast id bV5D1l0061vN32cADYgMDu; Mon, 13 May 2013 20:40:21 +0000 Received: from mail-ie0-f179.google.com ([209.85.223.179]) by omta22.emeryville.ca.mail.comcast.net with comcast id bYeL1l00Q3sr69M8iYeLwi; Mon, 13 May 2013 20:38:21 +0000 Received: by mail-ie0-f179.google.com 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; d=google.com; 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 10.50.92.69 with SMTP id ck5mr10739014igb.107.1368477500277; Mon, 13 May 2013 13:38:20 -0700 (PDT) Received: by 10.50.180.201 with HTTP; Mon, 13 May 2013 13:38:20 -0700 (PDT) In-Reply-To: <5190A81F.1080700@ericsson.com> References: <20130508224937.21261.95132.idtracker@ietfa.amsl.com> <5190A81F.1080700@ericsson.com> 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; d=comcast.net; 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: "avt@ietf.org" , "draft-ietf-avtcore-clksrc@tools.ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt X-BeenThere: avt@ietf.org 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 --047d7b10d03d498fa904dc9f7fdd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for your continued help improving this. Let me know what you think about my answers and proposed revisions below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Mon, May 13, 2013 at 2:45 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I have reivewed the changes and I don't think Section 6.1 nor 6.2 is clea= r. > > 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=3Dts-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=3Dts-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 suggested. > > Question: Should as alternative to no a=3Dts-refclk in the answer > a=3Dts-refclk:private be allowed as indication that the answer will run o= n > 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=3Dts-refclk) with a=3Dmediaclk. I think it would better with a clearer > full spec for just the reference clock, like my proposal above, then > followed by the a=3Dmediaclk rules, especially in relation to the ts-refc= lk. > > 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=E4r=F6gatan 6 | Mobile +46 73 0949079 > 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 > --047d7b10d03d498fa904dc9f7fdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 -=A0www.AVAnw.com,=A0www.X192.org


On Mon, May 13, 2013 at 2:45 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wro= te:
Hi,

I have reivewed the changes and I don't think Section 6.1 nor 6.2 is cl= ear.

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 =A0 =A0allows the offerer to declare the reference clock and media clock in=
=A0 =A0use and allows the answerer to acknowledge that a connection
=A0 =A0according to these declarations will be successful or, in limited =A0 =A0cases described below, specify a simplified synchronization mode.&qu= ot;

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=3Dts-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=3Dts-refclk attribute SHALL NOT be included in the answer.

The meaning of multiple reference clock specification= s 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/answ= er as you have suggested.

Question: Should as alternative to no a=3Dts-refclk in the answer
a=3Dts-refclk:private be allowed as indication that the answer will run on<= br> 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 d= on't think it is useful for an answer to contain a reference clock spec= ification 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 co= nnection that is made is without a reference clock.

Then I think it makes sense to follow this by:

=A0 "While full negotiation of reference clock and media clock attribu= tes
=A0 =A0is not directly supported in the clock source signalling defined in<= br> =A0 =A0this document, negotiation MAY be accomplished using capabilities =A0 =A0negotiation 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 refer= ence clock offer/answer as separate topics because there are interactions: = some media clock modes do not require a reference clock, others do.=A0

Then we have =A0the use of SHOULD:

=A0 =A0An answer to an offer with direct-referenced media clock SHOULD
=A0 =A0include the same media clock and reference clock signalling in which=
=A0 =A0case a connection is established using the specified synchronisation= .
=A0 =A0Alternatively the answer MAY omit both signals or include only the =A0 =A0reference clock specified in the offer. =A0In this case, a connectio= n
=A0 =A0with 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 signal= ing - establish connection as offered - expected behavior for an answerer s= upporting Clksrc
  2. Omit media and reference signaling - establish asynchronous connec= tion - 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 thi= s 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.

=A0 =A0An answer to an offer with stream-referenced media clock signalling<= br> =A0 =A0SHOULD include the same media clock specification. =A0If the offer =A0 =A0contains reference clock signalling, the answer SHOULD include the =A0 =A0same reference clock specification. =A0The answer MAY omit reference=
=A0 =A0clock signalling. =A0If reference clock signalling is not present in=
=A0 =A0the answer, either due to not being present in the offer or due to =A0 =A0being dropped in the answer, the stream may be established as rate =A0 =A0synchronised but not time synchronised.


I also think this above section mixes up reference clock signalling
(a=3Dts-refclk) with a=3Dmediaclk. I think it would better with a clearer full spec for just the reference clock, like my proposal above, then
followed by the a=3Dmediaclk 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 of= fer:
  1. Stream-reference media clock with refere= nce clock
  2. Stream-referenced media clock without reference clock
Perhaps splitting this into separate paragraphs or subsec= tions would clarify things.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287=
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--047d7b10d03d498fa904dc9f7fdd-- From magnus.westerlund@ericsson.com Tue May 14 01:15:44 2013 Return-Path: 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 4D5A021F852A for ; Tue, 14 May 2013 01:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.285 X-Spam-Level: X-Spam-Status: No, score=-104.285 tagged_above=-999 required=5 tests=[AWL=1.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 cb2cWsGMeEWG for ; Tue, 14 May 2013 01:15:32 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8721F8450 for ; Tue, 14 May 2013 01:15:30 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-b6-5191f2a1905f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 15.DD.01956.1A2F1915; Tue, 14 May 2013 10:15:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 14 May 2013 10:15:29 +0200 Message-ID: <5191F29F.8050106@ericsson.com> Date: Tue, 14 May 2013 10:15:27 +0200 From: Magnus Westerlund 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 References: <20130508224937.21261.95132.idtracker@ietfa.amsl.com> <5190A81F.1080700@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvre7CTxMDDbYtVLd42bOS3WLS1+2s Fi8OtbM5MHv8u7qd2WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyrh2eT1TwX6niu+951ka GHuMuxg5OSQETCRWrXrBCmGLSVy4t56ti5GLQ0jgFKNE64yHUM5yRomDTzeygVTxCmhLvH+/ H8xmEVCVODGrkxHEZhOwkLj5oxEozsEhKhAssbU1BqJcUOLkzCcsILaIgLrEo10PmUBsZoFq iVVr5oGNERZwluj+B7N4GaPE5v+bwRo4BQIlTsw/BnWdpMSWF+3sEM16ElOutjBC2PISzVtn M4PYQkC3NTR1sE5gFJqFZPcsJC2zkLQsYGRexciem5iZk15uvokRGMAHt/w22MG46b7YIUZp DhYlcd5krsZAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxzZFy/Knr6uzUtuLyfZfMDqTdp q33mPDjC0hi8NFKDa+bHmG89x4XDvx5wUND8EzI/f2WQIM9Gm/32xS8VF3d41L3Ll+M0tVuo 6+C0zMFV8Y7B/9qymN8P3/AIKjZ7rk7NNA0KmCefuf5D/+FEqyvSG3J2zzC/uYNN+M0NmaQX Xz7l8CUuOKTEUpyRaKjFXFScCACKlQV3LgIAAA== Cc: "avt@ietf.org" , "draft-ietf-avtcore-clksrc@tools.ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt X-BeenThere: avt@ietf.org 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: Tue, 14 May 2013 08:15:44 -0000 Hi, I think we are making progress on this. O/A is challenging to describe in sufficient detail. I can try to find time for a phone call if you think that would significantly speed up the progress. Contact me of list in that case. Comments inline. On 2013-05-13 22:38, Kevin Gross wrote: > Thanks for your continued help improving this. Let me know what you > think about my answers and proposed revisions below. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > 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. Yes, I understand the need to discuss when you have a mediaclk the need for having certain types of reference clocks etc. However, usage of the reference clock alone is not clear, neither what is allowed to include, nor how to interpret the answer, and what is allowed in the answer. This must be clarified. > > > 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 suggested. Please do. > > > 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. Ok, then I guess the specification should be clear that you shall include a value that says, we don't have a common clock, to separate that from the case of I don't know what this a=ts-refclk is. Although the actual implications may be the same. > > > 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. Yes, I just meant this as a hint that I think the above text proposal should be inserted prior to the above paragraph. Sorry for not being clear. > > > 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. Sure, but you need to ensure that all options allowed and relevant combinations that can be produced and their interpretations are described. > > > 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. Yes, I think you should split the different types of offers into different paragraphs, then look at the result depending on what the answerer can and do answer. 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Mon May 20 12:10:12 2013 Return-Path: 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 C234E21F9612; Mon, 20 May 2013 12:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 F5jx+fbzplv9; Mon, 20 May 2013 12:10:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF3C21F9610; Mon, 20 May 2013 12:10:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130520191008.12178.61780.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 12:10:08 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-06.txt X-BeenThere: avt@ietf.org 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, 20 May 2013 19:10:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : AES-GCM and AES-CCM Authenticated Encryption in Secure R= TP (SRTP) Author(s) : David A. McGrew Kevin M. Igoe Filename : draft-ietf-avtcore-srtp-aes-gcm-06.txt Pages : 27 Date : 2013-05-20 Abstract: This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-aes-gcm-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rlb@ipv.sx Tue May 28 13:10:49 2013 Return-Path: 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 A56A621F8900 for ; Tue, 28 May 2013 13:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 bnT3PKA4Jl+T for ; Tue, 28 May 2013 13:10:43 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id C2AA021F8976 for ; Tue, 28 May 2013 13:10:38 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j6so10645544oag.18 for ; Tue, 28 May 2013 13:10:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=j47UEvnwFa8gj8gPqZsYSuuGoNdmx8QjsrR+DwOg39s=; b=A1xjif0lueFdIW0eCQQJ3bZ43NRVQQEdnfiSaf+sBs6wKyLSE5mLxJWkdCAWlsLcD6 B+Fp2Zkj6v9sbNNz3x24fmUy7guzRLU4TLwjecwxlK3+SDvN8MFSAH97D5ha4QhRm5vj txprQY1VzPPPa7tsk/evRhYvyxXxyP/E3g7grH9TsETw0MUm/RbhgGUXOj/lFu5EuixJ mHEBmAIRcT2EjsjYxPDLCvv5mUZiulB9GM30dgMl9Lo/EPFK0V0FQ7AJEaRwYvUaERtF vBA6uyr1jFkO308GUfB9BV97//xxuGMId/9ZoUl/FapCfxDHYILahoIz2MSzb1mfy4Pj STcQ== MIME-Version: 1.0 X-Received: by 10.182.125.164 with SMTP id mr4mr22018913obb.94.1369771838332; Tue, 28 May 2013 13:10:38 -0700 (PDT) Received: by 10.60.17.9 with HTTP; Tue, 28 May 2013 13:10:38 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: References: Date: Tue, 28 May 2013 16:10:38 -0400 Message-ID: From: Richard Barnes To: avt@ietf.org Content-Type: multipart/alternative; boundary=089e013c709ad8f6a204ddccdb2d X-Gm-Message-State: ALoCoQlEEaZYElsF5muCIzfJcaaTA3l6wKU2KS+qKqPs8vEeCADOF7dSojb2uvXWvuDKnBTSm46P Subject: [AVTCORE] Fwd: AD review of draft-ietf-avtcore-avp-codecs-02 X-BeenThere: avt@ietf.org 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: Tue, 28 May 2013 20:10:49 -0000 --089e013c709ad8f6a204ddccdb2d Content-Type: text/plain; charset=ISO-8859-1 Sent to wrong list... ---------- Forwarded message ---------- From: Richard Barnes Date: Tue, May 28, 2013 at 4:09 PM Subject: AD review of draft-ietf-avtcore-avp-codecs-02 To: avtcore@ietf.org, draft-ietf-avtcore-avp-codecs@tools.ietf.org I have reviewed this draft, and think it's pretty much good to go to IETF LC. Two minor comments: -- Given that the only thing this document does is remove DVI4 from the recommendation, it would be helpful if the title were more specific. Say, "Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)" Of course, then the rest of the document isn't so necessary :) -- I don't think the all-caps "REQUIRED" makes sense in the context of "some environments". It's not a requirement of this specification. Thanks, --Richard --089e013c709ad8f6a204ddccdb2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sent to wrong list...

--= -------- Forwarded message ----------
From: Richard Barnes <rlb@ipv.sx>
Date: T= ue, May 28, 2013 at 4:09 PM
Subject: AD review of draft-ietf-avtcore-avp-codecs-02
To: avtcore@ietf.org, draft-ietf-avtcore-avp-codecs@tools.ietf.= org


I have reviewed this draft, and think it's pre= tty much good to go to IETF LC.

Two minor comments:=A0

-- Given that the only thing this document does is = remove DVI4 from the recommendation, it would be helpful if the title were = more specific. =A0Say, "Update to Remove DVI4 from the Recommended Codecs for the RTP Profile fo= r Audio and Video=A0Conferences with Minimal Control (RTP/AVP)" =A0Of course, then= the rest of the document isn't so necessary :)

-- I don't think the all-caps "REQUIRED" = makes sense in the context of "some environments". =A0It's no= t a requirement of this specification.

Thanks,
--Richard

--089e013c709ad8f6a204ddccdb2d-- From rlb@ipv.sx Tue May 28 13:50:59 2013 Return-Path: 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 BDB1221F8CE9 for ; Tue, 28 May 2013 13:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 AFGuCRrAAmTW for ; Tue, 28 May 2013 13:50:54 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 96E3621F842B for ; Tue, 28 May 2013 13:50:54 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id ef5so9634131obb.16 for ; Tue, 28 May 2013 13:50:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=XvV91Yeji5Jdsqv22qkFnmeQQqX4S7loVNsJYwEV2XM=; b=PCx7FccDS3nuT1t174Q0MaPSl/LEr9gKaylUOX6KXTvkr/To87l75TIpmC328ckGCZ o95yRvZXdfxHmomVMoy3WkwTfeT7R0YSw1QSRdBg9g1GsK/WKj8EBPoJYft8s+GsyRz6 K2gDkVNqVctrjKsaU/Fw/Vtyt9ZtmeN9mo1bK2QMH6bvPD0VEagBMq09auVupF90zlnB OQ7AfL1Xw0DUs3P0Ql8GwzcuJaWblrix2xkouJ6E6TmgKMSGyJ/+CXft3cNrBX8dI/dJ EJF7glR6IJfKgGmAodDXmErjiFZrxknSzEsR26lVEFcnjHvNtuG+D8+m1DJCxXLtX14p OBTw== MIME-Version: 1.0 X-Received: by 10.182.46.230 with SMTP id y6mr3232037obm.79.1369774252611; Tue, 28 May 2013 13:50:52 -0700 (PDT) Received: by 10.60.17.9 with HTTP; Tue, 28 May 2013 13:50:52 -0700 (PDT) X-Originating-IP: [192.1.51.101] Date: Tue, 28 May 2013 16:50:52 -0400 Message-ID: From: Richard Barnes To: avt@ietf.org, draft-ietf-avtcore-idms@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b676104bfe9ec04ddcd6bb9 X-Gm-Message-State: ALoCoQnaZ2jYAHle6PBwP3hTChRTxHDtQWfPUuD8j3FTp4jhxGxZUhv2Lq1tvmqmVL8wd/SpRhVE Subject: [AVTCORE] AD review of draft-ietf-avtcore-idms-09 X-BeenThere: avt@ietf.org 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: Tue, 28 May 2013 20:50:59 -0000 --047d7b676104bfe9ec04ddcd6bb9 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this draft. I'm going to go ahead and send it to IETF LC, but would like the authors to consider the following comments: -- It doesn't seem appropriate for the figures in Section 7 and Section 8 to have the XR header in addition to the block format. If you compare other documents defining XR block types, none of them include the header. Suggest removing the header lines. -- Do you want to define a registry for SPST values? That would let you assign values out of the remaining space (for example, if TISPAN needed one) without updating this RFC. -- The value you provide for 2^32 - 1 is incorrect. It should be 4294967295, not 4294967294. Other than that, the document reads well. The use cases were helpful in understanding how the overall system would work. Thanks, --Richard --047d7b676104bfe9ec04ddcd6bb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this draft. =A0I'm going to go ahead a= nd send it to IETF LC, but would like the authors to consider the following= comments:

-- It doesn't seem appropriate for the fi= gures in Section 7 and Section 8 to have the XR header in addition to the b= lock format. =A0If you compare other documents defining XR block types, non= e of them include the header. =A0Suggest removing the header lines.

-- Do you want to define a registry for SPST values? = =A0That would let you assign values out of the remaining space (for example= , if TISPAN needed one) without updating this RFC.

-- The value you provide for 2^32 - 1 is incorrect. =A0It should be 4294967= 295, not=A04294967294.

Other than that, the document reads well. =A0The use cases were he= lpful in understanding how the overall system would work. =A0
<= div>
Thanks,
--Richard
--047d7b676104bfe9ec04ddcd6bb9-- From iesg-secretary@ietf.org Tue May 28 13:53:13 2013 Return-Path: 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 084D011E80EE; Tue, 28 May 2013 13:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 e3dJN0ktq9NV; Tue, 28 May 2013 13:53:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DDD11E80EC; Tue, 28 May 2013 13:52:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Sender: Message-ID: <20130528205259.13259.77801.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2013 13:52:59 -0700 Cc: avt@ietf.org Subject: [AVTCORE] Last Call: (Update to Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 20:53:13 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Update to Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates the RTP/AVP profile (and by extension, the profiles that build upon it) to reflect changes in audio codec usage since the document was originally published. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue May 28 13:55:44 2013 Return-Path: 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 8CA6C21E8063; Tue, 28 May 2013 13:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 vVvwUujrHXqA; Tue, 28 May 2013 13:55:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B02D611E80E2; Tue, 28 May 2013 13:55:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Sender: Message-ID: <20130528205543.24390.76625.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2013 13:55:43 -0700 Cc: avt@ietf.org Subject: [AVTCORE] Last Call: (Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 20:55:44 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue May 28 14:00:44 2013 Return-Path: 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 AFCD521F842A; Tue, 28 May 2013 14:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 kVkLjjiARpsw; Tue, 28 May 2013 14:00:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEFC21F90BB; Tue, 28 May 2013 14:00:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Sender: Message-ID: <20130528210043.13263.62684.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2013 14:00:43 -0700 Cc: avt@ietf.org Subject: [AVTCORE] Last Call: (Inter-destination Media Synchronization using the RTP Control Protocol (RTCP)) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 21:00:44 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Inter-destination Media Synchronization using the RTP Control Protocol (RTCP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new RTP Control Protocol (RTCP) Packet Type and RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Reporting Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be send to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is usefull are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-idms/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-idms/ballot/ No IPR declarations have been submitted directly on this I-D.