From internet-drafts@ietf.org Fri Feb 7 07:26:29 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 0DAAC1A8033; Fri, 7 Feb 2014 07:26:29 -0800 (PST) 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 M24HVqZur7rl; Fri, 7 Feb 2014 07:26:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAED1AC49D; Fri, 7 Feb 2014 07:26:23 -0800 (PST) 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.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207152623.11584.94176.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 07:26:23 -0800 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-duplication-05.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, 07 Feb 2014 15:26:29 -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 : Duplicating RTP Streams Authors : Ali Begen Colin Perkins Filename : draft-ietf-avtext-rtp-duplication-05.txt Pages : 12 Date : 2014-02-07 Abstract: Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-duplication-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-duplication-05 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 abegen@cisco.com Fri Feb 7 07:34:04 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 17AA61AC3DD for ; Fri, 7 Feb 2014 07:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, 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 5dUzlk18nEIk for ; Fri, 7 Feb 2014 07:34:02 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2E58E1A802A for ; Fri, 7 Feb 2014 07:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3076; q=dns/txt; s=iport; t=1391787242; x=1392996842; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jPArwuFovr0MumIibfB9YIiUSVf+AysHUVWGGxweuHo=; b=K+PfjgyeNdVWywhVCfYaH+EMkXWT7Wy9ZUdioFZIEENMPBHOeMM6AYxs idCMnB8c2KfGn9H1cKW225cb5BV1YYE6dxJDM/JoPfIAudae/TX9pdxyT tOknyBP/Ef26u6SbLVi0LRdiEIK7MYYfF2yrmkkyvm4jiCN+/5kasWsAc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4GAMv79FKtJXHB/2dsb2JhbABZgmshOFEGgwG7GE8YdhZ0giUBAQEEAQEBIBE6FwQCAQgRAwECAwImAgICJQsVCAgCBBMJh3wBBwWrNaEVF4EpjSE6BoJpgUkEmCuBMpBvgy2CKg X-IronPort-AV: E=Sophos;i="4.95,801,1384300800"; d="scan'208";a="18754971" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-5.cisco.com with ESMTP; 07 Feb 2014 15:34:01 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s17FY1DM002347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Feb 2014 15:34:01 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 09:34:01 -0600 From: "Ali C. Begen (abegen)" To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-duplication-05.txt Thread-Index: AQHPJBkGNJbtdYsfo0yTuuGt+DvsSZqqcfMA Date: Fri, 7 Feb 2014 15:34:00 +0000 Message-ID: References: <20140207152623.11584.94176.idtracker@ietfa.amsl.com> In-Reply-To: <20140207152623.11584.94176.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.86.246.87] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-duplication-05.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, 07 Feb 2014 15:34:04 -0000 VGhpcyBpcyB0byB1cGRhdGUgY29tbWVudHMgZnJvbSBJRVRGIExDLiBXZSBzaG91bGQgYmUgYWxs IHNldCBmb3IgdGhlIElFU0cNCnJldmlldy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206ICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDcsIDIwMTQgYXQgNToyNiBQTQ0KVG86ICJpLWQt YW5ub3VuY2VAaWV0Zi5vcmciIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpDYzogImF2dGV4dEBp ZXRmLm9yZyIgPGF2dGV4dEBpZXRmLm9yZz4NClN1YmplY3Q6IFthdnRleHRdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtYXZ0ZXh0LXJ0cC1kdXBsaWNhdGlvbi0wNS50eHQNCg0KPg0KPkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cw0KPmRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBdWRp by9WaWRlbyBUcmFuc3BvcnQgRXh0ZW5zaW9ucw0KPldvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYu DQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBEdXBsaWNhdGluZyBSVFAgU3RyZWFtcw0K PiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQWxpIEJlZ2VuDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICBDb2xpbiBQZXJraW5zDQo+CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYXZ0 ZXh0LXJ0cC1kdXBsaWNhdGlvbi0wNS50eHQNCj4JUGFnZXMgICAgICAgICAgIDogMTINCj4JRGF0 ZSAgICAgICAgICAgIDogMjAxNC0wMi0wNw0KPg0KPkFic3RyYWN0Og0KPiAgIFBhY2tldCBsb3Nz IGlzIHVuZGVzaXJhYmxlIGZvciByZWFsLXRpbWUgbXVsdGltZWRpYSBzZXNzaW9ucywgYnV0IGNh bg0KPiAgIG9jY3VyIGR1ZSB0byBjb25nZXN0aW9uLCBvciBvdGhlciB1bnBsYW5uZWQgbmV0d29y ayBvdXRhZ2VzLiAgVGhpcyBpcw0KPiAgIGVzcGVjaWFsbHkgdHJ1ZSBmb3IgSVAgbXVsdGljYXN0 IG5ldHdvcmtzLCB3aGVyZSBwYWNrZXQgbG9zcyBwYXR0ZXJucw0KPiAgIGNhbiB2YXJ5IGdyZWF0 bHkgYmV0d2VlbiByZWNlaXZlcnMuICBPbmUgdGVjaG5pcXVlIHRoYXQgY2FuIGJlIHVzZWQNCj4g ICB0byByZWNvdmVyIGZyb20gcGFja2V0IGxvc3Mgd2l0aG91dCBpbmN1cnJpbmcgdW5ib3VuZGVk IGRlbGF5IGZvciBhbGwNCj4gICB0aGUgcmVjZWl2ZXJzIGlzIHRvIGR1cGxpY2F0ZSB0aGUgcGFj a2V0cyBhbmQgc2VuZCB0aGVtIGluIHNlcGFyYXRlDQo+ICAgcmVkdW5kYW50IHN0cmVhbXMuICBU aGlzIGRvY3VtZW50IGV4cGxhaW5zIGhvdyBSZWFsLXRpbWUgVHJhbnNwb3J0DQo+ICAgUHJvdG9j b2wgKFJUUCkgc3RyZWFtcyBjYW4gYmUgZHVwbGljYXRlZCB3aXRob3V0IGJyZWFraW5nIFJUUCBv ciBSVFANCj4gICBDb250cm9sIFByb3RvY29sIChSVENQKSBydWxlcy4NCj4NCj4NCj5UaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGV4dC1ydHAtZHVwbGljYXRpb24v DQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hdnRleHQtcnRwLWR1cGxpY2F0aW9u LTA1DQo+DQo+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYXZ0ZXh0LXJ0 cC1kdXBsaWNhdGlvbi0wNQ0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0KPnVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5hdnRleHQgbWFpbGlu ZyBsaXN0DQo+YXZ0ZXh0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hdnRleHQNCj4NCg0KDQo= From bo.burman@ericsson.com Tue Feb 11 08:41: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 8CE491A0548 for ; Tue, 11 Feb 2014 08:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 doqcgv4NbOHA for ; Tue, 11 Feb 2014 08:41:08 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 64E9D1A01A8 for ; Tue, 11 Feb 2014 08:41:04 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-c5-52fa529ebe0c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id E1.C8.04853.E925AF25; Tue, 11 Feb 2014 17:41:03 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.223]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 17:41:02 +0100 From: Bo Burman To: Alex Eleftheriadis , "avtext@ietf.org" Thread-Topic: [AVTCORE] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: Ac8dU7mieb6dcTfdT9S2qN1Oa7QzawAmN6QAAlUk8+A= Date: Tue, 11 Feb 2014 16:41:01 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B125741@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvje78oF9BBg8bWSyu71zLYvHx3g1W ByaPJUt+Mnm0PbvDHsAUxWWTkpqTWZZapG+XwJVx9/5r9oKb+hVH1p5kbWC8p9bFyMkhIWAi sffFL3YIW0ziwr31bF2MXBxCAicYJa79n80M4SxhlOh8dYYJpIpNQENi/o67jCC2iICPxKwz 88DiwgKOElPv7GGHiDtJ9B7qYYawrSQOHf7FAmKzCKhKLJv8FSjOwcEr4Ctxs0ELJCwk0Mso cX95MUiYU8BW4uW5YJAwo4CsxP3v98A6mQXEJW49mc8EcaeAxJI955khbFGJl4//sULYShI/ NlyCqteRWLD7ExuErS2xbOFrsHpeAUGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNkcWpx cW66kYFebnpuiV5qUWZycXF+nl5x6iZGYLQc3PLbaAfjyT32hxilOViUxHmvs9YECQmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamBkLrfXUj1lVB0RfCTkae+XNX/vFC88U2q6ZPv9T+KXl0Z4 XD/OVpUv8Zjx0rHXG0p+8M1tmhPv5XD7ENv2H4dZkut6lcsWfX+gqbvq5sNsB6N1fttjpnR8 /pH+pUTiaGmdv4Vbm9nHp5Nm/tVcIPmk4qt7f7yIRWKs0Bub+6LdZdY73IL6Cw8osRRnJBpq MRcVJwIARE75KmQCAAA= Subject: Re: [avtext] [AVTCORE] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 11 Feb 2014 16:41:11 -0000 Hi Alex, > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Alex Eleftheri= adis > Sent: den 30 januari 2014 20:54 > To: avtext@ietf.org > Subject: Re: [avtext] [AVTCORE] draft-ietf-avtext-rtp-grouping-taxonomy-0= 0 >=20 [snip] > I did a quick read-through. Comments below; hope they are useful. [BoB] Thank you, yes they were indeed useful! >=20 > --- >=20 > 2.1 Media Chain >=20 > I would take the first sentence of 2.1, Media Chain, and use it to define= media: "a sequence of physical world stimulus > represented in digital form" [BoB] Agree. What about starting 2.1 with: In the context of this memo, Media is a sequence of synthetic or Physical S= timulus (sound waves, photons, key-strokes), represented in digital form. S= ynthesized Media is typically generated directly in the digital domain. This section contains the concepts that can be involved in taking Media at = a sender side... > It is not evident from the text, but it should be recognized that it is p= ossible to have a a Media Source without a Physical > Stimulus and associated Media Capture. Computer-generated content would = fall under this category. [BoB] Agree. I added explicit mentioning of "synthetic" in the definition o= f Media above. I also suggest adding something like "A Raw Stream can also = contain synthesized Media that may not require any explicit Media Capture, = since it is already in an appropriate digital form" at the end of Raw Strea= m section, which I hope should take care of your comment. Do you believe it= is important to explicitly mention "computer-generated", since there are o= ther media-generating devices than "computers"? > 2.1.1 Physical Stimulus >=20 > The definition does not need to use the receiver. Also, the word "capture= " is ambiguous. You probably mean measured > using an appropriate sensor/transducer and converted in digital form. [BoB] Again, agree. I'll remove any mentioning of a receiver and replace "c= apture" with your proposed text. > 2.1.2 Media Capture >=20 > Should not use "captured" in the definition itself (circular definition).= I would use: "The process of transforming the > Physical Stimulus into digital form using an appropriate sensor/transduce= r." [BoB] Good proposal. > 2.1.6 Media Encoder >=20 > In addition to hierarchical encoding, such as the one used in H.264 SVC, = it is also possible to have what is called multiple > description coding. In this case you have two independently encoded strea= ms, each one complementing the other. One > simple example would be taken the even and odd samples of an audio stream= , and forming two independently encoded > audio streams (each at half the sampling rate). If you receive either you= can decode; if you receive both you can decode > at full quality. >=20 > The section should also mention that for completeness. I am not aware of = any commercially available encoder that uses > MDC today. [BoB] OK. I believe it could increase understanding of the concepts we try = to describe. What about adding: " There are also other variants of encoders, like so-called Multiple Descri= ption Coding (MDC). Such Media Encoder produce multiple independent and thu= s individually decodable Encoded Streams that are possible to combine into = a Received Source Stream that is somehow a better representation of the ori= ginal Source Stream than using only a single Encoded Stream"? > 2.1.9 Media Packetizer >=20 > The terms SST and MST were defined as Single Session Transmission and Mul= ti-Session Transmission, respectively, in RFC > 6190. I understand the arguments for switching session with stream, but I= think re-defining them now only creates > confusion (plus the new terms do not appear to be drop-in replacements fo= r RFC 6190 anyway, since Multi-Session in > Single-Stream was not anticipated in RFC 6190). [BoB] We already have a separate section describing SST (3.2.1). What about= keeping the Media Packetizer text simple, mentioning SST just as an exampl= e without describing it further and cross-referencing the section 3 text? I= think we should then do the same for MST, which would require adding anoth= er short section in section 3 for that. In the SST and MST sections, their = specific assumptions on use of RTP Sessions could be described and that com= plicating aspect could then be kept out of the text in Media Packetizer sec= tion. The 6190 "omission" of MST in a single RTP Session could then also be= mentioned in section 3, maybe in one of the SST or MST sections. > 2.1.20 Media Decoder >=20 > The way the system is presented, with 2.1.18 Media Depacketizer as an ind= ependent component, you do not foresee > that the media decoder may perform concealment. There may be much tighter= coupling between the components that > suggested here (ILP concepts etc.). [BoB] I believe this is already partly covered by the disclaimer early on i= n 2.1 "The below examples are basic ones and it is important to keep in min= d that this conceptual model enables more complex usages", but it may be wo= rth pointing that out again. What about adding "It should be noted that in practical implementations, the Media Decoder an= d the Media Depacketizer may be tightly coupled and share information to im= prove or optimize the overall decoding process in various ways. It is howev= er not expected that there would be any benefit in defining a taxonomy for = those detailed (and likely very implementation-dependent) steps"? It would even be possible to add this text to both Media Depacketizer and M= edia Decoder sections. > 4. Topologies and Communication Entities >=20 > I think here you should cite the new topologies update (http://tools.ietf= .org/html/draft-ietf-avtcore-rtp-topologies- > update-01), and mention that there are topologies that are not included i= n this brief summary. Otherwise it appears that > the section tries to be exhaustive - and it clearly is not. [BoB] Agree. From alex@vidyo.com Tue Feb 11 10:07: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 144F71A0665 for ; Tue, 11 Feb 2014 10:07:39 -0800 (PST) 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 ztd5QPNH8Mvy for ; Tue, 11 Feb 2014 10:07:36 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id CF8A01A061E for ; Tue, 11 Feb 2014 10:07:35 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/11/2014 1:07:34 PM 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-50/SG:2 2/11/2014 1:07:05 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.743077 p=-0.960118 Source White X-Signature-Violations: 0-0-0-14403-c X-Note-419: 31.201 ms. Fail:1 Chk:1345 of 1345 total X-Note: SCH-CT/SI:1-1345/SG:1 2/11/2014 1:07:17 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: 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.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 96960244; Tue, 11 Feb 2014 13:07:34 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Tue, 11 Feb 2014 12:07:32 -0600 From: Alex Eleftheriadis To: Bo Burman Thread-Topic: [AVTCORE] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPHfT6eb6dcTfdT9S2qN1Oa7Qza5qwuMOAgAAYK4A= Date: Tue, 11 Feb 2014 18:07:32 +0000 Message-ID: <4D86CA03-BAC4-465F-B3E4-FBAF61E9FF63@vidyo.com> References: <949EF20990823C4C85C18D59AA11AD8B125741@FR712WXCHMBA11.zeu.alcatel-lucent.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.213.248] Content-Type: text/plain; charset="us-ascii" Content-ID: <0339DCE5675B3949A97D96C67D09A018@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: Re: [avtext] [AVTCORE] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 11 Feb 2014 18:07:39 -0000 Thanks Bo. All suggested changes are gerat.=20 One possible solution for the SST/MST redefinition issue is to use the term= s: single-port transmission and single-SSRC transmission, as well as the co= rresponding multi- variants. Acronyms: Sp / Ss - Mp / Ms.=20 SST per RFC 6190 is single-port, single SSRC. MST per RFC 6190 is multi-port, multi-SSRC. What is being referred to as Single Stream Transmission here, is single-por= t covering both single-SSRC and multi-SSRC cases. --Alex=20 On Feb 11, 2014, at 6:41 PM, Bo Burman wrote: > Hi Alex, >=20 >> -----Original Message----- >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Alex Elefther= iadis >> Sent: den 30 januari 2014 20:54 >> To: avtext@ietf.org >> Subject: Re: [avtext] [AVTCORE] draft-ietf-avtext-rtp-grouping-taxonomy-= 00 >>=20 > [snip] >> I did a quick read-through. Comments below; hope they are useful. > [BoB] Thank you, yes they were indeed useful! >=20 >>=20 >> --- >>=20 >> 2.1 Media Chain >>=20 >> I would take the first sentence of 2.1, Media Chain, and use it to defin= e media: "a sequence of physical world stimulus >> represented in digital form" > [BoB] Agree. What about starting 2.1 with: > In the context of this memo, Media is a sequence of synthetic or Physical= Stimulus (sound waves, photons, key-strokes), represented in digital form.= Synthesized Media is typically generated directly in the digital domain. > This section contains the concepts that can be involved in taking Media a= t a sender side... >=20 >> It is not evident from the text, but it should be recognized that it is = possible to have a a Media Source without a Physical >> Stimulus and associated Media Capture. Computer-generated content would= fall under this category. > [BoB] Agree. I added explicit mentioning of "synthetic" in the definition= of Media above. I also suggest adding something like "A Raw Stream can als= o contain synthesized Media that may not require any explicit Media Capture= , since it is already in an appropriate digital form" at the end of Raw Str= eam section, which I hope should take care of your comment. Do you believe = it is important to explicitly mention "computer-generated", since there are= other media-generating devices than "computers"? >=20 >> 2.1.1 Physical Stimulus >>=20 >> The definition does not need to use the receiver. Also, the word "captur= e" is ambiguous. You probably mean measured >> using an appropriate sensor/transducer and converted in digital form. > [BoB] Again, agree. I'll remove any mentioning of a receiver and replace = "capture" with your proposed text. >=20 >> 2.1.2 Media Capture >>=20 >> Should not use "captured" in the definition itself (circular definition)= . I would use: "The process of transforming the >> Physical Stimulus into digital form using an appropriate sensor/transduc= er." > [BoB] Good proposal. >=20 >> 2.1.6 Media Encoder >>=20 >> In addition to hierarchical encoding, such as the one used in H.264 SVC,= it is also possible to have what is called multiple >> description coding. In this case you have two independently encoded stre= ams, each one complementing the other. One >> simple example would be taken the even and odd samples of an audio strea= m, and forming two independently encoded >> audio streams (each at half the sampling rate). If you receive either yo= u can decode; if you receive both you can decode >> at full quality. >>=20 >> The section should also mention that for completeness. I am not aware of= any commercially available encoder that uses >> MDC today. > [BoB] OK. I believe it could increase understanding of the concepts we tr= y to describe. > What about adding: > " There are also other variants of encoders, like so-called Multiple Desc= ription Coding (MDC). Such Media Encoder produce multiple independent and t= hus individually decodable Encoded Streams that are possible to combine int= o a Received Source Stream that is somehow a better representation of the o= riginal Source Stream than using only a single Encoded Stream"? >=20 >> 2.1.9 Media Packetizer >>=20 >> The terms SST and MST were defined as Single Session Transmission and Mu= lti-Session Transmission, respectively, in RFC >> 6190. I understand the arguments for switching session with stream, but = I think re-defining them now only creates >> confusion (plus the new terms do not appear to be drop-in replacements f= or RFC 6190 anyway, since Multi-Session in >> Single-Stream was not anticipated in RFC 6190). > [BoB] We already have a separate section describing SST (3.2.1). What abo= ut keeping the Media Packetizer text simple, mentioning SST just as an exam= ple without describing it further and cross-referencing the section 3 text?= I think we should then do the same for MST, which would require adding ano= ther short section in section 3 for that. In the SST and MST sections, thei= r specific assumptions on use of RTP Sessions could be described and that c= omplicating aspect could then be kept out of the text in Media Packetizer s= ection. The 6190 "omission" of MST in a single RTP Session could then also = be mentioned in section 3, maybe in one of the SST or MST sections. >=20 >=20 >> 2.1.20 Media Decoder >>=20 >> The way the system is presented, with 2.1.18 Media Depacketizer as an in= dependent component, you do not foresee >> that the media decoder may perform concealment. There may be much tighte= r coupling between the components that >> suggested here (ILP concepts etc.). > [BoB] I believe this is already partly covered by the disclaimer early on= in 2.1 "The below examples are basic ones and it is important to keep in m= ind that this conceptual model enables more complex usages", but it may be = worth pointing that out again. > What about adding > "It should be noted that in practical implementations, the Media Decoder = and the Media Depacketizer may be tightly coupled and share information to = improve or optimize the overall decoding process in various ways. It is how= ever not expected that there would be any benefit in defining a taxonomy fo= r those detailed (and likely very implementation-dependent) steps"? > It would even be possible to add this text to both Media Depacketizer and= Media Decoder sections. >=20 >> 4. Topologies and Communication Entities >>=20 >> I think here you should cite the new topologies update (http://tools.iet= f.org/html/draft-ietf-avtcore-rtp-topologies- >> update-01), and mention that there are topologies that are not included = in this brief summary. Otherwise it appears that >> the section tries to be exhaustive - and it clearly is not. > [BoB] Agree. >=20 >=20 From bernard_aboba@hotmail.com Tue Feb 11 16:19:44 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 892101A0796 for ; Tue, 11 Feb 2014 16:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 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.548, 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 oElAUD9oP18w for ; Tue, 11 Feb 2014 16:19:41 -0800 (PST) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2B31A06F5 for ; Tue, 11 Feb 2014 16:19:36 -0800 (PST) Received: from BLU181-W75 ([65.55.111.71]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Feb 2014 16:19:34 -0800 X-TMN: [pIoqXozLdyX0sHzCS7bxkFERRfGtACbT] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b2e877df-04e0-435f-9a0e-4b0a827e0e97_" From: Bernard Aboba To: "avtext@ietf.org" Date: Tue, 11 Feb 2014 16:19:34 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2014 00:19:34.0834 (UTC) FILETIME=[1B8DB120:01CF2788] Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 12 Feb 2014 00:19:44 -0000 --_b2e877df-04e0-435f-9a0e-4b0a827e0e97_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alex said: "One possible solution for the SST/MST redefinition issue is to = use the terms: single-port transmission and single-SSRC transmission=2C as = well as the corresponding multi- variants. Acronyms: Sp / Ss - Mp / Ms. =0A= =0A= SST per RFC 6190 is single-port=2C single SSRC.=0A= =0A= MST per RFC 6190 is multi-port=2C multi-SSRC.=0A= =0A= What is being referred to as Single Stream Transmission here=2C is single-p= ort covering both single-SSRC and multi-SSRC cases."[BA] Agree with Alex ab= out what the definitions were in RFC 6190. Also agree that it would be bes= t to use new abbreviations if we are going to define new terms. The subject= is confusing enough that we don't need to add any more :)Section 3.2.1 say= s: " Scalable Video Coding [RFC6190] has a mode of operation where Encode= d Streams and Dependent Streams from the SVC Media Encoder is grouped toget= her in a single Source Packet Stream using the SVC RTP Payload format."This= isn't right=2C because Single Session Transport in RFC 6190 could refer to= either a single stream or multiple. So I think Alex is correct. Section 3= .3.2 says: " Multi-stream transmission (MST) is a mechanism by which diff= erent portions of a layered encoding of a Source Stream are sent using sepa= rate Packet Streams (sometimes in separate RTP sessions)."So here what the = document is calling "Multi-stream transmission" is referring to multiple-SS= RC=2C either with a single-port or multiple ports. =20 = --_b2e877df-04e0-435f-9a0e-4b0a827e0e97_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Alex said: =3B
"One=
 possible solution for the SST/MST redefinition issue is to use the terms:&=
