From nobody Thu May 1 02:44:35 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 9B4FF1A076C for ; Thu, 1 May 2014 02:44:32 -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, HTML_MESSAGE=0.001, 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 CDSp3mRJO3oG for ; Thu, 1 May 2014 02:44:29 -0700 (PDT) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED541A076B for ; Thu, 1 May 2014 02:44:28 -0700 (PDT) X-Note-AR-ScanTimeLocal: 5/1/2014 5:44:25 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com 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-165/SG:5 5/1/2014 5:43:41 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.898393 p=-0.987565 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 31.199 ms. Fail:1 Chk:1340 of 1340 total X-Note: SCH-CT/SI:1-1340/SG:1 5/1/2014 5:44:14 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail2.vidyo.com X-Note-Return-Path: alex@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 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 93620967; Thu, 01 May 2014 05:44:25 -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.0146.000; Thu, 1 May 2014 04:44:24 -0500 From: Alex Eleftheriadis To: Bernard Aboba Thread-Topic: [avtext] Proposed RTP Taxonomy updates Thread-Index: Ac9eyJwZU1yGeu96Tu+aOoOxWGE6dgFEwugAAC4LHgAADXhHgAAA7t0AAB+ZiwA= Date: Thu, 1 May 2014 09:44:24 +0000 Message-ID: References: <8BA7D4CEACFFE04BA2D902BF11719A8345247374@nasanexd02f.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.72.236.166] Content-Type: multipart/alternative; boundary="_000_E19D0EF0E8FD42BB8DD76D959942C43Fvidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/xzaRVN3b63VJgXriMzudDKv3EbU Cc: "avtext@ietf.org" Subject: Re: [avtext] Proposed RTP Taxonomy 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: Thu, 01 May 2014 09:44:32 -0000 --_000_E19D0EF0E8FD42BB8DD76D959942C43Fvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with Bernard. There is now both SST-MS and SST-SS widely deployed b= ut, more importantly, the concepts are truly distinct. So we should not "ov= erload" SST to always mean one or the other. W.r.t. the HEVC payload spec, I would argue that redefining it there to mea= n stream rather than session, as it does in the H.264 spec, should be serio= usly reconsidered. As someone who, for many years, has tried to explain these architectures to= several people, a lot of them technically very very knowledgeable, I have = found the lack of appropriate commonly accepted terminology a serious imped= iment. Now that these architectures are investigated very extensively, we = have a great opportunity to fix that and do it the right way. Redefining ac= ronyms, and particularly in the same series of specifications, is imho goin= g in the exactly opposite direction. Maybe we can use something like "configuration": Single Stream Configuratio= n (SSC) and Multi-Stream Configuration (MSC). They describe how the layers = are configured for transmission, not how they are transmitted. The transmis= sion part comes next, and uses the SST and MST acronyms. That would simpli= fy potential changes to all drafts, and avoid confusion. --Alex [with apologies for not always closely following the thread] On Apr 30, 2014, at 9:39 PM, Bernard Aboba > wrote: The problem is that the single/ multiple session and single/multiple stream= dimensions are somewhat independent, and affect SFU design as well as clie= nt behavior. In particular, SST-MS has now been widely implemented, so we = cannot pretend it doesn't exist. Changing the meaning of the SST/MST abbrev= iations could potentially increase the already considerable confusion. On Apr 30, 2014, at 11:12 AM, "Wang, Ye-Kui" > wrote: Regarding the term of =93RTP packet stream=94, =93packet stream=94, or =93R= TP stream=94, I prefer =93RTP stream=94 too. On SST/MST, note that in the latest HEVC/H.265 payload draft, we are using = =93Single-Stream Transmission=94 and =93Multi-Stream Transmission=94. SST h= ere is obviously within one RTP session, while MST herein can involve eithe= r a single or multiple RTP sessions. What is the importance of adding the s= uffix =93-SS=94 or =93-MS=94 herein in the term? Why it is not sufficient t= o just use SST/MST with the S in the middle mean =93stream=94? BR, YK From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman Sent: Wednesday, April 30, 2014 4:47 AM To: Bernard Aboba Cc: avtext@ietf.org Subject: Re: [avtext] Proposed RTP Taxonomy updates With respect to leaving current SST/MST definition alone, I agree, but I th= ink there was also agreement to describe them in Taxonomy terms, without re= -defining anything. In that, =93MST=94 and =93SST=94 without any distinction is unclear, but sh= ould according to IETF 89 discussions typically mean =93MST-SS=94 and =93SS= T-SS=94 , which should be described (with or without explicitly referring t= o any =96SS and =96MS distinctions). Bernard and Alex, do I understand you correctly that you prefer to keep the= =96SS and =96MS distinctions? I have no problem keeping it, and I am also = open to alternative terminology describing the same thing. Do you have any = proposals? From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: den 29 april 2014 15:49 To: Bo Burman Cc: avtext@ietf.org; Alex Eleftheriadis Subject: Re: [avtext] Proposed RTP Taxonomy updates With respect to SST/MST, as I recall, Alex's suggestion was to leave the RF= C 6190 definition alone, but also define terminology for the single/multi-s= tream distinction. For example, it is possible to have multiple streams wit= hin a single session (SST-MS). On Apr 29, 2014, at 6:27, "Bo Burman" > wrote: Hi all, Based on the AVTEXT session at IETF 88 & 89 and some mailing list discussio= ns, I propose to make the following updates to RTP Taxonomy: =95 In 3.2.1 clearly define what RFC 6190 terms =93SST=94 and =93MS= T=94 means in Taxonomy terms and remove the current discussion on Single- a= nd Multi-Stream. =95 Mention in 2.2.1 under Alternate usages that an =93End Point=94= in Taxonomy terms is typically a single =93host=94 (although =93host=94 ha= s no unique definition). =95 Change the term =93Packet Stream=94 throughout the document, si= nce it is arguably too generic: o =93RTP Packet Stream=94 was suggested by Magnus W about a month ago and= received some support. I think it is a bit long and unnecessarily redundan= t, since RTP already implies that it is a packet o =93RTP Stream=94 could possibly be a sufficiently precise term; what d= o others think? =95 Re-structure the document such that Alternate usages (describin= g existing terms in Taxonomy wording) are separated out into their own sub-= sections, making it possible to find them through the table of contents o I believe this could take care of Roni Even=92s request at IETF 88 for = an overview table with existing terms, while avoiding the fact that the nee= ded explanations will hardly fit in a table format. =95 Editorial: o Remove formal numberings of level 4 headings (change to body text or he= adings in body text format). Comments are welcome! Cheers, Bo _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_E19D0EF0E8FD42BB8DD76D959942C43Fvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8298DEF701BB6B428CECE4AFBAD943CB@vidyo.com> Content-Transfer-Encoding: quoted-printable I agree with Bernard. There is now both SST-MS and SST-SS widely deployed b= ut, more importantly, the concepts are truly distinct. So we should not &qu= ot;overload" SST to always mean one or the other. 

