http://blog.gmane.org/gmane.ietf.avt hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.avt/14442 <pre>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: 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. Please do. 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. 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. Sure, but you need to ensure that all options allowed and relevant combinations that can be produced and their interpretations are described. 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&lt; at &gt;ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Magnus Westerlund 2013-05-14T08:15:27 http://permalink.gmane.org/gmane.ietf.avt/14441 <pre>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 &lt;http://www.avanw.com/&gt;, www.X192.org On Mon, May 13, 2013 at 2:45 AM, Magnus Westerlund &lt; magnus.westerlund&lt; at &gt;ericsson.com&gt; wrote: Reference clock requirements are discussed in parallel with media clock in the paragraphs that follow. 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. 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. 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. 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. 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. _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Kevin Gross 2013-05-13T20:38:20 http://permalink.gmane.org/gmane.ietf.avt/14440 <pre>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&lt; at &gt;ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Magnus Westerlund 2013-05-13T08:45:19 http://permalink.gmane.org/gmane.ietf.avt/14439 <pre>Due to some strange list issues, I forward this on behalf of Kevin. ---------- Forwarded message ---------- From: Kevin Gross &lt;kevin.gross&lt; at &gt;avanw.com&gt; Date: Wed, May 8, 2013 at 4:58 PM Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-04.txt To: "avt&lt; at &gt;ietf.org" &lt;avt&lt; at &gt;ietf.org&gt; 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&lt; at &gt;ietf.org wrote: </pre> Magnus Westerlund 2013-05-13T07:09:25 http://permalink.gmane.org/gmane.ietf.avt/14438 <pre>Roni, With regards to items 5 &amp; 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 &lt;http://www.avanw.com/&gt;, www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Kevin Gross 2013-05-08T23:01:00 http://permalink.gmane.org/gmane.ietf.avt/14437 <pre> 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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> internet-drafts< at >ietf.org 2013-05-08T22:49:37 http://permalink.gmane.org/gmane.ietf.avt/14436 <pre>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 &lt;From, To&gt; 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&lt; at &gt;ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Magnus Westerlund 2013-05-08T14:07:33 http://permalink.gmane.org/gmane.ietf.avt/14435 <pre>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&lt; at &gt;ietf.org wrote: </pre> Colin Perkins 2013-05-07T12:26:18 http://permalink.gmane.org/gmane.ietf.avt/14433 <pre>Hi, see inline. On 2013-05-07 02:58, Kevin Gross wrote: 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? Agreed. Ok, lets fix this issue. Agree that it doesn't apply as no a=mediaclk is specified. 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. Please be explicit about this exception. I suggest that you are very explicit, especially when discussing clocks that have identifiers on how they are to be compared. 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. I think that is fine. 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. 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&lt; at &gt;ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Magnus Westerlund 2013-05-07T11:47:48 http://permalink.gmane.org/gmane.ietf.avt/14432 <pre>Kevin, My mistake. Roni From: Kevin Gross [mailto:kevin.gross&lt; at &gt;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=", there is EITHER a server address (with optional port number) OR "traceable". I believe that's what the code (specifically =/) specifies. If not, please set me straight. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Sun, May 5, 2013 at 3:15 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: Hi Kevin, On comment 2. The syntax is timestamp-refclk = "a=ts-refclk:" clksrc CRLF clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext ntp = "ntp=" ntp-server-addr ntp-server-addr = host [ ":" port ] ntp-server-addr =/ "traceable" this is why I expected a host address Roni From: Kevin Gross [mailto:kevin.gross&lt; at &gt;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 &lt;tel:%2B1-303-447-0517&gt; Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: Hi Kevin, I looked at the document and at Magnus comment. I am not sure if the document allows offering and two reference clocks. I am not sure what is meant in section 4.2 “Two or more NTP servers may be listed at the same level in the session description to indicate that they are interchangeable. RTP senders or receivers can use any of the listed NTP servers to govern a local clock that is equivalent to a local clock slaved to a different server.” When you say interchangeable and how it relates to Magnus proposal to allow negotiation. What we're trying to say is that you're allowed to list multiple clock sources with the understanding that all listed clocks deliver the same time. Any of the clocks can be used interchangeably and synchronization is assured. This capability is intended to support fault-tolerant clock distribution scenarios. I also assume that the information in offer/answer and in declarative SDP is used to provide sender information and not receiver one so is there a reason to have the same media clock in both direction when using conversional (offer/answer) application For backwards compatibility, when no clock attribute is specified in a description, it has a specific meaning (e.g. local time reference or free-running media clock). For this reason, the answer must echo the offer's clock attribute. This is acknowledgement to the offerer that answerer recognises and supports the clksrc attributes. Other comments 1. ptp-domain-name = "domain-name=" 16ptp-domain-char – did you mean exactly 16 charaters? Basically, yes, although I admit it is a bit strange. IEEE 1588-2002 (clause 6.2.5.1) domain names are 16 character fixed-length strings. Shorter-looking names can be used but they are padded out with null characters. 2. In figure 2 a=ts-refclk:ntp=traceable – do you need also to specify the server address? Traceable sources imply TAI-based time. Any TAI source of a particular technology (e.g. GPS, NTP) is assumed to be equivalent to any other TAI source using the same technology. We appreciate that this is a crude simplification but trying to go further takes us down a rabbit hole. 3. In figure 3 a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00 – what is the last part with the date and time, I thought the syntax only have server address. This is a timestamp left over from a previous "clock quality" proposal that has since been removed from the draft. I had already made note to remove this if no one caught in WGLC :) 4. In section 6.1 the first sentence in the first and second paragraph it look to me like the “must” is really a “SHOULD” Another issue I had already noted for correction. 5. In section 8 when defining a new registry you need to say what is the policy for adding values to the registry (I think here it will be specification required” see RFC 5226 We will review RFC 5226 again and correct this. 6. The IANA section is not fully compliant with the requirements from RFC4566 you can look at examples in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-13 IANA section or other MMUSIC RFCs We will review RFC 4566 and correct this. Thanks for a pointer to examples. Roni Even From: avt-bounces&lt; at &gt;ietf.org [mailto:avt-bounces&lt; at &gt;ietf.org] On Behalf Of Kevin Gross Sent: 18 April, 2013 1:41 AM To: Magnus Westerlund Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 Magnus, Thanks for looking at this and sorry for the delay responding. I agree that mediaclk-ext is too restrictive. Your suggestion is very accommodating Something a bit more structured such as 'token "=" byte-string' might be more appropriate. I will check with my co authors on this. As there is great precedent for it in SDP, we have implemented a simple offer-answer model. I would propose that systems should use the mechanisms defined in RFC 5939 if negotiation of clock configurations is necessary. Perhaps adding some discussion and a reference to this RFC would help. I don't think that independently negotiating reference and media clocks as you have suggested will be adequate. Under some implementations, while multiple clocks are supported, certain combinations of media and reference clocks may not be allowed. Kevin Gross +1-303-447-0517 &lt;tel:%2B1-303-447-0517&gt; Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund &lt;magnus.westerlund&lt; at &gt;ericsson.com&gt; wrote: Hi, I promised doing an review of the O/A section. I also found some other issues to consider. 1. Section 5.4: Figure 5 shows the ABNF [5] grammar for the SDP media clock source information. mediaclk-master = "a=ssrc:" integer SP clk-master-id clk-master-id = "mediaclk:master-id=" master-id timestamp-mediaclk = "a=mediaclk:" mediaclock mediaclock = sender / refclk / streamid / mediaclock-ext sender = "sender" sender-ext sender-ext = token refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] rate = [ SP "rate=" integer "/" integer ] direct-ext = token streamid = "master-id=" master-id streamid =/ "IEEE1722=" avb-stream-id streamid =/ streamid-ext master-id = EUI48 avb-stream-id = EUI64 EUI48 = 5(2HEXDIG ":") 2HEXDIG EUI64 = 7(2HEXDIG ":") 2HEXDIG streamid-ext = token mediaclock-ext = token I wonder if not the mediaclock-ext construction is to restrictive. As the refclk produces a sting with white-spaces in it, why isn't other mediaclock-ext allowed the same freedom? I think the mediaclock-ext can be basically byte-string, i.e. any character allowed on an SDP line should be possible to use. Likely the only resteriction should be that it starts with a token. Thus using: mediaclock-ext = token [SP byte-string] This would require a token for identifying the method followed by a space and then full freedom for anything that is allowed on an SDP attribute value. 2. Section 6: Purpose of signalling? I think this type of signalling can select two levels of goals with signalling: 1) Declaring what each SDP O/A uses on its side 2) Negotiating to arrive at the best but available mechanism on both sides. The currently proposed solution does neither of these. It enables the offerer to express to declare I intended to use X and for the answer to say I know that, or simply say I can't tell you because we are not having the same clocks. I think we need to be clear what our goals are here. And I will propose some goals with the signalling based on my understanding of how these defined timestamp reference clocks and media stream clocks can be used. And we do need to be aware that different application may have different needs. Goal with signalling: 1. Enable each media sender to declare its actually used ts-refclk, i.e. what clock is base for the RTCP SR NTP timestamps 2. Enable each media sender to identify what clock reference is used to check/drive the media sampling, i.e. RTP timestamp advancement. 3. Enable two media sender using SDP O/A to determine what common clocks they actually have so they can be used in either of ts-refclk or mediaclk. The purpose of doing three (3) is really so that one can do the following. A. has three ts-refclk it can use. B has two ts-refclk available. They are going to watch social TV. To make it at all possible for the social TV service to play out content at A and B in sync they need to have either of these two things be available. a) Each has a common clock with the TV service b) A and B has a common clock In either of the scenario the TV service will be able to ensure that the media is played out is sync. As a technical solution to these issues there are two main solution tracks: 1) Change the respective SDP attributes to provide info on all possible clocks for that it could be using and let the answer select the most preferred that both are supporting 2) Leave the current SDP attributes as they are and only use them for declaration that: I use this! Then add new SDP attributes to negotiate the list of commonly supported clocks. At this stage I think 2) is what is simplest and require the least changes to what already exist. I will note that this is likely to require a second round of O/A messages to update used clocks if the arrived common clock(s) are not the default used ones. But, I don't see a way around these. In SIP one could use OPTIONS to provide a SDP which includes the negotiation attribute to enable the other side to select using a clock that is supported by both. But when that isn't done, it will take two rounds or other a'priori knowledge. So my proposal is simply that one create two new SDP attributes one for each type of clock usage (ts-refclk and mediaclk) and include a list of clock type and any ID of the clock in a priority order. The O/A is basic negotiated and the answer removes all clocks it doesn't support and adds all it supports. Hopefully there is someone in the list that is common. The highest priority between the two parties should be used when common clock is required. IF that is not, then these attributes should not be included. This for example allows one to use a common ts-refclk, but not require common mediaclk. We should also discuss if the answerer may change the priority of commonly supported, and if it should or should not add additional clocks it supports that are not common. I really appreciate feedback on these comments and ideas. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 &lt;tel:%2B46%2010%207148287&gt; Färögatan 6 | Mobile +46 73 0949079 &lt;tel:%2B46%2073%200949079&gt; SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund&lt; at &gt;ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt _____ _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Roni Even 2013-05-06T23:41:59 http://permalink.gmane.org/gmane.ietf.avt/14431 <pre>The intention is that after "ntp=", there is EITHER a server address (with optional port number) OR "traceable". I believe that's what the code (specifically =/) specifies. If not, please set me straight. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt;, www.X192.org On Sun, May 5, 2013 at 3:15 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Kevin Gross 2013-05-06T23:32:03 http://permalink.gmane.org/gmane.ietf.avt/14430 <pre>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: </pre> Magnus Westerlund 2013-05-06T14:45:24 http://permalink.gmane.org/gmane.ietf.avt/14429 <pre>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&lt; at &gt;ietf.org wrote: </pre> Magnus Westerlund 2013-05-06T09:48:37 http://permalink.gmane.org/gmane.ietf.avt/14428 <pre> 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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> internet-drafts< at >ietf.org 2013-05-06T09:40:39 http://permalink.gmane.org/gmane.ietf.avt/14427 <pre>Kevin, Also a=ts-refclk:ntp=traceable probably a=ts-refclk:ntp= host /traceable Roni From: Kevin Gross [mailto:kevin.gross&lt; at &gt;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 &lt;http://www.avanw.com/&gt; , www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: Hi Kevin, I looked at the document and at Magnus comment. I am not sure if the document allows offering and two reference clocks. I am not sure what is meant in section 4.2 “Two or more NTP servers may be listed at the same level in the session description to indicate that they are interchangeable. RTP senders or receivers can use any of the listed NTP servers to govern a local clock that is equivalent to a local clock slaved to a different server.” When you say interchangeable and how it relates to Magnus proposal to allow negotiation. What we're trying to say is that you're allowed to list multiple clock sources with the understanding that all listed clocks deliver the same time. Any of the clocks can be used interchangeably and synchronization is assured. This capability is intended to support fault-tolerant clock distribution scenarios. I also assume that the information in offer/answer and in declarative SDP is used to provide sender information and not receiver one so is there a reason to have the same media clock in both direction when using conversional (offer/answer) application For backwards compatibility, when no clock attribute is specified in a description, it has a specific meaning (e.g. local time reference or free-running media clock). For this reason, the answer must echo the offer's clock attribute. This is acknowledgement to the offerer that answerer recognises and supports the clksrc attributes. Other comments 1. ptp-domain-name = "domain-name=" 16ptp-domain-char – did you mean exactly 16 charaters? Basically, yes, although I admit it is a bit strange. IEEE 1588-2002 (clause 6.2.5.1) domain names are 16 character fixed-length strings. Shorter-looking names can be used but they are padded out with null characters. 2. In figure 2 a=ts-refclk:ntp=traceable – do you need also to specify the server address? Traceable sources imply TAI-based time. Any TAI source of a particular technology (e.g. GPS, NTP) is assumed to be equivalent to any other TAI source using the same technology. We appreciate that this is a crude simplification but trying to go further takes us down a rabbit hole. 3. In figure 3 a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00 – what is the last part with the date and time, I thought the syntax only have server address. This is a timestamp left over from a previous "clock quality" proposal that has since been removed from the draft. I had already made note to remove this if no one caught in WGLC :) 4. In section 6.1 the first sentence in the first and second paragraph it look to me like the “must” is really a “SHOULD” Another issue I had already noted for correction. 5. In section 8 when defining a new registry you need to say what is the policy for adding values to the registry (I think here it will be specification required” see RFC 5226 We will review RFC 5226 again and correct this. 6. The IANA section is not fully compliant with the requirements from RFC4566 you can look at examples in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-13 IANA section or other MMUSIC RFCs We will review RFC 4566 and correct this. Thanks for a pointer to examples. Roni Even From: avt-bounces&lt; at &gt;ietf.org [mailto:avt-bounces&lt; at &gt;ietf.org] On Behalf Of Kevin Gross Sent: 18 April, 2013 1:41 AM To: Magnus Westerlund Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 Magnus, Thanks for looking at this and sorry for the delay responding. I agree that mediaclk-ext is too restrictive. Your suggestion is very accommodating Something a bit more structured such as 'token "=" byte-string' might be more appropriate. I will check with my co authors on this. As there is great precedent for it in SDP, we have implemented a simple offer-answer model. I would propose that systems should use the mechanisms defined in RFC 5939 if negotiation of clock configurations is necessary. Perhaps adding some discussion and a reference to this RFC would help. I don't think that independently negotiating reference and media clocks as you have suggested will be adequate. Under some implementations, while multiple clocks are supported, certain combinations of media and reference clocks may not be allowed. Kevin Gross +1-303-447-0517 &lt;tel:%2B1-303-447-0517&gt; Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund &lt;magnus.westerlund&lt; at &gt;ericsson.com&gt; wrote: Hi, I promised doing an review of the O/A section. I also found some other issues to consider. 1. Section 5.4: Figure 5 shows the ABNF [5] grammar for the SDP media clock source information. mediaclk-master = "a=ssrc:" integer SP clk-master-id clk-master-id = "mediaclk:master-id=" master-id timestamp-mediaclk = "a=mediaclk:" mediaclock mediaclock = sender / refclk / streamid / mediaclock-ext sender = "sender" sender-ext sender-ext = token refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] rate = [ SP "rate=" integer "/" integer ] direct-ext = token streamid = "master-id=" master-id streamid =/ "IEEE1722=" avb-stream-id streamid =/ streamid-ext master-id = EUI48 avb-stream-id = EUI64 EUI48 = 5(2HEXDIG ":") 2HEXDIG EUI64 = 7(2HEXDIG ":") 2HEXDIG streamid-ext = token mediaclock-ext = token I wonder if not the mediaclock-ext construction is to restrictive. As the refclk produces a sting with white-spaces in it, why isn't other mediaclock-ext allowed the same freedom? I think the mediaclock-ext can be basically byte-string, i.e. any character allowed on an SDP line should be possible to use. Likely the only resteriction should be that it starts with a token. Thus using: mediaclock-ext = token [SP byte-string] This would require a token for identifying the method followed by a space and then full freedom for anything that is allowed on an SDP attribute value. 2. Section 6: Purpose of signalling? I think this type of signalling can select two levels of goals with signalling: 1) Declaring what each SDP O/A uses on its side 2) Negotiating to arrive at the best but available mechanism on both sides. The currently proposed solution does neither of these. It enables the offerer to express to declare I intended to use X and for the answer to say I know that, or simply say I can't tell you because we are not having the same clocks. I think we need to be clear what our goals are here. And I will propose some goals with the signalling based on my understanding of how these defined timestamp reference clocks and media stream clocks can be used. And we do need to be aware that different application may have different needs. Goal with signalling: 1. Enable each media sender to declare its actually used ts-refclk, i.e. what clock is base for the RTCP SR NTP timestamps 2. Enable each media sender to identify what clock reference is used to check/drive the media sampling, i.e. RTP timestamp advancement. 3. Enable two media sender using SDP O/A to determine what common clocks they actually have so they can be used in either of ts-refclk or mediaclk. The purpose of doing three (3) is really so that one can do the following. A. has three ts-refclk it can use. B has two ts-refclk available. They are going to watch social TV. To make it at all possible for the social TV service to play out content at A and B in sync they need to have either of these two things be available. a) Each has a common clock with the TV service b) A and B has a common clock In either of the scenario the TV service will be able to ensure that the media is played out is sync. As a technical solution to these issues there are two main solution tracks: 1) Change the respective SDP attributes to provide info on all possible clocks for that it could be using and let the answer select the most preferred that both are supporting 2) Leave the current SDP attributes as they are and only use them for declaration that: I use this! Then add new SDP attributes to negotiate the list of commonly supported clocks. At this stage I think 2) is what is simplest and require the least changes to what already exist. I will note that this is likely to require a second round of O/A messages to update used clocks if the arrived common clock(s) are not the default used ones. But, I don't see a way around these. In SIP one could use OPTIONS to provide a SDP which includes the negotiation attribute to enable the other side to select using a clock that is supported by both. But when that isn't done, it will take two rounds or other a'priori knowledge. So my proposal is simply that one create two new SDP attributes one for each type of clock usage (ts-refclk and mediaclk) and include a list of clock type and any ID of the clock in a priority order. The O/A is basic negotiated and the answer removes all clocks it doesn't support and adds all it supports. Hopefully there is someone in the list that is common. The highest priority between the two parties should be used when common clock is required. IF that is not, then these attributes should not be included. This for example allows one to use a common ts-refclk, but not require common mediaclk. We should also discuss if the answerer may change the priority of commonly supported, and if it should or should not add additional clocks it supports that are not common. I really appreciate feedback on these comments and ideas. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 &lt;tel:%2B46%2010%207148287&gt; Färögatan 6 | Mobile +46 73 0949079 &lt;tel:%2B46%2073%200949079&gt; SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund&lt; at &gt;ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt _____ _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Roni Even 2013-05-05T09:18:22 http://permalink.gmane.org/gmane.ietf.avt/14426 <pre>Hi Kevin, On comment 2. The syntax is timestamp-refclk = "a=ts-refclk:" clksrc CRLF clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext ntp = "ntp=" ntp-server-addr ntp-server-addr = host [ ":" port ] ntp-server-addr =/ "traceable" this is why I expected a host address Roni From: Kevin Gross [mailto:kevin.gross&lt; at &gt;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 &lt;http://www.avanw.com/&gt; , www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: Hi Kevin, I looked at the document and at Magnus comment. I am not sure if the document allows offering and two reference clocks. I am not sure what is meant in section 4.2 “Two or more NTP servers may be listed at the same level in the session description to indicate that they are interchangeable. RTP senders or receivers can use any of the listed NTP servers to govern a local clock that is equivalent to a local clock slaved to a different server.” When you say interchangeable and how it relates to Magnus proposal to allow negotiation. What we're trying to say is that you're allowed to list multiple clock sources with the understanding that all listed clocks deliver the same time. Any of the clocks can be used interchangeably and synchronization is assured. This capability is intended to support fault-tolerant clock distribution scenarios. I also assume that the information in offer/answer and in declarative SDP is used to provide sender information and not receiver one so is there a reason to have the same media clock in both direction when using conversional (offer/answer) application For backwards compatibility, when no clock attribute is specified in a description, it has a specific meaning (e.g. local time reference or free-running media clock). For this reason, the answer must echo the offer's clock attribute. This is acknowledgement to the offerer that answerer recognises and supports the clksrc attributes. Other comments 1. ptp-domain-name = "domain-name=" 16ptp-domain-char – did you mean exactly 16 charaters? Basically, yes, although I admit it is a bit strange. IEEE 1588-2002 (clause 6.2.5.1) domain names are 16 character fixed-length strings. Shorter-looking names can be used but they are padded out with null characters. 2. In figure 2 a=ts-refclk:ntp=traceable – do you need also to specify the server address? Traceable sources imply TAI-based time. Any TAI source of a particular technology (e.g. GPS, NTP) is assumed to be equivalent to any other TAI source using the same technology. We appreciate that this is a crude simplification but trying to go further takes us down a rabbit hole. 3. In figure 3 a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00 – what is the last part with the date and time, I thought the syntax only have server address. This is a timestamp left over from a previous "clock quality" proposal that has since been removed from the draft. I had already made note to remove this if no one caught in WGLC :) 4. In section 6.1 the first sentence in the first and second paragraph it look to me like the “must” is really a “SHOULD” Another issue I had already noted for correction. 5. In section 8 when defining a new registry you need to say what is the policy for adding values to the registry (I think here it will be specification required” see RFC 5226 We will review RFC 5226 again and correct this. 6. The IANA section is not fully compliant with the requirements from RFC4566 you can look at examples in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-13 IANA section or other MMUSIC RFCs We will review RFC 4566 and correct this. Thanks for a pointer to examples. Roni Even From: avt-bounces&lt; at &gt;ietf.org [mailto:avt-bounces&lt; at &gt;ietf.org] On Behalf Of Kevin Gross Sent: 18 April, 2013 1:41 AM To: Magnus Westerlund Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 Magnus, Thanks for looking at this and sorry for the delay responding. I agree that mediaclk-ext is too restrictive. Your suggestion is very accommodating Something a bit more structured such as 'token "=" byte-string' might be more appropriate. I will check with my co authors on this. As there is great precedent for it in SDP, we have implemented a simple offer-answer model. I would propose that systems should use the mechanisms defined in RFC 5939 if negotiation of clock configurations is necessary. Perhaps adding some discussion and a reference to this RFC would help. I don't think that independently negotiating reference and media clocks as you have suggested will be adequate. Under some implementations, while multiple clocks are supported, certain combinations of media and reference clocks may not be allowed. Kevin Gross +1-303-447-0517 &lt;tel:%2B1-303-447-0517&gt; Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund &lt;magnus.westerlund&lt; at &gt;ericsson.com&gt; wrote: Hi, I promised doing an review of the O/A section. I also found some other issues to consider. 1. Section 5.4: Figure 5 shows the ABNF [5] grammar for the SDP media clock source information. mediaclk-master = "a=ssrc:" integer SP clk-master-id clk-master-id = "mediaclk:master-id=" master-id timestamp-mediaclk = "a=mediaclk:" mediaclock mediaclock = sender / refclk / streamid / mediaclock-ext sender = "sender" sender-ext sender-ext = token refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] rate = [ SP "rate=" integer "/" integer ] direct-ext = token streamid = "master-id=" master-id streamid =/ "IEEE1722=" avb-stream-id streamid =/ streamid-ext master-id = EUI48 avb-stream-id = EUI64 EUI48 = 5(2HEXDIG ":") 2HEXDIG EUI64 = 7(2HEXDIG ":") 2HEXDIG streamid-ext = token mediaclock-ext = token I wonder if not the mediaclock-ext construction is to restrictive. As the refclk produces a sting with white-spaces in it, why isn't other mediaclock-ext allowed the same freedom? I think the mediaclock-ext can be basically byte-string, i.e. any character allowed on an SDP line should be possible to use. Likely the only resteriction should be that it starts with a token. Thus using: mediaclock-ext = token [SP byte-string] This would require a token for identifying the method followed by a space and then full freedom for anything that is allowed on an SDP attribute value. 2. Section 6: Purpose of signalling? I think this type of signalling can select two levels of goals with signalling: 1) Declaring what each SDP O/A uses on its side 2) Negotiating to arrive at the best but available mechanism on both sides. The currently proposed solution does neither of these. It enables the offerer to express to declare I intended to use X and for the answer to say I know that, or simply say I can't tell you because we are not having the same clocks. I think we need to be clear what our goals are here. And I will propose some goals with the signalling based on my understanding of how these defined timestamp reference clocks and media stream clocks can be used. And we do need to be aware that different application may have different needs. Goal with signalling: 1. Enable each media sender to declare its actually used ts-refclk, i.e. what clock is base for the RTCP SR NTP timestamps 2. Enable each media sender to identify what clock reference is used to check/drive the media sampling, i.e. RTP timestamp advancement. 3. Enable two media sender using SDP O/A to determine what common clocks they actually have so they can be used in either of ts-refclk or mediaclk. The purpose of doing three (3) is really so that one can do the following. A. has three ts-refclk it can use. B has two ts-refclk available. They are going to watch social TV. To make it at all possible for the social TV service to play out content at A and B in sync they need to have either of these two things be available. a) Each has a common clock with the TV service b) A and B has a common clock In either of the scenario the TV service will be able to ensure that the media is played out is sync. As a technical solution to these issues there are two main solution tracks: 1) Change the respective SDP attributes to provide info on all possible clocks for that it could be using and let the answer select the most preferred that both are supporting 2) Leave the current SDP attributes as they are and only use them for declaration that: I use this! Then add new SDP attributes to negotiate the list of commonly supported clocks. At this stage I think 2) is what is simplest and require the least changes to what already exist. I will note that this is likely to require a second round of O/A messages to update used clocks if the arrived common clock(s) are not the default used ones. But, I don't see a way around these. In SIP one could use OPTIONS to provide a SDP which includes the negotiation attribute to enable the other side to select using a clock that is supported by both. But when that isn't done, it will take two rounds or other a'priori knowledge. So my proposal is simply that one create two new SDP attributes one for each type of clock usage (ts-refclk and mediaclk) and include a list of clock type and any ID of the clock in a priority order. The O/A is basic negotiated and the answer removes all clocks it doesn't support and adds all it supports. Hopefully there is someone in the list that is common. The highest priority between the two parties should be used when common clock is required. IF that is not, then these attributes should not be included. This for example allows one to use a common ts-refclk, but not require common mediaclk. We should also discuss if the answerer may change the priority of commonly supported, and if it should or should not add additional clocks it supports that are not common. I really appreciate feedback on these comments and ideas. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 &lt;tel:%2B46%2010%207148287&gt; Färögatan 6 | Mobile +46 73 0949079 &lt;tel:%2B46%2073%200949079&gt; SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund&lt; at &gt;ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt _____ _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Roni Even 2013-05-05T09:15:37 http://permalink.gmane.org/gmane.ietf.avt/14425 <pre>Roni, Thanks for the review. See below. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt;, www.X192.org On Wed, Apr 24, 2013 at 8:01 AM, Roni Even &lt;ron.even.tlv&lt; at &gt;gmail.com&gt; wrote: 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. 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. 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. 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. 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 :) Another issue I had already noted for correction. We will review RFC 5226 again and correct this. We will review RFC 4566 and correct this. Thanks for a pointer to examples. _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Kevin Gross 2013-05-05T04:02:32 http://permalink.gmane.org/gmane.ietf.avt/14424 <pre>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 &lt;http://www.avanw.com/&gt;, www.X192.org On Tue, Apr 23, 2013 at 1:23 AM, Magnus Westerlund &lt; magnus.westerlund&lt; at &gt;ericsson.com&gt; wrote: _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Kevin Gross 2013-05-05T03:29:03 http://permalink.gmane.org/gmane.ietf.avt/14423 <pre> 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=ssrc: lines. Making this change will probably also requires changes to the ABNF, to cleanly separate the syntax for "a=..." and "a=ssrc: ..." forms so they can be separately referenced. </pre> Colin Perkins 2013-05-03T16:26:36 http://permalink.gmane.org/gmane.ietf.avt/14422 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> johnsonhammond2< at >hushmail.com 2013-04-27T17:15:16 http://permalink.gmane.org/gmane.ietf.avt/14421 <pre>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. I also assume that the information in offer/answer and in declarative SDP is used to provide sender information and not receiver one so is there a reason to have the same media clock in both direction when using conversional (offer/answer) application Other comments 1. ptp-domain-name = "domain-name=" 16ptp-domain-char – did you mean exactly 16 charaters? 2. In figure 2 a=ts-refclk:ntp=traceable – do you need also to specify the server address? 3. In figure 3 a=ts-refclk:ntp=203.0.113.10 2011-02-19 21:03:20.345+01:00 – what is the last part with the date and time, I thought the syntax only have server address. 4. In section 6.1 the first sentence in the first and second paragraph it look to me like the “must” is really a “SHOULD” 5. In section 8 when defining a new registry you need to say what is the policy for adding values to the registry (I think here it will be specification required” see RFC 5226 6. The IANA section is not fully compliant with the requirements from RFC4566 you can look at examples in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-13 IANA section or other MMUSIC RFCs Roni Even From: avt-bounces&lt; at &gt;ietf.org [mailto:avt-bounces&lt; at &gt;ietf.org] On Behalf Of Kevin Gross Sent: 18 April, 2013 1:41 AM To: Magnus Westerlund Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 Magnus, Thanks for looking at this and sorry for the delay responding. I agree that mediaclk-ext is too restrictive. Your suggestion is very accommodating Something a bit more structured such as 'token "=" byte-string' might be more appropriate. I will check with my co authors on this. As there is great precedent for it in SDP, we have implemented a simple offer-answer model. I would propose that systems should use the mechanisms defined in RFC 5939 if negotiation of clock configurations is necessary. Perhaps adding some discussion and a reference to this RFC would help. I don't think that independently negotiating reference and media clocks as you have suggested will be adequate. Under some implementations, while multiple clocks are supported, certain combinations of media and reference clocks may not be allowed. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com &lt;http://www.avanw.com/&gt; , www.X192.org On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund &lt;magnus.westerlund&lt; at &gt;ericsson.com&gt; wrote: Hi, I promised doing an review of the O/A section. I also found some other issues to consider. 1. Section 5.4: Figure 5 shows the ABNF [5] grammar for the SDP media clock source information. mediaclk-master = "a=ssrc:" integer SP clk-master-id clk-master-id = "mediaclk:master-id=" master-id timestamp-mediaclk = "a=mediaclk:" mediaclock mediaclock = sender / refclk / streamid / mediaclock-ext sender = "sender" sender-ext sender-ext = token refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] rate = [ SP "rate=" integer "/" integer ] direct-ext = token streamid = "master-id=" master-id streamid =/ "IEEE1722=" avb-stream-id streamid =/ streamid-ext master-id = EUI48 avb-stream-id = EUI64 EUI48 = 5(2HEXDIG ":") 2HEXDIG EUI64 = 7(2HEXDIG ":") 2HEXDIG streamid-ext = token mediaclock-ext = token I wonder if not the mediaclock-ext construction is to restrictive. As the refclk produces a sting with white-spaces in it, why isn't other mediaclock-ext allowed the same freedom? I think the mediaclock-ext can be basically byte-string, i.e. any character allowed on an SDP line should be possible to use. Likely the only resteriction should be that it starts with a token. Thus using: mediaclock-ext = token [SP byte-string] This would require a token for identifying the method followed by a space and then full freedom for anything that is allowed on an SDP attribute value. 2. Section 6: Purpose of signalling? I think this type of signalling can select two levels of goals with signalling: 1) Declaring what each SDP O/A uses on its side 2) Negotiating to arrive at the best but available mechanism on both sides. The currently proposed solution does neither of these. It enables the offerer to express to declare I intended to use X and for the answer to say I know that, or simply say I can't tell you because we are not having the same clocks. I think we need to be clear what our goals are here. And I will propose some goals with the signalling based on my understanding of how these defined timestamp reference clocks and media stream clocks can be used. And we do need to be aware that different application may have different needs. Goal with signalling: 1. Enable each media sender to declare its actually used ts-refclk, i.e. what clock is base for the RTCP SR NTP timestamps 2. Enable each media sender to identify what clock reference is used to check/drive the media sampling, i.e. RTP timestamp advancement. 3. Enable two media sender using SDP O/A to determine what common clocks they actually have so they can be used in either of ts-refclk or mediaclk. The purpose of doing three (3) is really so that one can do the following. A. has three ts-refclk it can use. B has two ts-refclk available. They are going to watch social TV. To make it at all possible for the social TV service to play out content at A and B in sync they need to have either of these two things be available. a) Each has a common clock with the TV service b) A and B has a common clock In either of the scenario the TV service will be able to ensure that the media is played out is sync. As a technical solution to these issues there are two main solution tracks: 1) Change the respective SDP attributes to provide info on all possible clocks for that it could be using and let the answer select the most preferred that both are supporting 2) Leave the current SDP attributes as they are and only use them for declaration that: I use this! Then add new SDP attributes to negotiate the list of commonly supported clocks. At this stage I think 2) is what is simplest and require the least changes to what already exist. I will note that this is likely to require a second round of O/A messages to update used clocks if the arrived common clock(s) are not the default used ones. But, I don't see a way around these. In SIP one could use OPTIONS to provide a SDP which includes the negotiation attribute to enable the other side to select using a clock that is supported by both. But when that isn't done, it will take two rounds or other a'priori knowledge. So my proposal is simply that one create two new SDP attributes one for each type of clock usage (ts-refclk and mediaclk) and include a list of clock type and any ID of the clock in a priority order. The O/A is basic negotiated and the answer removes all clocks it doesn't support and adds all it supports. Hopefully there is someone in the list that is common. The highest priority between the two parties should be used when common clock is required. IF that is not, then these attributes should not be included. This for example allows one to use a common ts-refclk, but not require common mediaclk. We should also discuss if the answerer may change the priority of commonly supported, and if it should or should not add additional clocks it supports that are not common. I really appreciate feedback on these comments and ideas. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund&lt; at &gt;ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt _____ _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Roni Even 2013-04-24T14:01:09 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.avt