nbsp=3B
single-port transmission and single-SSRC transmission=2C =
as well as the corresponding multi- variants. Acronyms: Sp / Ss - Mp / Ms. =
=0A=
=0A=
SST per RFC 6190 is single-port=2C single SSRC.=0A=
=0A=
MST per RFC 6190 is multi-port=2C multi-SSRC.=0A=
=0A=
What is being referred to as Single Stream Transmission here=2C =3B
is single-port covering both single-SSRC and multi-SSRC cases."
[BA] Agree with Alex about what the definitions were in RFC 6190.  Al=
so agree that it would be best to use new abbreviations if we are going to =
define new terms. The subject is confusing enough that we don't need to add=
 any more :)
Section 3.2.1 says: 
"   Scalable Video Codi=
ng [RFC6190] has a mode of opera=
tion where Encoded Streams and Dependent Streams from the SVC Media En=
coder is grouped together in a single Source Packet Stream using the S=
VC RTP Payload format."
This isn't right=2C beca=
use Single Session Transport in RFC 6190 could refer to either a single str=
eam or multiple.  So I think Alex is correct. 
Section 3.3.2 says: =

"   Multi-stream transmission (MST) is a mechanism by whi=
ch different portions of a layered encoding of a Source Stream are se=
nt using separate Packet Streams (sometimes in separate RTP sessions).=
"
So here what the document is calling "Multi-stream transmi=
ssion" is referring to multiple-SSRC=2C either with a single-port or multip=
le ports.



=
= --_b2e877df-04e0-435f-9a0e-4b0a827e0e97_-- From magnus.westerlund@ericsson.com Tue Feb 11 23:45:47 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 5DCE61A0867 for ; Tue, 11 Feb 2014 23:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 CLHxxDlSR6-L for ; Tue, 11 Feb 2014 23:45:45 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8CA1A0874 for ; Tue, 11 Feb 2014 23:45:44 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-5d-52fb26a7d000 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 04.C7.04853.7A62BF25; Wed, 12 Feb 2014 08:45:43 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.347.0; Wed, 12 Feb 2014 08:45:02 +0100 Message-ID: <52FB267D.3000903@ericsson.com> Date: Wed, 12 Feb 2014 08:45:01 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alex Eleftheriadis , Bo Burman References: <949EF20990823C4C85C18D59AA11AD8B125741@FR712WXCHMBA11.zeu.alcatel-lucent.com> <4D86CA03-BAC4-465F-B3E4-FBAF61E9FF63@vidyo.com> In-Reply-To: <4D86CA03-BAC4-465F-B3E4-FBAF61E9FF63@vidyo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvje5ytd9BBg97TSyu71zLYvHx3g1W ByaPJUt+Mnm0PbvDHsAUxWWTkpqTWZZapG+XwJXx4atqwVLRinub9jM2MPYIdjFyckgImEi0 LfrJCGGLSVy4t56ti5GLQ0jgBKPEqeNbwRJCAssZJe4cqAaxeQW0JVZvbmMBsVkEVCWufZjB BmKzCVhI3PzRCGaLCgRL7DzwmxGiXlDi5MwnYPUiAt4Sq1esAYszC6hLHN63BMwWFvCSuDj9 BCPE4n+MEhf+nwYbxClgK7FwyhWgBAfQdeISPY1BEL16ElOutkDNkZdo3jqbGeJObYmGpg7W CYxCs5CsnoWkZRaSlgWMzKsYJYtTi4tz040M9HLTc0v0Uosyk4uL8/P0ilM3MQKD+eCW30Y7 GE/usT/EKM3BoiTOe521JkhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD40StOnfVGUoHKvj3 RcmkK54/VlmaxB1wftO6uZxGFseXtF7mChQ7pXFNwmFb8uZFa9q3v1lcdNvjVa3w5T/PzkRN EeS1fu1uzFHP/6pLY2o3c8j+rxsfrM6P/OYkVM+u0vNXflIrw2SlGTx6HXGN1dKWB7e56+Rt 9Q48wfDp0oeyZ54BqZeYlFiKMxINtZiLihMBMJ+MITQCAAA= Cc: "avtext@ietf.org" Subject: Re: [avtext] [AVTCORE] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 12 Feb 2014 07:45:47 -0000 On 2014-02-11 19:07, Alex Eleftheriadis wrote: > Thanks Bo. All suggested changes are gerat. > > One possible solution for the SST/MST redefinition issue is to use > the terms: single-port transmission and single-SSRC transmission, as > well as the corresponding multi- variants. Acronyms: Sp / Ss - Mp / > Ms. > > SST per RFC 6190 is single-port, single SSRC. > > MST per RFC 6190 is multi-port, multi-SSRC. I would protest the single port term here. Tough it is common to determine what a single RTP session is by using a single listener port, that is not always the truth. One can have a single RTP session using multiple transport flows both incoming and outgoing from an endpoint. Thus, please reference this as single RTP session. > > What is being referred to as Single Stream Transmission here, is > single-port covering both single-SSRC and multi-SSRC cases. > In the context of RFC 6190 I don't think this is clear. Let me quote form page 5 of RFC 6190: This memo defines two basic modes for transmission of SVC data, single-session transmission (SST) and multi-session transmission (MST). In SST, a single RTP session is used for the transmission of all scalability layers comprising an SVC bitstream; in MST, the scalability layers are transported on different RTP sessions. In SST, packetization is a straightforward extension of [RFC6184]. Using multi-SSRC for one SVC encoding in a single RTP session is not a straightforward extension of RFC6184. This multi-SSRC usage has more to do with MST mode than the SST mode for the SVC RTP payload format. Thus, I think we are on the right track to define this as its own usage requiring a special set of considerations. I would claim that the SVC RTP payload format does not adequately define how to use the RTP payload format in this mode. The reason is that it fails to make clear how you would correctly associate the right set of SSRCs that are carrying the encoded and dependent stream for a particular media source. Thus, for endpoints that transmit multiple sources there exist a short coming in this mode. My suggestion would be to simple label this mode of operation with its own label. Cheers 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 jonathan@vidyo.com Wed Feb 12 08:40:41 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 EEA1B1A0325 for ; Wed, 12 Feb 2014 08:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 80a6exOLX6rK for ; Wed, 12 Feb 2014 08:40:39 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 4362D1A0310 for ; Wed, 12 Feb 2014 08:40:39 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/12/2014 11:40:38 AM X-Policy: GLOBAL - vidyo.com 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-182/SG:2 2/12/2014 11:40:34 AM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.815867 p=-0.967201 Source White X-Signature-Violations: 0-0-0-2789-c X-Note-419: 0 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/12/2014 11:40:33 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: 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.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 97316922; Wed, 12 Feb 2014 11:40:37 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Wed, 12 Feb 2014 10:40:36 -0600 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Agenda requests for AVTEXT at IETF 89 - London Thread-Index: AQHPKBEo9vbuYpXrrki9v8ZiznlR2w== Date: Wed, 12 Feb 2014 16:40:36 +0000 Message-ID: <1111524F-EA73-4059-B3FF-F480AEE0805B@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: <83601CB23AC44542AB60EDC694D1943D@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "straw-chairs@tools.ietf.org" Subject: [avtext] Agenda requests for AVTEXT at IETF 89 - London 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, 12 Feb 2014 16:40:41 -0000 AVTEXT will be meeting on Thursday afternoon at IETF 89: 1520-1650 Afternoon Session II 1700-1830 Afternoon Session III Buckingham RAI avtext Audio/Video Transport Extensions WG Buckingham RAI avtext Audio/Video Transport Extensions WG (We don't anticipate needing the entire time.) If you have not already done so, please send the WG chairs requests for age= nda time if you have items you would like to discuss. AVTEXT is currently scheduled opposite the STRAW working group. The primar= y item on STRAW's agenda is the B2BUA-RTCP draft, which we expect to be of = interest to many participants in AVTEXT. We will be coordinating with the = STRAW chairs to make sure participants can attend both sessions, possibly (= given the large time window AVTEXT has) by running the sessions back-to-bac= k in the same room.= From bo.burman@ericsson.com Wed Feb 12 10:03:52 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 DD9841A0601 for ; Wed, 12 Feb 2014 10:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=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 YOvwKsym8bjR for ; Wed, 12 Feb 2014 10:03:49 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 562F91A0583 for ; Wed, 12 Feb 2014 10:03:48 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-8b-52fbb782f382 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 00.0A.04853.287BBF25; Wed, 12 Feb 2014 19:03:46 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.223]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 19:03:46 +0100 From: Bo Burman To: Bernard Aboba , "avtext@ietf.org" Thread-Topic: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPJ4gk+DpeFSd18kW9VQ74Ql37kpqxrlUA Date: Wed, 12 Feb 2014 18:03:45 +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.146] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E123A7EESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvjW7T9t9BBt/aTCw+3rvBarF/yWVm ByaPxz1n2DyWLPnJFMAUxWWTkpqTWZZapG+XwJXx4fVDtoIzNRVHZ1c1ME7K6WLk5JAQMJHo 3nWDHcIWk7hwbz1bFyMXh5DACUaJV+++sIIkhASWMEocnVkAYrMJaEjM33GXEcQWEQiRWNG2 FKxGWMBBYtf6FWwQcUeJefdmsHQxcgDZRhINN/lAwiwCqhJNry4ygdi8Ar4Sx+6egxpvKXG/ 9wMLiM0pYCWxo3sdM4jNKCArcf/7PbA4s4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VghbSeLH hktQ9fkSXzY/gNolKHFy5hOWCYwis5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZC Fl/AyL6KUbI4tbg4N93IQC83PbdEL7UoM7m4OD9Przh1EyMwtg5u+W20g/HkHvtDjNIcLEri vNdZa4KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MO76VLrMoWZdy+17My6dOqI0r33LB/7k 5U8/bXvsYVMjaM75Qv3ZvLbqrSwdq+5qx285rrPZrD+D9c2pwqwMdUfLdQHOE+5eyvU8yGsd 8q444QHTMZ+G8y3Jq/eJRdo9nHQ+vj11s/CCWw2y262CUw7bvYv/25TcrXCzYKHomotrb4Z5 cSxof6fEUpyRaKjFXFScCAARZXuXewIAAA== Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 12 Feb 2014 18:03:53 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E123A7EESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, I get confused what you think is specified in 6190. On one hand you agree with Alex what the definitions were in 6190, assumedl= y referring to the text "SST per RFC 6190 is single-port, single SSRC". On the other hand, it seems you object to exactly that ("Encoded Streams an= d Dependent Streams from the SVC Media Encoder is grouped together in a sin= gle Source Packet Stream") in your next comment: "This isn't right, because= Single Session Transport in RFC 6190 could refer to either a single stream= or multiple. So I think Alex is correct". Could you please clarify? In 6190 section 5.1 Packetization Rules for Single-Session Transmission, it= says "When a set of layers including one or more SVC enhancement layers is= transmitted in an RTP session, the set SHOULD be carried in one RTP stream= that SHOULD be encapsulated according to this memo". The definition of "RT= P packet stream" in section 3.1.2 of 6190, is "A sequence of RTP packets wi= th increasing sequence numbers (except for wrap-around), identical payload = type and identical SSRC (Synchronization Source), carried in one RTP sessio= n. Within the scope of this memo, one RTP packet stream is utilized to tran= sport one or more layers". So, to me it seems that multiple RTP streams are in fact not disallowed by = SST, but 6190 is entirely silent on how such multiple streams would be mapp= ed to multiple SSRC. It in fact seems to be agnostic to the use of SSRC and= (assumedly) relies entirely on information in the SVC bitstream. Correct? = In that case, can any number of SSRC be used to describe the SVC stream (I = know it SHOULD only be one) from a single Media Source? Furthermore, in another mail in this thread, I noted Magnus says there is a= specific problem in SST to handle multiple Media Sources (in taxonomy term= s, like multiple cameras) and to know which SSRC belongs to which Media Sou= rce. I tend to agree, given the above. In any case, I think it will be unwise to re-define anything, we should onl= y clarify. I hope to do that by including text that describe SST and MST in= taxonomy terms, but I still have difficulties to understand exactly how to= describe them. Cheers, Bo From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: den 12 februari 2014 01:20 To: avtext@ietf.org Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Alex said: "One possible solution for the SST/MST redefinition issue is to use the ter= ms: single-port transmission and single-SSRC transmission, as well as the corre= sponding multi- variants. Acronyms: Sp / Ss - Mp / Ms. SST per RFC 6190 is single-port, single SSRC. MST per RFC 6190 is multi-port, multi-SSRC. What is being referred to as Single Stream Transmission here, is single-port covering both single-SSRC and multi-SSRC cases." [BA] Agree with Alex about what the definitions were in RFC 6190. Also agr= ee that it would be best to use new abbreviations if we are going to define= new terms. The subject is confusing enough that we don't need to add any m= ore :) Section 3.2.1 says: " Scalable Video Coding [RFC6190] has= a mode of operation where Encoded Streams and Dependent Streams from the S= VC Media Encoder is grouped together in a single Source Packet Stream using= the SVC RTP Payload format." This isn't right, because Single Session Transport in RFC 6190 could refer = to either a single stream or multiple. So I think Alex is correct. Section 3.3.2 says: " Multi-stream transmission (MST) is a mechanism by which different porti= ons of a layered encoding of a Source Stream are sent using separate Packet= Streams (sometimes in separate RTP sessions)." So here what the document is calling "Multi-stream transmission" is referri= ng to multiple-SSRC, either with a single-port or multiple ports. --_000_BBE9739C2C302046BD34B42713A1E2A22E123A7EESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard, I get confused w= hat you think is specified in 6190.

 
On one hand you agree with Alex what the de=
finitions were in 6190, assumedly referring to the text “SST p=
er RFC 6190 is single-port, single SSRC”.<=
o:p>
 
On the other hand, it seems you object to e=
xactly that (“Encoded Streams and Dependent Strea=
ms from the SVC Media Encoder is grouped together in a single Source Packet=
 Stream”) in your next comment: =
220;This isn't right, because Single Session Transport in RFC 6190 c=
ould refer to either a single stream or multiple.  So I think Alex is =
correct”.
 