W.r.t. the HEVC payload spec, I would argue that redefining it there t= o mean stream rather than session, as it does in the H.264 spec, should be = seriously reconsidered.   

As someone who, for many years, has tried to explain these architectur= es to several people, a lot of them technically very very knowledgeable, I = have found the lack of appropriate commonly accepted terminology a serious = impediment. Now that these architectures are investigated very extensively,  we have a great opportunity to fi= x that and do it the right way. Redefining acronyms, and particularly in th= e same series of specifications, is imho going in the exactly opposite dire= ction. 

Maybe we can use something like "configuration": Single Stre= am Configuration (SSC) and Multi-Stream Configuration (MSC). They describe = how the layers are configured for transmission, not how they are transmitte= d. The transmission part comes next, and uses the SST and MST acronyms.  That would simplify potential changes to a= ll drafts, and avoid confusion. 

--Alex [with apologies for not always closely following the thread]&nb= sp;

On Apr 30, 2014, at 9:39 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

The problem is that the single/ multiple session and single/multiple s= tream dimensions are somewhat independent, and affect SFU design as well as= client behavior.  In particular, SST-MS has now been widely implement= ed, so we cannot pretend it doesn't exist. Changing the meaning of the SST/MST abbreviations could potentially increa= se the already considerable confusion.

On Apr 30, 2014, at 11:12 AM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> wrote:

Regarding the term of =93RTP packe= t stream=94, =93packet stream=94, or =93RTP stream=94,  I prefer =93RT= P stream=94 too.
 
On SST/MST, note that in the lates= t HEVC/H.265 payload draft, we are using =93Single-Stream Transmission=94 a= nd =93Multi-Stream Transmission=94. SST here is obviously within one RTP se= ssion, while MST herein can involve either a single or multiple RTP sessions. What is the importance of adding the su= ffix =93-SS=94 or =93-MS=94 herein in the term? Why it is not sufficient to= just use SST/MST with the S in the middle mean =93stream=94?
 
BR, YK
 
From:<= /span> avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman<= br> Sent: Wednesday, A= pril 30, 2014 4:47 AM
To: Bernard Aboba<= br> Cc: a= vtext@ietf.org
Subject: Re: [avte= xt] Proposed RTP Taxonomy updates
 
With respect to leaving current SS= T/MST definition alone, I agree, but I think there was also agreement to de= scribe them in Taxonomy terms, without re-defining anything.
 
In that, =93MST=94 and =93SST=94 w= ithout any distinction is unclear, but should according to IETF 89 discussi= ons typically mean =93MST-SS=94 and =93SST-SS=94 , which should be describe= d (with or without explicitly referring to any =96SS and =96MS distinctions).
 
Bernard and Alex, do I understand = you correctly that you prefer to keep the =96SS and =96MS distinctions? I h= ave no problem keeping it, and I am also open to alternative terminology de= scribing the same thing. Do you have any proposals?
 
 
From:<= /span> Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Sent: den 29 april= 2014 15:49
To: Bo Burman
Cc: a= vtext@ietf.org; Alex Eleftheriadis
Subject: Re: [avte= xt] Proposed RTP Taxonomy updates
 
With respect to SST/MST, as I recall, Alex's suggestion was to leave the RF= C 6190 definition alone, but also define terminology for the single/multi-s= tream distinction. For example, it is possible to have multiple streams wit= hin a single session (SST-MS).


On Apr 29, 2014, at 6:27, "Bo Burman" <bo.= burman@ericsson.com> wrote:

Hi all,
 
Based on the AVTEXT session at IETF 88 & 89 and some mailing list discu= ssions, I propose to make the following updates to RTP Taxonomy:=
=B7     &= nbsp;   = In 3.2.1 clearly define what RFC 6190 terms =93SST=94 and =93MST=94 means in = Taxonomy terms and remove the current discussion on Single- and Multi-Strea= m.
=B7     &= nbsp;   = Mention in 2.2.1 under Alternate usages that an =93End Point=94 in Taxonomy terms = is typically a single =93host=94 (although =93host=94 has no unique definit= ion).
=B7     &= nbsp;   = Change the term =93Packet Stream=94 throughout the document, since it is arguably= too generic:
o   =93RTP Packet Stream=94 was suggested by Magnus W about a month ago and received = some support. I think it is a bit long and unnecessarily redundant, since R= TP already implies that it is a packet
o    =93RTP Stream=94 could possibly be a sufficiently precise term; what do others th= ink?
=B7     &= nbsp;   = Re-structure the document such that Alternate usages (describing existing terms in Taxo= nomy wording) are separated out into their own sub-sections, making it poss= ible to find them through the table of contents
o   I believe this could take care of Roni Even=92s request at IETF 88 for an ov= erview table with existing terms, while avoiding the fact that the needed e= xplanations will hardly fit in a table format.
=B7     &= nbsp;   = Editorial:
o   Remove formal numberings of level 4 headings (change to body text or headings in = body text format).
 
Comments are welcome!
 
Cheers,
Bo
 
___= ____________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/av= text

