From nobody Tue Jul 1 08:20:46 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338341B2821 for ; Tue, 1 Jul 2014 08:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfB5X_Ei2XKN for ; Tue, 1 Jul 2014 08:20:39 -0700 (PDT) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2A91B281C for ; Tue, 1 Jul 2014 08:20:38 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/1/2014 11:20:34 AM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-128/SG:2 7/1/2014 11:19:58 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.867845 p=-0.979754 Source White X-Signature-Violations: 0-0-0-2098-c X-Note-419: 0 ms. Fail:0 Chk:1337 of 1337 total X-Note: SCH-CT/SI:0-1337/SG:1 7/1/2014 11:20:24 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G334 G335 G336 G337 G341 G342 G452 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 109606510 for avtext@ietf.org; Tue, 01 Jul 2014 11:20:34 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Tue, 1 Jul 2014 10:20:33 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Adopting an AVTEXT work item for splicing notification Thread-Index: AQHPlUAAgYFle5RD1E2Z2+lfgd1E+w== Date: Tue, 1 Jul 2014 15:20:32 +0000 Message-ID: <96091FC4-CE82-4C6A-B13B-5D3E9858B214@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/kaPjd6ha3468FTt7HHFgSr6Ghhg Subject: [avtext] Adopting an AVTEXT work item for splicing notification X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 15:20:41 -0000 Hello, all =97 Given the interest expressed on the mailing list for the work on splicing n= otification, I=92m concluding that the AVTEXT working group has reasonable = consensus about adopting a work item to define an RTCP-based mechanism for = indicating when content splicing should occur in multimedia content. If you disagree, speak now; otherwise, I will request a milestone for this = work, with a target date of November 2015 to send it to the IESG for Propos= ed Standard. Thanks! Jonathan From nobody Wed Jul 2 01:44:56 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D1C1A0101 for ; Wed, 2 Jul 2014 01:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJiTSm42rWgz for ; Wed, 2 Jul 2014 01:44:53 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B8E81A00E6 for ; Wed, 2 Jul 2014 01:44:52 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-51-53b3c6819780 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.2D.03739.186C3B35; Wed, 2 Jul 2014 10:44:50 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.228]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 10:44:49 +0200 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: PAUSE/RESUME draft updates Thread-Index: Ac+OwIFuBzkbNTqhREmBCTnE8XQ3+wHEN6sg Date: Wed, 2 Jul 2014 08:44:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E254011ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW7Tsc3BBqt+81l8vHeD1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGb3vTAv+21RsX7SBvYGx2bSLkZNDQsBE4tm9n2wQtpjEhXvr gWwuDiGBo4wS207tYYRwFjNKfLm1lAmkik1AQ2L+jruMILaIgLrEnekXwLqFgewPs/qh4hoS u9qfMkPYRhIve+aygNgsAioSzV+2AdVzcPAK+ErMauQBCQsBmceXrgMr5xTwkzjz+RjYGEYB WYn73++BtTILiEvcejKfCeJQAYkle84zQ9iiEi8f/2MFGSkhoCQxbWsaRHm+xObuN2CtvAKC EidnPmGZwCgyC8mkWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtTi4tz 042M9VKLMpOLi/Pz9PJSSzYxAuPn4JbfujsYV792PMQowMGoxMOr8H1TsBBrYllxZe4hRmkO FiVx3kXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJyzb+XHwzNEWqqvrfowS8umv7KM sedtXv8B//vTCu6oTPvr94irLf98TPTFmggWxoV6WYoH/2mv/d0Qf5PlmWn1t2UbHVs2/V7q mDtNY4ons6Pb97DFj1bb1mbFrK9+c9z9gpraBYc53I2at7ivrTv0Sf7b6R+uU3Z/Yk5uOLs+ ivmulqiqpIQSS3FGoqEWc1FxIgAWfSPEgAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/Gaae_68-_NmXn_xOvPCxvVBmcR8 Subject: Re: [avtext] PAUSE/RESUME draft updates X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 08:44:55 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E254011ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lacking any responses to this question, I will keep section 5.1 as is, corr= ect the mistake in section 6.5, and submit the new version by July 4. Please speak up if you think otherwise! Cheers, Bo From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman Sent: den 23 juni 2014 14:32 To: avtext@ietf.org Subject: [avtext] PAUSE/RESUME draft updates Hi, I would like to learn the WG's opinion on removing text from section 5.1 "S= ignaling Technology Performance Comparison" of https://datatracker.ietf.org= /doc/draft-ietf-avtext-rtp-stream-pause/. Today that section is a fairly verbose performance comparison between SIP- = and RTCP-based signaling, which is part of the argumentation and conclusion= to use RTCP for RTP PAUSE/RESUME signaling purposes. That section could po= tentially be replaced by a much more compact summary, maybe a table, given = that the WG already decided to go for RTCP-based signaling. On the other ha= nd, the current text may be seen as containing useful information that shou= ld be kept for future reference. Should section 5.1 be kept as-is, or should it be replaced by a shorter tex= t (and possibly a table)? I've also found a mistake in section 6.5: TMMBN >0: Corresponds to a REFUSE indication when a media stream is requested to be paused with TMMBR 0. This statement is not correct, since the TMMBR 0 must unconditionally be fo= llowed according to CCM [RFC 5104]. It is thus not possible to refuse a PAU= SE when using TMMBR/TMMBN. I suggest to change this paragraph accordingly. = I also suggest to insert an explicit note in section 6.4 (REFUSE) that TMMB= N>0 cannot be used as REFUSE to a PAUSE that is sent using TMMBR 0. Cheers, Bo --_000_BBE9739C2C302046BD34B42713A1E2A22E254011ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lacking any responses = to this question, I will keep section 5.1 as is, correct the mistake in sec= tion 6.5, and submit the new version by July 4.

Please speak up if you= think otherwise!

Cheers,

Bo

 