Could you please clarify?=

 
In 6190 section 5.1 Packetization Rules for=
 Single-Session Transmission, it says “When a set of layers including=
 one or more SVC enhancement layers is transmitted in an RTP session, the s=
et SHOULD be carried in one RTP stream that SHOULD be encapsulated accordin=
g to this memo”. The definition of “RTP packet stream” in=
 section 3.1.2 of 6190, is “A sequence of RTP packets with increasing=
 sequence numbers (except for wrap-around), identical payload type and iden=
tical SSRC (Synchronization Source), carried in one RTP session. Within the=
 scope of this memo, one RTP packet stream is utilized to transport one or =
more layers”.
 
So, to me it seems that multiple RTP stream=
s are in fact not disallowed by SST, but 6190 is entirely silent on how suc=
h multiple streams would be mapped to multiple SSRC. It in fact seems to be=
 agnostic to the use of SSRC and (assumedly) relies entirely on information=
 in the SVC bitstream. Correct? In that case, can any number of SSRC be use=
d to describe the SVC stream (I know it SHOULD only be one) from a single M=
edia Source?
 
Furthermore, in another mail in this thread=
, I noted Magnus says there is a specific problem in SST to handle multiple=
 Media Sources (in taxonomy terms, like multiple cameras) and to know which=
 SSRC belongs to which Media Source. I tend to agree, given the above.=

 
In any case, I think it will be unwise to r=
e-define anything, we should only clarify. I hope to do that by including t=
ext that describe SST and MST in taxonomy terms, but I still have difficult=
ies to understand exactly how to describe them.
 
Cheers,
Bo 
 

 <= /p>

From: avtext [= mailto:avtext-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: den 12 februari 2014 01:20
To: avtext@ietf.org
Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00

 

Alex said: 

"One possible solution for the SST/MST redefinition issue is to u=
se the terms: 
single-port transmission and single-SSRC transmission, as well as the =
corresponding multi- variants. Acronyms: Sp / Ss - Mp / Ms. 

 


SST per RFC 6190 is single-port, single SSRC.


 


MST per RFC 6190 is multi-port, multi-SSRC.


 


What is being referred to as Single Stream Transmission here, 


is single-port covering both single-SSRC and multi-SSRC cases."


[BA] Agree with Alex about what the definitions were in RFC 6190. =
; Also agree that it would be best to use new abbreviations if we are going=
 to define new terms. The subject is confusing enough that we don't need to=
 add any more :)


Section 3.2.1 says: 


"   Scalable Video Coding [RFC6190] has a mode of =
operation where Encoded Streams and Dependent Streams from the SVC Media En=
coder is grouped together in a single Source Packet Stream using the SVC RT=
P Payload format."


This isn't right, because Single Session Transport in RFC 6190 could r=
efer to either a single stream or multiple.  So I think Alex is correc=
t. 


Section 3.3.2 says: 


"   Multi-stream transmission (MST) is a m=
echanism by which different portions of a layered encoding of a Source Stre=
am are sent using separate Packet Streams (sometimes in separate RTP sessio=
ns)."


So here what the document is calling "Multi-stream t=
ransmission" is referring to multiple-SSRC, either with a single-port =
or multiple ports.  


 


 

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E123A7EESESSMB105erics_-- From bernard_aboba@hotmail.com Wed Feb 12 10:51:36 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 224A91A0658 for ; Wed, 12 Feb 2014 10:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 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.548, 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 ehq15eytqM-s for ; Wed, 12 Feb 2014 10:51:31 -0800 (PST) Received: from blu0-omc1-s35.blu0.hotmail.com (blu0-omc1-s35.blu0.hotmail.com [65.55.116.46]) by ietfa.amsl.com (Postfix) with ESMTP id 802251A066C for ; Wed, 12 Feb 2014 10:51:21 -0800 (PST) Received: from BLU181-W75 ([65.55.116.8]) by blu0-omc1-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Feb 2014 10:51:21 -0800 X-TMN: [1jXuICHIAa9/xQpuRkt22ZIAk0kXQklVgkt+W15z8lQ=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_8db4b468-fe17-41b6-aa1a-0159520da7bb_" From: Bernard Aboba To: Bo Burman , "avtext@ietf.org" Date: Wed, 12 Feb 2014 10:51:20 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2014 18:51:21.0324 (UTC) FILETIME=[6BB84AC0:01CF2823] Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 12 Feb 2014 18:51:36 -0000 --_8db4b468-fe17-41b6-aa1a-0159520da7bb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bo said:=20 =0A= "So=2C to me it seems that multiple RTP streams are in fact not disallowed = by SST"[BA] Correct. There are some implementations that send multiple RTP= streams within a single session. [Bo Burman]"6190 is entirely silent on ho= w such multiple streams would be mapped to multiple SSRC. It in fact seems = to be agnostic to the use of SSRC and (assumedly) relies entirely on inform= ation in the SVC bitstream. Correct? "[BA] For multiple streams (whether se= nt on separate RTP sessions or the same session)=2C it is necessary to reco= ver the decoding orderacross the multiple streams=2C as described in RFC 61= 90 Section 4.11. This leads to multiple source transport requiring distinc= t packetizationfrom that used in single source transport=2C as described in= Section 5.2. IMHO=2C this was a major mistake=2C which has lead to intero= perabilityissues with H.264/SVC transport. That issue is being addressed i= n the HEVC over RTP payload specification where there is no longer distinct= packetization modes for SST and MST and DON support is mandatory. With resp= ect to signaling=2C RFC 6190 provides examples of single session transport = (7.3.1=2C 7.3.2) and multi-session transport (7.3.3=2C 7.3.4)=2C but does n= ot provideexamples of how to signal multiple sources within the same sessio= n. With BUNDLE=2C RFC 5761 and RFC 5583 dependency groups=2C I believe th= is isnow possible. However=2C since the topic is somewhat "bleeding edge"= it will probably not end up in the HEVC over RTP spec=2C eventhough that w= ill cover temporal scalability. [Bo]In that case=2C can any number of SSRC = be used to describe the SVC stream (I know it SHOULD only be one) from a si= ngle Media Source?[BA] Yes=2C this has been implemented=2C and has been sho= wn to have some advantages. For example=2C when dropping a layer=2C sequen= ce number rewriting can potentially be avoided. Also=2C FEC can be applied= to some layers and not others. =0A= [Bo] Furthermore=2C in another mail in this thread=2C I noted Magnus says = there is a specific problem in SST to handle multiple Media Sources (in tax= onomy terms=2C like multiple cameras) and to know which SSRC belongs to whi= ch Media Source. I tend to agree=2C given the above.=0A= [BA] There is a need for a receiver to understand the purpose of each inco= ming stream. The ways in which this can be done are underdiscussion. As a= n example=2C App-Id/Receive-App-Id may be one way to handle this. [Bo] In a= ny case=2C I think it will be unwise to re-define anything=2C we should onl= y clarify. [BA] I agree. [Bo] I hope to do that by including text that desc= ribe SST and MST in taxonomy terms=2C but I still have difficulties to unde= rstand exactly how to describe them.=0A= [BA] To be clear=2C my objection was not to defining new terms Single Stre= am Transport and Multiple Stream Transport =2Cbut to redefining the meaning= of the SST and MSTabbreviations used in RFC 6190. =0A= =0A= =0A= =0A= = --_8db4b468-fe17-41b6-aa1a-0159520da7bb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bo said:
=0A= 
"So=2C to me it seems that multiple =
RTP streams are in fact not disallowed by SST"
[BA] Correct.  There are some implementations that sen=
d multiple RTP streams within a single session. 
[Bo Burman]
"6190 is entirely silent on how such multiple streams would be ma=
pped to multiple SSRC. 
It=
 in fact seems to be agnostic to the use of SSRC and (assumedly) relies ent=
irely on information in the SVC bitstream. Correct? "
[BA] For multiple streams (whether sent on sepa=
rate RTP sessions or the same session)=2C it is necessary to recover the de=
coding order
across the mu=
ltiple streams=2C as described in RFC 6190 Section 4.11.  This leads to mul=
tiple source transport requiring distinct packetization
from that used in single source transport=2C =
as described in Section 5.2.  IMHO=2C this was a major mistake=2C which has=
 lead to interoperability
=
issues with H.264/SVC transport.  That issue is being addressed in the HEVC=
 over RTP payload specification where there is no longer distinct
packetization modes for SST and MST=
 and DON support is mandatory. 
With respect to signaling=2C RFC 6190 provides examples of single ses=
sion transport (7.3.1=2C 7.3.2) and multi-session transport (7.3.3=2C 7.3.4=
)=2C but does not provide
=
examples of how to signal multiple sources within the same session.   With =
BUNDLE=2C RFC 5761 and RFC 5583 dependency groups=2C I believe this is
now possible.   However=2C sin=
ce the topic is somewhat "bleeding edge" it will probably not end up in the=
 HEVC over RTP spec=2C even
though that will cover temporal scalability. 
[Bo]
In that case=2C can any number of SSRC be used to describe the SVC str=
eam (I know it SHOULD only be one) from a single Media Source?
=

[BA] Yes=2C this has been implemente=
d=2C and has been shown to have some advantages.  For example=2C when dropp=
ing a layer=2C 
sequence number rewriting can potentially be a=
voided.  Also=2C FEC can be applied to some layers and not others. <=
/pre>=0A=

 =3B[Bo] Furthermore=2C in another mail in this thread=2C I noted Ma=
gnus says there is a specific problem in SST to handle multiple Media Sourc=
es (in taxonomy terms=2C like multiple cameras) and to know which SSRC belo=
ngs to which Media Source. I tend to agree=2C given the above.
=
=0A=

 =3B[BA] There is a need for a r=
eceiver to understand the purpose of each incoming stream.  The ways in whi=
ch this can be done are under
discussion.  As an example=2C App-Id/Receive-App-Id may be one way to =
handle this. 
[Bo] In any case=2C I think it will be unwise =
to re-define anything=2C we should only clarify. 
[BA] I agree. 
[Bo] I hope to do that by including text that describe SST and=
 MST in taxonomy terms=2C 
but I still have difficulties to understand exactly how to describe them.<=
/span>
=0A=

 =3B[BA] To be clear=2C my objec=
tion was not to defining new terms Single Stream Transport and Multiple Str=
eam Transport =2Cbut to redefining the meaning of the SST and MST
abbreviations used in RFC 6190. 
=0A=
=0A=
=0A=
=0A=
= --_8db4b468-fe17-41b6-aa1a-0159520da7bb_-- From nobody Thu Feb 13 15:26:54 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 D47441A0023 for ; Thu, 13 Feb 2014 15:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=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 s5MVvvfJglCQ for ; Thu, 13 Feb 2014 15:26:48 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id C5B011A001D for ; Thu, 13 Feb 2014 15:26:47 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-ec-52fd54b5642e Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id E8.20.04853.5B45DF25; Fri, 14 Feb 2014 00:26:45 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.223]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 00:26:45 +0100 From: Bo Burman To: Bernard Aboba , "avtext@ietf.org" Thread-Topic: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPJ4gk+DpeFSd18kW9VQ74Ql37kpqxrlUAgAA4rQCAAdTpEA== Date: Thu, 13 Feb 2014 23:26:44 +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.148] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E1258C8ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvje7WkL9BBjuealt8vHeD1WL/ksvM Dkwej3vOsHksWfKTKYApissmJTUnsyy1SN8ugSvj/pMd7AWf6yt2LdjD3MC4O7+LkZNDQsBE 4sGkTUwQtpjEhXvr2UBsIYETjBJ/ZiRA2EsYJV61RoLYbAIaEvN33GUEsUUEQiRWtC1lBbGF BRwkdq1fwQYRd5SYd28GC4TtJHF99TOwOIuAqsS/SQ/A4rwCvhKHG64B9XIBzV/NKPHz8C+w QZwCVhLX3q0CsxkFZCXuf78H1sAsIC5x68l8qEMFJJbsOc8MYYtKvHz8jxXCVpJoXPIEyOYA qs+XuHEgF2KXoMTJmU9YJjCKzEIyaRZC1SwkVRAlOhILdn9ig7C1JZYtfM0MY5858JgJWXwB I/sqRsni1OLi3HQjA73c9NwSvdSizOTi4vw8veLUTYzA2Dq45bfRDsaTe+wPMUpzsCiJ815n rQkSEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLi64eJp3wfdLdG7ZjmcSzTdff1Y2gPDiGiZ TrHdIlny9mbBk95NffZnaVekfRHnr1SJlON+coePpiyNLpAU1Ms5uWo+50eemvPsL9c2fZF6 zLq2Z6lOln9E5fX6F/PlRPsOzGxJc+sx7nU6Z7px9nyJ9avfzJPrXdWg0r0kYMrVDxvuOpwt dVViKc5INNRiLipOBAAZhSvZewIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/eIvt8gN_plVueu9B5aXkqc5GB-g Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 13 Feb 2014 23:26:53 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E1258C8ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would then suggest to simply clarify that, as 6190 define them, both SST = and MST can use one or more Encoded Packet Streams (SSRC) per Media Source. So, to elaborate, there is a SST-SingleStream with all scalable layers of a= Media Source sent in a single Packet Stream (with a single SSRC). SST-Mult= iStream uses a single RTP Session where the scalable layers are spread acro= ss multiple different Packet Streams. In MST-SS, the scalable layers use mu= ltiple RTP Sessions, each carrying a single Packet Stream. Finally, the sca= lable layers in MST-MS use multiple Packet Streams in each of the multiple = RTP Sessions. Then there is the complication that scalable layers signaled as MST (in SDP= ) that are also BUNDLE'd are in fact combined into a single RTP Session, ef= fectively becoming equivalent to SST-MS. Comments? From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: den 12 februari 2014 19:51 To: Bo Burman; avtext@ietf.org Subject: RE: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Bo said: "So, to me it seems that multiple RTP streams are in fact not disallowed by= SST" [BA] Correct. There are some implementations that send multiple RTP stream= s within a single session. [Bo Burman] "6190 is entirely silent on how such multiple streams would be mapped to mu= ltiple SSRC. It in fact seems to be agnostic to the use of SSRC and (assumedly) relies e= ntirely on information in the SVC bitstream. Correct? " [BA] For multiple streams (whether sent on separate RTP sessions or the sam= e session), it is necessary to recover the decoding order across the multiple streams, as described in RFC 6190 Section 4.11. This l= eads to multiple source transport requiring distinct packetization from that used in single source transport, as described in Section 5.2. IM= HO, this was a major mistake, which has lead to interoperability issues with H.264/SVC transport. That issue is being addressed in the HEVC= over RTP payload specification where there is no longer distinct packetization modes for SST and MST and DON support is mandatory. With respect to signaling, RFC 6190 provides examples of single session tra= nsport (7.3.1, 7.3.2) and multi-session transport (7.3.3, 7.3.4), but does = not provide examples of how to signal multiple sources within the same session. With = BUNDLE, RFC 5761 and RFC 5583 dependency groups, I believe this is now possible. However, since the topic is somewhat "bleeding edge" it wil= l probably not end up in the HEVC over RTP spec, even though that will cover temporal scalability. [Bo] In that case, can any number of SSRC be used to describe the SVC stream (I = know it SHOULD only be one) from a single Media Source? [BA] Yes, this has been implemented, and has been shown to have some advant= ages. For example, when dropping a layer, sequence number rewriting can potentially be avoided. Also, FEC can be app= lied to some layers and not others. [Bo] Furthermore, in another mail in this thread, I noted Magnus says ther= e is a specific problem in SST to handle multiple Media Sources (in taxonom= y terms, like multiple cameras) and to know which SSRC belongs to which Med= ia Source. I tend to agree, given the above. [BA] There is a need for a receiver to understand the purpose of each inco= ming stream. The ways in which this can be done are under discussion. As an example, App-Id/Receive-App-Id may be one way to handle = this. [Bo] In any case, I think it will be unwise to re-define anything, we shoul= d only clarify. [BA] I agree. [Bo] I hope to do that by including text that describe SST and MST in taxon= omy terms, but I still have difficulties to understand exactly how to describe them. [BA] To be clear, my objection was not to defining new terms Single Stream= Transport and Multiple Stream Transport ,but to redefining the meaning of = the SST and MST abbreviations used in RFC 6190. --_000_BBE9739C2C302046BD34B42713A1E2A22E1258C8ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would then suggest to s= imply clarify that, as 6190 define them, both SST and MST can use one or mo= re Encoded Packet Streams (SSRC) per Media Source.

 <= /p>

So, to elaborate, there i= s a SST-SingleStream with all scalable layers of a Media Source sent in a s= ingle Packet Stream (with a single SSRC). SST-MultiStream uses a single RTP Session where the scalable layers are spread across mult= iple different Packet Streams. In MST-SS, the scalable layers use multiple = RTP Sessions, each carrying a single Packet Stream. Finally, the scalable l= ayers in MST-MS use multiple Packet Streams in each of the multiple RTP Sessions.

 <= /p>

Then there is the complic= ation that scalable layers signaled as MST (in SDP) that are also BUNDLE= 217;d are in fact combined into a single RTP Session, effectively becoming equivalent to SST-MS.

 <= /p>

Comments?

 <= /p>

From: Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: den 12 februari 2014 19:51
To: Bo Burman; avtext@ietf.org
Subject: RE: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00

 

Bo said: 

"So, to me it seems that multiple RTP =
streams are in fact not disallowed by SST"
[BA] Correct.  There are some implemen=
tations that send multiple RTP streams within a single session. 
[Bo Burman]
"6190 is entirely silent on how such m=
ultiple streams would be mapped to multiple SSRC. 
It in fact seems to be agnostic to the use =
of SSRC and (assumedly) relies entirely on information in the SVC bitstream=
. Correct? "
[BA] For multiple streams (whether sent on =
separate RTP sessions or the same session), it is necessary to recover the =
decoding order
across the multiple streams, as described i=
n RFC 6190 Section 4.11.  This leads to multiple source transport requ=
iring distinct packetization
from that used in single source transport, =
as described in Section 5.2.  IMHO, this was a major mistake, which ha=
s lead to interoperability
issues with H.264/SVC transport.  That=
 issue is being addressed in the HEVC over RTP payload specification where =
there is no longer distinct
packetization modes for SST and MST and DON=
 support is mandatory. 
With respect to signaling, RFC 6190 provide=
s examples of single session transport (7.3.1, 7.3.2) and multi-session tra=
nsport (7.3.3, 7.3.4), but does not provide
examples of how to signal multiple sources =
within the same session.   With BUNDLE, RFC 5761 and RFC 5583 dep=
endency groups, I believe this is
now possible.   However, since th=
e topic is somewhat "bleeding edge" it will probably not end up i=
n the HEVC over RTP spec, even
though that will cover temporal scalability=
. 
[Bo]
In that case, can any number of SSRC be use=
d to describe the SVC stream (I know it SHOULD only be one) from a single M=
edia Source?
[BA] Yes, this has been implemented, and ha=
s been shown to have some advantages.  For example, when dropping a la=
yer, 
sequence number rewriting can potentially b=
e avoided.  Also, FEC can be applied to some layers and not others. 
 [Bo] Furthermore, in another mail in =