--_000_E19D0EF0E8FD42BB8DD76D959942C43Fvidyocom_-- From nobody Thu May 1 05:40: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 1595F1A88EC for ; Thu, 1 May 2014 05:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 z29x1RigkKLS for ; Thu, 1 May 2014 05:40:00 -0700 (PDT) Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by ietfa.amsl.com (Postfix) with ESMTP id EC3A11A88E4 for ; Thu, 1 May 2014 05:39:59 -0700 (PDT) Received: from BLU406-EAS420 ([65.55.111.72]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 May 2014 05:39:58 -0700 X-TMN: [xBfTzls2NEcOWeXp07yly2PvY9P+3/X+] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-1E07DC2F-FB2A-4DA5-B89C-911DB394AD15" Content-Transfer-Encoding: 7bit References: From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Thu, 1 May 2014 05:39:56 -0700 To: Bo Burman X-OriginalArrivalTime: 01 May 2014 12:39:58.0026 (UTC) FILETIME=[760F5AA0:01CF653A] Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/yAvRiuXVitCFLHNciSixSnZsVyM Cc: "avtext@ietf.org" Subject: Re: [avtext] Proposed RTP Taxonomy 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: Thu, 01 May 2014 12:40:01 -0000 --Apple-Mail-1E07DC2F-FB2A-4DA5-B89C-911DB394AD15 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gQXByIDMwLCAyMDE0LCBhdCA0OjQ3LCAiQm8gQnVybWFuIiA8Ym8uYnVybWFuQGVyaWNzc29u LmNvbT4gd3JvdGU6DQo+IA0KPiBXaXRoIHJlc3BlY3QgdG8gbGVhdmluZyBjdXJyZW50IFNTVC9N U1QgZGVmaW5pdGlvbiBhbG9uZSwgSSBhZ3JlZSwgYnV0IEkgdGhpbmsgdGhlcmUgd2FzIGFsc28g YWdyZWVtZW50IHRvIGRlc2NyaWJlIHRoZW0gaW4gVGF4b25vbXkgdGVybXMsIHdpdGhvdXQgcmUt ZGVmaW5pbmcgYW55dGhpbmcuDQo+ICANCj4gSW4gdGhhdCwg4oCcTVNU4oCdIGFuZCDigJxTU1Ti gJ0gd2l0aG91dCBhbnkgZGlzdGluY3Rpb24gaXMgdW5jbGVhciwgYnV0IHNob3VsZCBhY2NvcmRp bmcgdG8gSUVURiA4OSBkaXNjdXNzaW9ucyB0eXBpY2FsbHkgbWVhbiDigJxNU1QtU1PigJ0gYW5k IOKAnFNTVC1TU+KAnSAsIHdoaWNoIHNob3VsZCBiZSBkZXNjcmliZWQgKHdpdGggb3Igd2l0aG91 dCBleHBsaWNpdGx5IHJlZmVycmluZyB0byBhbnkg4oCTU1MgYW5kIOKAk01TIGRpc3RpbmN0aW9u cykuDQoNCkkgZG8gbm90IGJlbGlldmUgdGhhdCBNU1QtU1MgbWFrZXMgc2Vuc2UgLSBpdCB3b3Vs ZCBpbXBseSB1c2Ugb2YgdGhlIHNhbWUgU1NSQyBpbiBtdWx0aXBsZSBzZXNzaW9ucy4gU2luY2Ug U1NSQyBjb2xsaXNpb25zIGFyZSBkZXRlY3RlZCB3aXRoaW4gYSBzZXNzaW9uLCB0aGUgU1NSQyBj b3VsZCBjaGFuZ2UgaW4gb25lIHNlc3Npb24sIGFuZCBub3QgYW5vdGhlci4gU28gTVNULU1TIG1h a2VzIG1vcmUgc2Vuc2UuIA0K --Apple-Mail-1E07DC2F-FB2A-4DA5-B89C-911DB394AD15 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+T24gQXBy IDMwLCAyMDE0LCBhdCA0OjQ3LCAiQm8gQnVybWFuIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJvLmJ1 cm1hbkBlcmljc3Nvbi5jb20iPmJvLmJ1cm1hbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pg0KDQo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11 dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0 IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICov DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAw IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBh bm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD YWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206 MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEw NTMyMzkzNjA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xNzQ1MTcwNDk0IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCg0KDQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPldpdGggcmVzcGVjdCB0byBsZWF2aW5nIGN1cnJlbnQgU1NUL01TVCBkZWZpbml0aW9u IGFsb25lLCBJIGFncmVlLCBidXQgSSB0aGluayB0aGVyZSB3YXMgYWxzbyBhZ3JlZW1lbnQgdG8g ZGVzY3JpYmUgdGhlbSBpbiBUYXhvbm9teSB0ZXJtcywgd2l0aG91dCByZS1kZWZpbmluZyBhbnl0 aGluZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SW4gdGhhdCwg4oCc TVNU4oCdIGFuZCDigJxTU1TigJ0gd2l0aG91dCBhbnkgZGlzdGluY3Rpb24gaXMgdW5jbGVhciwg YnV0IHNob3VsZCBhY2NvcmRpbmcgdG8gSUVURiA4OSBkaXNjdXNzaW9ucyB0eXBpY2FsbHkgbWVh biDigJxNU1QtU1PigJ0gYW5kIOKAnFNTVC1TU+KAnSAsIHdoaWNoIHNob3VsZCBiZSBkZXNjcmli ZWQgKHdpdGggb3Igd2l0aG91dCBleHBsaWNpdGx5IHJlZmVycmluZw0KIHRvIGFueSDigJNTUyBh bmQg4oCTTVMgZGlzdGluY3Rpb25zKS48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90 ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgZG8gbm90IGJlbGlldmUgdGhhdCBNU1QtU1MgbWFrZXMg c2Vuc2UgLSBpdCB3b3VsZCBpbXBseSB1c2Ugb2YgdGhlIHNhbWUgU1NSQyBpbiBtdWx0aXBsZSBz ZXNzaW9ucy4gU2luY2UgU1NSQyBjb2xsaXNpb25zIGFyZSBkZXRlY3RlZCB3aXRoaW4gYSBzZXNz aW9uLCB0aGUgU1NSQyBjb3VsZCBjaGFuZ2UgaW4gb25lIHNlc3Npb24sIGFuZCBub3QgYW5vdGhl ci4gU28gTVNULU1TIG1ha2VzIG1vcmUgc2Vuc2UuJm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi PjxkaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQoNCg0KPC9ibG9j a3F1b3RlPjwvYm9keT48L2h0bWw+ --Apple-Mail-1E07DC2F-FB2A-4DA5-B89C-911DB394AD15-- From nobody Fri May 2 17:23: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 7B6751A6EF1; Fri, 2 May 2014 17:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 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, RP_MATCHES_RCVD=-0.651, 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 Ay_A1qkQWlCW; Fri, 2 May 2014 17:23:11 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4A1A6F63; Fri, 2 May 2014 17:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1399076589; x=1430612589; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ddWj0guMcAobIRW+tMWMy8HUEG2/46gDUp2/hwuANJI=; b=rv0PDiv7bt9BaUHxDPMGHk4ALwudriEwDWNTSpU5/OiIOJMit6S2AMKN c0I2LidV5kdW85aoL6xlkmr8vOmB3s1VGvuMeKhcIU1Y9snKtrRROhN0Q k85JK/MqhWWbLk76LqAfR+6fXa20LVshdKTX/CW6C1KbPhGpS9jDJoDuS I=; X-IronPort-AV: E=McAfee;i="5600,1067,7426"; a="62858178" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 02 May 2014 17:23:08 -0700 X-IronPort-AV: E=Sophos; i="4.97,975,1389772800"; d="scan'208,217"; a="29584736" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 May 2014 17:23:09 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.134]) by NASANEXHC17.na.qualcomm.com ([10.45.158.129]) with mapi id 14.03.0158.001; Fri, 2 May 2014 17:23:10 -0700 From: "Wang, Ye-Kui" To: Alex Eleftheriadis , Bernard Aboba Thread-Topic: [avtext] Proposed RTP Taxonomy updates Thread-Index: Ac9eyJwZU1yGeu96Tu+aOoOxWGE6dgFI88oAAC4LHgAAAVzTQAANClEAAB+Z2AAAQdy2sA== Date: Sat, 3 May 2014 00:23:09 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8345249883@nasanexd02f.na.qualcomm.com> References: <8BA7D4CEACFFE04BA2D902BF11719A8345247374@nasanexd02f.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8345249883nasanexd02fnaqu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/NJLHXkvG8G4qpbSggAYXSU_-L0Y Cc: "avtext@ietf.org" , "payload@ietf.org" Subject: Re: [avtext] Proposed RTP Taxonomy 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: Sat, 03 May 2014 00:23:14 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A8345249883nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Posting it to payload reflector as well]. I am fine with Alex's suggestion on Single Stream Configuration (SSC) and M= ulti-Stream Configuration (MSC) to replace SST/MST in the HEVC payload form= at. Does anyone else has an opinion here? @Bernard: Note that changing of "S" the middle of "SST" and "MST" from "ses= sion" to "stream" in the HEVC payload draft was a result from one of your s= uggestions. @Bernard and Alex: It is just editorial, I don't understand why it is relev= ant to mention whether something has been implemented or not - you implemen= t techniques not editorial terms - unless you meant "implemented or deploye= d in specifications". Anyway, I hope you guys can converge on the terms soon. BR, YK From: Alex Eleftheriadis [mailto:alex@vidyo.com] Sent: Thursday, May 01, 2014 2:44 AM To: Bernard Aboba Cc: Wang, Ye-Kui; Bo Burman; avtext@ietf.org Subject: Re: [avtext] Proposed RTP Taxonomy updates I agree with Bernard. There is now both SST-MS and SST-SS widely deployed b= ut, more importantly, the concepts are truly distinct. So we should not "ov= erload" SST to always mean one or the other. W.r.t. the HEVC payload spec, I would argue that redefining it there to mea= n stream rather than session, as it does in the H.264 spec, should be serio= usly reconsidered. As someone who, for many years, has tried to explain these architectures to= several people, a lot of them technically very very knowledgeable, I have = found the lack of appropriate commonly accepted terminology a serious imped= iment. Now that these architectures are investigated very extensively, we = have a great opportunity to fix that and do it the right way. Redefining ac= ronyms, and particularly in the same series of specifications, is imho goin= g in the exactly opposite direction. Maybe we can use something like "configuration": Single Stream Configuratio= n (SSC) and Multi-Stream Configuration (MSC). They describe how the layers = are configured for transmission, not how they are transmitted. The transmis= sion part comes next, and uses the SST and MST acronyms. That would simpli= fy potential changes to all drafts, and avoid confusion. --Alex [with apologies for not always closely following the thread] On Apr 30, 2014, at 9:39 PM, Bernard Aboba > wrote: The problem is that the single/ multiple session and single/multiple stream= dimensions are somewhat independent, and affect SFU design as well as clie= nt behavior. In particular, SST-MS has now been widely implemented, so we = cannot pretend it doesn't exist. Changing the meaning of the SST/MST abbrev= iations could potentially increase the already considerable confusion. On Apr 30, 2014, at 11:12 AM, "Wang, Ye-Kui" > wrote: Regarding the term of "RTP packet stream", "packet stream", or "RTP stream"= , I prefer "RTP stream" too. On SST/MST, note that in the latest HEVC/H.265 payload draft, we are using = "Single-Stream Transmission" and "Multi-Stream Transmission". SST here is o= bviously within one RTP session, while MST herein can involve either a sing= le or multiple RTP sessions. What is the importance of adding the suffix "-= SS" or "-MS" herein in the term? Why it is not sufficient to just use SST/M= ST with the S in the middle mean "stream"? BR, YK From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bo Burman Sent: Wednesday, April 30, 2014 4:47 AM To: Bernard Aboba Cc: avtext@ietf.org Subject: Re: [avtext] Proposed RTP Taxonomy updates With respect to leaving current SST/MST definition alone, I agree, but I th= ink there was also agreement to describe them in Taxonomy terms, without re= -defining anything. In that, "MST" and "SST" without any distinction is unclear, but should acc= ording to IETF 89 discussions typically mean "MST-SS" and "SST-SS" , which = should be described (with or without explicitly referring to any -SS and -M= S distinctions). Bernard and Alex, do I understand you correctly that you prefer to keep the= -SS and -MS distinctions? I have no problem keeping it, and I am also open= to alternative terminology describing the same thing. Do you have any prop= osals? From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: den 29 april 2014 15:49 To: Bo Burman Cc: avtext@ietf.org; Alex Eleftheriadis Subject: Re: [avtext] Proposed RTP Taxonomy updates With respect to SST/MST, as I recall, Alex's suggestion was to leave the RF= C 6190 definition alone, but also define terminology for the single/multi-s= tream distinction. For example, it is possible to have multiple streams wit= hin a single session (SST-MS). On Apr 29, 2014, at 6:27, "Bo Burman" > wrote: Hi all, Based on the AVTEXT session at IETF 88 & 89 and some mailing list discussio= ns, I propose to make the following updates to RTP Taxonomy: * In 3.2.1 clearly define what RFC 6190 terms "SST" and "MST" means= in Taxonomy terms and remove the current discussion on Single- and Multi-S= tream. * Mention in 2.2.1 under Alternate usages that an "End Point" in Ta= xonomy terms is typically a single "host" (although "host" has no unique de= finition). * Change the term "Packet Stream" throughout the document, since it= is arguably too generic: o "RTP Packet Stream" was suggested by Magnus W about a month ago and rec= eived some support. I think it is a bit long and unnecessarily redundant, s= ince RTP already implies that it is a packet o "RTP Stream" could possibly be a sufficiently precise term; what do ot= hers think? * Re-structure the document such that Alternate usages (describing = existing terms in Taxonomy wording) are separated out into their own sub-se= ctions, making it possible to find them through the table of contents o I believe this could take care of Roni Even's request at IETF 88 for an= overview table with existing terms, while avoiding the fact that the neede= d explanations will hardly fit in a table format. * Editorial: o Remove formal numberings of level 4 headings (change to body text or he= adings in body text format). Comments are welcome! Cheers, Bo _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_8BA7D4CEACFFE04BA2D902BF11719A8345249883nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Posting it to payload re= flector as well].

 <= /p>