From: avtext [= mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman
Sent: den 23 juni 2014 14:32
To: avtext@ietf.org
Subject: [avtext] PAUSE/RESUME draft updates

 

Hi,

 

I would like to learn the WG’s opinion on remo= ving text from section 5.1 “Signaling Technology Performance Comparis= on” of https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/<= /a>.

 

Today that section is a fairly verbose performance c= omparison between SIP- and RTCP-based signaling, which is part of the argum= entation and conclusion to use RTCP for RTP PAUSE/RESUME signaling purposes= . That section could potentially be replaced by a much more compact summary, maybe a table, given that the WG = already decided to go for RTCP-based signaling. On the other hand, the curr= ent text may be seen as containing useful information that should be kept f= or future reference.

 

Should section 5.1 be kept as-is, or should it be re= placed by a shorter text (and possibly a table)?

 

I’ve also found a mistake in section 6.5:=

   TMMBN >0:&nbs= p; Corresponds to a REFUSE indication when a media stream is

     = ; requested to be paused with TMMBR 0.

 

This statement is not correct, since the TMMBR 0 mus= t unconditionally be followed according to CCM [RFC 5104]. It is thus not p= ossible to refuse a PAUSE when using TMMBR/TMMBN. I suggest to change this = paragraph accordingly. I also suggest to insert an explicit note in section 6.4 (REFUSE) that TMMBN>0 cannot = be used as REFUSE to a PAUSE that is sent using TMMBR 0.

 

Cheers,

Bo

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E254011ESESSMB105erics_-- From nobody Thu Jul 3 08:06:10 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14F51A0176 for ; Thu, 3 Jul 2014 08:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0y5xTJnices for ; Thu, 3 Jul 2014 08:03:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 717EB1B2827 for ; Thu, 3 Jul 2014 08:03:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: avtext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703150342.7747.15694.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 08:03:42 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/ZEVEfkuc59qrEYNXAErbn2dZLGo X-Mailman-Approved-At: Thu, 03 Jul 2014 08:06:07 -0700 Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 15:03:52 -0000 URL: http://datatracker.ietf.org/wg/avtext/charter/ From nobody Thu Jul 3 08:06:11 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E9B1A01BA for ; Thu, 3 Jul 2014 08:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrIAZ5EWOFUo for ; Thu, 3 Jul 2014 08:04:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD191B2AFC for ; Thu, 3 Jul 2014 08:04:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: avtext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703150434.12666.46756.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 08:04:34 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/Ah7qNNRWslFEr8WkYYp1SzdbV4M X-Mailman-Approved-At: Thu, 03 Jul 2014 08:06:07 -0700 Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 15:04:44 -0000 Changed milestone "Taxonomy of RTP (as informational) to IESG", added draft-ietf-avtext-rtp-grouping-taxonomy to milestone. Changed milestone "Submit Mechanism for RTP Stream Pause & Resume for Proposed Standard", added draft-ietf-avtext-rtp-stream-pause to milestone. URL: http://datatracker.ietf.org/wg/avtext/charter/ From nobody Fri Jul 4 04:36:07 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEAF1B2D46; Fri, 4 Jul 2014 04:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G7eLMxHAou7; Fri, 4 Jul 2014 04:36:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 506C01B2D3D; Fri, 4 Jul 2014 04:36:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704113604.21946.60609.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 04:36:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/FVzdGUqZ5Xq8FKVSHY2Jjw7Qg-g Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:36:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : RTP Stream Pause and Resume Authors : Bo Burman Azam Akram Roni Even Magnus Westerlund Filename : draft-ietf-avtext-rtp-stream-pause-01.txt Pages : 55 Date : 2014-07-04 Abstract: With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTCP feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real- time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 04:41:31 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6681B2D24 for ; Fri, 4 Jul 2014 04:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SZ6R-hNdvU4 for ; Fri, 4 Jul 2014 04:41:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088EF1B2D15 for ; Fri, 4 Jul 2014 04:41:27 -0700 (PDT) X-AuditID: c1b4fb3a-f799e6d000005085-49-53b692e67b28 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B2.9F.20613.6E296B35; Fri, 4 Jul 2014 13:41:26 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.228]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Fri, 4 Jul 2014 13:41:25 +0200 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-01.txt Thread-Index: AQHPl3wm9o41jmvJ3UOn0E43xU9Xq5uPyg4Q Date: Fri, 4 Jul 2014 11:41:24 +0000 Message-ID: References: <20140704113604.21946.60609.idtracker@ietfa.amsl.com> In-Reply-To: <20140704113604.21946.60609.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6zSduCDaY/57f4eO8GqwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mqb9n8xasE+kYuPaIywNjN/5uxg5OCQETCTO7ufuYuQEMsUk LtxbzwZiCwkcZZRYfi2ji5ELyF7MKPHg2Q5WkASbgIbE/B13GUFsEQF1iTvTL4A1CAt4Szy+ fZUVIu4jsWrqfCYI20jiwrx2dhCbRUBF4n/jAbAaXgFficZbv6CWOUr8P74OLM4p4CTxd8NU sDijgKzE/e/3WEBsZgFxiVtPIGZKCAhILNlznhnCFpV4+fgfK4StKPHx1T5GiHodiQW7P7FB 2NoSyxa+ZobYKyhxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhQtTi0uzk03MtJLLcpMLi7O z9PLSy3ZxAiMiINbflvtYDz43PEQowAHoxIPr8KsrcFCrIllxZW5hxilOViUxHkXnpsXLCSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoFx1a4n1R5K+qd2rPeY6zdztZjf87oUv1frKhSS1z5f WXfu07OJt9g7WoSWc/zZ4/Ti55oP+ixq6xiUptQcPt/m9yVu/myxk7s4gtZ1zt/5b+XByb8Y jk8NZN37J+dTufesb2lM+z/L/XXLchEvWfK5/LPjlQcOu15fsXx5+XCj8DkGbY9CsaCCeUos xRmJhlrMRcWJAE35GxRpAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/69NFm9ZbbgpREz8qKFtSpZxyx9M Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:41:30 -0000 This update contains the changes that were previously announced to this lis= t, as well as some additional alignment with the RTP Taxonomy draft, and a = few other editorial changes. > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org > Sent: den 4 juli 2014 13:36 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Extensions Workin= g Group of the IETF. >=20 > Title : RTP Stream Pause and Resume > Authors : Bo Burman > Azam Akram > Roni Even > Magnus Westerlund > Filename : draft-ietf-avtext-rtp-stream-pause-01.txt > Pages : 55 > Date : 2014-07-04 >=20 > Abstract: > With the increased popularity of real-time multimedia applications, > it is desirable to provide good control of resource usage, and users > also demand more control over communication sessions. This document > describes how a receiver in a multimedia conversation can pause and > resume incoming data from a sender by sending real-time feedback > messages when using Real-time Transport Protocol (RTP) for real time > data transport. This document extends the Codec Control Messages > (CCM) RTCP feedback package by explicitly allowing and describing > specific use of existing CCM messages and adding a group of new real- > time feedback messages used to pause and resume RTP data streams. > This document updates RFC 5104. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-stream-pause-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Thu Jul 10 11:49:39 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DAC1B296B for ; Thu, 10 Jul 2014 11:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1FP2uBFeAD4 for ; Thu, 10 Jul 2014 11:49:32 -0700 (PDT) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9511A0352 for ; Thu, 10 Jul 2014 11:49:31 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/10/2014 2:49:30 PM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-144/SG:2 7/10/2014 2:48:59 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.851193 p=-0.979824 Source White X-Signature-Violations: 0-0-0-2475-c X-Note-419: 15.6004 ms. Fail:0 Chk:1335 of 1335 total X-Note: SCH-CT/SI:0-1335/SG:1 7/10/2014 2:49:19 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G334 G335 G336 G337 G341 G342 G452 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 111864817 for avtext@ietf.org; Thu, 10 Jul 2014 14:49:30 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Thu, 10 Jul 2014 13:49:29 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Agenda for AVTExt session in Toronto Thread-Index: AQHPnG+tYU1uRFFXv0+GkTPcnkWxHw== Date: Thu, 10 Jul 2014 18:49:28 +0000 Message-ID: <51F7570C-0EAD-4E59-9B89-AA828238E002@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <379B9AAAB8A1394CA1D10BB362B902D2@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/NMMw0LoDUr-YBKo6UOC7-rtUkG4 Subject: [avtext] Agenda for AVTExt session in Toronto X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 18:49:34 -0000 Here is the proposed agenda for the AVTExt session in Toronto. Please let the chairs know if you have any suggestions, changes, or additio= ns. AVTEXT Audio/Video Transport Extensions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tuesday 14:20 - 16:20 (Salon B) Chairs: Keith Drage / Jonathan Lennox 14:20 Agenda bash and status update (10 min) Chairs RFC 7160, RFC 7198 14:30 Taxonomy (30 min) Bo Burman draft-ietf-avtext-rtp-grouping-taxonomy-02 15:00 RTP/RTCP extension for RTP Splicing Notification (10 min) Roni Even draft-xia-avtext-splicing-notification-03 15:10 RTP Stream Pause / Resume (15 min) Bo Burman draft-ietf-avtext-rtp-stream-pause-01 15:25 Close From nobody Thu Jul 10 18:25:23 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025201A00A8 for ; Thu, 10 Jul 2014 18:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zQzO3NBjTCv for ; Thu, 10 Jul 2014 18:25:21 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C0A1A0039 for ; Thu, 10 Jul 2014 18:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1295; q=dns/txt; s=iport; t=1405041920; x=1406251520; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=5RM7p1lLyeZZ6ykqvi2Om92evfCig1l8MBCuIfaqDAE=; b=TdzPePAp8OcriaUYzmDZK3kktDKg4gCFpXY0ulSLAtNnhCzyzxQydpCR AlnsicYxyZxz98+3EyLivwMydxyhjTsVP3tWFlbpxChrdfq+7kdy4JcaD YwSgABMEA/niRw32ooAXfoFrMdCme1DhtVp7rgKYyLtBeppmJYhWVSN+o g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAAs8v1OtJV2a/2dsb2JhbABZgmokUlrAcYdAgQwWdYQKOi4REgE+QicEDohHAQzGGRMEj0SDNIEWBZsAlBWDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,641,1400025600"; d="scan'208";a="59946406" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 11 Jul 2014 01:25:18 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6B1PJvh029562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 01:25:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 20:25:19 -0500 From: "Ali C. Begen (abegen)" To: "avtext@ietf.org" Thread-Topic: Alignment of 4566bis with RTP taxonomy draft Thread-Index: AQHPnKb6HjdKqcd0IkG2qQJyg+i3uQ== Date: Fri, 11 Jul 2014 01:25:19 +0000 Message-ID: <06F60AED-D155-4030-A603-68F16E013E61@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.234.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <6949C09E5ACA0A47BFA191F666DC1923@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/3_gpqurRN__LS902_1XzWchrIJw Cc: "draft-ietf-mmusic-rfc4566bis@tools.ietf.org" Subject: [avtext] Alignment of 4566bis with RTP taxonomy draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 01:25:23 -0000 Bo asked me to check the 4566bis (mmusic) draft to make sure it was aligned= with https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxon= omy/ Here is the summary. 4566bis is making the following definitions (remaining= from 4566): Conference: A multimedia conference is a set of two or more communicating users along with the software they are using to communicate. Session: A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session. Session Description: A well-defined format for conveying sufficient information to discover and participate in a multimedia session. My recommendations: 1) "Conference" should be defined in the taxonomy draft and 4566bis just re= fers to it. 2) "Session" is not defined in the taxonomy draft but we will adopt/use "mu= ltimedia session" defined in the taxonomy draft. 3) "Session Description" should stay in 4566bis. Now, Bo asked me to provide a definition for "conference" and the definitio= n above is one proposal. I will leave it to AVTEXT to agree on its definiti= on. 4566bis will just refer to the avtext document. Thanks. -acbegen= From nobody Fri Jul 11 10:20:24 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61591A0AEE for ; Fri, 11 Jul 2014 10:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbsGr8hY9vBy for ; Fri, 11 Jul 2014 10:20:17 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F4B1A0AC1 for ; Fri, 11 Jul 2014 10:20:17 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s6BHKDLW022276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jul 2014 12:20:15 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6BHKDcF027319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 19:20:13 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 11 Jul 2014 19:20:13 +0200 From: "DRAGE, Keith (Keith)" To: "Ali C. Begen (abegen)" , "avtext@ietf.org" Thread-Topic: Alignment of 4566bis with RTP taxonomy draft Thread-Index: AQHPnKb6HjdKqcd0IkG2qQJyg+i3uZuaG2Ig Date: Fri, 11 Jul 2014 17:20:12 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B2035DB@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <06F60AED-D155-4030-A603-68F16E013E61@cisco.com> In-Reply-To: <06F60AED-D155-4030-A603-68F16E013E61@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/3LvJqD_tcFe19yjLjoYiM_gymAw Cc: "draft-ietf-mmusic-rfc4566bis@tools.ietf.org" Subject: Re: [avtext] Alignment of 4566bis with RTP taxonomy draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:20:22 -0000 I'd note that the conference definition does not appear to be particularly = distinct from what I remember as the ITU-T definition for call, which was a= n association of two or more users. To be distinct, I suspect we need to be more specific on what the software = is - maybe we need to say something about needing mixing support. Keith=20 > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of=20 > Ali C. Begen (abegen) > Sent: 11 July 2014 02:25 > To: avtext@ietf.org > Cc: draft-ietf-mmusic-rfc4566bis@tools.ietf.org > Subject: [avtext] Alignment of 4566bis with RTP taxonomy draft >=20 > Bo asked me to check the 4566bis (mmusic) draft to make sure=20 > it was aligned with=20 > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-groupin > g-taxonomy/ >=20 > Here is the summary. 4566bis is making the following=20 > definitions (remaining from 4566): >=20 > Conference: A multimedia conference is a set of two or more > communicating users along with the software they are using to > communicate. >=20 > Session: A multimedia session is a set of multimedia senders and > receivers and the data streams flowing from senders to receivers. > A multimedia conference is an example of a multimedia session. >=20 > Session Description: A well-defined format for conveying sufficient > information to discover and participate in a multimedia session. >=20 > My recommendations: > 1) "Conference" should be defined in the taxonomy draft and=20 > 4566bis just refers to it. >=20 > 2) "Session" is not defined in the taxonomy draft but we will=20 > adopt/use "multimedia session" defined in the taxonomy draft. >=20 > 3) "Session Description" should stay in 4566bis. >=20 > Now, Bo asked me to provide a definition for "conference" and=20 > the definition above is one proposal. I will leave it to=20 > AVTEXT to agree on its definition. 4566bis will just refer to=20 > the avtext document. >=20 > Thanks. > -acbegen > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > = From nobody Mon Jul 21 08:26:06 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA4E1A02EF for ; Mon, 21 Jul 2014 08:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQHQ3fIA_I_O for ; Mon, 21 Jul 2014 08:26:03 -0700 (PDT) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5494C1A02F0 for ; Mon, 21 Jul 2014 08:26:03 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/21/2014 11:26:00 AM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-170/SG:2 7/21/2014 11:25:54 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.822344 p=-0.972621 Source White X-Signature-Violations: 0-0-0-3142-c X-Note-419: 15.6005 ms. Fail:0 Chk:1335 of 1335 total X-Note: SCH-CT/SI:0-1335/SG:1 7/21/2014 11:25:57 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 140895102 for avtext@ietf.org; Mon, 21 Jul 2014 11:25:59 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Mon, 21 Jul 2014 10:25:58 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Addition to AVTEXT agenda: header extension/RTCP usage in BUNDLE Thread-Index: AQHPpPgSNShy1osPBUu9xFO4JK5LQA== Date: Mon, 21 Jul 2014 15:25:58 +0000 Message-ID: <1B495351-4773-447B-843D-F947355CFE4A@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9CF67BB650A05444BEBB4CC14D7877AF@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/KpbbcXFaON8Sfp6CJ-3692RWfss Subject: [avtext] Addition to AVTEXT agenda: header extension/RTCP usage in BUNDLE X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:26:04 -0000 Hello, all =97 Following today=92s discussion in MMUSIC I=92ve uploaded an updated version= of the AVTEXT agenda, allocating 30 minutes for discussion of header exten= sion/RTCP usage in BUNDLE. AVTEXT Audio/Video Transport Extensions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tuesday 14:20 - 16:20 (Salon B) Chairs: Keith Drage / Jonathan Lennox 14:20 Agenda bash and status update (10 min) Chairs RFC 7160, RFC 7198 14:30 Taxonomy (30 min) Bo Burman draft-ietf-avtext-rtp-grouping-taxonomy-02 15:00 RTP/RTCP extension for RTP Splicing Notification (10 min) Roni Even draft-xia-avtext-splicing-notification-03 15:10 Negotiating Media Multiplexing Using SDP: Usage of header extensions = / RTCP (30 min) Christer Holmberg draft-ietf-mmusic-sdp-bundle-negotiation-07=20 15:10 RTP Stream Pause / Resume (15 min) Bo Burman draft-ietf-avtext-rtp-stream-pause-01 15:40 RTP Stream Pause / Resume (15 min) Bo Burman draft-ietf-avtext-rtp-stream-pause-01 15:55 Close From nobody Tue Jul 22 08:37:43 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADA81A02D0 for ; Tue, 22 Jul 2014 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNILW5U1_2tx for ; Tue, 22 Jul 2014 08:06:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 263861B28A8 for ; Tue, 22 Jul 2014 08:06:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: avtext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722150637.9769.58747.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 08:06:37 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/gYYkKuLKCfpDz3cjWBHbIzCfhKg X-Mailman-Approved-At: Tue, 22 Jul 2014 08:37:42 -0700 Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:06:41 -0000 Changed milestone "Submit Mechanism for Indication of Content Splicing Times in Multimedia Content for Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/avtext/charter/ From nobody Tue Jul 22 20:34:49 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC231A0202 for ; Tue, 22 Jul 2014 20:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWUY_4K2kT0g for ; Tue, 22 Jul 2014 20:34:47 -0700 (PDT) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15A01A0195 for ; Tue, 22 Jul 2014 20:34:47 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/22/2014 11:34:45 PM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-58/SG:2 7/22/2014 11:34:29 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.903283 p=-0.972227 Source White X-Signature-Violations: 0-0-0-2753-c X-Note-419: 0 ms. Fail:0 Chk:1335 of 1335 total X-Note: SCH-CT/SI:0-1335/SG:1 7/22/2014 11:34:39 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 115039057 for avtext@ietf.org; Tue, 22 Jul 2014 23:34:45 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Tue, 22 Jul 2014 22:34:44 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: As discussed today in AVTEXT: do we want to work on RTP header extensions for SDES items? Thread-Index: AQHPpicKrd+W74ieoUCDWhfL6fm+zg== Date: Wed, 23 Jul 2014 03:34:43 +0000 Message-ID: <7CB257BC-682A-4F3D-B4DF-79C3F31D02FC@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.146.29] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4AD70FD79F0A1741B56EBB215634FFE5@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/AHEuVMpECX70uxE6FtuUQ-xvC6k Subject: [avtext] As discussed today in AVTEXT: do we want to work on RTP header extensions for SDES items? X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 03:34:49 -0000 Hi, all =97 In the AVTEXT working group session today, there was a proposal to work on = standardizing an RTP header extension for SDES items, presumptively using d= raft-westerlund-avtext-sdes-hdr-ext-02 as the basis for a working group doc= ument. There were questions about how useful it would be (as BUNDLE is planning to= define its header extension for MID on its own, albeit in a way that shoul= d be compatible with the approach in the westerlund draft), but no objectio= ns to the work as such. So, I am calling for comments on the list. Does the group think this is something the AVTEXT group should work on? Does the group think that draft-westerlund-avtext-sdes-hdr-ext-02 should be= the basis for the working group document? Please comment to this list. Thank you! -Jonathan From nobody Tue Jul 22 22:03:00 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AAB1A03D2 for ; Tue, 22 Jul 2014 22:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diabBUYq55a7 for ; Tue, 22 Jul 2014 22:02:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730D31B289E for ; Tue, 22 Jul 2014 22:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3669; q=dns/txt; s=iport; t=1406091779; x=1407301379; h=from:to:subject:date:message-id:mime-version; bh=wq8VS1CFZM4wgoZW7+zueP3EhwftUzg7MNff6DZqCGQ=; b=msaFVEf9BN7YtJe2SCpCe02cTVCvkXQi0pYB8TbfhWcGClYAjobr2OZP uUu87GhubUROzLJ1KkABWWrO/Rxv/FfuNx+neJzu0ji21URLIBmsp/99+ THmNthecd1YgMt/GTbhzfkjS4FFTproCTBA4I3lRiJ1hNBPwVjzJdmurN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOdAz1OtJA2F/2dsb2JhbABZgkdHgS3QMxZ2hAqBCwEMdCcEiFWYcKZTF5QYBZsmlDSDRoIx X-IronPort-AV: E=Sophos;i="5.01,714,1400025600"; d="scan'208,217";a="342098282" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jul 2014 05:02:58 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6N52vmC020563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Jul 2014 05:02:57 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.221]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 00:02:57 -0500 From: "Mo Zanaty (mzanaty)" To: "avtext@ietf.org" Thread-Topic: Taxonomy Thread-Index: AQHPpjNe2+XlKjJ7DkCPUQ4TsxnXHg== Date: Wed, 23 Jul 2014 05:02:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.248.182] Content-Type: multipart/alternative; boundary="_000_CFF4BA3F35957mzanatyciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/0YYpJJs4yh9J0-cgcm6cnl2ahxw Subject: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 05:03:00 -0000 --_000_CFF4BA3F35957mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, In today=92s AVTEXT session, the following issues related to the taxonomy d= raft were discussed. 1. MST/SST: I suggest new terminology focused on Single/Multiple Transport = (rather than RTP Session) combined with Single/Multiple RTP Stream. MRMT (Multiple RTP Streams over Multiple Transports) MRST (Multiple RTP Streams over Single Transport) SRST (Single RTP Stream over Single Transport) 2. There is no term for referring to a media source or sink. Endpoint comes= to mind, but that is fundamentally different in -taxonomy. Terminal is ano= ther possibility, but is generally not used in RTP (outside H.323). Another= possibility is simply =91media source/sink=92, if the usage is not expecte= d to be very high. This issue came up in drafting text for the BUNDLE RTP m= id, which applies to all RTP streams between a pair of media sources/sinks. 3. There is no term for referring to the set of RTP streams between a media= source and sink. Transport comes to mind, but that is fundamentally differ= ent in -taxonomy. Channel is another possibility, but is generally not used= in RTP. Another possibility is simply =91RTP streams between media source/= sink X/Y=92, if the usage is not expected to be very high. This issue came = up in drafting text for the BUNDLE RTP mid, which applies to all RTP stream= s between a pair of media sources/sinks. Mo --_000_CFF4BA3F35957mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,
In today=92s AVTEXT session, the following issues related to the taxon= omy draft were discussed.

1. MST/SST: I suggest new terminology focused on Single/Multiple Trans= port (rather than RTP Session) combined with Single/Multiple RTP Stream.
MRMT (Multiple RTP Streams over Multiple Transports)
MRST (Multiple RTP Streams over Single Transport)
SRST (Single RTP Stream over Single Transport)

2. There is no term for referring to a media source or sink. Endpoint = comes to mind, but that is fundamentally different in -taxonomy. Terminal i= s another possibility, but is generally not used in RTP (outside H.323). An= other possibility is simply =91media source/sink=92, if the usage is not expected to be very high. This issue c= ame up in drafting text for the BUNDLE RTP mid, which applies to all RTP st= reams between a pair of media sources/sinks.

3. There is no term for referring to the set of RTP streams between a = media source and sink. Transport comes to mind, but that is fundamentally d= ifferent in -taxonomy. Channel is another possibility, but is generally not= used in RTP. Another possibility is simply =91RTP streams between media source/sink X/Y=92, if the usage is= not expected to be very high. This issue came up in drafting text for the = BUNDLE RTP mid, which applies to all RTP streams between a pair of media so= urces/sinks.

Mo

--_000_CFF4BA3F35957mzanatyciscocom_-- From nobody Wed Jul 23 06:39:18 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1635E1B27BF for ; Wed, 23 Jul 2014 06:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D43mZS0fh0KS for ; Wed, 23 Jul 2014 06:39:07 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7B41A0366 for ; Wed, 23 Jul 2014 06:39:07 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hu12so2173035vcb.14 for ; Wed, 23 Jul 2014 06:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=CpEZHKh5FBQ/0o/OtN23Ve/78dJ62jxET4TyPvexjC4=; b=LKeeRHGSe12JnmlN4M6kD28U3xNDMUVsshZPP2HtIfSS9E6kul1cychfjzCeaHwVVf gGGJNEsCKfn7nRsR+K+BRrmvfDUdeY37iKIaCYbK4tdj7dbqBeI8ps9yJArHgJEpOmpa rGM7T+poUZnMSDhtbieyrqe1h9Tmou1A1mN+ZbKfR5ib5iOVh6YFARCqDo6Mf7pqJBy0 8fU11gfkXd8tq3pxtdpKnrOIs95tL5sczgh3v84w+bVP3dUp3pj0ivMJMoMhlIMcB7wA 6ngbarzEy1ETzp67RYlgb5l1Jwt7R+RXgTShlE1J7GS2fBnwBTgYuvTsGMdWNjfEWVeD /8QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=CpEZHKh5FBQ/0o/OtN23Ve/78dJ62jxET4TyPvexjC4=; b=hN64TFoTwpnkuKC/wjgrm6pK4vs6pFQWqrLxWa21E3WVMvlVYnnWfRhbzbs4OX00hB VQV0SQ6xKolwjlvoOI5uMroNuUZQkVK4pVZLCgH2xenhWNibtjSfxmrA8k1N2tGIHJuG PzZQxhflIN09vl4Cv6P8OH5Hgq8Cq1R9CzRTz6xUMfZoEhKa9uWlaPik4v73y1D9x5xT ktaTZm3HGaIAJUlHriv3Ln8tOywS/VbWHZIDJb4SLB2j0uXMCvA4YnD6M5FqJIqME9AF Rd9B974kwFtjh7mtgCHUg8RsYz35LW8NZMROiUnvOoLv4jDKZ/QhRBcn1rV6M2E2ahIX KnJg== X-Gm-Message-State: ALoCoQlM3vGDPTaDUSuQptqsn4psSiyb2nF3vljbFtVuydu7iBICfu0/XPSh4GMIecZ5GjrxXkn5 X-Received: by 10.220.179.197 with SMTP id br5mr2165289vcb.80.1406122746074; Wed, 23 Jul 2014 06:39:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.47.238 with HTTP; Wed, 23 Jul 2014 06:38:25 -0700 (PDT) From: Peter Thatcher Date: Wed, 23 Jul 2014 06:38:25 -0700 Message-ID: To: avtext@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/CviQD9O7zVsDmxvotV3oSiJEQeM Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:39:08 -0000 On the issues of MST/SST, in the meeting, I proposed that we use non-acronyms, something like: single-stream-single-transport multi-stream-single-transport multi-stream-multi-transport I still think that this would be more readable and preferable to have in specs and formal documentation. However, I understand the tendency toward acronyms, and I find your proposed acronyms (SRST, MRST, MRMT) quite readable, and a big improvement over the existing ones. Would it be valuable for the Taxonomy to give both a "long form" for more readable spec and documentation and a "short acronym" for when acronyms are desired, like so? Single RTP Stream over Single Transport: single-stream-single-transport or = SRST Multiple RTP Streams over Single Transport: multi-stream-single-transport or MRST Multiple RTP Streams over Multiple Transports: multi-stream-multi-transport or MRMT Or would everyone just end up using the acronym everywhere? And while we're playing with names, I'd like to suggest a slight tweak of the names to highlight the "one to many "or "many to many" relationship by using the words "one to one" and "one to many". It also has the property that "S" can go back in the acronym rather than "R" for "RTP stream":t One RTP Stream over One Transport: one-stream-one-transport or OSOT Many RTP Streams over One Transport: many-streams-one-transport or MSOT Many RTP Streams over Many Transports: many-streams-many-transports or MSMT What do you think of that? Better, worse, or the same? > Hi, > In today=E2=80=99s AVTEXT session, the following issues related to the > taxonomy draft were discussed. > > 1. MST/SST: I suggest new terminology focused on Single/Multiple > Transport (rather than RTP Session) combined with Single/Multiple RTP > Stream. > MRMT (Multiple RTP Streams over Multiple Transports) > MRST (Multiple RTP Streams over Single Transport) > SRST (Single RTP Stream over Single Transport) > > 2. There is no term for referring to a media source or sink. Endpoint > comes to mind, but that is fundamentally different in -taxonomy. > Terminal is another possibility, but is generally not used in RTP > (outside H.323). Another possibility is simply =E2=80=98media source/sink= =E2=80=99, if > the usage is not expected to be very high. This issue came up in > drafting text for the BUNDLE RTP mid, which applies to all RTP streams > between a pair of media sources/sinks. > > 3. There is no term for referring to the set of RTP streams between a > media source and sink. Transport comes to mind, but that is > fundamentally different in -taxonomy. Channel is another possibility, > but is generally not used in RTP. Another possibility is simply =E2=80=98= RTP > streams between media source/sink X/Y=E2=80=99, if the usage is not expec= ted > to be very high. This issue came up in drafting text for the BUNDLE > RTP mid, which applies to all RTP streams between a pair of media > sources/sinks. > > Mo From nobody Wed Jul 23 06:43:13 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C281B27DF for ; Wed, 23 Jul 2014 06:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fcTuReFj9Fu for ; Wed, 23 Jul 2014 06:43:09 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5052F1A0AC9 for ; Wed, 23 Jul 2014 06:43:09 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6NDh6Ut009563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 08:43:07 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6NDgtbv026085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 15:43:05 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 23 Jul 2014 15:42:56 +0200 From: "DRAGE, Keith (Keith)" To: Peter Thatcher , "avtext@ietf.org" Thread-Topic: [avtext] Taxonomy Thread-Index: AQHPpnuDyS0FwFd+VEyY7hYKe7qsl5utqrtg Date: Wed, 23 Jul 2014 13:42:56 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B20E8C7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/iD6nh8gBYr-_dxVJ-MxBl1XPgGY Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:43:12 -0000 My individual preference is to avoid the acronyms, and my sense was that a = number of people in the room held that view as well. Keith=20 > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of=20 > Peter Thatcher > Sent: 23 July 2014 14:38 > To: avtext@ietf.org > Subject: Re: [avtext] Taxonomy >=20 > On the issues of MST/SST, in the meeting, I proposed that we=20 > use non-acronyms, something like: >=20 > single-stream-single-transport > multi-stream-single-transport > multi-stream-multi-transport >=20 > I still think that this would be more readable and preferable=20 > to have in specs and formal documentation. However, I=20 > understand the tendency toward acronyms, and I find your=20 > proposed acronyms (SRST, MRST, MRMT) quite readable, and a=20 > big improvement over the existing ones. Would it be valuable=20 > for the Taxonomy to give both a "long form" for more readable=20 > spec and documentation and a "short acronym" for when=20 > acronyms are desired, like so? >=20 > Single RTP Stream over Single Transport:=20 > single-stream-single-transport or SRST Multiple RTP Streams=20 > over Single Transport: > multi-stream-single-transport or MRST > Multiple RTP Streams over Multiple Transports: > multi-stream-multi-transport or MRMT >=20 > Or would everyone just end up using the acronym everywhere? >=20 >=20 > And while we're playing with names, I'd like to suggest a=20 > slight tweak of the names to highlight the "one to many "or=20 > "many to many" > relationship by using the words "one to one" and "one to=20 > many". It also has the property that "S" can go back in the=20 > acronym rather than "R" for "RTP stream":t >=20 > One RTP Stream over One Transport: one-stream-one-transport=20 > or OSOT Many RTP Streams over One Transport:=20 > many-streams-one-transport or MSOT Many RTP Streams over Many=20 > Transports: many-streams-many-transports or MSMT >=20 > What do you think of that? Better, worse, or the same? >=20 >=20 >=20 >=20 >=20 >=20 > > Hi, > > In today's AVTEXT session, the following issues related to the=20 > > taxonomy draft were discussed. > > > > 1. MST/SST: I suggest new terminology focused on Single/Multiple=20 > > Transport (rather than RTP Session) combined with=20 > Single/Multiple RTP=20 > > Stream. > > MRMT (Multiple RTP Streams over Multiple Transports) MRST (Multiple=20 > > RTP Streams over Single Transport) SRST (Single RTP Stream=20 > over Single=20 > > Transport) > > > > 2. There is no term for referring to a media source or=20 > sink. Endpoint=20 > > comes to mind, but that is fundamentally different in -taxonomy. > > Terminal is another possibility, but is generally not used in RTP=20 > > (outside H.323). Another possibility is simply 'media=20 > source/sink', if=20 > > the usage is not expected to be very high. This issue came up in=20 > > drafting text for the BUNDLE RTP mid, which applies to all=20 > RTP streams=20 > > between a pair of media sources/sinks. > > > > 3. There is no term for referring to the set of RTP streams=20 > between a=20 > > media source and sink. Transport comes to mind, but that is=20 > > fundamentally different in -taxonomy. Channel is another=20 > possibility,=20 > > but is generally not used in RTP. Another possibility is=20 > simply 'RTP=20 > > streams between media source/sink X/Y', if the usage is not=20 > expected=20 > > to be very high. This issue came up in drafting text for the BUNDLE=20 > > RTP mid, which applies to all RTP streams between a pair of media=20 > > sources/sinks. > > > > Mo >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > = From nobody Wed Jul 23 07:14:37 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEA21B298D for ; Wed, 23 Jul 2014 07:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv97LuIQwX_k for ; Wed, 23 Jul 2014 07:14:31 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2698D1B2851 for ; Wed, 23 Jul 2014 07:14:31 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hu12so2280189vcb.14 for ; Wed, 23 Jul 2014 07:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=q9bGt7ZlFsrYZxFtMohONdWXCm5hNsV+ZSjZre6zMCQ=; b=Gp0uwFJWFsrkUCR5cZQFd7E9Hbu+SfMGJlXlFnXLgyJegYBQg0bTATUSZWRDI8Z5t6 Z/ByAcKx6y9N/4Aa/2BHoxSL2+tPZmMlJ+gj8gBTLm4vyaL/HCraRqsHqS8MJF/kzD9j h9v7AYf55beYcS5C1SeoLBWKQYM4yq2YF5aLEF6JrOmo+HU2bebybZTX1t4ye4j1Dx4M WMJcZ+a9orHyx0Ze+D063ZT6yl9kPIkdWK6m7if+/Y8jAcv1NEDdvQ33QE4aNZyEMmdF DOMZK/klcl+N4uQZWkleOut/RajZekQUHnF8ZswKtzzpUABSxgF8eBtLxWvKVPjW4w2b sXig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=q9bGt7ZlFsrYZxFtMohONdWXCm5hNsV+ZSjZre6zMCQ=; b=jltlIG2uwKXSUSDoDy8imKDkZY/42Yqst6kAXF6/NFvI/jdYMLW7E38M0EECtMOPPC 9OegNFvdivDIEjSofNTeLBTZHE/K9QmWRIZCtpaW0kChT9/u4J/HsGDEfWvLuXqh86Lo Umq7IBsU2RSMsEkupPQq/vMWCK7SX+44AVKK0dmO4XmetGbZJN8cvfT1xTn0iJ3H0A7B RnriTonhqQCdkXKK5iLWQap5XJh7OPXb9+GARN87AnZ4yamwgD1fVhg1aFDwFAjx/f1L RhGsZO7MWehB2o9oZJe6czH036CerGiBGKnT8qjek+naWGDLAhEQ5IWLZ8WHIhFfiQqb ecKg== X-Gm-Message-State: ALoCoQnEEuk7NquILCTa/oDxNJ+6H3l8S8bSuEKwA4cXffGkIzVMomq+kHUvaoaBaWVjvJ3mP+L6 X-Received: by 10.52.246.11 with SMTP id xs11mr2118357vdc.96.1406124870274; Wed, 23 Jul 2014 07:14:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.47.238 with HTTP; Wed, 23 Jul 2014 07:13:50 -0700 (PDT) From: Peter Thatcher Date: Wed, 23 Jul 2014 07:13:50 -0700 Message-ID: To: avtext@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/14GbYDZm73dDG33jGKDhS_zoJ5s Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:14:32 -0000 On the issues of media source/sink, here are a few ideas, and perhaps a proposal. If we name #3 (the set of RTP streams), then we can simple give #2 the name of "#3 sender" or "#3 receiver", whatever #3 ends up being. I have two ideas for what #3 could be: Idea #1: Logical Stream Basically, use the phrase people often already use to describe this thing. Logical Stream: Combination of RTP streams into one logical thing Logical Stream Sender: The "source" of the logical stream Logical Stream Receiver: The "sink" of the logical stream Pros: People already use this term a lot; pretty clear what it means. Cons: If you say "stream", it's not clear if it's a logical stream or RTP stream. Idea #2: RTP Track Borrow the word that WebRTC uses. RTP Track: Combination of RTP streams into one logical thing RTP Track Sender: The "source" of the RTP track. RTP Track Receiver: The "sink" of the RTP track. This matches almost perfectly with the WebRTC taxonomy. In WebRTC, there is an RtpSender and an RtpReceiver which sends and receives tracks, which are logical source/sink of media sent and received as the combinations of multiple RTP streams. Pros: Short name with no ambiguity with "stream"; matches WebRTC very well Cons: Need to be clear when talking about an "RTP track" and a "WebRTC tra= ck". The more I think about it, the more I like #2, and I'd like to propose it as an option. What does everyone think? > Hi, > In today=E2=80=99s AVTEXT session, the following issues related to the > taxonomy draft were discussed. > > 1. MST/SST: I suggest new terminology focused on Single/Multiple > Transport (rather than RTP Session) combined with Single/Multiple RTP > Stream. > MRMT (Multiple RTP Streams over Multiple Transports) > MRST (Multiple RTP Streams over Single Transport) > SRST (Single RTP Stream over Single Transport) > > 2. There is no term for referring to a media source or sink. Endpoint > comes to mind, but that is fundamentally different in -taxonomy. > Terminal is another possibility, but is generally not used in RTP > (outside H.323). Another possibility is simply =E2=80=98media source/sink= =E2=80=99, if > the usage is not expected to be very high. This issue came up in > drafting text for the BUNDLE RTP mid, which applies to all RTP streams > between a pair of media sources/sinks. > > 3. There is no term for referring to the set of RTP streams between a > media source and sink. Transport comes to mind, but that is > fundamentally different in -taxonomy. Channel is another possibility, > but is generally not used in RTP. Another possibility is simply =E2=80=98= RTP > streams between media source/sink X/Y=E2=80=99, if the usage is not expec= ted > to be very high. This issue came up in drafting text for the BUNDLE > RTP mid, which applies to all RTP streams between a pair of media > sources/sinks. > > Mo From nobody Wed Jul 23 12:10:20 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312951B27D6 for ; Wed, 23 Jul 2014 12:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_les_Ar_wQg for ; Wed, 23 Jul 2014 12:10:16 -0700 (PDT) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621B61A0296 for ; Wed, 23 Jul 2014 12:10:16 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/23/2014 3:10:14 PM X-Policy: GLOBAL - vidyo.com X-Primary: alex@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-128/SG:2 7/23/2014 3:09:15 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.931955 p=-0.969994 Source White X-Signature-Violations: 0-0-0-8529-c X-Note-419: 31.2006 ms. Fail:0 Chk:1335 of 1335 total X-Note: SCH-CT/SI:0-1335/SG:1 7/23/2014 3:09:57 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: alex@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 141738340 for avtext@ietf.org; Wed, 23 Jul 2014 15:10:13 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 23 Jul 2014 14:10:12 -0500 From: Alex Eleftheriadis To: Google-Peter Thatcher Thread-Topic: [avtext] Taxonomy Thread-Index: AQHPpoBTOUdX1CJE5Ey9b/1gWHMLSZuuWkIA Date: Wed, 23 Jul 2014 19:10:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.72.239.80] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4A069221050C3D4C9BC2279434728D0D@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/ghD1pqb02EfD8xRARKNYa9OnyNE Cc: "avtext@ietf.org" Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:10:18 -0000 "Stream set" alone might work. "Logical stream" suggests that there is a hi= gher-level abstraction that operates as a single stream (which does not app= ear to apply here). The word "track" is very much associated with multi-tra= ck audio, QuickTime, etc., and definetely things that live on a file/tape.= =20 For the acronyms, as long as the word "transport" does not create confusion= , they look workable -- their long-hand version may indeed be preferrable b= ut that would be an editorial choice.=20 --A On Jul 23, 2014, at 5:13 PM, Peter Thatcher wrote: > On the issues of media source/sink, here are a few ideas, and perhaps > a proposal. >=20 > If we name #3 (the set of RTP streams), then we can simple give #2 the > name of "#3 sender" or "#3 receiver", whatever #3 ends up being. I > have two ideas for what #3 could be: >=20 >=20 > Idea #1: Logical Stream >=20 > Basically, use the phrase people often already use to describe this thing= . >=20 > Logical Stream: Combination of RTP streams into one logical thing > Logical Stream Sender: The "source" of the logical stream > Logical Stream Receiver: The "sink" of the logical stream >=20 > Pros: People already use this term a lot; pretty clear what it means. > Cons: If you say "stream", it's not clear if it's a logical stream or > RTP stream. >=20 >=20 >=20 > Idea #2: RTP Track >=20 > Borrow the word that WebRTC uses. >=20 > RTP Track: Combination of RTP streams into one logical thing > RTP Track Sender: The "source" of the RTP track. > RTP Track Receiver: The "sink" of the RTP track. >=20 > This matches almost perfectly with the WebRTC taxonomy. In WebRTC, > there is an RtpSender and an RtpReceiver which sends and receives > tracks, which are logical source/sink of media sent and received as > the combinations of multiple RTP streams. >=20 > Pros: Short name with no ambiguity with "stream"; matches WebRTC very we= ll > Cons: Need to be clear when talking about an "RTP track" and a "WebRTC t= rack". >=20 >=20 > The more I think about it, the more I like #2, and I'd like to propose > it as an option. >=20 > What does everyone think? >=20 >=20 >> Hi, >> In today=92s AVTEXT session, the following issues related to the >> taxonomy draft were discussed. >>=20 >> 1. MST/SST: I suggest new terminology focused on Single/Multiple >> Transport (rather than RTP Session) combined with Single/Multiple RTP >> Stream. >> MRMT (Multiple RTP Streams over Multiple Transports) >> MRST (Multiple RTP Streams over Single Transport) >> SRST (Single RTP Stream over Single Transport) >>=20 >> 2. There is no term for referring to a media source or sink. Endpoint >> comes to mind, but that is fundamentally different in -taxonomy. >> Terminal is another possibility, but is generally not used in RTP >> (outside H.323). Another possibility is simply =91media source/sink=92, = if >> the usage is not expected to be very high. This issue came up in >> drafting text for the BUNDLE RTP mid, which applies to all RTP streams >> between a pair of media sources/sinks. >>=20 >> 3. There is no term for referring to the set of RTP streams between a >> media source and sink. Transport comes to mind, but that is >> fundamentally different in -taxonomy. Channel is another possibility, >> but is generally not used in RTP. Another possibility is simply =91RTP >> streams between media source/sink X/Y=92, if the usage is not expected >> to be very high. This issue came up in drafting text for the BUNDLE >> RTP mid, which applies to all RTP streams between a pair of media >> sources/sinks. >>=20 >> Mo >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Wed Jul 23 12:19:23 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13781B2B98 for ; Wed, 23 Jul 2014 12:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPKLFyhaAAum for ; Wed, 23 Jul 2014 12:19:20 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47211A01E8 for ; Wed, 23 Jul 2014 12:19:20 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id id10so3083198vcb.35 for ; Wed, 23 Jul 2014 12:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hs2ZGkccNc4d/5dInh7k5jclFq0de7zwptx1KgcL7UI=; b=X42Ar2uH/LixVEm+AATszVNTk6TVpQqTh8QFp3aYl6YyScB08UKkJTYa4MtpiEtjvc lOsMR2nyLxrEJBN6kzK5n2aOUCMgs/kWZJi6hfNh5pXccT7HdRtZX9uMyWumuLX8GiVA LdafOhHzi+3oNdXALi4era0L2+3OMNU8TMKsTpo8nyYiuOFb7A6M3VxsQ6I4kUe9+7/P fcclGaT1U1gQ78AQRkkze4oLwPWpkRFuWt5s+ObYY1GTYQTllFZMhEBXCQtBlnt5Y5q+ Ds7U48J960YZS1Y9/SHq2r1e2lAEmO/C2ML2JIb+LKG4/1mNUMBLEEIfmW23Yy7EArwo 57+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=hs2ZGkccNc4d/5dInh7k5jclFq0de7zwptx1KgcL7UI=; b=RYODNFUCrysiIep7HtmZBP4OtlfHdf8ctrsK4eTuuQt2Q+fDhspey/0qzikJpUgKGx amnvgTdmd6ZxhZjii/tkFPquSBdVURcg+gKblPXI+PCHAfnVxB/2Z1q/RSxwlTD9yYu5 39NK0tESG6vkPZuYXc8niotr3E4dMTzePCK8ftSXIikbm7PHnyuJ7qNynYUCvYqgEHpv 0KjHyXEIoDaijb0SnVGuFLbYgp8p8x4eQ2QP/88l738GfGqsos6X1sn6e+X518CNsg/h duvIbZ3z1A4RGM8sNrAEFC0TqyFKDJ6hxbKGgplNNGfP0bZe/U/fHZx2FrAf9ZqCUWS+ JNMg== X-Gm-Message-State: ALoCoQkiQqAycRmeq4bFOroDIDIXvN8TyfONVxqBTS6yfjW/G7gqiyUkAuFoKvFHbY4rgacTfCJ6 X-Received: by 10.221.24.135 with SMTP id re7mr5168760vcb.53.1406143159807; Wed, 23 Jul 2014 12:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.47.238 with HTTP; Wed, 23 Jul 2014 12:18:39 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Wed, 23 Jul 2014 15:18:39 -0400 Message-ID: To: Alex Eleftheriadis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/DK-Q7pkt0rmCMQvbnMybS6mBJgs Cc: "avtext@ietf.org" Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:19:21 -0000 In defense of "track", it's the word used in WebRTC, and it's led to (as far as I have seen) zero confusion with multi-track audio, QuickTime, or file/tape. Plus, it would be fully an "RTP Track", just like we have an "RTP Stream", and "track" would just be short-hand. On Wed, Jul 23, 2014 at 3:10 PM, Alex Eleftheriadis wrote: > "Stream set" alone might work. "Logical stream" suggests that there is a = higher-level abstraction that operates as a single stream (which does not a= ppear to apply here). The word "track" is very much associated with multi-t= rack audio, QuickTime, etc., and definetely things that live on a file/tape= . > > For the acronyms, as long as the word "transport" does not create confusi= on, they look workable -- their long-hand version may indeed be preferrable= but that would be an editorial choice. > > --A > > On Jul 23, 2014, at 5:13 PM, Peter Thatcher wrote: > >> On the issues of media source/sink, here are a few ideas, and perhaps >> a proposal. >> >> If we name #3 (the set of RTP streams), then we can simple give #2 the >> name of "#3 sender" or "#3 receiver", whatever #3 ends up being. I >> have two ideas for what #3 could be: >> >> >> Idea #1: Logical Stream >> >> Basically, use the phrase people often already use to describe this thin= g. >> >> Logical Stream: Combination of RTP streams into one logical thing >> Logical Stream Sender: The "source" of the logical stream >> Logical Stream Receiver: The "sink" of the logical stream >> >> Pros: People already use this term a lot; pretty clear what it means. >> Cons: If you say "stream", it's not clear if it's a logical stream or >> RTP stream. >> >> >> >> Idea #2: RTP Track >> >> Borrow the word that WebRTC uses. >> >> RTP Track: Combination of RTP streams into one logical thing >> RTP Track Sender: The "source" of the RTP track. >> RTP Track Receiver: The "sink" of the RTP track. >> >> This matches almost perfectly with the WebRTC taxonomy. In WebRTC, >> there is an RtpSender and an RtpReceiver which sends and receives >> tracks, which are logical source/sink of media sent and received as >> the combinations of multiple RTP streams. >> >> Pros: Short name with no ambiguity with "stream"; matches WebRTC very w= ell >> Cons: Need to be clear when talking about an "RTP track" and a "WebRTC = track". >> >> >> The more I think about it, the more I like #2, and I'd like to propose >> it as an option. >> >> What does everyone think? >> >> >>> Hi, >>> In today=E2=80=99s AVTEXT session, the following issues related to the >>> taxonomy draft were discussed. >>> >>> 1. MST/SST: I suggest new terminology focused on Single/Multiple >>> Transport (rather than RTP Session) combined with Single/Multiple RTP >>> Stream. >>> MRMT (Multiple RTP Streams over Multiple Transports) >>> MRST (Multiple RTP Streams over Single Transport) >>> SRST (Single RTP Stream over Single Transport) >>> >>> 2. There is no term for referring to a media source or sink. Endpoint >>> comes to mind, but that is fundamentally different in -taxonomy. >>> Terminal is another possibility, but is generally not used in RTP >>> (outside H.323). Another possibility is simply =E2=80=98media source/si= nk=E2=80=99, if >>> the usage is not expected to be very high. This issue came up in >>> drafting text for the BUNDLE RTP mid, which applies to all RTP streams >>> between a pair of media sources/sinks. >>> >>> 3. There is no term for referring to the set of RTP streams between a >>> media source and sink. Transport comes to mind, but that is >>> fundamentally different in -taxonomy. Channel is another possibility, >>> but is generally not used in RTP. Another possibility is simply =E2=80= =98RTP >>> streams between media source/sink X/Y=E2=80=99, if the usage is not exp= ected >>> to be very high. This issue came up in drafting text for the BUNDLE >>> RTP mid, which applies to all RTP streams between a pair of media >>> sources/sinks. >>> >>> Mo >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext > From nobody Wed Jul 23 14:56:07 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAFA1A030B for ; Wed, 23 Jul 2014 14:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE04vFxqObNO for ; Wed, 23 Jul 2014 14:56:03 -0700 (PDT) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7000F1B2964 for ; Wed, 23 Jul 2014 14:56:02 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/23/2014 5:55:59 PM X-Policy: GLOBAL - vidyo.com X-Primary: alex@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-72/SG:2 7/23/2014 5:55:18 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.93705 p=-0.969418 Source White X-Signature-Violations: 0-0-0-10017-c X-Note-419: 15.6003 ms. Fail:0 Chk:1335 of 1335 total X-Note: SCH-CT/SI:0-1335/SG:1 7/23/2014 5:55:45 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: alex@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 141807513 for avtext@ietf.org; Wed, 23 Jul 2014 17:55:58 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 23 Jul 2014 16:55:53 -0500 From: Alex Eleftheriadis To: Google-Peter Thatcher Thread-Topic: [avtext] Taxonomy Thread-Index: AQHPpoBTOUdX1CJE5Ey9b/1gWHMLSZuuWkIAgAACX4CAACvtAA== Date: Wed, 23 Jul 2014 21:55:53 +0000 Message-ID: <23A2D21B-3A90-485B-B880-2C4AA19FE43E@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.72.239.80] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/TtY-59_06AmYCrzOwlITMtw7USI Cc: "avtext@ietf.org" Subject: Re: [avtext] Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:56:05 -0000 You are right (personal bias). Still it may be missing the aggregation aspe= ct.=20 On Jul 23, 2014, at 10:18 PM, Peter Thatcher wrote: > In defense of "track", it's the word used in WebRTC, and it's led to > (as far as I have seen) zero confusion with multi-track audio, > QuickTime, or file/tape. Plus, it would be fully an "RTP Track", just > like we have an "RTP Stream", and "track" would just be short-hand. >=20 > On Wed, Jul 23, 2014 at 3:10 PM, Alex Eleftheriadis wrot= e: >> "Stream set" alone might work. "Logical stream" suggests that there is a= higher-level abstraction that operates as a single stream (which does not = appear to apply here). The word "track" is very much associated with multi-= track audio, QuickTime, etc., and definetely things that live on a file/tap= e. >>=20 >> For the acronyms, as long as the word "transport" does not create confus= ion, they look workable -- their long-hand version may indeed be preferrabl= e but that would be an editorial choice. >>=20 >> --A >>=20 >> On Jul 23, 2014, at 5:13 PM, Peter Thatcher wrote= : >>=20 >>> On the issues of media source/sink, here are a few ideas, and perhaps >>> a proposal. >>>=20 >>> If we name #3 (the set of RTP streams), then we can simple give #2 the >>> name of "#3 sender" or "#3 receiver", whatever #3 ends up being. I >>> have two ideas for what #3 could be: >>>=20 >>>=20 >>> Idea #1: Logical Stream >>>=20 >>> Basically, use the phrase people often already use to describe this thi= ng. >>>=20 >>> Logical Stream: Combination of RTP streams into one logical thing >>> Logical Stream Sender: The "source" of the logical stream >>> Logical Stream Receiver: The "sink" of the logical stream >>>=20 >>> Pros: People already use this term a lot; pretty clear what it means. >>> Cons: If you say "stream", it's not clear if it's a logical stream or >>> RTP stream. >>>=20 >>>=20 >>>=20 >>> Idea #2: RTP Track >>>=20 >>> Borrow the word that WebRTC uses. >>>=20 >>> RTP Track: Combination of RTP streams into one logical thing >>> RTP Track Sender: The "source" of the RTP track. >>> RTP Track Receiver: The "sink" of the RTP track. >>>=20 >>> This matches almost perfectly with the WebRTC taxonomy. In WebRTC, >>> there is an RtpSender and an RtpReceiver which sends and receives >>> tracks, which are logical source/sink of media sent and received as >>> the combinations of multiple RTP streams. >>>=20 >>> Pros: Short name with no ambiguity with "stream"; matches WebRTC very = well >>> Cons: Need to be clear when talking about an "RTP track" and a "WebRTC= track". >>>=20 >>>=20 >>> The more I think about it, the more I like #2, and I'd like to propose >>> it as an option. >>>=20 >>> What does everyone think? >>>=20 >>>=20 >>>> Hi, >>>> In today=92s AVTEXT session, the following issues related to the >>>> taxonomy draft were discussed. >>>>=20 >>>> 1. MST/SST: I suggest new terminology focused on Single/Multiple >>>> Transport (rather than RTP Session) combined with Single/Multiple RTP >>>> Stream. >>>> MRMT (Multiple RTP Streams over Multiple Transports) >>>> MRST (Multiple RTP Streams over Single Transport) >>>> SRST (Single RTP Stream over Single Transport) >>>>=20 >>>> 2. There is no term for referring to a media source or sink. Endpoint >>>> comes to mind, but that is fundamentally different in -taxonomy. >>>> Terminal is another possibility, but is generally not used in RTP >>>> (outside H.323). Another possibility is simply =91media source/sink=92= , if >>>> the usage is not expected to be very high. This issue came up in >>>> drafting text for the BUNDLE RTP mid, which applies to all RTP streams >>>> between a pair of media sources/sinks. >>>>=20 >>>> 3. There is no term for referring to the set of RTP streams between a >>>> media source and sink. Transport comes to mind, but that is >>>> fundamentally different in -taxonomy. Channel is another possibility, >>>> but is generally not used in RTP. Another possibility is simply =91RTP >>>> streams between media source/sink X/Y=92, if the usage is not expected >>>> to be very high. This issue came up in drafting text for the BUNDLE >>>> RTP mid, which applies to all RTP streams between a pair of media >>>> sources/sinks. >>>>=20 >>>> Mo >>>=20 >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >>=20 From nobody Thu Jul 24 18:29:25 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9D1A0A90; Thu, 24 Jul 2014 18:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9lLOa-yyJCi; Thu, 24 Jul 2014 18:29:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB741A0386; Thu, 24 Jul 2014 18:29:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140725012921.25895.6831.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 18:29:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/_TEfsg09X_4h5gD4CbC4MbiTW5A Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:29:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : RTP Stream Pause and Resume Authors : Bo Burman Azam Akram Roni Even Magnus Westerlund Filename : draft-ietf-avtext-rtp-stream-pause-02.txt Pages : 45 Date : 2014-07-24 Abstract: With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTCP feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real- time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 24 18:42:56 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808F61A0A86 for ; Thu, 24 Jul 2014 18:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFmDdonzvB0q for ; Thu, 24 Jul 2014 18:42:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011DC1A0944 for ; Thu, 24 Jul 2014 18:42:51 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-f1-53d1b619edb5 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8D.5F.03739.916B1D35; Fri, 25 Jul 2014 03:42:49 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.228]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 03:42:49 +0200 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-02.txt Thread-Index: AQHPp6ffFtXbhyDueEaeULzybBXgmpuwAKiw Date: Fri, 25 Jul 2014 01:42:48 +0000 Message-ID: References: <20140725012921.25895.6831.idtracker@ietfa.amsl.com> In-Reply-To: <20140725012921.25895.6831.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja7ktovBBoc+6lh8vHeD1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGTcWHWYpuClVMXfDOcYGxi8iXYycHBICJhLrZl5ngbDFJC7c W8/WxcjFISRwlFHi1OTZLBDOEkaJl337WEGq2AQ0JObvuMsIYosIqEvcmX6BDcQWFvCWOPez iQUi7iOxvb0JqJ4DyDaSWLpSCCTMIqAqMeHsUbBWXgFfiS/Hp4PZQgIOEgte7AFr5RRwlDj+ aC3YKkYBWYn73++BxZkFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC2EoSK7ZfYoSo15FYsPsT G4StLbFs4WtmiL2CEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU4uLcdCNjvdSizOTi 4vw8vbzUkk2MwJg4uOW37g7G1a8dDzEKcDAq8fA+bLwYLMSaWFZcmXuIUZqDRUmcd9G5ecFC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGOUOT3i15RcXu2KifEdOacppjrjTtw30w++f2HjY yFcw4ApjukkcQ2qMeNmzddnxsZeMFu86pJO06PB1zp6M5UIK1i33jpdWSIufXPu6L7ht6WSd fZM2uO2ayN217Ovpj+/a/qw78aj+HsfrPYcTfspmTN+blrhEbWljQdFR804nlz/n9RlXH1Vi Kc5INNRiLipOBABjQPRxagIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/1KNF1XYEkYDuouSc9C_kaC4Evp0 Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:42:54 -0000 As discussed at the AVTEXT session in Toronto, here is a version that has r= educed previous section 5 on relation to other signaling solutions into a s= ingle, summarizing paragraph, put as the last sub-section of section 4 (des= ign considerations). Related to the question on a media sender pausing itself that was also disc= ussed there; may I ask you to specifically review the text regarding that, = and especially when using TMMBN 0 as the PAUSED indication that this has be= en done. Please also review the text on what to do after pausing itself whe= n a) the media stream sender resumes itself, and b) when (one of) the media= stream receiver(s) asks to resume the stream, especially when TMMBR/TMMBN = are used, but also for the case when PAUSED/RESUME are used. I also found that the IANA section of the document is probably not followin= g the formally required format, and help with how it should look like is hi= ghly appreciated. Cheers, Bo > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org > Sent: den 24 juli 2014 21:29 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Extensions Workin= g Group of the IETF. >=20 > Title : RTP Stream Pause and Resume > Authors : Bo Burman > Azam Akram > Roni Even > Magnus Westerlund > Filename : draft-ietf-avtext-rtp-stream-pause-02.txt > Pages : 45 > Date : 2014-07-24 >=20 > Abstract: > With the increased popularity of real-time multimedia applications, > it is desirable to provide good control of resource usage, and users > also demand more control over communication sessions. This document > describes how a receiver in a multimedia conversation can pause and > resume incoming data from a sender by sending real-time feedback > messages when using Real-time Transport Protocol (RTP) for real time > data transport. This document extends the Codec Control Messages > (CCM) RTCP feedback package by explicitly allowing and describing > specific use of existing CCM messages and adding a group of new real- > time feedback messages used to pause and resume RTP data streams. > This document updates RFC 5104. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-stream-pause-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Thu Jul 24 18:48:18 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2081A0A90 for ; Thu, 24 Jul 2014 18:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS4756bJUC4v for ; Thu, 24 Jul 2014 18:48:16 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECAA1A0944 for ; Thu, 24 Jul 2014 18:48:15 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-e8-53d1b75ec6d3 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 67.AF.03739.E57B1D35; Fri, 25 Jul 2014 03:48:14 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.228]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 03:48:13 +0200 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: As discussed today in AVTEXT: do we want to work on RTP header extensions for SDES items? Thread-Index: AQHPpicKrd+W74ieoUCDWhfL6fm+zpuwB1sA Date: Fri, 25 Jul 2014 01:48:12 +0000 Message-ID: References: <7CB257BC-682A-4F3D-B4DF-79C3F31D02FC@vidyo.com> In-Reply-To: <7CB257BC-682A-4F3D-B4DF-79C3F31D02FC@vidyo.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW7c9ovBBi/nCFp8vHeD1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGXdf9DMWPOKqWPP8KlMD4x2OLkYODgkBE4n3vzK6GDmBTDGJ C/fWs4HYQgJHGSUWNaZ3MXIB2UsYJTp2NrODJNgENCTm77jLCGKLCKhL3Jl+AaxBWCBD4ten O4wgM0UEMiUmrjGFKDGSuNq6jQnEZhFQlXh75S9YOa+Ar8Snif+ZIHbZSLyZ+4oZxOYUsJXY sWgLK4jNKCArcf/7PRYQm1lAXOLWk/lMEHcKSCzZc54ZwhaVePn4HyuErSSxYvslRoh6HYkF uz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3K TC4uzs/Ty0st2cQIjIeDW37r7mBc/drxEKMAB6MSD+/DxovBQqyJZcWVuYcYpTlYlMR5F52b FywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMc3dTlyvWTJsy+u/cn8d54Vaqvyd8yliRtGS oP1npzxp97SR6jyyL7+P10VBVCHlTEm3UZ3z7/LiNtsDX7w7Zt6VstVaJH5wo/afGtcURbPp Nac4Mp5fS6vexvjy04vnPyP9GByrlPztNCUvJs2rr/Y8v6sifyKH+WI+wSPy534KBZXrn3yh xFKckWioxVxUnAgA4bZE2GgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/bshxztcs-zgLBdE4mU1gCsNSoTk Subject: Re: [avtext] As discussed today in AVTEXT: do we want to work on RTP header extensions for SDES items? X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:48:18 -0000 I am probably biased as one of the co-authors, but yes to both questions. > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Jonathan Lenno= x > Sent: den 22 juli 2014 23:35 > To: avtext@ietf.org > Subject: [avtext] As discussed today in AVTEXT: do we want to work on RTP= header extensions for SDES items? >=20 > Hi, all - >=20 > In the AVTEXT working group session today, there was a proposal to work o= n standardizing an RTP header extension for > SDES items, presumptively using draft-westerlund-avtext-sdes-hdr-ext-02 a= s the basis for a working group document. >=20 > There were questions about how useful it would be (as BUNDLE is planning = to define its header extension for MID on its > own, albeit in a way that should be compatible with the approach in the w= esterlund draft), but no objections to the work > as such. >=20 > So, I am calling for comments on the list. >=20 > Does the group think this is something the AVTEXT group should work on? >=20 > Does the group think that draft-westerlund-avtext-sdes-hdr-ext-02 should = be the basis for the working group > document? >=20 > Please comment to this list. Thank you! >=20 > -Jonathan >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Fri Jul 25 09:37:17 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C571A033D for ; Fri, 25 Jul 2014 09:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlWSlpCzvNlK for ; Fri, 25 Jul 2014 09:37:12 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063DC1A031B for ; Fri, 25 Jul 2014 09:37:11 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s6PGb8q1019643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 25 Jul 2014 11:37:10 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s6PGaqkt004586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Jul 2014 18:37:06 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 25 Jul 2014 18:36:57 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: WGLC for draft-ietf-avtext-rtp-stream-pause-02 Thread-Index: Ac+oI8943NA5z66dRdGqdkJ2oCY7RQ== Date: Fri, 25 Jul 2014 16:36:56 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/8iS4gQ-v-gzDqujdPQY14n5iuEQ Subject: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:37:13 -0000 (As WG cochair) This is to announce a Working Group Last Call on=20 https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ draft-ietf-avtext-rtp-stream-pause-02 Please comment on the document by August 18th, 2014. Comments preferably to the AVTEXT list. It is helpful if you categorise your comments into Editorial, Minor technic= al, Major issue. The author has posed some open questions to the list. The chairs do not bel= ieve this should impact the appriateness of starting the WGLC now. However = do please respond to those questions. The chairs realise this is a period when people will be disappearing on lea= ve - if you intend commenting on the document but such leave means you need= more time, please email the chairs with that information and when you thin= k you might complete a WGLC review. Regards Keith= From nobody Tue Jul 29 06:15:25 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B131B288D; Tue, 29 Jul 2014 06:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20eYYSyR60tK; Tue, 29 Jul 2014 06:15:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E621B288C; Tue, 29 Jul 2014 06:15:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140729131517.29461.34635.idtracker@ietfa.amsl.com> Date: Tue, 29 Jul 2014 06:15:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/9lefP1OMGtiO-3pIN-3Cuo3goxU Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 13:15:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : RTP/RTCP Extension for RTP Splicing Notification Authors : Jinwei Xia Roni Even Rachel Huang Lingli Deng Filename : draft-ietf-avtext-splicing-notification-00.txt Pages : 12 Date : 2014-07-28 Abstract: Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The RTP mixer is designed to handle RTP splicing in [RFC6828], but how the RTP mixer knows when to start and end the splicing is still unspecified. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the RTP mixer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 29 13:41:07 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA6E1A0AA2 for ; Tue, 29 Jul 2014 13:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.269 X-Spam-Level: X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR2uLd8sWVze for ; Tue, 29 Jul 2014 13:41:04 -0700 (PDT) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9476B1A0A9D for ; Tue, 29 Jul 2014 13:41:04 -0700 (PDT) X-Note-AR-ScanTimeLocal: 7/29/2014 4:41:02 PM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-88/SG:2 7/29/2014 4:40:44 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.831031 p=-0.974835 Source White X-Signature-Violations: 0-0-0-1497-c X-Note-419: 0 ms. Fail:0 Chk:1335 of 1335 total X-Note: SCH-CT/SI:0-1335/SG:1 7/29/2014 4:40:45 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES-> X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 143233283 for avtext@ietf.org; Tue, 29 Jul 2014 16:41:02 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Tue, 29 Jul 2014 15:41:01 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: AVTEXT minutes from IETF 90 posted Thread-Index: AQHPq21o9Fg+vO6080K1n2vGwEqWgQ== Date: Tue, 29 Jul 2014 20:41:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/t4dFy5Y50kyxQkLOq92GbmdZFds Subject: [avtext] AVTEXT minutes from IETF 90 posted X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:41:06 -0000 The draft meeting minutes for AVTEXT from IETF 90 have been uploaded to the= proceedings website, at . Please review them and send any changes to the chairs. Thanks! -Jonathan