this thread, I noted Magnus says there is a specific problem in SST to hand=
le multiple Media Sources (in taxonomy terms, like multiple cameras) and to=
 know which SSRC belongs to which Media Source. I tend to agree, given the =
above.
 [BA] There is a need for a receiver t=
o understand the purpose of each incoming stream.  The ways in which t=
his can be done are under
discussion.  As an example, App-Id/Rec=
eive-App-Id may be one way to handle this. 
[Bo] In any case, I think it will be unwise=
 to re-define anything, we should only clarify. 
[BA] I agree. 
[Bo] I hope to do that by including text th=
at describe SST and MST in taxonomy terms, 
but I still have difficulties to understand=
 exactly how to describe them.
 [BA] To be clear, my objection was no=
t to defining new terms Single Stream Transport and Multiple Stream Transpo=
rt ,but to redefining the meaning of the SST and MST

abbreviations used in RFC 6190.
--_000_BBE9739C2C302046BD34B42713A1E2A22E1258C8ESESSMB105erics_-- From nobody Thu Feb 13 15:41: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 6B6B91A04F3 for ; Thu, 13 Feb 2014 15:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=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 Gb1rkVT67mkp for ; Thu, 13 Feb 2014 15:41:32 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id DF2351A02E3 for ; Thu, 13 Feb 2014 15:41:31 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hn9so9364876wib.0 for ; Thu, 13 Feb 2014 15:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/4AaapO7IbpYUdeNPH+KTB0wTgzu+DRY5acDSnubBfY=; b=vxZ7Lj21R18df1MvnVAAcZ1A4RFrdC6qACj4v0C0fI9NlFIRWhjR4GnVYi9poXvrNe LgdbQPK9tJvz/Z/nLy1tE82SUCqRqiUgMtX6sM15p6w3E4CDwTtaaUxFpR+gUAMQwa9M Mn8KTXiVTAQMg4H9gGSdtakqo+VIWYYgdcLWxs1NgrnMHnyApV4NRG43x93v1a4dgdv3 aG0epS+JQQB3qr5Z0g+ufsEdnhJr2SVUx9qEqxAudtmoHMLg1iHdJB6kM9sSkSKVMBFl xhtws0MDSTxLQD4t7y2B3bSXJqguMdoutwaQu4B/qmIrzKk3F50ukxcYqGfIID12Rzdl 0QSA== MIME-Version: 1.0 X-Received: by 10.180.149.206 with SMTP id uc14mr8446266wib.44.1392334890192; Thu, 13 Feb 2014 15:41:30 -0800 (PST) Received: by 10.195.12.134 with HTTP; Thu, 13 Feb 2014 15:41:30 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Feb 2014 15:41:30 -0800 Message-ID: From: Suhas Nandakumar To: Bo Burman Content-Type: multipart/alternative; boundary=001a11c3800889ee6b04f2523a1f Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/9NooYVhhIkAIwnw4xNvHkYHioIQ Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 13 Feb 2014 23:41:35 -0000 --001a11c3800889ee6b04f2523a1f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Bo, I like this way of enumerating all the possibilities . Few comments inline. Cheers Suhas On Thu, Feb 13, 2014 at 3:26 PM, Bo Burman wrote: > I would then suggest to simply clarify that, as 6190 define them, both > SST and MST can use one or more Encoded Packet Streams (SSRC) per Media > Source. > > > > So, to elaborate, there is a SST-SingleStream with all scalable layers of > a Media Source sent in a single Packet Stream (with a single SSRC). > SST-MultiStream uses a single RTP Session where the scalable layers are > spread across multiple different Packet Streams. In MST-SS, the scalable > layers use multiple RTP Sessions, each carrying a single Packet Stream. > Finally, the scalable layers in MST-MS use multiple Packet Streams in eac= h > of the multiple RTP Sessions. > [Suhas] Can we make a 2X2 table and add the terms in the matching cells. Something on the lines below Single RTP Session Multiple RTP Sessions Single Packet Stream * SST-SingleStream * *MST-SS* Multiple Packet Streams * SST-MultiStream MST-MS= * I am thinking that this table will go along with the above definition and might aid in the clarity. > > Then there is the complication that scalable layers signaled as MST (in > SDP) that are also BUNDLE'd are in fact combined into a single RTP Sessio= n, > effectively becoming equivalent to SST-MS. > > > I think we need to make the above categorization independent of the underlying transport. but i do agree with your overall direction. > Comments? > > > *From:* Bernard Aboba [mailto:bernard_aboba@hotmail.com] > *Sent:* den 12 februari 2014 19:51 > *To:* Bo Burman; avtext@ietf.org > *Subject:* RE: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 > > > > Bo said: > > "So, to me it seems that multiple RTP streams are in fact not disallowed = by SST" > > [BA] Correct. There are some implementations that send multiple RTP stre= ams within a single session. > > [Bo Burman] > > "6190 is entirely silent on how such multiple streams would be mapped to = multiple SSRC. > > It in fact seems to be agnostic to the use of SSRC and (assumedly) relies= entirely on information in the SVC bitstream. Correct? " > > [BA] For multiple streams (whether sent on separate RTP sessions or the s= ame session), it is necessary to recover the decoding order > > across the multiple streams, as described in RFC 6190 Section 4.11. This= leads to multiple source transport requiring distinct packetization > > from that used in single source transport, as described in Section 5.2. = IMHO, this was a major mistake, which has lead to interoperability > > issues with H.264/SVC transport. That issue is being addressed in the HE= VC over RTP payload specification where there is no longer distinct > > packetization modes for SST and MST and DON support is mandatory. > > With respect to signaling, RFC 6190 provides examples of single session t= ransport (7.3.1, 7.3.2) and multi-session transport (7.3.3, 7.3.4), but doe= s not provide > > examples of how to signal multiple sources within the same session. Wit= h BUNDLE, RFC 5761 and RFC 5583 dependency groups, I believe this is > > now possible. However, since the topic is somewhat "bleeding edge" it w= ill probably not end up in the HEVC over RTP spec, even > > though that will cover temporal scalability. > > [Bo] > > In that case, can any number of SSRC be used to describe the SVC stream (= I know it SHOULD only be one) from a single Media Source? > > [BA] Yes, this has been implemented, and has been shown to have some adva= ntages. For example, when dropping a layer, > > sequence number rewriting can potentially be avoided. Also, FEC can be a= pplied to some layers and not others. > > [Bo] Furthermore, in another mail in this thread, I noted Magnus says th= ere is a specific problem in SST to handle multiple Media Sources (in taxon= omy terms, like multiple cameras) and to know which SSRC belongs to which M= edia Source. I tend to agree, given the above. > > [BA] There is a need for a receiver to understand the purpose of each in= coming stream. The ways in which this can be done are under > > discussion. As an example, App-Id/Receive-App-Id may be one way to handl= e this. > > [Bo] In any case, I think it will be unwise to re-define anything, we sho= uld only clarify. > > [BA] I agree. > > [Bo] I hope to do that by including text that describe SST and MST in tax= onomy terms, > > but I still have difficulties to understand exactly how to describe them. > > [BA] To be clear, my objection was not to defining new terms Single Stre= am Transport and Multiple Stream Transport ,but to redefining the meaning o= f the SST and MST > > abbreviations used in RFC 6190. > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > > --001a11c3800889ee6b04f2523a1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Bo,

  I like this way of enu= merating  all the possibilities . Few comments inline.

<= /div>
Cheers
Suhas


On Thu, Feb 13, 2014 at 3:26 PM, Bo Burman <bo.burman@ericsson.com> wrote:

I would then suggest to s= imply clarify that, as 6190 define them, both SST and MST can use one or mo= re Encoded Packet Streams (SSRC) per Media Source.

 

So, to elaborate, there i= s a SST-SingleStream with all scalable layers of a Media Source sent in a s= ingle Packet Stream (with a single SSRC). SST-MultiStream uses a single RTP Session where the scalable layers are spread across mult= iple different Packet Streams. In MST-SS, the scalable layers use multiple = RTP Sessions, each carrying a single Packet Stream. Finally, the scalable l= ayers in MST-MS use multiple Packet Streams in each of the multiple RTP Sessions.


[Suhas] Can we make a 2X2 table and add the term= s in the matching cells. Something on the lines below
  &nbs= p;                     &n= bsp;                     = Single RTP Session               Multipl= e RTP Sessions
  Single Packet Stream           &nbs= p;SST-SingleStream               &nb= sp;  MST-SS
  Multiple Packet Streams   &nb= sp;    SST-MultiStream           &nbs= p;        MST-MS

I am thin= king that this table will go along with the above definition and might aid = in the clarity.
 

 

Then there is the complic= ation that scalable layers signaled as MST (in SDP) that are also BUNDLE&rs= quo;d are in fact combined into a single RTP Session, effectively becoming equivalent to SST-MS.

 

<= /div>

I think we need to make the abo= ve categorization independent of the underlying transport. but i do agree w= ith your overall direction.

 

Comments?


 

 

Bo said: 

"So, to me it seems that multiple RTP =
streams are in fact not disallowed by SST"
[BA] Correct.  There are some implemen=
tations that send multiple RTP streams within a single session. <=
/u>
[Bo Burman]
"6190 is entirely silent on how such m=
ultiple streams would be mapped to multiple SSRC. 


It in fact seems to be agnostic to the use =
of SSRC and (assumedly) relies entirely on information in the SVC bitstream=
. Correct? "



[BA] For multiple streams (whether sent on =
separate RTP sessions or the same session), it is necessary to recover the =
decoding order



across the multiple streams, as described i=
n RFC 6190 Section 4.11.  This leads to multiple source transport requ=
iring distinct packetization



from that used in single source transport, =
as described in Section 5.2.  IMHO, this was a major mistake, which ha=
s lead to interoperability



issues with H.264/SVC transport.  That=
 issue is being addressed in the HEVC over RTP payload specification where =
there is no longer distinct



packetization modes for SST and MST and DON=
 support is mandatory. 


With respect to signaling, RFC 6190 provide=
s examples of single session transport (7.3.1, 7.3.2) and multi-session tra=
nsport (7.3.3, 7.3.4), but does not provide



examples of how to signal multiple sources =
within the same session.   With BUNDLE, RFC 5761 and RFC 5583 dep=
endency groups, I believe this is



now possible.   However, since th=
e topic is somewhat "bleeding edge" it will probably not end up i=
n the HEVC over RTP spec, even



though that will cover temporal scalability=
. 


[Bo]


In that case, can any number of SSRC be use=
d to describe the SVC stream (I know it SHOULD only be one) from a single M=
edia Source?



[BA] Yes, this has been implemented, and ha=
s been shown to have some advantages.  For example, when dropping a la=
yer, 



sequence number rewriting can potentially b=
e avoided.  Also, FEC can be applied to some layers and not others. 



 [Bo] Furthermore, in another mail in =
this thread, I noted Magnus says there is a specific problem in SST to hand=
le multiple Media Sources (in taxonomy terms, like multiple cameras) and to=
 know which SSRC belongs to which Media Source. I tend to agree, given the =
above.



 [BA] There is a need for a receiver t=
o understand the purpose of each incoming stream.  The ways in which t=
his can be done are under



discussion.  As an example, App-Id/Rec=
eive-App-Id may be one way to handle this. 


[Bo] In any case, I think it will be unwise=
 to re-define anything, we should only clarify. 



[BA] I agree. 


[Bo] I hope to do that by including text th=
at describe SST and MST in taxonomy terms, 


but I still have difficulties to understand=
 exactly how to describe them.


 [BA] To be clear, my objection was no=
t to defining new terms Single Stream Transport and Multiple Stream Transpo=
rt ,but to redefining the meaning of the SST and MST


abbreviations used in RFC 6190. <=
/u>

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


--001a11c3800889ee6b04f2523a1f-- From nobody Fri Feb 14 15:54: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 14D481A0078; Fri, 14 Feb 2014 15:54:48 -0800 (PST) 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 GzXTY66XCJLe; Fri, 14 Feb 2014 15:54:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB3A1A038B; Fri, 14 Feb 2014 15:54:46 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214235446.27950.19725.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:54:46 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/_3SkhfeoIW-HOAG3_TtyR_dGE1g Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-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, 14 Feb 2014 23:54:48 -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 : A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources Authors : Jonathan Lennox Kevin Gross Suhas Nandakumar Gonzalo Salgueiro Bo Burman Filename : draft-ietf-avtext-rtp-grouping-taxonomy-01.txt Pages : 45 Date : 2014-02-14 Abstract: The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-grouping-taxonomy-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 Mon Feb 24 11:17: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 C717C1A024A for ; Mon, 24 Feb 2014 11:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.57 X-Spam-Level: * X-Spam-Status: No, score=1.57 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 WZHdhMe-N2IV for ; Mon, 24 Feb 2014 11:17:28 -0800 (PST) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id E7B621A0235 for ; Mon, 24 Feb 2014 11:17:27 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/24/2014 2:17:26 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com 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-300/SG:5 2/24/2014 2:17:15 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.812818 p=-0.972222 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 31.201 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/24/2014 2:17:20 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: 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.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 100597681; Mon, 24 Feb 2014 14:17:25 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Mon, 24 Feb 2014 13:17:24 -0600 From: Jonathan Lennox To: Suhas Nandakumar Thread-Topic: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPJ4gk+DpeFSd18kW9VQ74Ql37kpqxrlUAgAmpJdyACeghgA== Date: Mon, 24 Feb 2014 19:17:23 +0000 Message-ID: <7F836EE4-B8EC-4DB6-B951-43AE428419B5@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: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_7F836EE4B8EC4DB6B95143AE428419B5vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/x6JC9lfydGSa1ejbDWN6sCpumc4 Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 24 Feb 2014 19:17:30 -0000 --_000_7F836EE4B8EC4DB6B95143AE428419B5vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable (As an individual) I think the important distinction, both from an implementation and a specif= ication perspective, is between single-stream and multi-stream transmission= . Multi-stream cases are where you have issues of separation and reassembl= y, stream association, and the like =97 where all the complexity arises. Whether those multiple streams are sent in multiple sessions or not seems l= ike a secondary issue. It=92s obviously important as an deployment choice,= and has some signaling implications, but I don=92t think it makes a lot of= difference for either implementation or media-level specification. On another point: in your table, I don=92t understand MST-SS. How can a si= ngle stream be sent in multiple sessions? Based on the latest version of t= he taxonomy draft, it seems like you=92re interpreting this as meaning mult= iple streams in multiple sessions, where the streams have the same SSRC. T= hat may be worth calling out as a special case (since it=92s the mode that = RFC 3550 defines for MST) but I think that calling that =93single stream=94= is not a good idea. They still have separate sequence number spaces, prob= ably timestamp spaces, feedback, etc. On Feb 13, 2014, at 6:41 PM, Suhas Nandakumar > wrote: Hello Bo, I like this way of enumerating all the possibilities . Few comments inli= ne. Cheers Suhas On Thu, Feb 13, 2014 at 3:26 PM, Bo Burman > wrote: I would then suggest to simply clarify that, as 6190 define them, both SST = and MST can use one or more Encoded Packet Streams (SSRC) per Media Source. So, to elaborate, there is a SST-SingleStream with all scalable layers of a= Media Source sent in a single Packet Stream (with a single SSRC). SST-Mult= iStream uses a single RTP Session where the scalable layers are spread acro= ss multiple different Packet Streams. In MST-SS, the scalable layers use mu= ltiple RTP Sessions, each carrying a single Packet Stream. Finally, the sca= lable layers in MST-MS use multiple Packet Streams in each of the multiple = RTP Sessions. [Suhas] Can we make a 2X2 table and add the terms in the matching cells. So= mething on the lines below Single RTP Session = Multiple RTP Sessions Single Packet Stream SST-SingleStream MST-SS Multiple Packet Streams SST-MultiStream MST-MS I am thinking that this table will go along with the above definition and m= ight aid in the clarity. Then there is the complication that scalable layers signaled as MST (in SDP= ) that are also BUNDLE=92d are in fact combined into a single RTP Session, = effectively becoming equivalent to SST-MS. I think we need to make the above categorization independent of the underly= ing transport. but i do agree with your overall direction. Comments? From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: den 12 februari 2014 19:51 To: Bo Burman; avtext@ietf.org Subject: RE: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Bo said: "So, to me it seems that multiple RTP streams are in fact not disallowed by= SST" [BA] Correct. There are some implementations that send multiple RTP stream= s within a single session. [Bo Burman] "6190 is entirely silent on how such multiple streams would be mapped to mu= ltiple SSRC. It in fact seems to be agnostic to the use of SSRC and (assumedly) relies e= ntirely on information in the SVC bitstream. Correct? " [BA] For multiple streams (whether sent on separate RTP sessions or the sam= e session), it is necessary to recover the decoding order across the multiple streams, as described in RFC 6190 Section 4.11. This l= eads to multiple source transport requiring distinct packetization from that used in single source transport, as described in Section 5.2. IM= HO, this was a major mistake, which has lead to interoperability issues with H.264/SVC transport. That issue is being addressed in the HEVC= over RTP payload specification where there is no longer distinct packetization modes for SST and MST and DON support is mandatory. With respect to signaling, RFC 6190 provides examples of single session tra= nsport (7.3.1, 7.3.2) and multi-session transport (7.3.3, 7.3.4), but does = not provide examples of how to signal multiple sources within the same session. With = BUNDLE, RFC 5761 and RFC 5583 dependency groups, I believe this is now possible. However, since the topic is somewhat "bleeding edge" it wil= l probably not end up in the HEVC over RTP spec, even though that will cover temporal scalability. [Bo] In that case, can any number of SSRC be used to describe the SVC stream (I = know it SHOULD only be one) from a single Media Source? [BA] Yes, this has been implemented, and has been shown to have some advant= ages. For example, when dropping a layer, sequence number rewriting can potentially be avoided. Also, FEC can be app= lied to some layers and not others. [Bo] Furthermore, in another mail in this thread, I noted Magnus says ther= e is a specific problem in SST to handle multiple Media Sources (in taxonom= y terms, like multiple cameras) and to know which SSRC belongs to which Med= ia Source. I tend to agree, given the above. [BA] There is a need for a receiver to understand the purpose of each inco= ming stream. The ways in which this can be done are under discussion. As an example, App-Id/Receive-App-Id may be one way to handle = this. [Bo] In any case, I think it will be unwise to re-define anything, we shoul= d only clarify. [BA] I agree. [Bo] I hope to do that by including text that describe SST and MST in taxon= omy terms, but I still have difficulties to understand exactly how to describe them. [BA] To be clear, my objection was not to defining new terms Single Stream= Transport and Multiple Stream Transport ,but to redefining the meaning of = the SST and MST abbreviations used in RFC 6190. _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_7F836EE4B8EC4DB6B95143AE428419B5vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9EFED4A885B0A14CA063128879B504D6@vidyo.com> Content-Transfer-Encoding: quoted-printable
(As an individual)