I am fine with Alex’= ;s suggestion on Single Stream Configuration (SSC) and Multi-Stream Configu= ration (MSC) to replace SST/MST in the HEVC payload format. Does anyone else has an opinion here?

 <= /p>

@Bernard: Note that chang= ing of “S” the middle of “SST” and “MST”= ; from “session” to “stream” in the HEVC payload dr= aft was a result from one of your suggestions.

 <= /p>

@Bernard and Alex: It is = just editorial, I don’t understand why it is relevant to mention whet= her something has been implemented or not – you implement techniques not editorial terms – unless you meant “implemented or deploye= d in specifications”.

 <= /p>

Anyway, I hope you guys c= an converge on the terms soon.

 <= /p>

BR, YK<= /p>

 <= /p>

From: Alex Ele= ftheriadis [mailto:alex@vidyo.com]
Sent: Thursday, May 01, 2014 2:44 AM
To: Bernard Aboba
Cc: Wang, Ye-Kui; Bo Burman; avtext@ietf.org
Subject: Re: [avtext] Proposed RTP Taxonomy updates

 

I agree with Bernard. There is now both SST-MS and S= ST-SS widely deployed but, more importantly, the concepts are truly distinc= t. So we should not "overload" SST to always mean one or the othe= r. 

 

W.r.t. the HEVC payload spec, I would argue that red= efining it there to mean stream rather than session, as it does in the H.26= 4 spec, should be seriously reconsidered.   

 

