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://comments.gmane.org/gmane.ietf.avt/14472 <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 : Inter-destination Media Synchronization using the RTP Control Protocol (RTCP) Author(s) : Ray van Brandenburg Hans Stokking Oskar van Deventer Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-11.txt Pages : 22 Date : 2013-06-14 Abstract: This document defines a new RTP Control Protocol (RTCP) Packet Type and an 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 Report 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 sent 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 useful 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-idms-11 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-06-14T14:55:34 http://comments.gmane.org/gmane.ietf.avt/14471 <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 : Inter-destination Media Synchronization using the RTP Control Protocol (RTCP) Author(s) : Ray van Brandenburg Hans Stokking Oskar van Deventer Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-10.txt Pages : 22 Date : 2013-06-14 Abstract: This document defines a new RTP Control Protocol (RTCP) Packet Type and an 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 Report 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 sent 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 useful 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-idms-10 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-06-14T14:48:32 http://comments.gmane.org/gmane.ietf.avt/14470 <pre>I have a question regarding draft-ietf-avtcore-rtp-topologies-update. Is a source projecting middlebox part of Topo-Mixer? Section 3.6 describes the Topo-Mixer category, with subsections describing the media mixing variety and the media switching variety. Then section 3.7 describes a source projecting middlebox, but there is no Topo- designation for this case. If the source projecting middlebox is a third variety of Topo-Mixer, then this section 3.7 should be renumbered as 3.6.3, to indicate it is part of 3.6 Topo-Mixer. If the source projecting middlebox is not a variety of Topo-Mixer, then it should be given its own new Topo-Source-Projecting designation, and also added to the comparison in section 4.2. Mark Duckworth _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Duckworth, Mark 2013-06-14T13:50:26 http://comments.gmane.org/gmane.ietf.avt/14448 <pre> 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)' &lt;draft-ietf-avtcore-idms-09.txt&gt; 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&lt; at &gt;ietf.org mailing lists by 2013-06-11. Exceptionally, comments may be sent to iesg&lt; at &gt;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. _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> The IESG 2013-05-28T21:00:43 http://comments.gmane.org/gmane.ietf.avt/14447 <pre> 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)' &lt;draft-ietf-avtcore-6222bis-03.txt&gt; 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&lt; at &gt;ietf.org mailing lists by 2013-06-11. Exceptionally, comments may be sent to iesg&lt; at &gt;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. _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> The IESG 2013-05-28T20:55:43 http://comments.gmane.org/gmane.ietf.avt/14445 <pre>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: </pre> Richard Barnes 2013-05-28T20:50:52 http://comments.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://comments.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://comments.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://comments.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://comments.gmane.org/gmane.ietf.avt/14420 <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 : Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) Author(s) : Ali Begen Colin Perkins Dan Wing Eric Rescorla Filename : draft-ietf-avtcore-6222bis-03.txt Pages : 10 Date : 2013-04-23 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-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-04-23T13:28:45 http://comments.gmane.org/gmane.ietf.avt/14413 <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 : Guidelines for using the Multiplexing Features of RTP Author(s) : Magnus Westerlund Bo Burman Colin Perkins Harald Tveit Alvestrand Filename : draft-ietf-avtcore-multiplex-guidelines-00.txt Pages : 48 Date : 2013-04-22 Abstract: Real-time Transport Protocol (RTP) is a flexible protocol possible to use in a wide range of applications and network and system topologies. This flexibility and the implications of different choices should be understood by any application developer using RTP. To facilitate that understanding, this document contains an in-depth discussion of the usage of RTP's multiplexing points; the RTP session and the Synchronisation Source Identifier (SSRC). The document tries to give guidance and source material for an analysis on the most suitable choices for the application being designed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-multiplex-guidelines-00 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-04-22T09:10:55 http://comments.gmane.org/gmane.ietf.avt/14412 <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 Topologies Author(s) : Magnus Westerlund Stephan Wenger Filename : draft-ietf-avtcore-rtp-topologies-update-00.txt Pages : 37 Date : 2013-04-22 Abstract: This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and are intended to replace RFC 5117. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-00 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-04-22T07:28:55 http://comments.gmane.org/gmane.ietf.avt/14407 <pre>Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock Source Signalling. The WGLC will end on May 12th , 2013 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf-avtcore-clksrc-03? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publication. Thanks Roni Even AVTcore co-chair _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Roni Even 2013-04-21T06:39:14 http://comments.gmane.org/gmane.ietf.avt/14406 <pre>Hi, There were no new comments so please go ahead and submit the document as a WG document. I asked for a milestone Thanks Roni Even AVTCore co-chair From: Roni Even [mailto:ron.even.tlv&lt; at &gt;gmail.com] Sent: 09 April, 2013 10:33 AM To: avt&lt; at &gt;ietf.org Subject: draft-westerlund-avtcore-multiplex-architecture to a working group document Hi, At the Orlando meeting there was support to have draft-westerlund-avtcore-multiplex-architecture-03 &lt;http://tools.ietf.org/html/draft-westerlund-avtcore-multiplex-architecture- 03&gt; as a working group document. We would like to verify the support on the list. So if you have any comments please send to the list until April 19th. Thanks Roni Even AVTcore co-chair _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Roni Even 2013-04-21T06:31:53 http://comments.gmane.org/gmane.ietf.avt/14405 <pre>Hi, Since there were no further input please go ahead and submit this document as a WG document. I asked for a milestone Roni Even AVTCore co-chair From: Roni Even [mailto:ron.even.tlv&lt; at &gt;gmail.com] Sent: 09 April, 2013 10:35 AM To: avt&lt; at &gt;ietf.org Subject: draft-westerlund-avtcore-rtp-topologies-update to a working group document Hi, At the Orlando meeting there was support to have draft-westerlund-avtcore-rtp-topologies-update-02 &lt;http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-topologies-update-0 2&gt; as a working group document. We would like to verify the support on the list. So if you have any comments please send to the list until April 19th. Thanks Roni Even AVTcore co-chair _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Roni Even 2013-04-21T06:27:13 http://comments.gmane.org/gmane.ietf.avt/14402 <pre>Authors and WG, In my review of the draft in preparing the Document Shepherd's writeup I found some issues that I believe needs to be fixed. 1) Section 14.1: Security description [RFC 4568] defines SRTP "crypto suites"; a crypto suite corresponds to a particular AEAD algorithm in SRTP. As the registry is located on the SDP page it can be difficult to find and it also not named as written I propose to change this to: Security description [RFC 4568] defines the "SRTP Crypto Suite Registrations" registry on the "Session Description Protocol (SDP) Security Descriptions" page currently located at "http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xml"; a crypto suite corresponds to a particular AEAD algorithm in SRTP. 2) Security Descriptions and the "inline" value string Section 10.3.2.1 of RFC 4568 says: The semantics of the SRTP crypto suite MUST be described in an RFC in accordance with the RFC 2434 Standards Action, including the semantics of the "inline" key-method and any special semantics of parameters. As there is no such definition of how the inline method is actually using the fields for these algorithms this drafts appears to not be in conformance. Please look at RFC 4568 to figure out what is missing. I think at minimum one needs to define if one has both key and salt and how many octets that is going to be. Pointers to the DTLS SRTPprotection profiles is likely part of the solution here. 3) Section 14.2: DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; This registry is actually named "DTLS-SRTP Protection Profiles" on IANA's page. 4) IANA registry: 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) This registry is called : MIKEY Security Protocol Parameters at http://www.iana.org/assignments/mikey-payloads/mikey-payloads.xml Can you please confirm that it is this registry you want to add to? 5) IANA registry: 14.4. AEAD registry We request that IANA make the following additions to the AEAD registry: AEAD_AES_128_CCM_12 = TBD AEAD_AES_256_CCM_12 = TBD You are not using the exact correct names for the registry: http://www.iana.org/assignments/aead-parameters/aead-parameters.xml Would indicate that you should write this as: We request that IANA make the following additions to the IANA Authenticated Encryption with Associated Data (AEAD) Parameters page's registry for "AEAD Algorithms": 6) 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 ID-Checklist says: Should be meaningful to someone not versed in the technology; most abbreviations must be expanded on first use. This makes me wonder if you should expand the acronyms, although they probably need to be present in the acronym form to enable searching for them. 7) Usage of RFC 2119 words 8.1. SRTP/SRTCP Authentication Field The AEAD message authentication mechanism MUST be the primary message authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP authentication mechanisms SHOULD NOT be used with any AEAD algorithm and the optional SRTP/SRTCP Authentication Tags are NOT RECOMMENDED and SHOULD NOT be present. "NOT RECOMMENDED" is not included in the normal blurb text: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. So please modify it to include "NOT RECOMMENDED" as it is actually defined as part of the RFC. I also sent some basic editorial issues to the authors directly. Some which was unresolved isssue found by ID-Nits, please use it before submitting the draft! 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-04-18T15:09:45 http://comments.gmane.org/gmane.ietf.avt/14393 <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 : Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) Author(s) : Ali Begen Colin Perkins Dan Wing Eric Rescorla Filename : draft-ietf-avtcore-6222bis-02.txt Pages : 10 Date : 2013-04-13 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-02 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-04-13T10:34:55 http://comments.gmane.org/gmane.ietf.avt/14382 <pre>Hi all, I've reviewed draft-ietf-avtcore-6222bis. I've got two small comments/questions. I've not followed all discussion on this draft, so my comments might have been discussed earlier. - Section 1 includes a reference to I-D.rescorla-avtcore-random-cname. What is the nature and intended status of this draft? Is it meant to be updated in the future (the latest version expired a couple of months ago)? If not, is it necessary to include it here for reference or can it be removed? - Section 3 describes the deficiencies with the generation of CNAMEs in RFC3550, it does not describe the deficiencies in RFC6222 (while the problems with RFC6222 are hinted at in both the introduction and abstract). Is this intentional due to the fact that this draft obsoletes RFC6222 and that document can thus be considered informative for the purposes of this draft? Apart from these minor comments, I consider the draft to be ready for publication. Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Brandenburg, R. (Ray) van 2013-04-11T07:49:31 http://comments.gmane.org/gmane.ietf.avt/14381 <pre>The following errata report has been submitted for RFC6679, "Explicit Congestion Notification (ECN) for RTP over UDP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6679&amp;eid=3586 -------------------------------------- Type: Editorial Reported by: Magnus Westerlund &lt;magnus.westerlund&lt; at &gt;ericsson.com&gt; Section: 12.1 Original Text ------------- The Offer: ... a=ecn-capable-rtp: ice rtp ect=0 mode=setread ... The Answer: ... a=ecn-capable-rtp: ice ect=0 mode=readonly ... Corrected Text -------------- The Offer: ... a=ecn-capable-rtp: ice,rtp ect=0; mode=setread ... The Answer: ... a=ecn-capable-rtp: ice ect=0; mode=readonly ... Notes ----- The examples does not match the ABNF rules for the a=ecn-capaable-rtp attribute. Two issues are present, first the init method list must be comma separated with no spaces, secondly any additional parameters shall be semi colon plus space separated. Therefore both a=ecn-capable-rtp lines have been corrected. This is primarily an editorial issues but people needs to aware of the errors in the example. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6679 (draft-ietf-avtcore-ecn-for-rtp-08) -------------------------------------- Title : Explicit Congestion Notification (ECN) for RTP over UDP Publication Date : August 2012 Author(s) : M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg Category : PROPOSED STANDARD Source : Audio/Video Transport Core Maintenance Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> RFC Errata System 2013-04-10T13:12:56 http://comments.gmane.org/gmane.ietf.avt/14380 <pre>As requested of RTCWEB, I have read this document. It is good and should be published. I suspect that many people find it hard to get excited enough about this to bother reading it. It's just not that interesting a subject. Especially since this is entirely non-controversial. I feel a little uncomfortable that the document justifies its existence (as a -bis) largely based on a reference to an individual draft. I would prefer to see the rationale presented in an appendix instead; it's fairly important information to retain. _______________________________________________ Audio/Video Transport Core Maintenance avt&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/avt </pre> Martin Thomson 2013-04-10T17:42:07 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.avt