I think the important distinction, both from an implementation and a s= pecification perspective, is between single-stream and multi-stream transmi= ssion.  Multi-stream cases are where you have issues of separation and= reassembly, stream association, and the like =97 where all the complexity arises.

Whether those multiple streams are sent in multiple sessions or not se= ems like a secondary issue.  It=92s obviously important as an deployme= nt choice, and has some signaling implications, but I don=92t think it make= s a lot of difference for either implementation or media-level specification.

On another point: in your table, I don=92t understand MST-SS.  Ho= w can a single stream be sent in multiple sessions?  Based on the late= st version of the taxonomy draft, it seems like you=92re interpreting this = as meaning multiple streams in multiple sessions, where the streams have the same SSRC.  That may be worth calling out = as a special case (since it=92s the mode that RFC 3550 defines for MST) but= I think that calling that =93single stream=94 is not a good idea.  Th= ey still have separate sequence number spaces, probably timestamp spaces, feedback, etc.

On Feb 13, 2014, at 6:41 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:

Hello Bo,

  I like this way of enumerating  all the possibilities . Fe= w comments inline.

Cheers
Suhas


On Thu, Feb 13, 2014 at 3:26 PM, Bo Burman <bo.burman@e= ricsson.com> wrote:

I would then suggest to s= imply clarify that, as 6190 define them, both SST and MST can use one or mo= re Encoded Packet Streams (SSRC) per Media Source.

 

So, to elaborate, there i= s a SST-SingleStream with all scalable layers of a Media Source sent in a s= ingle Packet Stream (with a single SSRC). SST-MultiStream uses a single RTP Session where the scalable layers are spread across mult= iple different Packet Streams. In MST-SS, the scalable layers use multiple = RTP Sessions, each carrying a single Packet Stream. Finally, the scalable l= ayers in MST-MS use multiple Packet Streams in each of the multiple RTP Sessions.


[Suhas] Can we make a 2X2 table and add the terms in the matching cell= s. Something on the lines below
                    =                      = ;     Single RTP Session            = ;   Multiple RTP Sessions
  Single Packet Stream           &nbs= p;SST-SingleStream               &nb= sp;  MST-SS
  Multiple Packet Streams        SST-Multi= Stream                    = ;MST-MS

I am thinking that this table will go along with the above definition = and might aid in the clarity.
 

 

Then there is the complic= ation that scalable layers signaled as MST (in SDP) that are also BUNDLE=92= d are in fact combined into a single RTP Session, effectively becoming equivalent to SST-MS.

 


I think we need to make the above categorization independent of the un= derlying transport. but i do agree with your overall direction.

 

Comments?


 

From: Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: den 12 februari 2014 19:51
To: Bo Burman; = avtext@ietf.org
Subject: RE: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00<= /u>

 

Bo said: 

"So, to me it seems that multiple RTP =
streams are in fact not disallowed by SST"
[BA] Correct.  There are some implemen=
tations that send multiple RTP streams within a single session. <=
/u>
[Bo Burman]
"6190 is entirely silent on how such m=
ultiple streams would be mapped to multiple SSRC. 

It in fact seems to be agnostic to the use =
of SSRC and (assumedly) relies entirely on information in the SVC bitstream=
. Correct? "


[BA] For multiple streams (whether sent on =
separate RTP sessions or the same session), it is necessary to recover the =
decoding order


across the multiple streams, as described i=
n RFC 6190 Section 4.11.  This leads to multiple source transport requ=
iring distinct packetization


from that used in single source transport, =
as described in Section 5.2.  IMHO, this was a major mistake, which ha=
s lead to interoperability


issues with H.264/SVC transport.  That=
 issue is being addressed in the HEVC over RTP payload specification where =
there is no longer distinct


packetization modes for SST and MST and DON=
 support is mandatory. 


With respect to signaling, RFC 6190 provide=
s examples of single session transport (7.3.1, 7.3.2) and multi-session tra=
nsport (7.3.3, 7.3.4), but does not provide


examples of how to signal multiple sources =
within the same session.   With BUNDLE, RFC 5761 and RFC 5583 dep=
endency groups, I believe this is


now possible.   However, since th=
e topic is somewhat "bleeding edge" it will probably not end up i=
n the HEVC over RTP spec, even


though that will cover temporal scalability=
. 


[Bo]


In that case, can any number of SSRC be use=
d to describe the SVC stream (I know it SHOULD only be one) from a single M=
edia Source?


[BA] Yes, this has been implemented, and ha=
s been shown to have some advantages.  For example, when dropping a la=
yer, 


sequence number rewriting can potentially b=
e avoided.  Also, FEC can be applied to some layers and not others. 


 [Bo] Furthermore, in another mail in =
this thread, I noted Magnus says there is a specific problem in SST to hand=
le multiple Media Sources (in taxonomy terms, like multiple cameras) and to=
 know which SSRC belongs to which Media Source. I tend to agree, given the =
above.


 [BA] There is a need for a receiver t=
o understand the purpose of each incoming stream.  The ways in which t=
his can be done are under


discussion.  As an example, App-Id/Rec=
eive-App-Id may be one way to handle this. 


[Bo] In any case, I think it will be unwise=
 to re-define anything, we should only clarify. 


[BA] I agree. 


[Bo] I hope to do that by including text th=
at describe SST and MST in taxonomy terms, 


but I still have difficulties to understand=
 exactly how to describe them.


 [BA] To be clear, my objection was no=
t to defining new terms Single Stream Transport and Multiple Stream Transpo=
rt ,but to redefining the meaning of the SST and MST

abbreviations used in RFC 6190. <=
/u>

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


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

--_000_7F836EE4B8EC4DB6B95143AE428419B5vidyocom_-- From nobody Tue Feb 25 00:22: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 ACCC51A042C for ; Tue, 25 Feb 2014 00:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.461 X-Spam-Level: * X-Spam-Status: No, score=1.461 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=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 IkRgIfV57l0e for ; Tue, 25 Feb 2014 00:22:29 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id B68821A0363 for ; Tue, 25 Feb 2014 00:22:28 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-3b-530c52c37178 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 7A.E7.04853.3C25C035; Tue, 25 Feb 2014 09:22:27 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.166]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Tue, 25 Feb 2014 09:22:26 +0100 From: Bo Burman To: Jonathan Lennox , Suhas Nandakumar Thread-Topic: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPJ4gk+DpeFSd18kW9VQ74Ql37kpqxrlUAgAA4rQCAAdTpEIAADn4AgBD/2oCAAOXXAA== Date: Tue, 25 Feb 2014 08:22:26 +0000 Message-ID: References: <7F836EE4-B8EC-4DB6-B951-43AE428419B5@vidyo.com> In-Reply-To: <7F836EE4-B8EC-4DB6-B951-43AE428419B5@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.16] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E15A279ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RvdwEE+wwZK7shYf791gtdi/+Dyz xc65HcwOzB47Z91l91iy5CeTR9uzO+wBzFFcNimpOZllqUX6dglcGf0rXAqePmCsuD/nG1sD 4+LDjF2MnBwSAiYSjftPsUPYYhIX7q1n62Lk4hASOMEo8XfLaSYIZwmjxLOZG1hBqtgENCTm 77gL1i0iECQx5fxUJhCbWUBd4vC+JWBxYQEHiV3rV7BB1DhKzLs3gwXCDpNYs+MGM4jNIqAq Mf/aMzCbV8BX4s+7fWBXCAm8ZpI4dUQHxOYUsJVY27ILbD6jgKzE/e/3WCB2iUvcejKfCeJq AYkle84zQ9iiEi8f/2OFsBUldp5tZ4aoz5f43NrOCrFLUOLkzCcsExhFZyEZNQtJ2SwkZRBx HYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo2RxanFxbrqRgV5uem6JXmpRZnJxcX6eXnHq JkZgPB7c8ttoB+PJPfaHGKU5WJTEea+z1gQJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYAxz 6L+6u7fIJPcfCzPbsvfprd6nGmvTJ1ttDEvZ9FrYeeaNFL2l8065fFh7J/fv5JACm/IH2t7S f7rD04rmNSvyP/+zjPncmpyvP2//NTt0zJj5UfWTuuuHGSwzRNdL7Lh8e9f2enfGx0vUNz4X bziZryJs3p1+1fyH3N5plh9jtNVFZa3KeZVYijMSDbWYi4oTAaP+ppOVAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/hdfCEWuzHqvDhegWWnUdezjGqiY Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 25 Feb 2014 08:22:33 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E15A279ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: den 24 februari 2014 20:17 To: Suhas Nandakumar Cc: Bo Burman; avtext@ietf.org Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 (As an individual) I think the important distinction, both from an implementation and a specif= ication perspective, is between single-stream and multi-stream transmission= . Multi-stream cases are where you have issues of separation and reassembl= y, stream association, and the like - where all the complexity arises. [BoB] Agree Whether those multiple streams are sent in multiple sessions or not seems l= ike a secondary issue. It's obviously important as an deployment choice, a= nd has some signaling implications, but I don't think it makes a lot of dif= ference for either implementation or media-level specification. [BoB] Again, agree. One of the major points I wanted to make was that "SST"= not necessarily means that only a single stream is used. On another point: in your table, I don't understand MST-SS. How can a sing= le stream be sent in multiple sessions? Based on the latest version of the= taxonomy draft, it seems like you're interpreting this as meaning multiple= streams in multiple sessions, where the streams have the same SSRC. That = may be worth calling out as a special case (since it's the mode that RFC 35= 50 defines for MST) but I think that calling that "single stream" is not a = good idea. They still have separate sequence number spaces, probably times= tamp spaces, feedback, etc. [BoB] That was not my intent with MST-SS; it is multiple streams in total, = yes, but only a single stream, single SSRC, per RTP Session. MST-MS would u= se multiple streams, multiple SSRC, in each of the multiple RTP Sessions. T= he distinction between SS and MS is thus use of multiple SSRC or not in an = RTP Session. On Feb 13, 2014, at 6:41 PM, Suhas Nandakumar > wrote: Hello Bo, I like this way of enumerating all the possibilities . Few comments inli= ne. Cheers Suhas On Thu, Feb 13, 2014 at 3:26 PM, Bo Burman > wrote: I would then suggest to simply clarify that, as 6190 define them, both SST = and MST can use one or more Encoded Packet Streams (SSRC) per Media Source. So, to elaborate, there is a SST-SingleStream with all scalable layers of a= Media Source sent in a single Packet Stream (with a single SSRC). SST-Mult= iStream uses a single RTP Session where the scalable layers are spread acro= ss multiple different Packet Streams. In MST-SS, the scalable layers use mu= ltiple RTP Sessions, each carrying a single Packet Stream. Finally, the sca= lable layers in MST-MS use multiple Packet Streams in each of the multiple = RTP Sessions. [Suhas] Can we make a 2X2 table and add the terms in the matching cells. So= mething on the lines below Single RTP Session = Multiple RTP Sessions Single Packet Stream SST-SingleStream MST-SS Multiple Packet Streams SST-MultiStream MST-MS I am thinking that this table will go along with the above definition and m= ight aid in the clarity. Then there is the complication that scalable layers signaled as MST (in SDP= ) that are also BUNDLE'd are in fact combined into a single RTP Session, ef= fectively becoming equivalent to SST-MS. I think we need to make the above categorization independent of the underly= ing transport. but i do agree with your overall direction. Comments? From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: den 12 februari 2014 19:51 To: Bo Burman; avtext@ietf.org Subject: RE: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Bo said: "So, to me it seems that multiple RTP streams are in fact not disallowed by= SST" [BA] Correct. There are some implementations that send multiple RTP stream= s within a single session. [Bo Burman] "6190 is entirely silent on how such multiple streams would be mapped to mu= ltiple SSRC. It in fact seems to be agnostic to the use of SSRC and (assumedly) relies e= ntirely on information in the SVC bitstream. Correct? " [BA] For multiple streams (whether sent on separate RTP sessions or the sam= e session), it is necessary to recover the decoding order across the multiple streams, as described in RFC 6190 Section 4.11. This l= eads to multiple source transport requiring distinct packetization from that used in single source transport, as described in Section 5.2. IM= HO, this was a major mistake, which has lead to interoperability issues with H.264/SVC transport. That issue is being addressed in the HEVC= over RTP payload specification where there is no longer distinct packetization modes for SST and MST and DON support is mandatory. With respect to signaling, RFC 6190 provides examples of single session tra= nsport (7.3.1, 7.3.2) and multi-session transport (7.3.3, 7.3.4), but does = not provide examples of how to signal multiple sources within the same session. With = BUNDLE, RFC 5761 and RFC 5583 dependency groups, I believe this is now possible. However, since the topic is somewhat "bleeding edge" it wil= l probably not end up in the HEVC over RTP spec, even though that will cover temporal scalability. [Bo] In that case, can any number of SSRC be used to describe the SVC stream (I = know it SHOULD only be one) from a single Media Source? [BA] Yes, this has been implemented, and has been shown to have some advant= ages. For example, when dropping a layer, sequence number rewriting can potentially be avoided. Also, FEC can be app= lied to some layers and not others. [Bo] Furthermore, in another mail in this thread, I noted Magnus says ther= e is a specific problem in SST to handle multiple Media Sources (in taxonom= y terms, like multiple cameras) and to know which SSRC belongs to which Med= ia Source. I tend to agree, given the above. [BA] There is a need for a receiver to understand the purpose of each inco= ming stream. The ways in which this can be done are under discussion. As an example, App-Id/Receive-App-Id may be one way to handle = this. [Bo] In any case, I think it will be unwise to re-define anything, we shoul= d only clarify. [BA] I agree. [Bo] I hope to do that by including text that describe SST and MST in taxon= omy terms, but I still have difficulties to understand exactly how to describe them. [BA] To be clear, my objection was not to defining new terms Single Stream= Transport and Multiple Stream Transport ,but to redefining the meaning of = the SST and MST abbreviations used in RFC 6190. _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_BBE9739C2C302046BD34B42713A1E2A22E15A279ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline<= /p>

 <= /p>

From: Jonathan= Lennox [mailto:jonathan@vidyo.com]
Sent: den 24 februari 2014 20:17
To: Suhas Nandakumar
Cc: Bo Burman; avtext@ietf.org
Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00

 

(As an individual)

 

I think the important distinction, both from an impl= ementation and a specification perspective, is between single-stream and mu= lti-stream transmission.  Multi-stream cases are where you have issues= of separation and reassembly, stream association, and the like — where all the complexity arises.

[BoB] Agree<= /i>

 

Whether those multiple streams are sent in multiple = sessions or not seems like a secondary issue.  It’s obviously im= portant as an deployment choice, and has some signaling implications, but I= don’t think it makes a lot of difference for either implementation or media-level specification.

[BoB] Again, agree.= One of the major points I wanted to make was that “SST” not ne= cessarily means that only a single stream is used.

 

On another point: in your table, I don’t under= stand MST-SS.  How can a single stream be sent in multiple sessions? &= nbsp;Based on the latest version of the taxonomy draft, it seems like you&#= 8217;re interpreting this as meaning multiple streams in multiple sessions, where the streams have the same SSRC.  That may be= worth calling out as a special case (since it’s the mode that RFC 35= 50 defines for MST) but I think that calling that “single stream̶= 1; is not a good idea.  They still have separate sequence number spaces, probably timestamp spaces, feedback, etc.

[BoB] That was not = my intent with MST-SS; it is multiple streams in total, yes, but only a sin= gle stream, single SSRC, per RTP Session. MST-MS would use multiple streams, multiple SSRC, i= n each of the multiple RTP Sessions. The distinction between SS and MS is t= hus use of multiple SSRC or not in an RTP Session.

 

On Feb 13, 2014, at 6:41 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:



Hello Bo,

 

  I like this way of enumerating  all the = possibilities . Few comments inline.

 

Cheers

Suhas

 

On Thu, Feb 13, 2014 at 3:26 PM, Bo Burman <bo.burman@ericsson.c= om> wrote:

I would then suggest to simply clarify = that, as 6190 define them, both SST and MST can use one or more Encoded Packet Streams (SSRC) per Media Source.

 

So, to elaborate, there is a SST-Single= Stream with all scalable layers of a Media Source sent in a single Packet Stream (with a single SSRC). SST-MultiStream uses a single= RTP Session where the scalable layers are spread across multiple different= Packet Streams. In MST-SS, the scalable layers use multiple RTP Sessions, = each carrying a single Packet Stream. Finally, the scalable layers in MST-MS use multiple Packet Streams in each= of the multiple RTP Sessions.

 

[Suhas] Can we make a 2X2 table and add the terms in= the matching cells. Something on the lines below

              &nb= sp;                     &= nbsp;         Single RTP Session       &= nbsp;       Multiple RTP Sessions

  Single Packet Stream       &nb= sp;    SST-SingleStream          =        MST-SS

  Multiple Packet Streams       =  SST-MultiStream               &= nbsp;    MST-MS

 

I am thinking that this table will go along with the= above definition and might aid in the clarity.

 

 

 

Then there is the complication that sca= lable layers signaled as MST (in SDP) that are also BUNDLE’d are in fact combined into a single RTP Session, effectively becoming equiv= alent to SST-MS.

 

 

I think we need to make the above categorization ind= ependent of the underlying transport. but i do agree with your overall dire= ction.

 

 

Comments?

 

 

From: Bernard Aboba [mailto:= bernard_abob= a@hotmail.com]
Sent: den 12 februari 2014 19:51
To: Bo Burman; = avtext@ietf.org
Subject: RE: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00

 

Bo said: 

"So, to me it seems that multiple RTP =
streams are in fact not disallowed by SST"
[BA] Correct.  There are some implemen=
tations that send multiple RTP streams within a single session. 
[Bo Burman]
"6190 is entirely silent on how such m=
ultiple streams would be mapped to multiple SSRC. 
It in fact seems to be agnostic to the use =
of SSRC and (assumedly) relies entirely on information in the SVC bitstream=
. Correct? "
[BA] For multiple streams (whether sent on =
separate RTP sessions or the same session), it is necessary to recover the =
decoding order
across the multiple streams, as described i=
n RFC 6190 Section 4.11.  This leads to multiple source transport requ=
iring distinct packetization
from that used in single source transport, =
as described in Section 5.2.  IMHO, this was a major mistake, which ha=
s lead to interoperability
issues with H.264/SVC transport.  That=
 issue is being addressed in the HEVC over RTP payload specification where =
there is no longer distinct
packetization modes for SST and MST and DON=
 support is mandatory. 