As someone who, for many years, has tried to explain= these architectures to several people, a lot of them technically very very= knowledgeable, I have found the lack of appropriate commonly accepted term= inology a serious impediment. Now that these architectures are investigated very extensively,  we have = a great opportunity to fix that and do it the right way. Redefining acronym= s, and particularly in the same series of specifications, is imho going in = the exactly opposite direction. 

 

Maybe we can use something like "configuration&= quot;: Single Stream Configuration (SSC) and Multi-Stream Configuration (MS= C). They describe how the layers are configured for transmission, not how t= hey are transmitted. The transmission part comes next, and uses the SST and MST acronyms.  That would simplify potenti= al changes to all drafts, and avoid confusion. 

 

--Alex [with apologies for not always closely follow= ing the thread] 

 

On Apr 30, 2014, at 9:39 PM, Bernard Aboba <bernard_aboba@hotmail.com> w= rote:



The problem is that the single/ multiple = session and single/multiple stream dimensions are somewhat independent, and= affect SFU design as well as client behavior.  In particular, SST-MS has now been widely implemented, so we cannot pretend it doesn't ex= ist. Changing the meaning of the SST/MST abbreviations could potentially in= crease the already considerable confusion.


On Apr 30, 2014, at 11:12 AM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm= .com> wrote:

Regarding the term of = 220;RTP packet stream”, “packet stream”, or “RTP st= ream”,  I prefer “RTP stream” too.

 

On SST/MST, note that in = the latest HEVC/H.265 payload draft, we are using “Single-Stream Tran= smission” and “Multi-Stream Transmission”. SST here is ob= viously within one RTP session, while MST herein can involve either a single or mu= ltiple RTP sessions. What is the importance of adding the suffix “-SS= ” or “-MS” herein in the term? Why it is not sufficient t= o just use SST/MST with the S in the middle mean “stream”?

 

BR, YK

 

From: avtext [m= ailto:avtext-bounces@ietf.org] On Behalf Of = ;Bo Burman
Sent: Wednesday, A= pril 30, 2014 4:47 AM
To: Bernard Aboba<= br> Cc: avtext@ietf.org
Subject: Re: [avte= xt] Proposed RTP Taxonomy updates

 

With respect to leaving c= urrent SST/MST definition alone, I agree, but I think there was also agreem= ent to describe them in Taxonomy terms, without re-defining anything.

 