With respect to signaling, RFC 6190 provide=
s examples of single session transport (7.3.1, 7.3.2) and multi-session tra=
nsport (7.3.3, 7.3.4), but does not provide
examples of how to signal multiple sources =
within the same session.   With BUNDLE, RFC 5761 and RFC 5583 dep=
endency groups, I believe this is
now possible.   However, since th=
e topic is somewhat "bleeding edge" it will probably not end up i=
n the HEVC over RTP spec, even
though that will cover temporal scalability=
. 
[Bo]
In that case, can any number of SSRC be use=
d to describe the SVC stream (I know it SHOULD only be one) from a single M=
edia Source?
[BA] Yes, this has been implemented, and ha=
s been shown to have some advantages.  For example, when dropping a la=
yer, 
sequence number rewriting can potentially b=
e avoided.  Also, FEC can be applied to some layers and not others. 
 [Bo] Furthermore, in another mail in =
this thread, I noted Magnus says there is a specific problem in SST to hand=
le multiple Media Sources (in taxonomy terms, like multiple cameras) and to=
 know which SSRC belongs to which Media Source. I tend to agree, given the =
above.
 [BA] There is a need for a receiver t=
o understand the purpose of each incoming stream.  The ways in which t=
his can be done are under
discussion.  As an example, App-Id/Rec=
eive-App-Id may be one way to handle this. 
[Bo] In any case, I think it will be unwise=
 to re-define anything, we should only clarify. 
[BA] I agree. 
[Bo] I hope to do that by including text th=
at describe SST and MST in taxonomy terms, 
but I still have difficulties to understand=
 exactly how to describe them.
 [BA] To be clear, my objection was no=
t to defining new terms Single Stream Transport and Multiple Stream Transpo=
rt ,but to redefining the meaning of the SST and MST

abbreviations used in RFC 6190.


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

 

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

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E15A279ESESSMB105erics_-- From nobody Tue Feb 25 07:35: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 57CF21A078E for ; Tue, 25 Feb 2014 07:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.57 X-Spam-Level: * X-Spam-Status: No, score=1.57 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 3-9J7mSCzZn6 for ; Tue, 25 Feb 2014 07:35:36 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id EEEAC1A0033 for ; Tue, 25 Feb 2014 07:35:24 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/25/2014 10:35:23 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com 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-160/SG:5 2/25/2014 10:34:33 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.876497 p=-0.976932 Source White X-Signature-Violations: 0-0-0-12688-c X-Note-419: 0 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/25/2014 10:35:07 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL 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: 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.2) with ESMTPS id 100912912; Tue, 25 Feb 2014 10:35:23 -0500 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; Tue, 25 Feb 2014 09:35:22 -0600 From: Jonathan Lennox To: Bo Burman Thread-Topic: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPJ4gk+DpeFSd18kW9VQ74Ql37kpqxrlUAgAmpJdyACeghgIAA21gAgAB494A= Date: Tue, 25 Feb 2014 15:35:21 +0000 Message-ID: <3FD0BC33-4223-4A9D-BB02-93027D4E51B6@vidyo.com> References: <7F836EE4-B8EC-4DB6-B951-43AE428419B5@vidyo.com> In-Reply-To: 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: multipart/alternative; boundary="_000_3FD0BC3342234A9DBB0293027D4E51B6vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/RRTP4KwASJBecMAk42S0himh5RQ Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 25 Feb 2014 15:35:38 -0000 --_000_3FD0BC3342234A9DBB0293027D4E51B6vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Feb 25, 2014, at 3:22 AM, Bo Burman > wrote: Inline Similarly On another point: in your table, I don=92t understand MST-SS. How can a si= ngle stream be sent in multiple sessions? Based on the latest version of t= he taxonomy draft, it seems like you=92re interpreting this as meaning mult= iple streams in multiple sessions, where the streams have the same SSRC. T= hat may be worth calling out as a special case (since it=92s the mode that = RFC 3550 defines for MST) but I think that calling that =93single stream=94= is not a good idea. They still have separate sequence number spaces, prob= ably timestamp spaces, feedback, etc. [BoB] That was not my intent with MST-SS; it is multiple streams in total, = yes, but only a single stream, single SSRC, per RTP Session. MST-MS would u= se multiple streams, multiple SSRC, in each of the multiple RTP Sessions. T= he distinction between SS and MS is thus use of multiple SSRC or not in an = RTP Session. Okay, I see the distinction you=92re making; but I think the terminology yo= u=92ve chosen is confusing. The top-level distinction, I think, needs to be between single-stream and m= ulti-stream transmission. Then there are distinctions between various ways= of transmitting the streams that make up multi-stream transmission. Personally, I would retroactively redefine the acronyms SST and MST as =93s= ingle-stream transmission=94 and =93multi-stream transmission=94, despite 6= 190. At least in my personal recollection, when 6190 was being written, no= one thought there was a use case for multi-stream transmission in a single= session =97 and indeed, there was some desire to discourage it from being = used =97 so single-stream and single-session mode were thought of as basica= lly synonymous. Or if you think this would be confusing, we could instead come up with alte= rnate terms for the two modes. But I think that the grid where you imply t= hat single/multiple stream and single/multiple session are orthogonal choic= es is a bad idea. --_000_3FD0BC3342234A9DBB0293027D4E51B6vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 25, 2014, at 3:22 AM, Bo Burman <bo.burman@ericsson.com> wrote:

Inline

Similarly

On another point: in your table, I don=92t understand MST-SS.  How can= a single stream be sent in multiple sessions?  Based on the latest ve= rsion of the taxonomy draft, it seems like you=92re interpreting this as me= aning multiple streams in multiple sessions, where the streams have the same SSRC.  That may be worth calling out as a s= pecial case (since it=92s the mode that RFC 3550 defines for MST) but I thi= nk that calling that =93single stream=94 is not a good idea.  They sti= ll have separate sequence number spaces, probably timestamp spaces, feedback, etc.
[BoB] That was not my intent with MST-SS; it is mult= iple streams in total, yes, but only a single stream, single SSRC, per RTP Session. MST-MS would use multiple streams, multiple SSRC, in each= of the multiple RTP Sessions. The distinction between SS and MS is thus us= e of multiple SSRC or not in an RTP Session.

Okay, I see the distinction you=92re making; but I think the terminolo= gy you=92ve chosen is confusing.

The top-level distinction, I think, needs to be between single-stream = and multi-stream transmission.  Then there are distinctions between va= rious ways of transmitting the streams that make up multi-stream transmissi= on.

Personally, I would retroactively redefine the acronyms SST and MST as= =93single-stream transmission=94 and =93multi-stream transmission=94, desp= ite 6190.  At least in my personal recollection, when 6190 was being w= ritten, no one thought there was a use case for multi-stream transmission in a single session =97 and indeed, there was so= me desire to discourage it from being used =97 so single-stream and single-= session mode were thought of as basically synonymous.

Or if you think this would be confusing, we could instead come up with= alternate terms for the two modes.  But I think that the grid where y= ou imply that single/multiple stream and single/multiple session are orthog= onal choices is a bad idea.
--_000_3FD0BC3342234A9DBB0293027D4E51B6vidyocom_-- From nobody Tue Feb 25 08:27:32 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 C34561A0158 for ; Tue, 25 Feb 2014 08:27:30 -0800 (PST) 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 7fh-au_rXBMB for ; Tue, 25 Feb 2014 08:27:29 -0800 (PST) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id 82EEF1A0132 for ; Tue, 25 Feb 2014 08:27:29 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/25/2014 11:27:27 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-160/SG:2 2/25/2014 11:26:34 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.880184 p=-0.977353 Source White X-Signature-Violations: 0-0-0-3542-c X-Note-419: 15.6005 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/25/2014 11:27:11 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL 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: 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.2) with ESMTPS id 100944436 for avtext@ietf.org; Tue, 25 Feb 2014 11:27:27 -0500 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; Tue, 25 Feb 2014 10:27:26 -0600 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: AVTExt agenda for IETF 89 Thread-Index: AQHPMkZ4NJ8sNCvH2UOMOtV+R6IMmg== Date: Tue, 25 Feb 2014 16:27:26 +0000 Message-ID: <915255C6-D5C8-41E3-9F32-D837863A4DF0@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/yxs0AbMvJ4QezIOVbQadMJw5FL0 Subject: [avtext] AVTExt agenda for IETF 89 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, 25 Feb 2014 16:27:31 -0000 This is the proposed agenda for AVTExt for IETF 89. Please send any comments or requested changes to the chairs, or to the list= . 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 16:05 - 18:30 (Buckingham) Note: The meeting of the AVTEXT working group will follow the STRAW working group. STRAW is scheduled to meet from 15:20 - 16:05, in the same room. The starting time is approximate, so do not rely on a specific time for where one group finishes and the other starts. If STRAW has some interesting and constructive discussions, they may carry on a bit longer. Conversely, AVTEXT will start as soon as STRAW finishes, and if that is early, then AVTEXT will make use of the time. Chairs: Keith Drage / Jonathan Lennox 16:05 Agenda bash and status update (10 min) Chairs draft-ietf-avtext-multiple-clock-rates-11 draft-ietf-avtext-rtp-duplication-05 16:15 Taxonomy (60 min) Bo Burman draft-ietf-avtext-rtp-grouping-taxonomy-01 17:15 RTP Media Stream Pause and Resume (15 min) Bo Burman draft-westerlund-avtext-rtp-stream-pause-05 17:30 RTP/RTCP extension for RTP Splicing Notification (15 min) Roni Even draft-xia-avtext-splicing-notification-03 17:45 Close From nobody Tue Feb 25 09:18:21 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 F2A131A016C for ; Tue, 25 Feb 2014 09:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.57 X-Spam-Level: * X-Spam-Status: No, score=1.57 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 5YXQBIKUKcAX for ; Tue, 25 Feb 2014 09:18:16 -0800 (PST) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4E86B1A0111 for ; Tue, 25 Feb 2014 09:18:16 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/25/2014 12:18:14 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-255/SG:5 2/25/2014 12:17:36 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.883217 p=-0.978009 Source White X-Signature-Violations: 0-0-0-11654-c X-Note-419: 78.0025 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/25/2014 12:18:15 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL 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: 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.2) with ESMTPS id 100975213 for avtext@ietf.org; Tue, 25 Feb 2014 12:18:14 -0500 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; Tue, 25 Feb 2014 11:18:13 -0600 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: AVTExt agenda for IETF 89 [day corrected] Thread-Index: AQHPMk2QsV4xZ2zdaEKG0ZuOuQImCQ== Date: Tue, 25 Feb 2014 17:18:13 +0000 Message-ID: <3BFC8032-4128-42C2-BCA2-E22BF2755F07@vidyo.com> References: <915255C6-D5C8-41E3-9F32-D837863A4DF0@vidyo.com> In-Reply-To: <915255C6-D5C8-41E3-9F32-D837863A4DF0@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: multipart/alternative; boundary="_000_3BFC8032412842C2BCA2E22BF2755F07vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/B5O5VvvLsek4d8aLUfOODZdPPww Subject: [avtext] AVTExt agenda for IETF 89 [day corrected] 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, 25 Feb 2014 17:18:18 -0000 --_000_3BFC8032412842C2BCA2E22BF2755F07vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There was a typo in the day in the original message =97 the AVTExt meeting = at IETF 89 is on *Thursday*. Thanks to Colin Perkins for catching this! Please send any further comments or requested changes to the chairs, or to = the list. 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 Thurdsay 16:05 - 18:30 (Buckingham) Note: The meeting of the AVTEXT working group will follow the STRAW working group. STRAW is scheduled to meet from 15:20 - 16:05, in the same room. The starting time is approximate, so do not rely on a specific time for where one group finishes and the other starts. If STRAW has some interesting and constructive discussions, they may carry on a bit longer. Conversely, AVTEXT will start as soon as STRAW finishes, and if that is early, then AVTEXT will make use of the time. Chairs: Keith Drage / Jonathan Lennox 16:05 Agenda bash and status update (10 min) Chairs draft-ietf-avtext-multiple-clock-rates-11 draft-ietf-avtext-rtp-duplication-05 16:15 Taxonomy (60 min) Bo Burman draft-ietf-avtext-rtp-grouping-taxonomy-01 17:15 RTP Media Stream Pause and Resume (15 min) Bo Burman draft-westerlund-avtext-rtp-stream-pause-05 17:30 RTP/RTCP extension for RTP Splicing Notification (15 min) Roni Even draft-xia-avtext-splicing-notification-03 17:45 Close --_000_3BFC8032412842C2BCA2E22BF2755F07vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
There was a typo in the day in the original message =97 the AVTExt mee= ting at IETF 89 is on *Thursday*.  Thanks to Colin Perkins for catchin= g this!

Please send any further comments or requested changes to the chairs, o= r to the list.

AVTEXT Aud= io/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

Thurdsay 1= 6:05 - 18:30 (Buckingham)

Note: The = meeting of the AVTEXT working group will follow the STRAW
working gr= oup.  STRAW is scheduled to meet from 15:20 - 16:05, in the
same room.=

The starti= ng time is approximate, so do not rely on a specific time
for where = one group finishes and the other starts. If STRAW has some
interestin= g and constructive discussions, they may carry on a bit
longer.&nb= sp; Conversely, AVTEXT will start as soon as STRAW finishes, and
if that is= early, then AVTEXT will make use of the time.


Chairs: Ke= ith Drage / Jonathan Lennox

16:05 Agen= da bash and status update (10 min)

  &nb= sp;   Chairs

  &nb= sp;   draft-ietf-avtext-multiple-clock-rates-11
  &nb= sp;   draft-ietf-avtext-rtp-duplication-05

16:15 Taxo= nomy (60 min)

  &nb= sp;   Bo Burman

  &nb= sp;   draft-ietf-avtext-rtp-grouping-taxonomy-01

17:15 RTP = Media Stream Pause and Resume (15 min)

  &nb= sp;   Bo Burman

  &nb= sp;   draft-westerlund-avtext-rtp-stream-pause-05

17:30 RTP/= RTCP extension for RTP Splicing Notification (15 min)

  &nb= sp;   Roni Even

  &nb= sp;   draft-xia-avtext-splicing-notification-03

17:45 Clos= e





--_000_3BFC8032412842C2BCA2E22BF2755F07vidyocom_-- From nobody Wed Feb 26 00:50: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 B4B7E1A012C for ; Wed, 26 Feb 2014 00:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, 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 N5iqTzZLqNGQ for ; Wed, 26 Feb 2014 00:50:08 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A8E5D1A0103 for ; Wed, 26 Feb 2014 00:50:07 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-f8-530daabd8c72 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CC.1C.10875.DBAAD035; Wed, 26 Feb 2014 09:50:06 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.166]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Wed, 26 Feb 2014 09:50:05 +0100 From: Bo Burman To: Jonathan Lennox Thread-Topic: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPJ4gk+DpeFSd18kW9VQ74Ql37kpqxrlUAgAA4rQCAAdTpEIAADn4AgBD/2oCAAOXXAIAAbnSAgAEuMsA= Date: Wed, 26 Feb 2014 08:50:04 +0000 Message-ID: References: <7F836EE4-B8EC-4DB6-B951-43AE428419B5@vidyo.com> <3FD0BC33-4223-4A9D-BB02-93027D4E51B6@vidyo.com> In-Reply-To: <3FD0BC33-4223-4A9D-BB02-93027D4E51B6@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.19] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E15CDC3ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvje6+VbzBBq2XGC0+3rvBarF/8Xlm i51zO5gdmD12zrrL7rFkyU8mj7Znd9gDmKO4bFJSczLLUov07RK4MuZdfcxUsDyy4sfPQywN jJd9uhg5OSQETCR2fD7MBGGLSVy4t56ti5GLQ0jgEKPEz47XzBDOEkaJmU+fsIBUsQloSMzf cZcRxBYBsi8++8AGYjMLBEos2v2BFcQWFnCQ2LV+BRtEjaPEvHszWCDsJIl5CzeCxVkEVCV2 tRwBinNw8Ar4Srz8IA2x6xGzxNvDV5hBajgFbCX+nr8G1ssoICtx//s9Fohd4hK3nsyHulpA Ysme88wQtqjEy8f/WCFsRYn2pw2MEPX5Eos6GtlBbF4BQYmTM5+wTGAUnYVk1CwkZbOQlEHE dSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjOy5iZk56eWGmxiBkXZwy2/dHYynzokcYpTm YFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6Op7Pb1+omvj1tJ5G8urXPePHHu 1blRjySmFc1nVJkV+tSw61tkxrGHl5OeXlCUl/tz+YJrROrm6UVpf1UUXsZKbj7gXPt97opz +4TNPFnV9VL+bXxud+JarZ3mh9jdi1TXusaFFTz7HdV82n1jnp1FacTNyad/a03af+RczMR+ NvZOgV1s34OUWIozEg21mIuKEwELXlEJggIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/G_oO-B0ZY9PFFIPjDYnmlF1362Y Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 26 Feb 2014 08:50:14 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E15CDC3ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, just to confirm, your point is that "SST" in 6190 terms is really what = I chose to call "SST-SS", right? And, you suggest that any use of multiple = RTP streams (Packet Streams) should be defined as using "MST", irrespective= of how they are transported? In effect, re-defining 6190 "Single/Multiple = Session Transmission" to "Single/Multiple Stream Transmission" (as, I noted= , is already done in the HEVC payload format draft). How do you suggest to handle the fact that you have been able, and still wi= ll be able, to signal "SST" for an SDP media block in 6190 and use multiple= streams in that media block? Is that not a confusion that we should try to= remove/clarify, and is not the Taxonomy an appropriate place for this? If = you have a suitable remedy, please suggest text that we can use. /Bo From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: den 25 februari 2014 16:35 To: Bo Burman Cc: Suhas Nandakumar; avtext@ietf.org Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 On Feb 25, 2014, at 3:22 AM, Bo Burman > wrote: Inline Similarly On another point: in your table, I don't understand MST-SS. How can a sing= le stream be sent in multiple sessions? Based on the latest version of the= taxonomy draft, it seems like you're interpreting this as meaning multiple= streams in multiple sessions, where the streams have the same SSRC. That = may be worth calling out as a special case (since it's the mode that RFC 35= 50 defines for MST) but I think that calling that "single stream" is not a = good idea. They still have separate sequence number spaces, probably times= tamp spaces, feedback, etc. [BoB] That was not my intent with MST-SS; it is multiple streams in total, = yes, but only a single stream, single SSRC, per RTP Session. MST-MS would u= se multiple streams, multiple SSRC, in each of the multiple RTP Sessions. T= he distinction between SS and MS is thus use of multiple SSRC or not in an = RTP Session. Okay, I see the distinction you're making; but I think the terminology you'= ve chosen is confusing. The top-level distinction, I think, needs to be between single-stream and m= ulti-stream transmission. Then there are distinctions between various ways= of transmitting the streams that make up multi-stream transmission. Personally, I would retroactively redefine the acronyms SST and MST as "sin= gle-stream transmission" and "multi-stream transmission", despite 6190. At= least in my personal recollection, when 6190 was being written, no one tho= ught there was a use case for multi-stream transmission in a single session= - and indeed, there was some desire to discourage it from being used - so = single-stream and single-session mode were thought of as basically synonymo= us. Or if you think this would be confusing, we could instead come up with alte= rnate terms for the two modes. But I think that the grid where you imply t= hat single/multiple stream and single/multiple session are orthogonal choic= es is a bad idea. --_000_BBE9739C2C302046BD34B42713A1E2A22E15CDC3ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So, just to confirm, your= point is that “SST” in 6190 terms is really what I chose to ca= ll “SST-SS”, right? And, you suggest that any use of multiple R= TP streams (Packet Streams) should be defined as using “MST”, irrespectiv= e of how they are transported? In effect, re-defining 6190 “Single/Mu= ltiple Session Transmission” to “Single/Multiple Stream Transmi= ssion” (as, I noted, is already done in the HEVC payload format draft).

 <= /p>

How do you suggest to han= dle the fact that you have been able, and still will be able, to signal = 220;SST” for an SDP media block in 6190 and use multiple streams in that media block? Is that not a confusion that we should try to remove/= clarify, and is not the Taxonomy an appropriate place for this? If you have= a suitable remedy, please suggest text that we can use.<= /p>

 <= /p>

/Bo

 <= /p>

From: Jonathan= Lennox [mailto:jonathan@vidyo.com]
Sent: den 25 februari 2014 16:35
To: Bo Burman
Cc: Suhas Nandakumar; avtext@ietf.org
Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00

 

 

On Feb 25, 2014, at 3:22 AM, Bo Burman <bo.burman@ericsson.com> wrote:



Inline<= /p>

 

Similarly



On another point: in your table, I don’t under= stand MST-SS.  How can a single stream be sent in multiple sessions? &= nbsp;Based on the latest version of the taxonomy draft, it seems like you&#= 8217;re interpreting this as meaning multiple streams in multiple sessions, where the streams have the same SSRC.  That may be= worth calling out as a special case (since it’s the mode that RFC 35= 50 defines for MST) but I think that calling that “single stream̶= 1; is not a good idea.  They still have separate sequence number spaces, probably timestamp spaces, feedback, etc.

[BoB] That was not = my intent with MST-SS; it is multiple streams in total, yes, but only a sin= gle stream, single SSRC, = per RTP Session. MST-MS would use multiple streams, multiple SSRC, in each= of the multiple RTP Sessions. The distinction between SS and MS is thus us= e of multiple SSRC or not in an RTP Session.

 

Okay, I see the distinction you’re making; but= I think the terminology you’ve chosen is confusing.

 

The top-level distinction, I think, needs to be betw= een single-stream and multi-stream transmission.  Then there are disti= nctions between various ways of transmitting the streams that make up multi= -stream transmission.

 

Personally, I would retroactively redefine the acron= yms SST and MST as “single-stream transmission” and “mult= i-stream transmission”, despite 6190.  At least in my personal r= ecollection, when 6190 was being written, no one thought there was a use case for multi-stream transmission in a single session — a= nd indeed, there was some desire to discourage it from being used — s= o single-stream and single-session mode were thought of as basically synony= mous.

 

Or if you think this would be confusing, we could in= stead come up with alternate terms for the two modes.  But I think tha= t the grid where you imply that single/multiple stream and single/multiple = session are orthogonal choices is a bad idea.

--_000_BBE9739C2C302046BD34B42713A1E2A22E15CDC3ESESSMB105erics_-- From nobody Wed Feb 26 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 5B4C81A0393; Wed, 26 Feb 2014 06:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] 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 j_LeIJxBCs25; Wed, 26 Feb 2014 06:39:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7631A037D; Wed, 26 Feb 2014 06:39:07 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226143907.24513.83430.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 06:39:07 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/vcG6Bi14J-nkLmlZNkMNtkFD-IU Cc: avtext@ietf.org Subject: [avtext] I-D ACTION:draft-ietf-avtext-rtp-duplication-06.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: Wed, 26 Feb 2014 14:39:10 -0000 --NextPart 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 : Duplicating RTP Streams Author(s) : A. Begen, et al Filename : draft-ietf-avtext-rtp-duplication Pages : 13 Date : 2014-02-26 Packet loss is undesirable for real-time multimedia sessions, but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration due to the potential large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. One solution to this challenge without incurring unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-rtp-duplication-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtext-rtp-duplication"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-26063906.I-D@ietf.org> --NextPart-- From nobody Wed Feb 26 08:29: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 58C491A00FB for ; Wed, 26 Feb 2014 08:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 rsD-aemUMtEA for ; Wed, 26 Feb 2014 08:29:02 -0800 (PST) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC4B1A06CE for ; Wed, 26 Feb 2014 08:28:55 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/26/2014 11:28:53 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com 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-310/SG:5 2/26/2014 11:27:53 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.86942 p=-0.97746 Source White X-Signature-Violations: 0-0-0-23151-c X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/26/2014 11:28:35 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL 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: 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 75561308; Wed, 26 Feb 2014 11:28:52 -0500 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; Wed, 26 Feb 2014 10:28:52 -0600 From: Jonathan Lennox To: Bo Burman Thread-Topic: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPJ4gk+DpeFSd18kW9VQ74Ql37kpqxrlUAgAmpJdyACeghgIAA21gAgAB494CAASEWAIAAgDUA Date: Wed, 26 Feb 2014 16:28:52 +0000 Message-ID: <5E5BFE64-6B52-4879-9ADD-647EC689E781@vidyo.com> References: <7F836EE4-B8EC-4DB6-B951-43AE428419B5@vidyo.com> <3FD0BC33-4223-4A9D-BB02-93027D4E51B6@vidyo.com> In-Reply-To: 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: multipart/alternative; boundary="_000_5E5BFE646B5248799ADD647EC689E781vidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/EhRMSDaBrw7gRTC-SV1FJZsEVX4 Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 26 Feb 2014 16:29:04 -0000 --_000_5E5BFE646B5248799ADD647EC689E781vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Feb 26, 2014, at 3:50 AM, Bo Burman > wrote: So, just to confirm, your point is that =93SST=94 in 6190 terms is really w= hat I chose to call =93SST-SS=94, right? And, you suggest that any use of m= ultiple RTP streams (Packet Streams) should be defined as using =93MST=94, = irrespective of how they are transported? In effect, re-defining 6190 =93Si= ngle/Multiple Session Transmission=94 to =93Single/Multiple Stream Transmis= sion=94 (as, I noted, is already done in the HEVC payload format draft). Right, that=92s what I=92m thinking. How do you suggest to handle the fact that you have been able, and still wi= ll be able, to signal =93SST=94 for an SDP media block in 6190 and use mult= iple streams in that media block? Is that not a confusion that we should tr= y to remove/clarify, and is not the Taxonomy an appropriate place for this?= If you have a suitable remedy, please suggest text that we can use. Do you mean multiple streams with SST encodings of different sources? That= =92s unremarkable, I think. Or do you think that SST would actually let yo= u use multiple packet streams for different layers of the same source? /Bo From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: den 25 februari 2014 16:35 To: Bo Burman Cc: Suhas Nandakumar; avtext@ietf.org Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 On Feb 25, 2014, at 3:22 AM, Bo Burman > wrote: Inline Similarly On another point: in your table, I don=92t understand MST-SS. How can a si= ngle stream be sent in multiple sessions? Based on the latest version of t= he taxonomy draft, it seems like you=92re interpreting this as meaning mult= iple streams in multiple sessions, where the streams have the same SSRC. T= hat may be worth calling out as a special case (since it=92s the mode that = RFC 3550 defines for MST) but I think that calling that =93single stream=94= is not a good idea. They still have separate sequence number spaces, prob= ably timestamp spaces, feedback, etc. [BoB] That was not my intent with MST-SS; it is multiple streams in total, = yes, but only a single stream, single SSRC, per RTP Session. MST-MS would u= se multiple streams, multiple SSRC, in each of the multiple RTP Sessions. T= he distinction between SS and MS is thus use of multiple SSRC or not in an = RTP Session. Okay, I see the distinction you=92re making; but I think the terminology yo= u=92ve chosen is confusing. The top-level distinction, I think, needs to be between single-stream and m= ulti-stream transmission. Then there are distinctions between various ways= of transmitting the streams that make up multi-stream transmission. Personally, I would retroactively redefine the acronyms SST and MST as =93s= ingle-stream transmission=94 and =93multi-stream transmission=94, despite 6= 190. At least in my personal recollection, when 6190 was being written, no= one thought there was a use case for multi-stream transmission in a single= session =97 and indeed, there was some desire to discourage it from being = used =97 so single-stream and single-session mode were thought of as basica= lly synonymous. Or if you think this would be confusing, we could instead come up with alte= rnate terms for the two modes. But I think that the grid where you imply t= hat single/multiple stream and single/multiple session are orthogonal choic= es is a bad idea. --_000_5E5BFE646B5248799ADD647EC689E781vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7F597F86CA46E64EBAB0277B2B29C6BC@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Feb 26, 2014, at 3:50 AM, Bo Burman <bo.burman@ericsson.com> wrote:

So, just to confirm, your point is that =93SST=94 in 6190 = terms is really what I chose to call =93SST-SS=94, right? And, you suggest = that any use of multiple RTP streams (Packet Streams) should be defined as using =93MST=94, irrespective of how they ar= e transported? In effect, re-defining 6190 =93Single/Multiple Session Trans= mission=94 to =93Single/Multiple Stream Transmission=94 (as, I noted, is al= ready done in the HEVC payload format draft).

Right, that=92s what I=92m thinking.

 
How do you suggest to handle the fact that you have been a= ble, and still will be able, to signal =93SST=94 for an SDP media block in = 6190 and use multiple streams in that media block? Is that not a confusion that we should try to remove/clarify,= and is not the Taxonomy an appropriate place for this? If you have a suita= ble remedy, please suggest text that we can use.

Do you mean multiple streams with SST encodings of different sources? =  That=92s unremarkable, I think.  Or do you think that SST would = actually let you use multiple packet streams for different layers of the sa= me source? 

 
/Bo
 
From:<= /span> Jonathan Lennox [mailto:jonathan@vidyo.com] 
Sent: den 25 febru= ari 2014 16:35
To: Bo Burman
Cc: Suhas Nandakum= ar; avtext@i= etf.org
Subject: Re: [avte= xt] draft-ietf-avtext-rtp-grouping-taxonomy-00
 
 
On Feb 25, 2014, at 3:22 AM, Bo Burman <bo.burman@er= icsson.com> wrote:


Inline
 
Similarly


On another point: in your table, I don=92t understand MST-SS.  How can= a single stream be sent in multiple sessions?  Based on the latest ve= rsion of the taxonomy draft, it seems like you=92re interpreting this as me= aning multiple streams in multiple sessions, where the streams have the same SSRC.  That may be worth calling out as a s= pecial case (since it=92s the mode that RFC 3550 defines for MST) but I thi= nk that calling that =93single stream=94 is not a good idea.  They sti= ll have separate sequence number spaces, probably timestamp spaces, feedback, etc.
[BoB] That was not my intent with MST-SS; it is mult= iple streams in total, yes, but only a single stream, single SSRC, per RTP Session. MST-MS would use multiple streams, multiple SSRC, in each= of the multiple RTP Sessions. The distinction between SS and MS is thus us= e of multiple SSRC or not in an RTP Session.
 
Okay, I see the distinction you=92re making; but I think the terminology yo= u=92ve chosen is confusing.
 
The top-level distinction, I think, needs to be between single-stream and m= ulti-stream transmission.  Then there are distinctions between various= ways of transmitting the streams that make up multi-stream transmission.
 
Personally, I would retroactively redefine the acronyms SST and MST as =93s= ingle-stream transmission=94 and =93multi-stream transmission=94, despite 6= 190.  At least in my personal recollection, when 6190 was being writte= n, no one thought there was a use case for multi-stream transmission in a single session =97 and indeed, there was some desire to = discourage it from being used =97 so single-stream and single-session mode = were thought of as basically synonymous.
 
Or if you think this would be confusing, we could instead come up with alte= rnate terms for the two modes.  But I think that the grid where you im= ply that single/multiple stream and single/multiple session are orthogonal = choices is a bad idea.

--_000_5E5BFE646B5248799ADD647EC689E781vidyocom_-- From nobody Wed Feb 26 08:53:02 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 7DB821A0161; Wed, 26 Feb 2014 08:52:55 -0800 (PST) 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 tRcobf96SPlx; Wed, 26 Feb 2014 08:52:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B285B1A06AB; Wed, 26 Feb 2014 08:52:38 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226165238.17083.89629.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 08:52:38 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/gdrNs_uZ8URRgvF757D4E6VQ_zA Cc: avtext mailing list , avtext chair , RFC Editor Subject: [avtext] Protocol Action: 'Duplicating RTP Streams' to Proposed Standard (draft-ietf-avtext-rtp-duplication-06.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: Wed, 26 Feb 2014 16:52:55 -0000 The IESG has approved the following document: - 'Duplicating RTP Streams' (draft-ietf-avtext-rtp-duplication-06.txt) as Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-duplication/ Technical Summary Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. Working Group Summary The document went through a working group last call. There were comments and the document was updated to resolve all comments. The work was originally presented in the AVTCORE working group, but following chair and AD discussion was adopted as a work item of the AVTEXT group instead. Document Quality The document got good reviews from several AVText members, notably Magnus Westerlund, who brought up several important topics about the document's congestion control, and limitations of its source-association mechanisms, which were resolved during working group last call. Ali Begen says that Cisco uses duplicated streams "more or less" according to the guidelines in this document, as do several other implementations from the SMPTE community. Personnel The Document Shepherd is Jonathan Lennox. The Responsible Area Director is Gonzalo Camarillo. From nobody Thu Feb 27 06:37: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 354DA1A01DA for ; Thu, 27 Feb 2014 06:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=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 Am5o6F-LzdHJ for ; Thu, 27 Feb 2014 06:37:08 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 187F81A02C6 for ; Thu, 27 Feb 2014 06:37:06 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-b4-530f4d903769 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 68.F2.04853.09D4F035; Thu, 27 Feb 2014 15:37:04 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.166]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Thu, 27 Feb 2014 15:37:03 +0100 From: Bo Burman To: Jonathan Lennox Thread-Topic: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPJ4gk+DpeFSd18kW9VQ74Ql37kpqxrlUAgAA4rQCAAdTpEIAADn4AgBD/2oCAAOXXAIAAbnSAgAEuMsCAAHMXAIABYfCg Date: Thu, 27 Feb 2014 14:37:04 +0000 Message-ID: References: <7F836EE4-B8EC-4DB6-B951-43AE428419B5@vidyo.com> <3FD0BC33-4223-4A9D-BB02-93027D4E51B6@vidyo.com> <5E5BFE64-6B52-4879-9ADD-647EC689E781@vidyo.com> In-Reply-To: <5E5BFE64-6B52-4879-9ADD-647EC689E781@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.18] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E15D82FESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RneCL3+wwdkjJhYf791gtdi/+Dyz xc65HcwOzB47Z91l91iy5CeTR9uzO+wBzFFcNimpOZllqUX6dglcGVvOn2As2DiNsWLxwgXM DYxTGhm7GDk4JARMJJ4/1eti5AQyxSQu3FvP1sXIxSEkcIJRovHxLkYIZwmjxIILE9lBqtgE NCTm77jLCGKLANkXn31gA7GZBQIlFu3+wApiCws4SOxav4INosZRYt69GSwQdp7EzKkvweIs AqoSB3snMYPYvAK+Er8nnWGBWHaTReLCzJtMINdxCthK3FkQBFLDKCArcf/7PRaIXeISt57M Z4K4WkBiyZ7zzBC2qMTLx/9YIWxFiY+v9jFC1OdLXPz9hAVil6DEyZlPWCYwis5CMmoWkrJZ SMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8 PL3i1E2MwHg8uOW30Q7Gk3vsDzFKc7AoifNeZ60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cBYlG7SYDBJyICLyXpvz8HJCtJlIX6WW2axJ4mxFSY3tpbnhwUc+76uqfLr6+0bpO5IXJEq 5puQv7Ulx/br/02vonnEMq6VsZ+yncn+4mfR9Jce/Z7Lrm7veDql+9bl56X5rJcOFz+Yo1jZ PfXZat1XZVpPf0/jqG5b/k7CyPehyZNJXvzRrB1KLMUZiYZazEXFiQDyYNT1lQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/DYAC6YS6duTxXpw9cz558zY7a9Q Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 27 Feb 2014 14:37:11 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E15D82FESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: den 26 februari 2014 17:29 On Feb 26, 2014, at 3:50 AM, Bo Burman > wrote: So, just to confirm, your point is that "SST" in 6190 terms is really what = I chose to call "SST-SS", right? And, you suggest that any use of multiple = RTP streams (Packet Streams) should be defined as using "MST", irrespective= of how they are transported? In effect, re-defining 6190 "Single/Multiple = Session Transmission" to "Single/Multiple Stream Transmission" (as, I noted= , is already done in the HEVC payload format draft). Right, that's what I'm thinking. [BoB] OK, so what I then believe is needed in the Taxonomy is a clarificati= on that although SST and MST definitions in 6190 contain ...Session..., it = assumes a single Packet Stream per Media Source in that "Session". This als= o means that a re-definition of SST and MST reading as ...Stream... would b= e equivalent with the original intent and more in line with the rest of the= Taxonomy. How do you suggest to handle the fact that you have been able, and still wi= ll be able, to signal "SST" for an SDP media block in 6190 and use multiple= streams in that media block? Is that not a confusion that we should try to= remove/clarify, and is not the Taxonomy an appropriate place for this? If = you have a suitable remedy, please suggest text that we can use. Do you mean multiple streams with SST encodings of different sources? That= 's unremarkable, I think. Or do you think that SST would actually let you = use multiple packet streams for different layers of the same source? [BoB] Multiple SST Media Sources in a single RTP Session is straightforward= and all possible issues should already be covered by draft-ietf-avtcore-rt= p-multi-stream. I don't know what I was thinking of, because SST has no iss= ue. Sorry. On the other hand, there is a statement on MST in 1.2.2 of 6190 that says "= In MST, each RTP session is associated with one RTP stream, which may carry= one or more layers". I guess that is no longer correct, especially in the = context of BUNDLE where several media blocks can contribute to a single RTP= session. To reflect that, I think we should clarify in the Taxonomy that m= ultiple 6190 Packet Streams from a single Media Source can be present in a = single RTP Session, despite what was originally intended and what is said i= n 6190. Agree? Related to that, can you confirm that an 6190 SDP media block will still on= ly result in a single RTP Packet Stream per Media Source? Or, do you see a = need to relax that for MST and clarify that there may be multiple Packet St= reams per Media Source even in the case of a single SDP media block using 6= 190 MST? As I see it, that would be desirable to align with the new definit= ion of SST and MST. /Bo From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: den 25 februari 2014 16:35 To: Bo Burman Cc: Suhas Nandakumar; avtext@ietf.org Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 On Feb 25, 2014, at 3:22 AM, Bo Burman > wrote: Inline Similarly On another point: in your table, I don't understand MST-SS. How can a sing= le stream be sent in multiple sessions? Based on the latest version of the= taxonomy draft, it seems like you're interpreting this as meaning multiple= streams in multiple sessions, where the streams have the same SSRC. That = may be worth calling out as a special case (since it's the mode that RFC 35= 50 defines for MST) but I think that calling that "single stream" is not a = good idea. They still have separate sequence number spaces, probably times= tamp spaces, feedback, etc. [BoB] That was not my intent with MST-SS; it is multiple streams in total, = yes, but only a single stream, single SSRC, per RTP Session. MST-MS would u= se multiple streams, multiple SSRC, in each of the multiple RTP Sessions. T= he distinction between SS and MS is thus use of multiple SSRC or not in an = RTP Session. Okay, I see the distinction you're making; but I think the terminology you'= ve chosen is confusing. The top-level distinction, I think, needs to be between single-stream and m= ulti-stream transmission. Then there are distinctions between various ways= of transmitting the streams that make up multi-stream transmission. Personally, I would retroactively redefine the acronyms SST and MST as "sin= gle-stream transmission" and "multi-stream transmission", despite 6190. At= least in my personal recollection, when 6190 was being written, no one tho= ught there was a use case for multi-stream transmission in a single session= - and indeed, there was some desire to discourage it from being used - so = single-stream and single-session mode were thought of as basically synonymo= us. Or if you think this would be confusing, we could instead come up with alte= rnate terms for the two modes. But I think that the grid where you imply t= hat single/multiple stream and single/multiple session are orthogonal choic= es is a bad idea. --_000_BBE9739C2C302046BD34B42713A1E2A22E15D82FESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