In that, “MST”= ; and “SST” without any distinction is unclear, but should acco= rding to IETF 89 discussions typically mean “MST-SS” and “= ;SST-SS” , which should be described (with or without explicitly referring to any –SS and &#= 8211;MS distinctions).

 

Bernard and Alex, do I un= derstand you correctly that you prefer to keep the –SS and –MS = distinctions? I have no problem keeping it, and I am also open to alternati= ve terminology describing the same thing. Do you have any proposals?

 

 

 

With respect to SST/MST, as I recall, A= lex's suggestion was to leave the RFC 6190 definition alone, but also defin= e terminology for the single/multi-stream distinction. For example, it is possible to have multiple streams within a single session (= SST-MS).

Hi all,

 

Based on the AVTEXT session at IETF 88 = & 89 and some mailing list discussions, I propose to make the following= updates to RTP Taxonomy:

·         In 3.2.1 clearly define what RFC 6190 terms “SST” and “MST&= #8221; means in Taxonomy terms and remove the current discussion on Single-= and Multi-Stream.

·         Mention in 2.2.1 under Alternate usages that an “End Point” in Taxonom= y terms is typically a single “host” (although “host̶= 1; has no unique definition).

·         Change the term “Packet Stream” throughout the document, since it is = arguably too generic:

o   <= /span>“RTP Packet Stream” was suggested by Magnus W about a month ago and recei= ved some support. I think it is a bit long and unnecessarily redundant, sin= ce RTP already implies that it is a packet

o   <= /span> “RTP Stream” could possibly be a sufficiently precise term; what do other= s think?

·         Re-structure the document such that Alternate usages (describing existing terms in Taxo= nomy wording) are separated out into their own sub-sections, making it poss= ible to find them through the table of contents

o   <= /span>I believe this could take care of Roni Even’s request at IETF 88 for a= n overview table with existing terms, while avoiding the fact that the need= ed explanations will hardly fit in a table format.

·         Editorial:

o   <= /span>Remove formal numberings of level 4 headings (change to body text or headings in = body text format).

 

Comments are welcome!=

 

Cheers,

Bo

 

_______________________________________________
avtext mailing list
avtext@ietf= .org
https://www.ietf.org/mailman/listinfo/avtext

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A8345249883nasanexd02fnaqu_-- From nobody Mon May 5 00:23:28 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 4A2C61A0275 for ; Mon, 5 May 2014 00:23:26 -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 XjOkmDMMRAz6 for ; Mon, 5 May 2014 00:23:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7F81A0019 for ; Mon, 5 May 2014 00:23:24 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-75-53673c687547 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 22.34.04714.86C37635; Mon, 5 May 2014 09:23:20 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.216]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Mon, 5 May 2014 09:23:19 +0200 From: Bo Burman To: Bernard Aboba Thread-Topic: [avtext] Proposed RTP Taxonomy updates Thread-Index: Ac9eyJwZU1yGeu96Tu+aOoOxWGE6dgE2F9AAADFjXgAAMMogAADCFVsg Date: Mon, 5 May 2014 07:23:18 +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.16] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E1E242DESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3RjfDJj3YYPUlYYvrO9eyWHy8d4PV Yv+Sy8wOzB6Pe86weSxZ8pPJo+3ZHfYA5igum5TUnMyy1CJ9uwSujJtrDrMVHHCv2Pv6E3sD 4wHXLkZODgkBE4kP606yQthiEhfurWfrYuTiEBI4yihxteUqK4SzmFFi58VLbCBVbAIaEvN3 3GXsYuTgEBHQlfjbZQQSZhbwkZj74D7YIGEBY4mdh/eB2SJAC/5unMwMYbtJrDiwkwWklUVA ReLho2CQMK+Ar8SGR29ZIFZ9Z5RYMWEGO0iCU8BW4v252UwgNqOArMT97/dYIHaJS9x6Mp8J 4mgBiSV7zjND2KISLx//g3pGUWLn2XZmiPp8iU3/VjJCLBOUODnzCcsERtFZSEbNQlI2C0nZ LKBTmQU0Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OLi3HQjY73Uoszk4uL8PL28 1JJNjMAIPLjlt+4OxtWvHQ8xCnAwKvHwFn+JDBZiTSwrrsw9xCjNwaIkztt21ztYSCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA+O0qd93ub73PC6bO/mF47t9S+KZGiRTm/qdfpn+N/ZNr774 zzRk9017xSQer8zQh+t+7jnS6e72g1vgetz9qwu3nSo5xvdpr1PnzZVMs703TnkwfaK39jlO bkumy97a+ebTGHesTuDclrMs4Z+Ji9Lsjd2zDH+Y+bSvWDDp063VBmXOXrGxpXOUWIozEg21 mIuKEwFedsI8oQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/TefaT2jQJn2xSfSDWnyTC1X1c8g Cc: "avtext@ietf.org" Subject: Re: [avtext] Proposed RTP Taxonomy 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: Mon, 05 May 2014 07:23:26 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E1E242DESESSMB105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB3ZSBtYXkgaGF2ZSBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zIG9mIE1TVC1TUz8g VG8gbWUsIE1TVC1TUyBpcyBtdWx0aXBsZSBSVFAgU2Vzc2lvbnMsIGVhY2ggd2l0aCBhIHNpbmds ZSBzdHJlYW0uIEkgZG9u4oCZdCBzZWUgYW55IHJlcXVpcmVtZW50IHRoYXQgdGhvc2Ugc3RyZWFt cyBuZWNlc3NhcmlseSB1c2UgdGhlIHNhbWUgU1NSQyB2YWx1ZS4gV2h5IGRvIHlvdSBtYWtlIHRo YXQgYXNzdW1wdGlvbj8NCg0KU28gdG8gY2xhcmlmeSBldmVuIGZ1cnRoZXIsIHdoZW4gc3VnZ2Vz dGluZyBNU1QtTVMsIGRvIHlvdSBtZWFuIHRoYXQgdGhlIGN1cnJlbnQgbWFpbiB1c2Ugb2Yg4oCc TVNU4oCdIGlzIG11bHRpcGxlIFJUUCBTZXNzaW9ucywgZWFjaCB3aXRoIG11bHRpcGxlIHN0cmVh bXMgdXNpbmcgZGlmZmVyZW50IFNTUkM/DQoNCkZyb206IEJlcm5hcmQgQWJvYmEgW21haWx0bzpi ZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tXQ0KU2VudDogZGVuIDEgbWFqIDIwMTQgMTQ6NDANClRv OiBCbyBCdXJtYW4NCkNjOiBhdnRleHRAaWV0Zi5vcmc7IEFsZXggRWxlZnRoZXJpYWRpcw0KU3Vi amVjdDogUmU6IFthdnRleHRdIFByb3Bvc2VkIFJUUCBUYXhvbm9teSB1cGRhdGVzDQoNCk9uIEFw ciAzMCwgMjAxNCwgYXQgNDo0NywgIkJvIEJ1cm1hbiIgPGJvLmJ1cm1hbkBlcmljc3Nvbi5jb208 bWFpbHRvOmJvLmJ1cm1hbkBlcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KV2l0aCByZXNwZWN0IHRv IGxlYXZpbmcgY3VycmVudCBTU1QvTVNUIGRlZmluaXRpb24gYWxvbmUsIEkgYWdyZWUsIGJ1dCBJ IHRoaW5rIHRoZXJlIHdhcyBhbHNvIGFncmVlbWVudCB0byBkZXNjcmliZSB0aGVtIGluIFRheG9u b215IHRlcm1zLCB3aXRob3V0IHJlLWRlZmluaW5nIGFueXRoaW5nLg0KDQpJbiB0aGF0LCDigJxN U1TigJ0gYW5kIOKAnFNTVOKAnSB3aXRob3V0IGFueSBkaXN0aW5jdGlvbiBpcyB1bmNsZWFyLCBi dXQgc2hvdWxkIGFjY29yZGluZyB0byBJRVRGIDg5IGRpc2N1c3Npb25zIHR5cGljYWxseSBtZWFu IOKAnE1TVC1TU+KAnSBhbmQg4oCcU1NULVNT4oCdICwgd2hpY2ggc2hvdWxkIGJlIGRlc2NyaWJl ZCAod2l0aCBvciB3aXRob3V0IGV4cGxpY2l0bHkgcmVmZXJyaW5nIHRvIGFueSDigJNTUyBhbmQg 4oCTTVMgZGlzdGluY3Rpb25zKS4NCg0KSSBkbyBub3QgYmVsaWV2ZSB0aGF0IE1TVC1TUyBtYWtl cyBzZW5zZSAtIGl0IHdvdWxkIGltcGx5IHVzZSBvZiB0aGUgc2FtZSBTU1JDIGluIG11bHRpcGxl IHNlc3Npb25zLiBTaW5jZSBTU1JDIGNvbGxpc2lvbnMgYXJlIGRldGVjdGVkIHdpdGhpbiBhIHNl c3Npb24sIHRoZSBTU1JDIGNvdWxkIGNoYW5nZSBpbiBvbmUgc2Vzc2lvbiwgYW5kIG5vdCBhbm90 aGVyLiBTbyBNU1QtTVMgbWFrZXMgbW9yZSBzZW5zZS4NCg== --_000_BBE9739C2C302046BD34B42713A1E2A22E1E242DESESSMB105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9t OjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHdlIG1heSBoYXZlIGRpZmZlcmVudCBpbnRlcnBy ZXRhdGlvbnMgb2YgTVNULVNTPyBUbyBtZSwgTVNULVNTIGlzIG11bHRpcGxlIFJUUCBTZXNzaW9u cywgZWFjaCB3aXRoIGEgc2luZ2xlIHN0cmVhbS4gSSBkb27igJl0IHNlZSBhbnkgcmVxdWlyZW1l bnQgdGhhdCB0aG9zZSBzdHJlYW1zIG5lY2Vzc2FyaWx5IHVzZSB0aGUgc2FtZSBTU1JDIHZhbHVl Lg0KIFdoeSBkbyB5b3UgbWFrZSB0aGF0IGFzc3VtcHRpb24/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5TbyB0byBjbGFyaWZ5IGV2ZW4gZnVydGhlciwgd2hlbiBzdWdnZXN0 aW5nIE1TVC1NUywgZG8geW91IG1lYW4gdGhhdCB0aGUgY3VycmVudCBtYWluIHVzZSBvZiDigJxN U1TigJ0gaXMgbXVsdGlwbGUgUlRQIFNlc3Npb25zLCBlYWNoIHdpdGggbXVsdGlwbGUgc3RyZWFt cyB1c2luZyBkaWZmZXJlbnQgU1NSQz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQmVy bmFyZCBBYm9iYSBbbWFpbHRvOmJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gZGVuIDEgbWFqIDIwMTQgMTQ6NDA8YnI+DQo8Yj5Ubzo8L2I+IEJvIEJ1cm1hbjxi cj4NCjxiPkNjOjwvYj4gYXZ0ZXh0QGlldGYub3JnOyBBbGV4IEVsZWZ0aGVyaWFkaXM8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFthdnRleHRdIFByb3Bvc2VkIFJUUCBUYXhvbm9teSB1cGRhdGVz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEFwciAzMCwgMjAxNCwgYXQgNDo0NywgJnF1b3Q7Qm8gQnVybWFuJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86Ym8uYnVybWFuQGVyaWNzc29uLmNvbSI+Ym8uYnVybWFuQGVyaWNzc29uLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XaXRoIHJlc3BlY3QgdG8g bGVhdmluZyBjdXJyZW50IFNTVC9NU1QgZGVmaW5pdGlvbiBhbG9uZSwgSSBhZ3JlZSwgYnV0IEkg dGhpbmsgdGhlcmUgd2FzIGFsc28gYWdyZWVtZW50IHRvIGRlc2NyaWJlIHRoZW0gaW4gVGF4b25v bXkgdGVybXMsIHdpdGhvdXQgcmUtZGVmaW5pbmcgYW55dGhpbmcuDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIHRoYXQsIOKAnE1TVOKAnSBhbmQg4oCcU1NU4oCdIHdp dGhvdXQgYW55IGRpc3RpbmN0aW9uIGlzIHVuY2xlYXIsIGJ1dCBzaG91bGQgYWNjb3JkaW5nIHRv IElFVEYgODkgZGlzY3Vzc2lvbnMgdHlwaWNhbGx5IG1lYW4g4oCcTVNULVNT4oCdIGFuZCDigJxT U1QtU1PigJ0gLCB3aGljaCBzaG91bGQgYmUgZGVzY3JpYmVkICh3aXRoIG9yIHdpdGhvdXQgZXhw bGljaXRseSByZWZlcnJpbmcNCiB0byBhbnkg4oCTU1MgYW5kIOKAk01TIGRpc3RpbmN0aW9ucyku PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgZG8gbm90IGJlbGlldmUgdGhhdCBN U1QtU1MgbWFrZXMgc2Vuc2UgLSBpdCB3b3VsZCBpbXBseSB1c2Ugb2YgdGhlIHNhbWUgU1NSQyBp biBtdWx0aXBsZSBzZXNzaW9ucy4gU2luY2UgU1NSQyBjb2xsaXNpb25zIGFyZSBkZXRlY3RlZCB3 aXRoaW4gYSBzZXNzaW9uLCB0aGUgU1NSQyBjb3VsZA0KIGNoYW5nZSBpbiBvbmUgc2Vzc2lvbiwg YW5kIG5vdCBhbm90aGVyLiBTbyBNU1QtTVMgbWFrZXMgbW9yZSBzZW5zZS4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_BBE9739C2C302046BD34B42713A1E2A22E1E242DESESSMB105erics_-- From nobody Mon May 5 01:16:14 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 9734C1A0289 for ; Mon, 5 May 2014 01:16:12 -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 UuI_PvEP_LLR for ; Mon, 5 May 2014 01:16:11 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 731E11A0283 for ; Mon, 5 May 2014 01:16:10 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-88-536748c67433 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F7.21.04199.6C847635; Mon, 5 May 2014 10:16:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.174.1; Mon, 5 May 2014 10:16:05 +0200 Message-ID: <536748C5.6070603@ericsson.com> Date: Mon, 5 May 2014 10:16:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Bo Burman , Bernard Aboba References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvje4xj/Rgg81bJS0+3rvBarF/yWVm ByaPxz1n2DyWLPnJFMAUxWWTkpqTWZZapG+XwJUxa+ExloIemYrm2ekNjO2iXYycHBICJhKr trewQthiEhfurWfrYuTiEBI4yihxZ8EDJghnGaPE/u4t7CBVvALaElenPGIEsVkEVCSmLtrE DGKzCVhI3PzRyAZiiwoES2x4+BeqXlDi5MwnLCC2CFB8zY99YDXMAuoSh/ctAZsjLGAs8Wv7 eqhlm5kkTrxcBVTEwcEp4Cfx43I9iCkhIC7R0xgE0WogcWTRHFYIW16ieetssBOEgE5raOpg ncAoNAvJ5llIWmYhaVnAyLyKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCID275bbCD8eVz x0OMAhyMSjy8xV8ig4VYE8uKK3MPMUpzsCiJ83476x4sJJCeWJKanZpakFoUX1Sak1p8iJGJ g1OqgbHG26Dna6rJbaEJPXvdXPbvv7zZIXChwBsHidoZ1c7Kv01cPp3SndVrYbfBmrH1HF+p jbr3+2iDsODIp1Vb64OSL8tf+rXgW8wThWaZr3m7OGdMP1YmYrvz4BH9CxGuLUpJ4ZIGjX4v gz1q+XZfFhKp2bWP6WWXsYoq/wbzpz+Sngj7MlY3KLEUZyQaajEXFScCAGiaPz9DAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/t5N3Ri1q2p9-QZVffwisBCYBMqc Cc: "avtext@ietf.org" Subject: Re: [avtext] Proposed RTP Taxonomy 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: Mon, 05 May 2014 08:16:13 -0000 Hi, The definitions of the MST-SS that exist is based on this matrix from the current taxonomy draft: +-----------------------+--------------------+----------------------+ | | Single RTP Session | Multiple RTP | | | | Sessions | +-----------------------+--------------------+----------------------+ | Single Packet Stream | SST-SS | MST-SS | | Multiple Packet | SST-MS | MST-MS | | Streams | | | +-----------------------+--------------------+----------------------+ Which means that MST-SS is a single packet stream per RTP session, but that multiple RTP sessions are used to spread the encoded stream and is dependent streams over. The intention was not to restrict the SSRC in these different RTP sessions, rather if one is supporting this mode of operation, I think the solution MUST be capable of handling different SSRCs in the various RTP sessions. If not one ends up with some inter session dependencies, especially how SSRC collision effects the various sessions. I will note that if one redefines MST to means Multiple Stream Transmission, then SST-MS must also be changed. Cheers Magnus On 2014-05-05 09:23, Bo Burman wrote: > I think we may have different interpretations of MST-SS? To me, MST-SS > is multiple RTP Sessions, each with a single stream. I don’t see any > requirement that those streams necessarily use the same SSRC value. Why > do you make that assumption? > > > > So to clarify even further, when suggesting MST-MS, do you mean that the > current main use of “MST” is multiple RTP Sessions, each with multiple > streams using different SSRC? > > > > *From:*Bernard Aboba [mailto:bernard_aboba@hotmail.com] > *Sent:* den 1 maj 2014 14:40 > *To:* Bo Burman > *Cc:* avtext@ietf.org; Alex Eleftheriadis > *Subject:* Re: [avtext] Proposed RTP Taxonomy updates > > > > On Apr 30, 2014, at 4:47, "Bo Burman" > wrote: > > > > With respect to leaving current SST/MST definition alone, I agree, > but I think there was also agreement to describe them in Taxonomy > terms, without re-defining anything. > > > > In that, “MST” and “SST” without any distinction is unclear, but > should according to IETF 89 discussions typically mean “MST-SS” and > “SST-SS” , which should be described (with or without explicitly > referring to any –SS and –MS distinctions). > > > > I do not believe that MST-SS makes sense - it would imply use of the > same SSRC in multiple sessions. Since SSRC collisions are detected > within a session, the SSRC could change in one session, and not another. > So MST-MS makes more sense. > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed May 7 08:00: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 330B91A00DF for ; Wed, 7 May 2014 08:00:03 -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 BRGZDISD1cOe for ; Wed, 7 May 2014 07:59:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AE9CF1A0092 for ; Wed, 7 May 2014 07:59:56 -0700 (PDT) X-AuditID: c1b4fb25-f798c6d000001521-c5-536a4a67f4e8 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 92.D6.05409.76A4A635; Wed, 7 May 2014 16:59:51 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.216]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Wed, 7 May 2014 16:59:51 +0200 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: Add term for streams sharing a 5-tuple to Taxonomy? Thread-Index: Ac9p6CXWFHOtBVkySFWoTs3nalvRIQ== Date: Wed, 7 May 2014 14:59:50 +0000 Message-ID: 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: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E1E3C15ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW66V1awwe9PxhYf791gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtNTG9kLPolXtEzJbmBsE+1i5OSQEDCRuLf2KxuELSZx4d56 IJuLQ0jgKKPEtsatLBDOYkaJg+ePMYJUsQloSMzfcRfMFhFQl7gz/QJQBweHsICNxLXbdhBh R4k7U7awQ9h6EofvvQYrZxFQkfjf+wBsGa+Ar8TLq/tYQWxGAVmJ+9/vsYDYzALiEreezGeC OEhAYsme88wQtqjEy8f/WCFsRYmPr/YxQtTnS2xqWs4IMVNQ4uTMJywTGIVmIRk1C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZG YEQc3PJbdQfj5TeOhxgFOBiVeHgfvMoIFmJNLCuuzD3EKM3BoiTO++WWT7CQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGRq7eyRbW/cdvG4U/2bvOJHdO+IUXrzsrn729r+9+el1P3n3mpEfJ LVM+9IQeOJL+hGm2VPNk+3UHJG9s1bR8/X7WC18lufXe2p7ncx9Nioz6/eD9xMUPE2Zyixqs KX8UdWbdFrbAlzsrHOPrOCSZC1d869a3Ovzt0LQ5U38ZdNRPXZA1rTE0c4MSS3FGoqEWc1Fx IgAK3YmUaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/vQbBVelAsTzGOXC09GUeqDZSrFY Subject: [avtext] Add term for streams sharing a 5-tuple to 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, 07 May 2014 15:00:03 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E1E3C15ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Is there an interest or need to add a term to the RTP Taxonomy that denotes= the set of (in current -01 taxonomy terms) "Sent Packet Streams" that shar= e a common 5-tuple? If so, is a suitable term "Transport Flow", or something else? Let me know what you think! Cheers, Bo --_000_BBE9739C2C302046BD34B42713A1E2A22E1E3C15ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Is there an interest or need to add a term to the RT= P Taxonomy that denotes the set of (in current -01 taxonomy terms) “S= ent Packet Streams” that share a common 5-tuple?

 