From: Jonathan= Lennox [mailto:jonathan@vidyo.com]
Sent: den 26 februari 2014 17:29

On Feb 26, 2014, at 3:50 AM, Bo Burman <bo.burman@ericsson.com> wrote:



So, just to confirm, your= point is that “SST” in 6190 terms is really what I chose to ca= ll “SST-SS”, right? And, you suggest that any use of multiple R= TP streams (Packet Streams) should be defined as using “MST”, irrespectiv= e of how they are transported? In effect, re-defining 6190 “Single/Mu= ltiple Session Transmission” to “Single/Multiple Stream Transmi= ssion” (as, I noted, is already done in the HEVC payload format draft).

 

Right, that’s what I’m thinking.

[BoB] OK, so what I= then believe is needed in the Taxonomy is a clarification that although SS= T and MST definitions in 6190 contain …Session…, it assumes a single Packet Stream per Media Source in that “Session”. Thi= s also means that a re-definition of SST and MST reading as …Stream&#= 8230; would be equivalent with the original intent and more in line with the rest of the Taxonomy.

 <= /p>

How do you suggest to han= dle the fact that you have been able, and still will be able, to signal = 220;SST” for an SDP media block in 6190 and use multiple streams in that media block? Is that not a confusion that we should try to remove/= clarify, and is not the Taxonomy an appropriate place for this? If you have= a suitable remedy, please suggest text that we can use.<= /p>

 

Do you mean multiple streams with SST encodings of d= ifferent sources?  That’s unremarkable, I think.  Or do you= think that SST would actually let you use multiple packet streams for diff= erent layers of the same source? 

[BoB] Multiple SST = Media Sources in a single RTP Session is straightforward and all possible i= ssues should already be covered by draft-ietf-avtcore-rtp-multi-stream. I don’t know what I was thinking of, because SST has no issue. Sorry= .

 

On the other hand, = there is a statement on MST in 1.2.2 of 6190 that says “In MST, each RTP session is as= sociated with one RTP stream, which may carry one or more layers”. I guess t= hat is no longer correct, especially in the context of BUNDLE where several= media blocks can contribute to a single RTP session. To reflect that, I th= ink we should clarify in the Taxonomy that multiple 6190 Packet Streams from a single Media Source can be presen= t in a single RTP Session, despite what was originally intended and what is= said in 6190. Agree?

 

Related to that, ca= n you confirm that an 6190 SDP media block will still only result in a single RTP Packet Stream per= Media Source? Or, do you see a need to relax that for MST and clarify that= there may be multiple Packet Streams per Media Source even in the case of = a single SDP media block using 6190 MST? As I see it, that would be desirable to align with the new definition= of SST and MST.

 <= /p>

/Bo

 <= /p>

From: Jonathan Lennox [mailto:jonathan@vidyo.com] 
Sent: den 25 febru= ari 2014 16:35
To: Bo Burman
Cc: Suhas Nandakum= ar; avtext@ietf.org
Subject: Re: [avte= xt] draft-ietf-avtext-rtp-grouping-taxonomy-00

 

 On Feb 25, 2014, at 3:22 AM, Bo Burman <bo.burm= an@ericsson.com> wrote:

 

Inline<= /p>

 

Similarly

 

On another point: in your table, I don’t under= stand MST-SS.  How can a single stream be sent in multiple sessions? &= nbsp;Based on the latest version of the taxonomy draft, it seems like you&#= 8217;re interpreting this as meaning multiple streams in multiple sessions, where the streams have the same SSRC.  That may be= worth calling out as a special case (since it’s the mode that RFC 35= 50 defines for MST) but I think that calling that “single stream̶= 1; is not a good idea.  They still have separate sequence number spaces, probably timestamp spaces, feedback, etc.

[BoB] That was not = my intent with MST-SS; it is multiple streams in total, yes, but only a sin= gle stream, single SSRC, = per RTP Session. MST-MS would use multiple streams, multiple SSRC, in each= of the multiple RTP Sessions. The distinction between SS and MS is thus us= e of multiple SSRC or not in an RTP Session.

 

Okay, I see the distinction you’re making; but= I think the terminology you’ve chosen is confusing.

 

The top-level distinction, I think, needs to be betw= een single-stream and multi-stream transmission.  Then there are disti= nctions between various ways of transmitting the streams that make up multi= -stream transmission.

 

Personally, I would retroactively redefine the acron= yms SST and MST as “single-stream transmission” and “mult= i-stream transmission”, despite 6190.  At least in my personal r= ecollection, when 6190 was being written, no one thought there was a use case for multi-stream transmission in a single session — a= nd indeed, there was some desire to discourage it from being used — s= o single-stream and single-session mode were thought of as basically synony= mous.

 

Or if you think this would be confusing, we could in= stead come up with alternate terms for the two modes.  But I think tha= t the grid where you imply that single/multiple stream and single/multiple = session are orthogonal choices is a bad idea.

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E15D82FESESSMB105erics_-- From nobody Thu Feb 27 15:28:15 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 4685C1A064F for ; Thu, 27 Feb 2014 15:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, 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 sMW2X8cG2x32 for ; Thu, 27 Feb 2014 15:28:10 -0800 (PST) Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) by ietfa.amsl.com (Postfix) with ESMTP id C938D1A0697 for ; Thu, 27 Feb 2014 15:28:09 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/27/2014 6:28:05 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com 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-215/SG:5 2/27/2014 6:28:01 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.890312 p=-0.984074 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 31.2006 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/27/2014 6:28:03 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL 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: 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 76122851; Thu, 27 Feb 2014 18:28:04 -0500 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, 27 Feb 2014 17:28:03 -0600 From: Jonathan Lennox To: Bo Burman Thread-Topic: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 Thread-Index: AQHPJ4gk+DpeFSd18kW9VQ74Ql37kpqxrlUAgAmpJdyACeghgIAA21gAgAB494CAASEWAIAAgDUAgAFzEwCAAJRaAA== Date: Thu, 27 Feb 2014 23:28:02 +0000 Message-ID: <2A34919F-92C1-46E5-A188-D3A1E5F8A87B@vidyo.com> References: <7F836EE4-B8EC-4DB6-B951-43AE428419B5@vidyo.com> <3FD0BC33-4223-4A9D-BB02-93027D4E51B6@vidyo.com> <5E5BFE64-6B52-4879-9ADD-647EC689E781@vidyo.com> In-Reply-To: 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: multipart/alternative; boundary="_000_2A34919F92C146E5A188D3A1E5F8A87Bvidyocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/ymh22wAO0TD-dLRl1psvBdaQZzM Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 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, 27 Feb 2014 23:28:12 -0000 --_000_2A34919F92C146E5A188D3A1E5F8A87Bvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Feb 27, 2014, at 9:37 AM, Bo Burman > wrote: From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: den 26 februari 2014 17:29 On Feb 26, 2014, at 3:50 AM, Bo Burman > wrote: So, just to confirm, your point is that =93SST=94 in 6190 terms is really w= hat I chose to call =93SST-SS=94, right? And, you suggest that any use of m= ultiple RTP streams (Packet Streams) should be defined as using =93MST=94, = irrespective of how they are transported? In effect, re-defining 6190 =93Si= ngle/Multiple Session Transmission=94 to =93Single/Multiple Stream Transmis= sion=94 (as, I noted, is already done in the HEVC payload format draft). Right, that=92s what I=92m thinking. [BoB] OK, so what I then believe is needed in the Taxonomy is a clarificati= on that although SST and MST definitions in 6190 contain =85Session=85, it = assumes a single Packet Stream per Media Source in that =93Session=94. This= also means that a re-definition of SST and MST reading as =85Stream=85 wou= ld be equivalent with the original intent and more in line with the rest of= the Taxonomy. That seems correct to me. How do you suggest to handle the fact that you have been able, and still wi= ll be able, to signal =93SST=94 for an SDP media block in 6190 and use mult= iple streams in that media block? Is that not a confusion that we should tr= y to remove/clarify, and is not the Taxonomy an appropriate place for this?= If you have a suitable remedy, please suggest text that we can use. Do you mean multiple streams with SST encodings of different sources? That= =92s unremarkable, I think. Or do you think that SST would actually let yo= u use multiple packet streams for different layers of the same source? [BoB] Multiple SST Media Sources in a single RTP Session is straightforward= and all possible issues should already be covered by draft-ietf-avtcore-rt= p-multi-stream. I don=92t know what I was thinking of, because SST has no i= ssue. Sorry. Right, good. On the other hand, there is a statement on MST in 1.2.2 of 6190 that says = =93In MST, each RTP session is associated with one RTP stream, which may ca= rry one or more layers=94. I guess that is no longer correct, especially in= the context of BUNDLE where several media blocks can contribute to a singl= e RTP session. To reflect that, I think we should clarify in the Taxonomy t= hat multiple 6190 Packet Streams from a single Media Source can be present = in a single RTP Session, despite what was originally intended and what is s= aid in 6190. Agree? Yes. Related to that, can you confirm that an 6190 SDP media block will still on= ly result in a single RTP Packet Stream per Media Source? Or, do you see a = need to relax that for MST and clarify that there may be multiple Packet St= reams per Media Source even in the case of a single SDP media block using 6= 190 MST? As I see it, that would be desirable to align with the new definit= ion of SST and MST. That would probably be my understanding of it, but I think this is an area = where SDP semantics are still pretty unclear. That said, I think SDP issues are probably out of the scope of Taxonomy. From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: den 25 februari 2014 16:35 To: Bo Burman Cc: Suhas Nandakumar; avtext@ietf.org Subject: Re: [avtext] draft-ietf-avtext-rtp-grouping-taxonomy-00 On Feb 25, 2014, at 3:22 AM, Bo Burman > wrote: Inline Similarly On another point: in your table, I don=92t understand MST-SS. How can a si= ngle stream be sent in multiple sessions? Based on the latest version of t= he taxonomy draft, it seems like you=92re interpreting this as meaning mult= iple streams in multiple sessions, where the streams have the same SSRC. T= hat may be worth calling out as a special case (since it=92s the mode that = RFC 3550 defines for MST) but I think that calling that =93single stream=94= is not a good idea. They still have separate sequence number spaces, prob= ably timestamp spaces, feedback, etc. [BoB] That was not my intent with MST-SS; it is multiple streams in total, = yes, but only a single stream, single SSRC, per RTP Session. MST-MS would u= se multiple streams, multiple SSRC, in each of the multiple RTP Sessions. T= he distinction between SS and MS is thus use of multiple SSRC or not in an = RTP Session. Okay, I see the distinction you=92re making; but I think the terminology yo= u=92ve chosen is confusing. The top-level distinction, I think, needs to be between single-stream and m= ulti-stream transmission. Then there are distinctions between various ways= of transmitting the streams that make up multi-stream transmission. Personally, I would retroactively redefine the acronyms SST and MST as =93s= ingle-stream transmission=94 and =93multi-stream transmission=94, despite 6= 190. At least in my personal recollection, when 6190 was being written, no= one thought there was a use case for multi-stream transmission in a single= session =97 and indeed, there was some desire to discourage it from being = used =97 so single-stream and single-session mode were thought of as basica= lly synonymous. Or if you think this would be confusing, we could instead come up with alte= rnate terms for the two modes. But I think that the grid where you imply t= hat single/multiple stream and single/multiple session are orthogonal choic= es is a bad idea. --_000_2A34919F92C146E5A188D3A1E5F8A87Bvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1F0251C49D8A01459D4B774765BB5F62@vidyo.com> Content-Transfer-Encoding: quoted-printable

--_000_2A34919F92C146E5A188D3A1E5F8A87Bvidyocom_--
On Feb 27, 2014, at 9:37 AM, Bo Burman <bo.burman@ericsson.com> wrote:

 
From:<= /span> Jonathan Lennox [mailto:jonathan@vidyo.com] 
Sent: den 26 febru= ari 2014 17:29

On Feb 26, 2014, at 3:50 AM, Bo Burman <bo.burman@er= icsson.com> wrote:


So, just to confirm, your point is that =93SST=94 in 6190 = terms is really what I chose to call =93SST-SS=94, right? And, you suggest = that any use of multiple RTP streams (Packet Streams) should be defined as using =93MST=94, irrespective of how they ar= e transported? In effect, re-defining 6190 =93Single/Multiple Session Trans= mission=94 to =93Single/Multiple Stream Transmission=94 (as, I noted, is al= ready done in the HEVC payload format draft).
 
Right, that=92s what I=92m thinking.
[BoB] OK, so what I then believe is needed in the Ta= xonomy is a clarification that although SST and MST definitions in 6190 con= tain =85Session=85, it assumes a single Packet Stream per Media Source in that =93Session=94. This also means that= a re-definition of SST and MST reading as =85Stream=85 would be equivalent= with the original int= ent and more in line with the rest of the Taxonomy.

That seems correct to me.

How do you suggest to handle the fact that you have been a= ble, and still will be able, to signal =93SST=94 for an SDP media block in = 6190 and use multiple streams in that media block? Is that not a confusion that we should try to remove/clarify,= and is not the Taxonomy an appropriate place for this? If you have a suita= ble remedy, please suggest text that we can use.
 
Do you mean multiple streams with SST encodings of different sources?  = ;That=92s unremarkable, I think.  Or do you think that SST would actua= lly let you use multiple packet streams for different layers of the same so= urce? 
[BoB] Multiple SST Media Sources in a single RTP Ses= sion is straightforward and all possible issues should already be covered b= y draft-ietf-avtcore-rtp-multi-stream. I don=92t know what I was thinking of, because SST has no issue. Sorry.

Right, good.

 <= i>On the other hand, there is a statement on MST in 1.2.2 of 6190 that says =93In MS= T, each RTP session is associated with one RTP stream, whi= ch may carry one or more layers=94. I guess that is no longer correct, espe= cially in the context of BUNDLE where several media blocks can contribute to a single RTP session. To reflect that, I think we should= clarify in the Taxonomy that multiple 6190 Packet Streams from a single Me= dia Source can be present in a single RTP Session, despite what was origina= lly intended and what is said in 6190. Agree?

Yes. 

Related to that, can you confirm that an 6190 SDP media block will still only result in a single RTP Packet Stream per Media Source? Or, do you see= a need to relax that for MST and clarify that there may be multiple Packet= Streams per Media Source even in the case of a single SDP media block usin= g 6190 MST? As I see it, that would be desirable to align with the new definition of SST and MST.

That would probably be my understanding of it, but I think this is an = area where SDP semantics are still pretty unclear.

That said, I think SDP issues are probably out of the scope of Taxonom= y. 

From:<= /span> Jonathan Lennox [mailto:jonathan@vid= yo.com] 
Sent: den 25 febru= ari 2014 16:35
To: Bo Burman
Cc: Suhas Nandakum= ar; avtext@ietf.org
Subject: Re: [avte= xt] draft-ietf-avtext-rtp-grouping-taxonomy-00
 
 On Feb 25, 2014, at 3:22 AM, Bo Burman <bo.burman@ericsson.com> wrote:<= /o:p>
 
Inline
 
Similarly
 
On another point: in your table, I don=92t understand MST-SS.  How can= a single stream be sent in multiple sessions?  Based on the latest ve= rsion of the taxonomy draft, it seems like you=92re interpreting this as me= aning multiple streams in multiple sessions, where the streams have the same SSRC.  That may be worth calling out as a s= pecial case (since it=92s the mode that RFC 3550 defines for MST) but I thi= nk that calling that =93single stream=94 is not a good idea.  They sti= ll have separate sequence number spaces, probably timestamp spaces, feedback, etc.
[BoB] That was not my intent with MST-SS; it is mult= iple streams in total, yes, but only a single stream, single SSRC, per RTP Session. MST-MS would use multiple streams, multiple SSRC, in each= of the multiple RTP Sessions. The distinction between SS and MS is thus us= e of multiple SSRC or not in an RTP Session.
 
Okay, I see the distinction you=92re making; but I think the terminology yo= u=92ve chosen is confusing.
 
The top-level distinction, I think, needs to be between single-stream and m= ulti-stream transmission.  Then there are distinctions between various= ways of transmitting the streams that make up multi-stream transmission.
 
Personally, I would retroactively redefine the acronyms SST and MST as =93s= ingle-stream transmission=94 and =93multi-stream transmission=94, despite 6= 190.  At least in my personal recollection, when 6190 was being writte= n, no one thought there was a use case for multi-stream transmission in a single session =97 and indeed, there was some desire to = discourage it from being used =97 so single-stream and single-session mode = were thought of as basically synonymous.
 
Or if you think this would be confusing, we could instead come up with alte= rnate terms for the two modes.  But I think that the grid where you im= ply that single/multiple stream and single/multiple session are orthogonal = choices is a bad idea.