If so, is a suitable term “Transport Flow̶= 1;, or something else?

 

Let me know what you think!

 

Cheers,

Bo

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E1E3C15ESESSMB105erics_-- From nobody Thu May 15 07:53:40 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 0BE7A1A00BE for ; Thu, 15 May 2014 07:53:39 -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_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 HgnqCvdKtRiA for ; Thu, 15 May 2014 07:53:37 -0700 (PDT) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C873A1A00BD for ; Thu, 15 May 2014 07:53:37 -0700 (PDT) X-Note-AR-ScanTimeLocal: 5/15/2014 10:53:24 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-148/SG:2 5/15/2014 10:52:28 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.884594 p=-0.97905 Source White X-Signature-Violations: 0-0-0-2966-c X-Note-419: 15.6002 ms. Fail:0 Chk:1340 of 1340 total X-Note: SCH-CT/SI:0-1340/SG:1 5/15/2014 10:53:20 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: G327 G328 G329 G330 G334 G335 G445 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 97378935 for avtext@ietf.org; Thu, 15 May 2014 10:53:24 -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.0146.000; Thu, 15 May 2014 09:53:23 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Call for confirmation of consensus: WG adoption of draft-westerlund-avtext-rtp-stream-pause Thread-Index: AQHPXoAYWtqXwZQVXECGHOpIVJEPBptCMaeA Date: Thu, 15 May 2014 14:53:23 +0000 Message-ID: <88CC7529-EF6E-440D-84E5-8F11AF9D5FB7@vidyo.com> References: <957D42D5-894D-4A35-88E8-320C890E65F9@vidyo.com> In-Reply-To: <957D42D5-894D-4A35-88E8-320C890E65F9@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: <0DC6C46AABD2BF4293C505EE180BDEE5@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/KjsxbKAj97RrdtIzUtusnD8g06s Subject: Re: [avtext] Call for confirmation of consensus: WG adoption of draft-westerlund-avtext-rtp-stream-pause 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, 15 May 2014 14:53:39 -0000 On Apr 22, 2014, at 7:10 PM, Jonathan Lennox wrote: > Hi, all =97 >=20 > AVTExt's milestone for RTP Pause & Resume has been approved. >=20 > In the WG session in London, we had consensus that the group would adopt = draft-westerlund-avtext-rtp-stream-pause-05 as the basis of an initial Work= ing Group draft towards this milestone. >=20 > I would like to put out a two-week call for confirmation of this consensu= s. If you didn=92t provide input at the meeting at London =97 or if your o= pinion has changed =97 please provide your support or objection to the adop= tion of this draft, for this milestone, no later than May 6th. This consensus is confirmed (I have heard no disagreements). Authors, please submit draft-westerlund-avtext-rtp-stream-pause-05 verbatim= as draft-ietf-avtext-rtp-stream-pause-00. Thank you! Jonathan From nobody Fri May 16 00:06:05 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 C9C441A01A0; Fri, 16 May 2014 00:06:02 -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 2snK8T-TDG4G; Fri, 16 May 2014 00:06:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 916641A0197; Fri, 16 May 2014 00:06:01 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140516070601.24095.88442.idtracker@ietfa.amsl.com> Date: Fri, 16 May 2014 00:06:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/ycgL31D5-D0lIGk8aZCec2cH70Q Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-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: Fri, 16 May 2014 07:06:03 -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 Media Stream Pause and Resume Authors : Azam Akram Bo Burman Roni Even Magnus Westerlund Filename : draft-ietf-avtext-rtp-stream-pause-00.txt Pages : 54 Date : 2014-05-16 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-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/