From bill.wu@huawei.com Sat Nov 2 18:24:41 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E888B11E8285 for ; Sat, 2 Nov 2013 18:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-3.998, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji36T0K+HK55 for ; Sat, 2 Nov 2013 18:24:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6A411E8281 for ; Sat, 2 Nov 2013 18:24:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXM31176; Sun, 03 Nov 2013 01:24:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 3 Nov 2013 01:24:04 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 3 Nov 2013 01:24:03 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Sun, 3 Nov 2013 09:23:57 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , Roni Even , "'DRAGE, Keith (Keith)'" , "avtext@ietf.org" Thread-Topic: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy Thread-Index: Ac7QumntAGjgO2pjT1ysU24IrXE3TwFIromAAAAtJgAAlWDk8A== Date: Sun, 3 Nov 2013 01:23:56 +0000 Message-ID: References: <007001ced620$347c4520$9d74cf60$@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.40] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [avtext] =?gb2312?b?tPC4tDogIGRyYWZ0LWxlbm5veC1yYWlhcmVhLXJ0cC1n?= =?gb2312?b?cm91cGluZy10YXhvbm9teQ==?= X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 03 Nov 2013 01:24:42 -0000 U3VwcG9ydC4NCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGF2dGV4dC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86YXZ0ZXh0LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQWxpIEMuIEJlZ2Vu IChhYmVnZW4pDQq3osvNyrG85DogMjAxM8TqMTDUwjMxyNUgMTg6MDcNCsrVvP7IyzogUm9uaSBF dmVuOyAnRFJBR0UsIEtlaXRoIChLZWl0aCknOyBhdnRleHRAaWV0Zi5vcmcNCtb3zOI6IFJlOiBb YXZ0ZXh0XSBkcmFmdC1sZW5ub3gtcmFpYXJlYS1ydHAtZ3JvdXBpbmctdGF4b25vbXkNCg0KSSBh bHNvIHN1cHBvcnQgYWRvcHRpb24uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBSb25pIEV2ZW4gPHJvbi5ldmVuLnRsdkBnbWFpbC5jb20+DQpEYXRlOiBUaHVyc2RheSwgT2N0 b2JlciAzMSwgMjAxMyBhdCAxMTowMSBBTQ0KVG86ICInRFJBR0UsIEtlaXRoIChLZWl0aCknIiA8 a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPiwgImF2dGV4dEBpZXRmLm9yZyIgPGF2dGV4 dEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbYXZ0ZXh0XSBkcmFmdC1sZW5ub3gtcmFpYXJlYS1y dHAtZ3JvdXBpbmctdGF4b25vbXkNCg0KPkhpLA0KPkkgc3VwcG9ydCBhZG9wdGluZyB0aGlzIGRv Y3VtZW50DQo+Um9uaSBFdmVuDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogYXZ0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphdnRleHQtYm91bmNlc0BpZXRm Lm9yZ10gT24gDQo+PiBCZWhhbGYNCj5PZg0KPj4gRFJBR0UsIEtlaXRoIChLZWl0aCkNCj4+IFNl bnQ6IDI0IE9jdG9iZXIsIDIwMTMgNDoyMyBQTQ0KPj4gVG86IGF2dGV4dEBpZXRmLm9yZw0KPj4g U3ViamVjdDogW2F2dGV4dF0gZHJhZnQtbGVubm94LXJhaWFyZWEtcnRwLWdyb3VwaW5nLXRheG9u b215DQo+PiANCj4+IChBcyBXRyBjby1jaGFpcikNCj4+IA0KPj4gVGhlIGZvbGxvd2luZyBkcmFm dDoNCj4+IA0KPj4NCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZW5u b3gtcmFpYXJlYS1ydHAtZ3JvdXBpbmctdGF4bw0KPm5vbQ0KPnkvDQo+PiBkcmFmdC1sZW5ub3gt cmFpYXJlYS1ydHAtZ3JvdXBpbmctdGF4b25vbXktMDMNCj4+IEEgVGF4b25vbXkgb2YgR3JvdXBp bmcgU2VtYW50aWNzIGFuZCBNZWNoYW5pc21zIGZvciBSZWFsLVRpbWUgDQo+PiBUcmFuc3BvcnQg UHJvdG9jb2wgKFJUUCkgU291cmNlcw0KPj4gDQo+PiBIYXMgYmVlbiBzaWduaWZpY2FudGx5IHVw ZGF0ZWQuDQo+PiANCj4+IFdlIGFscmVhZHkgaGF2ZSB0aGUgbWlsZXN0b25lIGZvciB0aGlzIHdv cmsuDQo+PiANCj4+IEknZCBsaWtlIHRvIHN0YXJ0IGEgY2FsbCB0byBhZG9wdCB0aGlzIHRleHQg YXMgYSBXRyBpdGVtLiBTbyBwbGVhc2UNCj5yZXNwb25kIHRvIHRoaXMNCj4+IG1haWwgd2l0aCBl aXRoZXIgc3VwcG9ydCwgbm90IHN1cHBvcnQsIG9yIHN1cHBvcnQgb25seSBwYXJ0IG9mIHRoZSAN Cj4+IHRleHQNCj4oaWYgdGhlDQo+PiBsYXR0ZXIgcGxlYXNlIGJlIHNwZWNpZmljIGFzIHRvIHdo aWNoIHBhcnRzIGNhdXNlIGlzc3VlcykuDQo+PiANCj4+IFBsZWFzZSByZXNwb25kIGJ5IFR1ZXNk YXkgNXRoIE5vdmVtYmVyLiBXZSB3aWxsIGFsc28gZG8gYSBmaW5hbCBjYWxsIA0KPj4gYXQNCj50 aGUNCj4+IGZhY2UgdG8gZmFjZSBtZWV0aW5nLCBidXQgcGxlYXNlIHJhaXNlIGlzc3VlcyBiZWZv cmUgdGhpcy4NCj4+IA0KPj4gUGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHJhaXNlIHNlcGFyYXRl bHkgYW55IGlzc3VlcyB5b3Ugd291bGQgbGlrZSANCj4+Zml4ZWQNCj5pbiB0aGUNCj4+IHRleHQg d2hpY2ggeW91IGJlbGlldmUgZG8gbm90IGltcGFjdCB0aGUgY2FsbCBhYm92ZS4gQWxzbyBhbnkg c3ViamVjdA0KPm1hdHRlcg0KPj4gdGhhdCB5b3UgdGhpbmsgaXMgbWlzc2luZy4gSXQgd291bGQg YmUgZ29vZCB0byBrbm93IHRoYXQgc29tZSBwZW9wbGUgDQo+PmhhdmUNCj5yZWFkDQo+PiB0aGUg ZHJhZnQuDQo+PiANCj4+IFJlZ2FyZHMNCj4+IA0KPj4gS2VpdGgNCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBhdnRleHQgbWFpbGluZyBsaXN0 DQo+PiBhdnRleHRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYXZ0ZXh0DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5hdnRleHQgbWFpbGluZyBsaXN0DQo+YXZ0ZXh0QGlldGYub3JnDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnRleHQNCj4NCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXZ0ZXh0IG1haWxpbmcgbGlz dA0KYXZ0ZXh0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2F2dGV4dA0K From keith.drage@alcatel-lucent.com Sun Nov 3 15:15:42 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6C321E80A3 for ; Sun, 3 Nov 2013 15:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muX8s9BTV5TV for ; Sun, 3 Nov 2013 15:15:36 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A15B921F9B07 for ; Sun, 3 Nov 2013 15:15:36 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rA3NFV80023798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 3 Nov 2013 17:15:33 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rA3NFVqr002943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Nov 2013 00:15:31 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 4 Nov 2013 00:15:31 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: draft-lennox-raiarea-rtp-grouping-taxonomy Thread-Index: Ac7QumntAGjgO2pjT1ysU24IrXE3TwILzgUw Date: Sun, 3 Nov 2013 23:15:29 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0C70A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 03 Nov 2013 23:15:42 -0000 (As WG co-chair) Just a reminder that the following call is still open, and responses can st= ill be made. As part of the taxonomy discussion we will briefly discuss the adoption, bu= t primarily that discussion should concentrate on issues raised with this c= all. Assuming we have consensus that the document is adopted, the chairs would a= lso appreciate indications on what needs to be completed in the document be= fore we get to WGLC, because we would like to get to that point fairly quic= kly. Feel free to post these. Regards Keith=20 > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: 24 October 2013 14:10 > To: 'avtext@ietf.org' > Subject: draft-lennox-raiarea-rtp-grouping-taxonomy >=20 > (As WG co-chair) >=20 > The following draft: >=20 > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grou > ping-taxonomy/ > draft-lennox-raiarea-rtp-grouping-taxonomy-03 > A Taxonomy of Grouping Semantics and Mechanisms for Real-Time=20 > Transport Protocol (RTP) Sources >=20 > Has been significantly updated. >=20 > We already have the milestone for this work. >=20 > I'd like to start a call to adopt this text as a WG item. So=20 > please respond to this mail with either support, not support,=20 > or support only part of the text (if the latter please be=20 > specific as to which parts cause issues). >=20 > Please respond by Tuesday 5th November. We will also do a=20 > final call at the face to face meeting, but please raise=20 > issues before this. >=20 > Please also feel free to raise separately any issues you=20 > would like fixed in the text which you believe do not impact=20 > the call above. Also any subject matter that you think is=20 > missing. It would be good to know that some people have read=20 > the draft. >=20 > Regards >=20 > Keith > = From harald@alvestrand.no Mon Nov 4 04:51:18 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DEE11E8193 for ; Mon, 4 Nov 2013 04:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JzVm8npPlRM for ; Mon, 4 Nov 2013 04:51:12 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2910711E8167 for ; Mon, 4 Nov 2013 04:51:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8715D39E175 for ; Mon, 4 Nov 2013 13:51:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLpjrt5DE-68 for ; Mon, 4 Nov 2013 13:51:11 +0100 (CET) Received: from [31.133.162.5] (dhcp-a205.meeting.ietf.org [31.133.162.5]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A6F3439E095 for ; Mon, 4 Nov 2013 13:51:10 +0100 (CET) Message-ID: <5277983A.2010207@alvestrand.no> Date: Mon, 04 Nov 2013 13:51:06 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: avtext@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B0C70A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0C70A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 12:51:18 -0000 I support adoption of this document as a WG item. From ron.even.tlv@gmail.com Tue Nov 5 15:19:38 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE6321E80E3 for ; Tue, 5 Nov 2013 15:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coqPepQ9KD7E for ; Tue, 5 Nov 2013 15:19:38 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4621E80D9 for ; Tue, 5 Nov 2013 15:19:38 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id x10so9225084pdj.40 for ; Tue, 05 Nov 2013 15:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=IAbzPp2dQRiGvshwH/v2V5HMTvugzh4zwdbL5+G7jkM=; b=oZzX/ft6I+qD0WLUQS83ERXNykYWNORygzmt5G+KhAhFSkuzOmBo6xTBv6eXxTsoZ7 wSQe2w4TiV7atDi21LZnAB+ZLiNNCyKV/VnHARQPxJXz4oKxaZ5rMIU8yuHTJ4UoKRY5 sz/Zn90MsBC9BV0oHmTSWzPxm+nS6eRNhLLokd2f3304dIEr0Dv5gCKiB6BgvSfJBog8 T0JhybMcMMQh91O2ZaSLzdnKjUkGEbpsY+ZLu8k4UpSkQpOhTfGddQX4KGHVJto2cduR mivf3ZKdgHkJmDeZeIOBx1H8k3VJ6Ot4Z7rYJsHe41Ckbf3FGfA2dAI7AT7XyPLv8CVO S7Jw== X-Received: by 10.68.209.232 with SMTP id mp8mr17056pbc.129.1383693577691; Tue, 05 Nov 2013 15:19:37 -0800 (PST) Received: from RoniE ([2001:67c:370:160:5931:63fe:a028:4423]) by mx.google.com with ESMTPSA id qn1sm36975922pbc.34.2013.11.05.15.19.34 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Nov 2013 15:19:36 -0800 (PST) From: "Roni Even" To: Date: Wed, 6 Nov 2013 01:16:18 +0200 Message-ID: <057e01ceda7d$0ae41510$20ac3f30$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_057F_01CEDA8D.CE6F5610" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7afQgfceQDdM8DR4S5BGtJjZQHkA== Content-Language: en-us Subject: [avtext] taxonomy question about endpoint and participant X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2013 23:19:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_057F_01CEDA8D.CE6F5610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am not sure what is the difference between endpoint and participant. Some terms from H.323 endpoint: An H.323 terminal, Gateway, or MCU. An endpoint can call and be called. It generates and/or terminates information streams. addressable: An H.323 entity on the network having a Transport Address is addressable. Not the same as being callable. A terminal, Gateway, or MCU is addressable and callable. A Gatekeeper is addressable but not callable. An MC or MP is neither callable nor addressable but is contained within an endpoint or Gatekeeper that is. In a composite Gateway, both the MGC and the MG are addressable, but only the MGC is callable. terminal: An H.323 Terminal is an endpoint on the network which provides for real-time, two-way communications with another H.323 terminal, Gateway, or Multipoint Control Unit. This communication consists of control, indications, audio, moving colour video pictures, and/or data between the two terminals. A terminal may provide speech only, speech and data, speech and video, or speech, data and video. Note the distinction between terminal and intermediaries like MCUs and Gateways Roni ------=_NextPart_000_057F_01CEDA8D.CE6F5610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am not sure = what is the difference between endpoint and = participant.

 

Some terms from H.323

 

endpoint: An H.323 terminal, Gateway, or = MCU. An endpoint can call and be called. It generates and/or terminates = information streams.

 

addressable: An H.323 entity on the network = having a Transport Address is addressable. Not the same as being = callable. A terminal, Gateway, or MCU is addressable and callable. A = Gatekeeper is addressable but not callable. An MC or MP is neither = callable nor addressable but is contained within an endpoint or = Gatekeeper that is. In a composite Gateway, both the MGC and the MG are = addressable, but only the MGC is callable.

 

terminal: An H.323 Terminal is an endpoint = on the network which provides for real-time, two-way communications with = another H.323 terminal, Gateway, or Multipoint Control Unit. This = communication consists of control, indications, audio, moving colour = video pictures, and/or data between the two terminals. A terminal may = provide speech only, speech and data, speech and video, or speech, data = and video.

 

 

Note the = distinction between terminal and intermediaries like MCUs and = Gateways

 

Roni

------=_NextPart_000_057F_01CEDA8D.CE6F5610-- From internet-drafts@ietf.org Tue Nov 5 16:32:58 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12F511E81EB; Tue, 5 Nov 2013 16:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa2rEtp5hJ+K; Tue, 5 Nov 2013 16:32:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8378821F9D2E; Tue, 5 Nov 2013 16:32:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131106003256.29536.51629.idtracker@ietfa.amsl.com> Date: Tue, 05 Nov 2013 16:32:56 -0800 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 06 Nov 2013 00:32:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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 Author(s) : Jonathan Lennox Kevin Gross Suhas Nandakumar Gonzalo Salgueiro Bo Burman Filename : draft-ietf-avtext-rtp-grouping-taxonomy-00.txt Pages : 42 Date : 2013-11-05 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-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From keith.drage@alcatel-lucent.com Tue Nov 5 16:54:18 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C6511E81EB for ; Tue, 5 Nov 2013 16:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.529 X-Spam-Level: X-Spam-Status: No, score=-110.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYclTWJ-SQn1 for ; Tue, 5 Nov 2013 16:54:12 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2B911E8163 for ; Tue, 5 Nov 2013 16:54:12 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rA60s95K014446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Nov 2013 18:54:11 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rA60s9pj018969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Nov 2013 01:54:09 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 6 Nov 2013 01:54:09 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: draft-lennox-raiarea-rtp-grouping-taxonomy Thread-Index: Ac7QumntAGjgO2pjT1ysU24IrXE3TwJz9J5A Date: Wed, 6 Nov 2013 00:54:09 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0C97D4@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B0BE94D@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0BE94D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 06 Nov 2013 00:54:18 -0000 (As WG cochair) The chairs have only received positive statements via the mailing list for = adopting this as the WG draft text, and no objections were raised in the fa= ce to face meeting. Therefore the chairs declare WG concensus to adopt the text.=20 We have asked Bo Berman to act as lead editor on the document. The first version of the working group draft has been posted. The chairs are interested in advancing this document reasonably quickly. It= would be useful to know issues where more material is believed to be requi= red, or where other issues need to be addressed. Please review with these q= uestions in mind. Regards Keith > -----Original Message----- > From: avtext-bounces@ietf.org=20 > [mailto:avtext-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: 24 October 2013 14:23 > To: avtext@ietf.org > Subject: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy >=20 > (As WG co-chair) >=20 > The following draft: >=20 > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grou > ping-taxonomy/ > draft-lennox-raiarea-rtp-grouping-taxonomy-03 > A Taxonomy of Grouping Semantics and Mechanisms for Real-Time=20 > Transport Protocol (RTP) Sources >=20 > Has been significantly updated. >=20 > We already have the milestone for this work. >=20 > I'd like to start a call to adopt this text as a WG item. So=20 > please respond to this mail with either support, not support,=20 > or support only part of the text (if the latter please be=20 > specific as to which parts cause issues). >=20 > Please respond by Tuesday 5th November. We will also do a=20 > final call at the face to face meeting, but please raise=20 > issues before this. >=20 > Please also feel free to raise separately any issues you=20 > would like fixed in the text which you believe do not impact=20 > the call above. Also any subject matter that you think is=20 > missing. It would be good to know that some people have read=20 > the draft. >=20 > Regards >=20 > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > = From mary.ietf.barnes@gmail.com Tue Nov 5 18:36:24 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDFA21E80DE for ; Tue, 5 Nov 2013 18:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5E3tEyHN4r1 for ; Tue, 5 Nov 2013 18:36:23 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 392F311E8163 for ; Tue, 5 Nov 2013 18:36:23 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id t61so4375446wes.34 for ; Tue, 05 Nov 2013 18:36:22 -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=0mAtNkR4SK3K0dgaghMLCwLxen0pgLIWsWpJGR6vKCs=; b=R6gc/Xd//wXOgq7+9oC2IQW4+vKAbHViWU9RyRn3HU3UjG+IosaQYxKWorL73B/FID DDVWDtq7o3lNFWtxaFzciLdoWrHQBsBsfdRB6Sp/WFBts/X4ggpPt4HiAl4p/fanm/EY uwWJhb7RAesYvl4Fg6uv31FMlbT4TSm9N0hACMTbhxLKrMSNTIkaKUv8ZBT5KkL6YLd8 pjjoHYZN5GdZqZonXfn8FYBIBVIZo4KYB5jFlC3wKpEFYV2KWizGT+3VudkQK9dfcFS8 q+NiZKKVRt6oDPInK9TNT07fr0zOvlYfeC2aoqldWCW2wj+jr3XUSXOBk0JqwNOmq516 37Vw== MIME-Version: 1.0 X-Received: by 10.181.11.163 with SMTP id ej3mr450403wid.47.1383705382360; Tue, 05 Nov 2013 18:36:22 -0800 (PST) Received: by 10.216.36.4 with HTTP; Tue, 5 Nov 2013 18:36:22 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0C97D4@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B0BE94D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0C97D4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 5 Nov 2013 20:36:22 -0600 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=f46d043be1e0ca24f004ea7903b7 Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 06 Nov 2013 02:36:24 -0000 --f46d043be1e0ca24f004ea7903b7 Content-Type: text/plain; charset=ISO-8859-1 Comments below [MB]. On Tue, Nov 5, 2013 at 6:54 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > (As WG cochair) > > The chairs have only received positive statements via the mailing list for > adopting this as the WG draft text, and no objections were raised in the > face to face meeting. > > Therefore the chairs declare WG concensus to adopt the text. > > We have asked Bo Berman to act as lead editor on the document. > > The first version of the working group draft has been posted. > > The chairs are interested in advancing this document reasonably quickly. > It would be useful to know issues where more material is believed to be > required, or where other issues need to be addressed. Please review with > these questions in mind. > [MB] As I stated during the meeting, I am concerned about the value of progressing this quickly. As I noted, the original milestone has been missed, so I would like a clearer understanding of what your target date is. As I stated in the meeting, some of the work which will use this document as an informational/terminology reference are not necessarily at the point of being able to make a judgement as to what additional material may be required. I certainly see no issue with doing a WGLC, but I think it would be prudent to keep the doc in the working until other WGs that will reference this document have a higher level of confidence that the document is complete as a reference. If you're talking about sending this to the IESG in July/August 2014, then I don't have a problem as that. If you're talking about finishing it by the end of the year, that's a problem. [/MB] > > Regards > > Keith > > > -----Original Message----- > > From: avtext-bounces@ietf.org > > [mailto:avtext-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > > Sent: 24 October 2013 14:23 > > To: avtext@ietf.org > > Subject: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy > > > > (As WG co-chair) > > > > The following draft: > > > > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grou > > ping-taxonomy/ > > draft-lennox-raiarea-rtp-grouping-taxonomy-03 > > A Taxonomy of Grouping Semantics and Mechanisms for Real-Time > > Transport Protocol (RTP) Sources > > > > Has been significantly updated. > > > > We already have the milestone for this work. > > > > I'd like to start a call to adopt this text as a WG item. So > > please respond to this mail with either support, not support, > > or support only part of the text (if the latter please be > > specific as to which parts cause issues). > > > > Please respond by Tuesday 5th November. We will also do a > > final call at the face to face meeting, but please raise > > issues before this. > > > > Please also feel free to raise separately any issues you > > would like fixed in the text which you believe do not impact > > the call above. Also any subject matter that you think is > > missing. It would be good to know that some people have read > > the draft. > > > > Regards > > > > Keith > > _______________________________________________ > > 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 > --f46d043be1e0ca24f004ea7903b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Comments below [MB].

On Tue, Nov 5, 2013 at 6:54 PM, DRAGE, Keith (K= eith) <keith.drage@alcatel-lucent.com> wrote:
(As WG cochair)

The chairs have only received positive statements via the mailing list for = adopting this as the WG draft text, and no objections were raised in the fa= ce to face meeting.

Therefore the chairs declare WG concensus to adopt the text.

We have asked Bo Berman to act as lead editor on the document.

The first version of the working group draft has been posted.

The chairs are interested in advancing this document reasonably quickly. It= would be useful to know issues where more material is believed to be requi= red, or where other issues need to be addressed. Please review with these q= uestions in mind.
[MB] As I stated during the meeting, I am concerned= about the value of progressing this quickly. =A0As I noted, the original m= ilestone has been missed, so I would like a clearer understanding of what y= our target date is. =A0 As I stated in the meeting, some of the work which = will use this document as an informational/terminology reference are not ne= cessarily at the point of being able to make a judgement as to what additio= nal material may be required. =A0I certainly see no issue with doing a WGLC= , but I think it would be prudent to keep the doc in the working until othe= r WGs that will reference this document have a higher level of confidence t= hat the document is complete as a reference. If you're talking about se= nding this to the IESG in July/August 2014, then I don't have a problem= as that. =A0If you're talking about finishing it by the end of the yea= r, that's a problem. =A0=A0
[/MB]=A0

Regards

Keith

> -----Original Message-----
> From: avtext-bounces@ietf.o= rg
> [mailto:avtext-bounces@ietf= .org] On Behalf Of DRAGE, Keith (Keith)
> Sent: 24 October 2013 14:23
> To: avtext@ietf.org
> Subject: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy
>
> (As WG co-chair)
>
> The following draft:
>
> https://datatracker.ietf.org/doc/draft-lennox-raiare= a-rtp-grou
> ping-taxonomy/
> draft-lennox-raiarea-rtp-grouping-taxonomy-03
> A Taxonomy of Grouping Semantics and Mechanisms for Real-Time
> Transport Protocol (RTP) Sources
>
> Has been significantly updated.
>
> We already have the milestone for this work.
>
> I'd like to start a call to adopt this text as a WG item. So
> please respond to this mail with either support, not support,
> or support only part of the text (if the latter please be
> specific as to which parts cause issues).
>
> Please respond by Tuesday 5th November. We will also do a
> final call at the face to face meeting, but please raise
> issues before this.
>
> Please also feel free to raise separately any issues you
> would like fixed in the text which you believe do not impact
> the call above. Also any subject matter that you think is
> missing. It would be good to know that some people have read
> the draft.
>
> Regards
>
> Keith
> _______________________________________________
> 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

--f46d043be1e0ca24f004ea7903b7-- From magnus.westerlund@ericsson.com Wed Nov 6 07:30:35 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2BF11E810F; Wed, 6 Nov 2013 07:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.5 X-Spam-Level: X-Spam-Status: No, score=-105.5 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kS6ioQLA5xa; Wed, 6 Nov 2013 07:30:29 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8943A21E8127; Wed, 6 Nov 2013 07:30:28 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-17-527a6093a712 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 85.57.03802.3906A725; Wed, 6 Nov 2013 16:30:27 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.328.9; Wed, 6 Nov 2013 16:30:26 +0100 Message-ID: <527A60F1.20604@ericsson.com> Date: Wed, 6 Nov 2013 07:32:01 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: IETF AVTCore WG , "avtext@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIJMWRmVeSWpSXmKPExsUyM+Jvje7khKogg9YL4hYve1ayW3y8d4PV gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZe//eZSzYKFDxfI95A+Ma3i5GTg4JAROJifs2MEPY YhIX7q1n62Lk4hASOMQosWT6SkaQhJDAMkaJ3l1gDbwCmhIrVq1gArFZBFQkvk89DNbMJmAh cfNHIxtEva7E+fkXWUFsUYFgifOvFrND9ApKnJz5hAXEFhFwl/jwbR9YvTDQnBV9TUA2B9AR 4hI9jUEgYWYBPYkpV1sYIWx5ieats5khxmtLNDR1sE5gFJiFZOosJC2zkLQsYGRexciem5iZ k15utIkRGGwHt/xW3cF455zIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBK NTCWWFqr6j10NlfgiFHgv30j4w+fipbUmfKnvi+Fb028+ClwXZrrrENzD2d+35nntL8jeULq 6jdL1572NZ9a0B+wurLw89TH2Qr3Dx5Z5LLupd/2T0pGmnf53IpfPS/a/kR1afbOOUFOPauZ F3UE8bmzZxg/Kk3ZwTtD+NFRBgfrvGKVq4whlmZKLMUZiYZazEXFiQBfVZHbBAIAAA== Subject: [avtext] RTP Topologies and Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "avtext@ietf.org" 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, 06 Nov 2013 15:30:35 -0000 AVTEXT and AVTCORE (Please respond to AVTEXT only) In yesterdays WG session in AVTEXT it was brought up a question regarding Section 4 of draft-ietf-avtext-rtp-grouping-taxonomy-00. This was the question if this belongs in this draft or should be part of the RTP Topologies. My understanding it was put into the taxonomy draft to provide some examples of how the entities definitions actually relate in some cases. However, they can also be seen to duplicate quite a lot of the RTP topologies drafts. And that draft needs an update that uses the taxonomy, as editor I have that on my todo list. Thus we get to the question of what should be done in the taxonomy document. I think there are three alternatives here: 1. Remove all the topologies related discussion and at most make an explicit reference to topologies as showing how taxonomy can be used to describe the RTP Topologies. 2. Select a very small number (1 or 2) enlightening examples just to show what can be done. 3. Include all the main topologies and focus on the bigger picture and point to how RTP and signalling relate using communication and multi-media sessions etc. I personally are not certain between alternative 1 and 2. RTP Topologies do have some signaling discussion, but may get more to function as good examples for the entities concepts. Thus, I might lean slightly more towards 2, with the purpose of focusing on how the communication and multi-media session interacts with participants, end points and RTP sessions. Please provide your opinion or if you think there are additional alternatives? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Wed Nov 6 07:44:57 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3952011E8155 for ; Wed, 6 Nov 2013 07:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd+zxlg7sZJS for ; Wed, 6 Nov 2013 07:44:51 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DED1721F9DAD for ; Wed, 6 Nov 2013 07:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3740; q=dns/txt; s=iport; t=1383752691; x=1384962291; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=cQLRp1dXnPiV3XissJq0TCEd/cU/Q3zVG72t3nxY5vg=; b=BC6f14fzfO/fM32244ZFalrro/aaVhLuXYIObaDWYJ+brDFy+fPIPeST jxSHZKY4Fuzp+KHIvSzdlvJsJUY1W00RFb/JS8B/o7dJqmaxVG1VyRlyQ 7SLeMyhC6CEGKGuw99RZSDDlqsl7Di1ezQE808dXBQKMG5V+MppuekoQu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHAMxjelKtJXG+/2dsb2JhbABagmYhOFOCOU+8LhiBDBZtB4IlAQEBBAEBAQkXEVECBAEGAhEDAQIDAiMDAgQZDAsUAQgIAgQTiAEBDJBvjFaPCJJABASBJY4VIgaCZYFFA5gMkgqDJoIq X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="281455198" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 06 Nov 2013 15:44:36 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA6Fiahp023642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Nov 2013 15:44:36 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 09:44:35 -0600 From: "Ali C. Begen (abegen)" To: "avtext@ietf.org" Thread-Topic: [AVTCORE] RTP Topologies and Taxonomy Thread-Index: AQHO2wUngnXFezLCpk6z1obcZbDs9ZoYNp6A Date: Wed, 6 Nov 2013 15:44:35 +0000 Message-ID: In-Reply-To: <527A60F1.20604@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.94.51] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [avtext] [AVTCORE] RTP Topologies and Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 06 Nov 2013 15:44:57 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQpSZXBseS1UbzogImF2dGV4dEBpZXRmLm9yZyIg PGF2dGV4dEBpZXRmLm9yZz4NCkRhdGU6IFdlZG5lc2RheSwgTm92ZW1iZXIgNiwgMjAxMyBhdCA0 OjMyIFBNDQpUbzogSUVURiBBVlRDb3JlIFdHIDxhdnRAaWV0Zi5vcmc+LCAiYXZ0ZXh0QGlldGYu b3JnIiA8YXZ0ZXh0QGlldGYub3JnPg0KU3ViamVjdDogW0FWVENPUkVdIFJUUCBUb3BvbG9naWVz IGFuZCBUYXhvbm9teQ0KDQo+QVZURVhUIGFuZCBBVlRDT1JFDQo+KFBsZWFzZSByZXNwb25kIHRv IEFWVEVYVCBvbmx5KQ0KPg0KPkluIHllc3RlcmRheXMgV0cgc2Vzc2lvbiBpbiBBVlRFWFQgaXQg d2FzIGJyb3VnaHQgdXAgYSBxdWVzdGlvbg0KPnJlZ2FyZGluZyBTZWN0aW9uIDQgb2YgZHJhZnQt aWV0Zi1hdnRleHQtcnRwLWdyb3VwaW5nLXRheG9ub215LTAwLiBUaGlzDQo+d2FzIHRoZSBxdWVz dGlvbiBpZiB0aGlzIGJlbG9uZ3MgaW4gdGhpcyBkcmFmdCBvciBzaG91bGQgYmUgcGFydCBvZiB0 aGUNCj5SVFAgVG9wb2xvZ2llcy4NCj4NCj5NeSB1bmRlcnN0YW5kaW5nIGl0IHdhcyBwdXQgaW50 byB0aGUgdGF4b25vbXkgZHJhZnQgdG8gcHJvdmlkZSBzb21lDQo+ZXhhbXBsZXMgb2YgaG93IHRo ZSBlbnRpdGllcyBkZWZpbml0aW9ucyBhY3R1YWxseSByZWxhdGUgaW4gc29tZSBjYXNlcy4NCj5I b3dldmVyLCB0aGV5IGNhbiBhbHNvIGJlIHNlZW4gdG8gZHVwbGljYXRlIHF1aXRlIGEgbG90IG9m IHRoZSBSVFANCj50b3BvbG9naWVzIGRyYWZ0cy4gQW5kIHRoYXQgZHJhZnQgbmVlZHMgYW4gdXBk YXRlIHRoYXQgdXNlcyB0aGUNCj50YXhvbm9teSwgYXMgZWRpdG9yIEkgaGF2ZSB0aGF0IG9uIG15 IHRvZG8gbGlzdC4gVGh1cyB3ZSBnZXQgdG8gdGhlDQo+cXVlc3Rpb24gb2Ygd2hhdCBzaG91bGQg YmUgZG9uZSBpbiB0aGUgdGF4b25vbXkgZG9jdW1lbnQuDQo+DQo+SSB0aGluayB0aGVyZSBhcmUg dGhyZWUgYWx0ZXJuYXRpdmVzIGhlcmU6DQo+DQo+MS4gUmVtb3ZlIGFsbCB0aGUgdG9wb2xvZ2ll cyByZWxhdGVkIGRpc2N1c3Npb24gYW5kIGF0IG1vc3QgbWFrZSBhbg0KPmV4cGxpY2l0IHJlZmVy ZW5jZSB0byB0b3BvbG9naWVzIGFzIHNob3dpbmcgaG93IHRheG9ub215IGNhbiBiZSB1c2VkIHRv DQo+ZGVzY3JpYmUgdGhlIFJUUCBUb3BvbG9naWVzLg0KDQpJIGFtIGluIGZhdm9yIG9mIHRoaXMg YXBwcm9hY2guIEl0IG1ha2VzIGl0IGNsZWFuZXIgYW5kIGVhc2llciBmb3Igc29tZW9uZQ0KZ2V0 dGluZyBpbnRvIHRoaXMgc3R1ZmYgZm9yIHRoZSBmaXJzdCB0aW1lLg0KDQo+DQo+Mi4gU2VsZWN0 IGEgdmVyeSBzbWFsbCBudW1iZXIgKDEgb3IgMikgZW5saWdodGVuaW5nIGV4YW1wbGVzIGp1c3Qg dG8NCj5zaG93IHdoYXQgY2FuIGJlIGRvbmUuDQo+DQo+My4gSW5jbHVkZSBhbGwgdGhlIG1haW4g dG9wb2xvZ2llcyBhbmQgZm9jdXMgb24gdGhlIGJpZ2dlciBwaWN0dXJlIGFuZA0KPnBvaW50IHRv IGhvdyBSVFAgYW5kIHNpZ25hbGxpbmcgcmVsYXRlIHVzaW5nIGNvbW11bmljYXRpb24gYW5kDQo+ bXVsdGktbWVkaWEgc2Vzc2lvbnMgZXRjLg0KPg0KPkkgcGVyc29uYWxseSBhcmUgbm90IGNlcnRh aW4gYmV0d2VlbiBhbHRlcm5hdGl2ZSAxIGFuZCAyLiBSVFAgVG9wb2xvZ2llcw0KPmRvIGhhdmUg c29tZSBzaWduYWxpbmcgZGlzY3Vzc2lvbiwgYnV0IG1heSBnZXQgbW9yZSB0byBmdW5jdGlvbiBh cyBnb29kDQo+ZXhhbXBsZXMgZm9yIHRoZSBlbnRpdGllcyBjb25jZXB0cy4gVGh1cywgSSBtaWdo dCBsZWFuIHNsaWdodGx5IG1vcmUNCj50b3dhcmRzIDIsIHdpdGggdGhlIHB1cnBvc2Ugb2YgZm9j dXNpbmcgb24gaG93IHRoZSBjb21tdW5pY2F0aW9uIGFuZA0KPm11bHRpLW1lZGlhIHNlc3Npb24g aW50ZXJhY3RzIHdpdGggcGFydGljaXBhbnRzLCBlbmQgcG9pbnRzIGFuZCBSVFANCj5zZXNzaW9u cy4NCj4NCj5QbGVhc2UgcHJvdmlkZSB5b3VyIG9waW5pb24gb3IgaWYgeW91IHRoaW5rIHRoZXJl IGFyZSBhZGRpdGlvbmFsDQo+YWx0ZXJuYXRpdmVzPw0KPg0KPkNoZWVycw0KPg0KPk1hZ251cyBX ZXN0ZXJsdW5kDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPk11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBF cmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkVyaWNzc29uIEFCICAg ICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+RsOkcsO2Z2F0YW4gNiAgICAg ICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPlNFLTE2NCA4MCBTdG9ja2hvbG0s IFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5BdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPmF2dEBpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+DQoNCg0K From csp@csperkins.org Wed Nov 6 13:14:12 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFA021E8185 for ; Wed, 6 Nov 2013 13:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ffe06nx--ol for ; Wed, 6 Nov 2013 13:14:12 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E7121E8182 for ; Wed, 6 Nov 2013 13:14:11 -0800 (PST) Received: from [31.133.152.95] (port=57617 helo=dhcp-985f.meeting.ietf.org) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VeAQU-0000Ib-6Z; Wed, 06 Nov 2013 21:14:10 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: Date: Wed, 6 Nov 2013 13:14:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0A8E7971-A871-4E63-BFD6-B9BCB51CA03D@csperkins.org> References: To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "avtext@ietf.org" Subject: Re: [avtext] [AVTCORE] RTP Topologies and Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 06 Nov 2013 21:14:12 -0000 On 6 Nov 2013, at 07:44, Ali C. Begen (abegen) wrote: > -----Original Message----- > From: Magnus Westerlund > Reply-To: "avtext@ietf.org" > Date: Wednesday, November 6, 2013 at 4:32 PM > To: IETF AVTCore WG , "avtext@ietf.org" = > Subject: [AVTCORE] RTP Topologies and Taxonomy >=20 >> AVTEXT and AVTCORE >> (Please respond to AVTEXT only) >>=20 >> In yesterdays WG session in AVTEXT it was brought up a question >> regarding Section 4 of draft-ietf-avtext-rtp-grouping-taxonomy-00. = This >> was the question if this belongs in this draft or should be part of = the >> RTP Topologies. >>=20 >> My understanding it was put into the taxonomy draft to provide some >> examples of how the entities definitions actually relate in some = cases. >> However, they can also be seen to duplicate quite a lot of the RTP >> topologies drafts. And that draft needs an update that uses the >> taxonomy, as editor I have that on my todo list. Thus we get to the >> question of what should be done in the taxonomy document. >>=20 >> I think there are three alternatives here: >>=20 >> 1. Remove all the topologies related discussion and at most make an = explicit reference to topologies as showing how taxonomy can be used to = describe the RTP Topologies. >=20 > I am in favor of this approach. It makes it cleaner and easier for = someone getting into this stuff for the first time. Agree - if it can be done cleanly, I'd prefer to see all the topologies = discussion in one place, rather than duplicating some of it into this = draft. --=20 Colin Perkins http://csperkins.org/ From keith.drage@alcatel-lucent.com Wed Nov 6 13:45:40 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B0C21F9EAD for ; Wed, 6 Nov 2013 13:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.531 X-Spam-Level: X-Spam-Status: No, score=-110.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7ntRHIUvdZO for ; Wed, 6 Nov 2013 13:45:35 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DCB6E21E81A5 for ; Wed, 6 Nov 2013 13:44:54 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rA6LieYO024473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Nov 2013 15:44:46 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rA6Lie8r006451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 22:44:40 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 6 Nov 2013 22:44:40 +0100 From: "DRAGE, Keith (Keith)" To: Colin Perkins , "Ali C. Begen (abegen)" Thread-Topic: [avtext] [AVTCORE] RTP Topologies and Taxonomy Thread-Index: AQHO2wUzKt1lSMCxg0us72eu+nUy/poYR2GAgABcEoCAABkZoA== Date: Wed, 6 Nov 2013 21:44:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0CB8B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <0A8E7971-A871-4E63-BFD6-B9BCB51CA03D@csperkins.org> In-Reply-To: <0A8E7971-A871-4E63-BFD6-B9BCB51CA03D@csperkins.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "avtext@ietf.org" Subject: Re: [avtext] [AVTCORE] RTP Topologies and Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 06 Nov 2013 21:45:41 -0000 Agree The function of the taxononmy document is to define the fundamental RTP ter= minology. The topology document should then use that taxonomy. Keith=20 > -----Original Message----- > From: avtext-bounces@ietf.org=20 > [mailto:avtext-bounces@ietf.org] On Behalf Of Colin Perkins > Sent: 06 November 2013 21:14 > To: Ali C. Begen (abegen) > Cc: avtext@ietf.org > Subject: Re: [avtext] [AVTCORE] RTP Topologies and Taxonomy >=20 > On 6 Nov 2013, at 07:44, Ali C. Begen (abegen)=20 > wrote: > > -----Original Message----- > > From: Magnus Westerlund > > Reply-To: "avtext@ietf.org" > > Date: Wednesday, November 6, 2013 at 4:32 PM > > To: IETF AVTCore WG , "avtext@ietf.org"=20 > > > > Subject: [AVTCORE] RTP Topologies and Taxonomy > >=20 > >> AVTEXT and AVTCORE > >> (Please respond to AVTEXT only) > >>=20 > >> In yesterdays WG session in AVTEXT it was brought up a question=20 > >> regarding Section 4 of draft-ietf-avtext-rtp-grouping-taxonomy-00.=20 > >> This was the question if this belongs in this draft or=20 > should be part=20 > >> of the RTP Topologies. > >>=20 > >> My understanding it was put into the taxonomy draft to=20 > provide some=20 > >> examples of how the entities definitions actually relate=20 > in some cases. > >> However, they can also be seen to duplicate quite a lot of the RTP=20 > >> topologies drafts. And that draft needs an update that uses the=20 > >> taxonomy, as editor I have that on my todo list. Thus we=20 > get to the=20 > >> question of what should be done in the taxonomy document. > >>=20 > >> I think there are three alternatives here: > >>=20 > >> 1. Remove all the topologies related discussion and at=20 > most make an explicit reference to topologies as showing how=20 > taxonomy can be used to describe the RTP Topologies. > >=20 > > I am in favor of this approach. It makes it cleaner and=20 > easier for someone getting into this stuff for the first time. >=20 >=20 > Agree - if it can be done cleanly, I'd prefer to see all the=20 > topologies discussion in one place, rather than duplicating=20 > some of it into this draft. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > = From ron.even.tlv@gmail.com Wed Nov 6 14:55:34 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D749021E8117 for ; Wed, 6 Nov 2013 14:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cBMZw6xXa6F for ; Wed, 6 Nov 2013 14:55:28 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87D21E80FD for ; Wed, 6 Nov 2013 14:55:23 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id w10so175455pde.31 for ; Wed, 06 Nov 2013 14:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=Qb8WEmkXGGEKUfzFn0I+5ZlPCPtmDTv0/mErBsd5fQ8=; b=cchV9RGxZeX4r2+79YO+HKGEXBCkvU1iSdTAfaXl2v5Br71yd16zB7B4S6B09XeZpr QtWi17S93pSbeKWIa8XlBL2OYAUrZy1Y1lG1+AQaO4uM50ZpzAFaE3cWB8MFdWg5vK5o eRZaA7Oh/zDRQYPJtSvm+k3N9Jl7N57ECtKxnAWPF4cYBJS9mGVz0acCc9jNCWtTT486 tG+2XLV4qHUC0Sh+hgvGCB4Q2Cp3yJFO1DjGnnCJGJ96xqDXdrjBdVvglNJBf4YfDhas QTSs5/dlaWNLjJp7t9IyrvkGwNPH3V540+gPtRRA9hBtzrQByAdgj1Zphszhy6xTiwsI R5yQ== X-Received: by 10.67.23.71 with SMTP id hy7mr6199334pad.99.1383778522036; Wed, 06 Nov 2013 14:55:22 -0800 (PST) Received: from RoniE ([2001:67c:370:160:406b:3f90:eda6:deb7]) by mx.google.com with ESMTPSA id ka3sm437724pbc.32.2013.11.06.14.55.19 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Nov 2013 14:55:21 -0800 (PST) From: "Roni Even" To: "'Colin Perkins'" , "'Ali C. Begen \(abegen\)'" References: <0A8E7971-A871-4E63-BFD6-B9BCB51CA03D@csperkins.org> In-Reply-To: <0A8E7971-A871-4E63-BFD6-B9BCB51CA03D@csperkins.org> Date: Thu, 7 Nov 2013 00:52:03 +0200 Message-ID: <00c201cedb42$d1acf2a0$7506d7e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ81Nv3rw4GRmBcaXne2Q+Hd5s93QM9EyZAmKLzLYA= Content-Language: en-us Cc: avtext@ietf.org Subject: Re: [avtext] [AVTCORE] RTP Topologies and Taxonomy X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 06 Nov 2013 22:55:34 -0000 Support Colin's and Ali's view Roni > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of > Colin Perkins > Sent: 06 November, 2013 11:14 PM > To: Ali C. Begen (abegen) > Cc: avtext@ietf.org > Subject: Re: [avtext] [AVTCORE] RTP Topologies and Taxonomy > > On 6 Nov 2013, at 07:44, Ali C. Begen (abegen) wrote: > > -----Original Message----- > > From: Magnus Westerlund > > Reply-To: "avtext@ietf.org" > > Date: Wednesday, November 6, 2013 at 4:32 PM > > To: IETF AVTCore WG , "avtext@ietf.org" > > > > Subject: [AVTCORE] RTP Topologies and Taxonomy > > > >> AVTEXT and AVTCORE > >> (Please respond to AVTEXT only) > >> > >> In yesterdays WG session in AVTEXT it was brought up a question > >> regarding Section 4 of draft-ietf-avtext-rtp-grouping-taxonomy-00. > >> This was the question if this belongs in this draft or should be part > >> of the RTP Topologies. > >> > >> My understanding it was put into the taxonomy draft to provide some > >> examples of how the entities definitions actually relate in some cases. > >> However, they can also be seen to duplicate quite a lot of the RTP > >> topologies drafts. And that draft needs an update that uses the > >> taxonomy, as editor I have that on my todo list. Thus we get to the > >> question of what should be done in the taxonomy document. > >> > >> I think there are three alternatives here: > >> > >> 1. Remove all the topologies related discussion and at most make an explicit > reference to topologies as showing how taxonomy can be used to describe the > RTP Topologies. > > > > I am in favor of this approach. It makes it cleaner and easier for someone > getting into this stuff for the first time. > > > Agree - if it can be done cleanly, I'd prefer to see all the topologies discussion > in one place, rather than duplicating some of it into this draft. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From Mark.Duckworth@polycom.com Wed Nov 6 18:51:08 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116CD21E80C8 for ; Wed, 6 Nov 2013 18:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAr6Q+edYBma for ; Wed, 6 Nov 2013 18:50:00 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A1C4121E80AA for ; Wed, 6 Nov 2013 18:49:58 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 6 Nov 2013 18:49:58 -0800 From: "Duckworth, Mark" To: "avtext@ietf.org" Date: Wed, 6 Nov 2013 18:49:56 -0800 Thread-Topic: taxonomy Packet Stream Thread-Index: Ac7bYu/3hvd+kbf+T9iQZ/eEXznqDw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D604069561@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D604069561CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [avtext] taxonomy Packet Stream X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 02:51:08 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D604069561CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have questions about the Packet Stream in the taxonomy. It says "At any = given point in time, a Packet Stream can have one and only one SSRC." So i= s it possible for a particular packet stream to have one SSRC value at one = time, and then have a different SSRC value some other time, but it is still= the same packet stream? What are some examples of this? For a media switching mixer (from rtp-topologies-update document), it sends= a packet stream with its own SSRC value. So when it switches between avai= lable sources, the outgoing SSRC from the mixer doesn't change, so all thos= e packets with the same SSRC belong to the same packet stream both before a= nd after a switch occurs, is that right? And what about a selective forwarding middlebox? In this case the SSRC chan= ges when a switch occurs, so does this mean a new packet stream starts and = the previous packet stream ends? Or do you consider it all the same packet = stream even though the SSRC has changed? Mark Duckworth --_000_49E45C59CA48264997FEBFB29B6BC2D604069561CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have questions= about the Packet Stream in the taxonomy.  It says “At any given= point in time, a Packet Stream can have one and only one SSRC.” = ; So is it possible for a particular packet stream to have one SSRC value a= t one time, and then have a different SSRC value some other time, but it is= still the same packet stream? What are some examples of this?

 

For a medi= a switching mixer (from rtp-topologies-update document), it sends a packet = stream with its own SSRC value.  So when it switches between available= sources, the outgoing SSRC from the mixer doesn’t change, so all tho= se packets with the same SSRC belong to the same packet stream both before = and after a switch occurs, is that right?

 

And what about a selective forw= arding middlebox? In this case the SSRC changes when a switch occurs, so do= es this mean a new packet stream starts and the previous packet stream ends= ? Or do you consider it all the same packet stream even though the SSRC has= changed?

 

Mark Duckworth

= --_000_49E45C59CA48264997FEBFB29B6BC2D604069561CRPMBOXPRD07pol_-- From roni.even@mail01.huawei.com Wed Nov 6 22:11:53 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14C011E8230 for ; Wed, 6 Nov 2013 22:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4twpIDgt5Z5 for ; Wed, 6 Nov 2013 22:11:47 -0800 (PST) Received: from hwsga01-in.huaweimarine.com (hwsga01-in.huaweimarine.com [119.145.15.223]) by ietfa.amsl.com (Postfix) with ESMTP id 6190711E8167 for ; Wed, 6 Nov 2013 22:11:47 -0800 (PST) Received: from 172.24.1.78 (EHLO szxpml204-edg.exmail.huawei.com) ([172.24.1.78]) by szxrg11-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWR55800; Thu, 07 Nov 2013 14:11:44 +0800 (CST) Received: from SZXPML402-HUB.exmail.huawei.com (10.82.67.142) by szxpml204-edg.exmail.huawei.com (172.24.2.15) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 14:11:34 +0800 Received: from SZXPML507-MBX.exmail.huawei.com ([169.254.2.47]) by szxpml402-hub.exmail.huawei.com ([10.82.67.142]) with mapi id 14.03.0158.001; Thu, 7 Nov 2013 14:11:39 +0800 From: Roni Even To: "Duckworth, Mark" , "avtext@ietf.org" Thread-Topic: taxonomy Packet Stream Thread-Index: Ac7bYu/3hvd+kbf+T9iQZ/eEXznqDwAHTJjc Date: Thu, 7 Nov 2013 06:11:39 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C23E53D558@szxpml507-mbx.exmail.huawei.com> References: <49E45C59CA48264997FEBFB29B6BC2D604069561@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D604069561@CRPMBOXPRD07.polycom.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.61] Content-Type: multipart/alternative; boundary="_000_760B7D45D1EFF74988DBF5C2122830C23E53D558szxpml507mbxexm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [avtext] taxonomy Packet Stream X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 06:11:53 -0000 --_000_760B7D45D1EFF74988DBF5C2122830C23E53D558szxpml507mbxexm_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mark, SSRC collison Roni ________________________________ From: avtext-bounces@ietf.org [avtext-bounces@ietf.org] on behalf of Duckwo= rth, Mark [Mark.Duckworth@polycom.com] Sent: Thursday, November 07, 2013 4:49 AM To: avtext@ietf.org Subject: [avtext] taxonomy Packet Stream I have questions about the Packet Stream in the taxonomy. It says =93At an= y given point in time, a Packet Stream can have one and only one SSRC.=94 = So is it possible for a particular packet stream to have one SSRC value at = one time, and then have a different SSRC value some other time, but it is s= till the same packet stream? What are some examples of this? For a media switching mixer (from rtp-topologies-update document), it sends= a packet stream with its own SSRC value. So when it switches between avai= lable sources, the outgoing SSRC from the mixer doesn=92t change, so all th= ose packets with the same SSRC belong to the same packet stream both before= and after a switch occurs, is that right? And what about a selective forwarding middlebox? In this case the SSRC chan= ges when a switch occurs, so does this mean a new packet stream starts and = the previous packet stream ends? Or do you consider it all the same packet = stream even though the SSRC has changed? Mark Duckworth --_000_760B7D45D1EFF74988DBF5C2122830C23E53D558szxpml507mbxexm_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Mark,

SSRC collison

Roni

From: avtext-bounces@ietf.org [avtext-boun= ces@ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com]
Sent: Thursday, November 07, 2013 4:49 AM
To: avtext@ietf.org
Subject: [avtext] taxonomy Packet Stream

I have questions about the Packet Stream in the taxo= nomy.  It says =93At any given point in time, a Packet Stream can have= one and only one SSRC.=94  So is it possible for a particular packet = stream to have one SSRC value at one time, and then have a different SSRC value some other time, but it is still the same pack= et stream? What are some examples of this?

 

For a media switching mixer (from rtp-topologies-upd= ate document), it sends a packet stream with its own SSRC value.  So w= hen it switches between available sources, the outgoing SSRC from the mixer= doesn=92t change, so all those packets with the same SSRC belong to the same packet stream both before and after a swi= tch occurs, is that right?

 

And what about a selective forwarding middlebox? In = this case the SSRC changes when a switch occurs, so does this mean a new pa= cket stream starts and the previous packet stream ends? Or do you consider = it all the same packet stream even though the SSRC has changed?

 

Mark Duckworth

--_000_760B7D45D1EFF74988DBF5C2122830C23E53D558szxpml507mbxexm_-- From mary.ietf.barnes@gmail.com Thu Nov 7 08:12:15 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9C821E8116 for ; Thu, 7 Nov 2013 08:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5zenYXAQlkU for ; Thu, 7 Nov 2013 08:12:15 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6911B21E81AA for ; Thu, 7 Nov 2013 08:12:12 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id c11so741949wgh.33 for ; Thu, 07 Nov 2013 08:12:11 -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=C9AjQ+fvizUtC18tm8EF3lS3Ah4cJCQBdmUtlOj9ijQ=; b=aoS4wOeUf87W6N047AjGIA2YQiYf6L2O74blYvKSZoXAnzP0v+l1En0YaNpzfXBX/4 1iDXURgH/8O2HW4ozBm8OkDxZxA1K3wfFCoY82iyEwr0YyN1yEbl8phWgesFBSffLsH2 U5nLe2JTzZ31028KWLprCACkj6ar0E+X8Omp8cVyeSS4OMsAJFeuv8uQPj46jPsl7HUz AZvyIQIex9NdxiFkRHyWcNjDQd5vXVWmk7KqXrkJc8kWvy4EZd8mYq6mgqWt+WC8sL5o wPN8A0uKG+tB93reixARlPYwZccgV9krrW1W1Z0+yAKbVHIBhWI+FJA9XBY4VBJIVGgx yjRw== MIME-Version: 1.0 X-Received: by 10.194.20.230 with SMTP id q6mr7275789wje.49.1383840731304; Thu, 07 Nov 2013 08:12:11 -0800 (PST) Received: by 10.216.36.4 with HTTP; Thu, 7 Nov 2013 08:12:11 -0800 (PST) In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C23E53D558@szxpml507-mbx.exmail.huawei.com> References: <49E45C59CA48264997FEBFB29B6BC2D604069561@CRPMBOXPRD07.polycom.com> <760B7D45D1EFF74988DBF5C2122830C23E53D558@szxpml507-mbx.exmail.huawei.com> Date: Thu, 7 Nov 2013 10:12:11 -0600 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=047d7b5d971b37193a04ea9887f5 Cc: "avtext@ietf.org" Subject: Re: [avtext] taxonomy Packet Stream X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 16:12:16 -0000 --047d7b5d971b37193a04ea9887f5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Roni, Can you elaborate a bit more - i.e., answer each of Mark's questions? Mary. On Thu, Nov 7, 2013 at 12:11 AM, Roni Even wro= te: > Mark, > > SSRC collison > > Roni > ------------------------------ > *From:* avtext-bounces@ietf.org [avtext-bounces@ietf.org] on behalf of > Duckworth, Mark [Mark.Duckworth@polycom.com] > *Sent:* Thursday, November 07, 2013 4:49 AM > *To:* avtext@ietf.org > *Subject:* [avtext] taxonomy Packet Stream > > I have questions about the Packet Stream in the taxonomy. It says =93A= t > any given point in time, a Packet Stream can have one and only one SSRC.= =94 > So is it possible for a particular packet stream to have one SSRC value a= t > one time, and then have a different SSRC value some other time, but it is > still the same packet stream? What are some examples of this? > > > > For a media switching mixer (from rtp-topologies-update document), it > sends a packet stream with its own SSRC value. So when it switches betwe= en > available sources, the outgoing SSRC from the mixer doesn=92t change, so = all > those packets with the same SSRC belong to the same packet stream both > before and after a switch occurs, is that right? > > > > And what about a selective forwarding middlebox? In this case the SSRC > changes when a switch occurs, so does this mean a new packet stream start= s > and the previous packet stream ends? Or do you consider it all the same > packet stream even though the SSRC has changed? > > > > Mark Duckworth > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > > --047d7b5d971b37193a04ea9887f5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Roni,

Can you elaborate a bit mor= e - i.e., answer each of Mark's questions?

Mary.


On Thu, Nov 7, 2013 at 12:11 AM, Roni Even <roni.even@mail01.hua= wei.com> wrote:

Mark,

SSRC collison

Roni

Fro= m: avtext-= bounces@ietf.org [avtext-bounces@ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@pol= ycom.com]
Sent: Thursday, November 07, 2013 4:49 AM
To: avtext@ietf= .org
Subject: [avtext] taxonomy Packet Stream

I have questions about the Packet Stream in the taxo= nomy.=A0 It says =93At any given point in time, a Packet Stream can have on= e and only one SSRC.=94=A0 So is it possible for a particular packet stream= to have one SSRC value at one time, and then have a different SSRC value some other time, but it is still the same pack= et stream? What are some examples of this?

=A0

For a media switching mixer (from rtp-topologies-upd= ate document), it sends a packet stream with its own SSRC value.=A0 So when= it switches between available sources, the outgoing SSRC from the mixer do= esn=92t change, so all those packets with the same SSRC belong to the same packet stream both before and after a swi= tch occurs, is that right?

=A0

And what about a selective forwarding middlebox? In = this case the SSRC changes when a switch occurs, so does this mean a new pa= cket stream starts and the previous packet stream ends? Or do you consider = it all the same packet stream even though the SSRC has changed?

=A0

Mark Duckworth


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


--047d7b5d971b37193a04ea9887f5-- From roni.even@mail01.huawei.com Thu Nov 7 08:47:58 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9352C11E80EC for ; Thu, 7 Nov 2013 08:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+Qxmkp3G1Fn for ; Thu, 7 Nov 2013 08:47:52 -0800 (PST) Received: from hwsga02-in.huaweimarine.com (unknown [119.145.15.224]) by ietfa.amsl.com (Postfix) with ESMTP id 140D021E8144 for ; Thu, 7 Nov 2013 08:46:28 -0800 (PST) Received: from 172.24.1.80 (EHLO szxpml203-edg.exmail.huawei.com) ([172.24.1.80]) by szxrg12-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTM79933; Fri, 08 Nov 2013 00:46:08 +0800 (CST) Received: from SZXPML401-HUB.exmail.huawei.com (10.82.67.140) by szxpml203-edg.exmail.huawei.com (172.24.2.14) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 00:45:50 +0800 Received: from SZXPML507-MBX.exmail.huawei.com ([169.254.2.47]) by szxpml401-hub.exmail.huawei.com ([10.82.67.140]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 00:46:01 +0800 From: Roni Even To: Mary Barnes Thread-Topic: [avtext] taxonomy Packet Stream Thread-Index: Ac7bYu/3hvd+kbf+T9iQZ/eEXznqDwAHTJjcAAQ7L4AAEd/ZKA== Date: Thu, 7 Nov 2013 16:46:01 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C23E53D786@szxpml507-mbx.exmail.huawei.com> References: <49E45C59CA48264997FEBFB29B6BC2D604069561@CRPMBOXPRD07.polycom.com> <760B7D45D1EFF74988DBF5C2122830C23E53D558@szxpml507-mbx.exmail.huawei.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.60] Content-Type: multipart/alternative; boundary="_000_760B7D45D1EFF74988DBF5C2122830C23E53D786szxpml507mbxexm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "avtext@ietf.org" Subject: Re: [avtext] taxonomy Packet Stream X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 16:48:00 -0000 --_000_760B7D45D1EFF74988DBF5C2122830C23E53D786szxpml507mbxexm_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mary, The taxonomy question was "So is it possible for a particular packet stream to have one SSRC value at= one time, and then have a different SSRC value some other time, but it is = still the same packet stream? What are some examples of this?" and one exmple is SSRC collison The other topics are about toplogies and maybe should be sent to avtcore ma= iling list with regards to the topologies draft Roni ________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Thursday, November 07, 2013 6:12 PM To: Roni Even Cc: Duckworth, Mark; avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream Roni, Can you elaborate a bit more - i.e., answer each of Mark's questions? Mary. On Thu, Nov 7, 2013 at 12:11 AM, Roni Even > wrote: Mark, SSRC collison Roni ________________________________ From: avtext-bounces@ietf.org [avtext-bounc= es@ietf.org] on behalf of Duckworth, Mark [= Mark.Duckworth@polycom.com] Sent: Thursday, November 07, 2013 4:49 AM To: avtext@ietf.org Subject: [avtext] taxonomy Packet Stream I have questions about the Packet Stream in the taxonomy. It says =93At an= y given point in time, a Packet Stream can have one and only one SSRC.=94 = So is it possible for a particular packet stream to have one SSRC value at = one time, and then have a different SSRC value some other time, but it is s= till the same packet stream? What are some examples of this? For a media switching mixer (from rtp-topologies-update document), it sends= a packet stream with its own SSRC value. So when it switches between avai= lable sources, the outgoing SSRC from the mixer doesn=92t change, so all th= ose packets with the same SSRC belong to the same packet stream both before= and after a switch occurs, is that right? And what about a selective forwarding middlebox? In this case the SSRC chan= ges when a switch occurs, so does this mean a new packet stream starts and = the previous packet stream ends? Or do you consider it all the same packet = stream even though the SSRC has changed? Mark Duckworth _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_760B7D45D1EFF74988DBF5C2122830C23E53D786szxpml507mbxexm_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Mary,

The taxonomy  question was

"So is it possible for a particul= ar packet stream to have one SSRC value at one time, and then have a differ= ent SSRC value some other time, but it is still the same packet stream? Wha= t are some examples of this?"

 and one exmple is SSRC collison<= /font>

 

The other topics are about toplogies a= nd maybe should be sent to avtcore mailing list with regards to the topolog= ies draft

Roni

 

From: Mary Barnes [mary.ietf.barnes@gmail.= com]
Sent: Thursday, November 07, 2013 6:12 PM
To: Roni Even
Cc: Duckworth, Mark; avtext@ietf.org
Subject: Re: [avtext] taxonomy Packet Stream

Roni,

Can you elaborate a bit more - i.e., answer each of Mark's questions?<= /div>

Mary.


On Thu, Nov 7, 2013 at 12:11 AM, Roni Even <roni.e= ven@mail01.huawei.com> wrote:

Mark,

SSRC collison

Roni

Fr= om: avtext-bounces@ietf.org [avtext-bounces@ietf.org] on behalf of Duckworth, Mark [<= a href=3D"mailto:Mark.Duckworth@polycom.com" target=3D"_blank">Mark.Duckwor= th@polycom.com]
Sent: Thursday, November 07, 2013 4:49 AM
To: avtext@ietf= .org
Subject: [avtext] taxonomy Packet Stream

I have questions about the Packet Stream in the taxo= nomy.  It says =93At any given point in time, a Packet Stream can have= one and only one SSRC.=94  So is it possible for a particular packet = stream to have one SSRC value at one time, and then have a different SSRC value some other time, but it is still the same pack= et stream? What are some examples of this?

 

For a media switching mixer (from rtp-topologies-upd= ate document), it sends a packet stream with its own SSRC value.  So w= hen it switches between available sources, the outgoing SSRC from the mixer= doesn=92t change, so all those packets with the same SSRC belong to the same packet stream both before and after a swi= tch occurs, is that right?

 

And what about a selective forwarding middlebox? In = this case the SSRC changes when a switch occurs, so does this mean a new pa= cket stream starts and the previous packet stream ends? Or do you consider = it all the same packet stream even though the SSRC has changed?

 

Mark Duckworth


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


--_000_760B7D45D1EFF74988DBF5C2122830C23E53D786szxpml507mbxexm_-- From Mark.Duckworth@polycom.com Fri Nov 8 09:53:56 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304E921E81D1 for ; Fri, 8 Nov 2013 09:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxK5+JXxZg8h for ; Fri, 8 Nov 2013 09:53:52 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B0E4611E81E4 for ; Fri, 8 Nov 2013 09:53:51 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 8 Nov 2013 09:53:48 -0800 From: "Duckworth, Mark" To: "avtext@ietf.org" Date: Fri, 8 Nov 2013 09:53:45 -0800 Thread-Topic: [avtext] taxonomy Packet Stream Thread-Index: Ac7bYu/3hvd+kbf+T9iQZ/eEXznqDwAHTJjcAAQ7L4AAEd/ZKAA0K1BA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D604069B31@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D604069561@CRPMBOXPRD07.polycom.com> <760B7D45D1EFF74988DBF5C2122830C23E53D558@szxpml507-mbx.exmail.huawei.com>, <760B7D45D1EFF74988DBF5C2122830C23E53D786@szxpml507-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C23E53D786@szxpml507-mbx.exmail.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D604069B31CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [avtext] taxonomy Packet Stream X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 17:53:56 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D604069B31CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Roni. It makes sense that SSRC collision is one reason why the SSRC= in a packet stream can change. Is that the only reason? I suggest we make = this more clear in section 2.1.10.2, the characteristics of a packet stream= . I will ask the other questions in avtcore. Mark From: Roni Even [mailto:roni.even@mail01.huawei.com] Sent: Thursday, November 07, 2013 8:46 AM To: Mary Barnes Cc: Duckworth, Mark; avtext@ietf.org Subject: RE: [avtext] taxonomy Packet Stream Mary, The taxonomy question was "So is it possible for a particular packet stream to have one SSRC value at= one time, and then have a different SSRC value some other time, but it is = still the same packet stream? What are some examples of this?" and one exmple is SSRC collison The other topics are about toplogies and maybe should be sent to avtcore ma= iling list with regards to the topologies draft Roni ________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Thursday, November 07, 2013 6:12 PM To: Roni Even Cc: Duckworth, Mark; avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream Roni, Can you elaborate a bit more - i.e., answer each of Mark's questions? Mary. On Thu, Nov 7, 2013 at 12:11 AM, Roni Even > wrote: Mark, SSRC collison Roni ________________________________ From: avtext-bounces@ietf.org [avtext-bounc= es@ietf.org] on behalf of Duckworth, Mark [= Mark.Duckworth@polycom.com] Sent: Thursday, November 07, 2013 4:49 AM To: avtext@ietf.org Subject: [avtext] taxonomy Packet Stream I have questions about the Packet Stream in the taxonomy. It says "At any = given point in time, a Packet Stream can have one and only one SSRC." So i= s it possible for a particular packet stream to have one SSRC value at one = time, and then have a different SSRC value some other time, but it is still= the same packet stream? What are some examples of this? For a media switching mixer (from rtp-topologies-update document), it sends= a packet stream with its own SSRC value. So when it switches between avai= lable sources, the outgoing SSRC from the mixer doesn't change, so all thos= e packets with the same SSRC belong to the same packet stream both before a= nd after a switch occurs, is that right? And what about a selective forwarding middlebox? In this case the SSRC chan= ges when a switch occurs, so does this mean a new packet stream starts and = the previous packet stream ends? Or do you consider it all the same packet = stream even though the SSRC has changed? Mark Duckworth _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_49E45C59CA48264997FEBFB29B6BC2D604069B31CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Ro= ni.  It makes sense that SSRC collision is one reason why the SSRC in = a packet stream can change. Is that the only reason? I suggest we make this= more clear in section 2.1.10.2, the characteristics of a packet stream.

 

=

I will ask the other questions in avtcore.=

 

Mark

 

= From:= Roni Even [mailto:roni.even@mail01.huawei.com]
Sent: Thursda= y, November 07, 2013 8:46 AM
To: Mary Barnes
Cc: Duckwo= rth, Mark; avtext@ietf.org
Subject: RE: [avtext] taxonomy Packet = Stream

 

Mary,

The taxonomy  que= stion was

"So is it possible for a particular packet strea= m to have one SSRC value at one time, and then have a different SSRC value = some other time, but it is still the same packet stream? What are some exam= ples of this?"

 and one exmple is SSRC col= lison

 

The other t= opics are about toplogies and maybe should be sent to avtcore mailing list = with regards to the topologies draft

Roni=

 

From:<= /span> Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Thu= rsday, November 07, 2013 6:12 PM
To: Roni Even
Cc: Duck= worth, Mark; avtext@ietf.org
Subject: Re: [avtext] taxonomy Packe= t Stream

Roni,

 

= Can you elaborate a bit more - i.e., answer each of Mark's questions?<= /o:p>

 

Mary.

 <= /o:p>

On Th= u, Nov 7, 2013 at 12:11 AM, Roni Even <roni.even@mail01.huawei.com> wrote:<= o:p>

Mark,

SSR= C collison

Roni

=

From: avtext-bounces@ietf.org [avtext-bounces@ietf.org]= on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com]
Sent: Thursda= y, November 07, 2013 4:49 AM
To: avtext@ietf.org
Subject: [avtext] taxono= my Packet Stream

I have questions= about the Packet Stream in the taxonomy.  It says “At any given= point in time, a Packet Stream can have one and only one SSRC.” = ; So is it possible for a particular packet stream to have one SSRC value a= t one time, and then have a different SSRC value some other time, but it is= still the same packet stream? What are some examples of this?

 

For a media switching mixer (from rtp-topol= ogies-update document), it sends a packet stream with its own SSRC value.&n= bsp; So when it switches between available sources, the outgoing SSRC from = the mixer doesn’t change, so all those packets with the same SSRC bel= ong to the same packet stream both before and after a switch occurs, is tha= t right?

 

And what about a selec= tive forwarding middlebox? In this case the SSRC changes when a switch occu= rs, so does this mean a new packet stream starts and the previous packet st= ream ends? Or do you consider it all the same packet stream even though the= SSRC has changed?

=  

Mark Duckwor= th

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

 =

= --_000_49E45C59CA48264997FEBFB29B6BC2D604069B31CRPMBOXPRD07pol_-- From keith.drage@alcatel-lucent.com Fri Nov 8 10:23:44 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB3D21E8082 for ; Fri, 8 Nov 2013 10:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGJ56e-VYR3b for ; Fri, 8 Nov 2013 10:23:39 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 633D811E81C1 for ; Fri, 8 Nov 2013 10:23:38 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rA8INZtq015543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Nov 2013 12:23:37 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rA8INZnL022050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 19:23:35 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 8 Nov 2013 19:23:35 +0100 From: "DRAGE, Keith (Keith)" To: "Duckworth, Mark" , "avtext@ietf.org" Thread-Topic: [avtext] taxonomy Packet Stream Thread-Index: Ac7bYu/3hvd+kbf+T9iQZ/eEXznqDwAHTJjcAAQ7L4AAEd/ZKAA0K1BAAAGT3kA= Date: Fri, 8 Nov 2013 18:23:35 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0CD953@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <49E45C59CA48264997FEBFB29B6BC2D604069561@CRPMBOXPRD07.polycom.com> <760B7D45D1EFF74988DBF5C2122830C23E53D558@szxpml507-mbx.exmail.huawei.com>, <760B7D45D1EFF74988DBF5C2122830C23E53D786@szxpml507-mbx.exmail.huawei.com> <49E45C59CA48264997FEBFB29B6BC2D604069B31@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D604069B31@CRPMBOXPRD07.polycom.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0CD953FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [avtext] taxonomy Packet Stream X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 18:23:45 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0CD953FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you have any suggestions on what the text in the taxonomy draft should s= ay, that always helps the editors Keith ________________________________ From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Duckworth, Mark Sent: 08 November 2013 17:54 To: avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream Thanks Roni. It makes sense that SSRC collision is one reason why the SSRC= in a packet stream can change. Is that the only reason? I suggest we make = this more clear in section 2.1.10.2, the characteristics of a packet stream= . I will ask the other questions in avtcore. Mark From: Roni Even [mailto:roni.even@mail01.huawei.com] Sent: Thursday, November 07, 2013 8:46 AM To: Mary Barnes Cc: Duckworth, Mark; avtext@ietf.org Subject: RE: [avtext] taxonomy Packet Stream Mary, The taxonomy question was "So is it possible for a particular packet stream to have one SSRC value at= one time, and then have a different SSRC value some other time, but it is = still the same packet stream? What are some examples of this?" and one exmple is SSRC collison The other topics are about toplogies and maybe should be sent to avtcore ma= iling list with regards to the topologies draft Roni ________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Thursday, November 07, 2013 6:12 PM To: Roni Even Cc: Duckworth, Mark; avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream Roni, Can you elaborate a bit more - i.e., answer each of Mark's questions? Mary. On Thu, Nov 7, 2013 at 12:11 AM, Roni Even > wrote: Mark, SSRC collison Roni ________________________________ From: avtext-bounces@ietf.org [avtext-bounc= es@ietf.org] on behalf of Duckworth, Mark [= Mark.Duckworth@polycom.com] Sent: Thursday, November 07, 2013 4:49 AM To: avtext@ietf.org Subject: [avtext] taxonomy Packet Stream I have questions about the Packet Stream in the taxonomy. It says "At any = given point in time, a Packet Stream can have one and only one SSRC." So i= s it possible for a particular packet stream to have one SSRC value at one = time, and then have a different SSRC value some other time, but it is still= the same packet stream? What are some examples of this? For a media switching mixer (from rtp-topologies-update document), it sends= a packet stream with its own SSRC value. So when it switches between avai= lable sources, the outgoing SSRC from the mixer doesn't change, so all thos= e packets with the same SSRC belong to the same packet stream both before a= nd after a switch occurs, is that right? And what about a selective forwarding middlebox? In this case the SSRC chan= ges when a switch occurs, so does this mean a new packet stream starts and = the previous packet stream ends? Or do you consider it all the same packet = stream even though the SSRC has changed? Mark Duckworth _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_949EF20990823C4C85C18D59AA11AD8B0CD953FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If you have any suggestions on wh= at the text in the taxonomy draft should say, that always helps the editors=
 
Keith

From: avtext-bounces@ietf.org [mail= to:avtext-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 08 November 2013 17:54
To: avtext@ietf.org
Subject: Re: [avtext] taxonomy Packet Stream

Thanks Roni.  It makes sense that SSR= C collision is one reason why the SSRC in a packet stream can change. Is th= at the only reason? I suggest we make this more clear in section 2.1.10.2, the characteristics of a packet stream.

 

I will ask the other questions in avtcore.=

 

Mark

 

From: Roni Even [mailto:roni.even@mail01.huawei.com]
Sent: Thursday, November 07, 2013 8:46 AM
To: Mary Barnes
Cc: Duckworth, Mark; avtext@ietf.org
Subject: RE: [avtext] taxonomy Packet Stream

 

Mary,

The taxonomy  question was

"= So is it possible for a particular packet stream to have one SSRC value at = one time, and then have a different SSRC value some other time, but it is s= till the same packet stream? What are some examples of this?"

 = and one exmple is SSRC collison

 

The ot= her topics are about toplogies and maybe should be sent to avtcore mailing = list with regards to the topologies draft

Roni

 

From:= Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Thursday, November 07, 2013 6:12 PM
To: Roni Even
Cc: Duckworth, Mark; avtext@ietf.org
Subject: Re: [avtext] taxonomy Packet Stream

Roni,

 

Can you elaborate a bit= more - i.e., answer each of Mark's questions?

 

Mary.=

 

On Thu, Nov 7, 2013 at = 12:11 AM, Roni Even <roni.even@mail01.huawei.com> wrote:<= /p>

Mark,

SSRC collison

Roni

From: avtext-bounces= @ietf.org [avtext-bounces@ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com= ]
Sent: Thursday, November 07, 2013 4:49 AM
To: avtext@ietf= .org
Subject: [avtext] taxonomy Packet Stream

I have questions about the Packet Stream in th= e taxonomy.  It says “At any given point in time, a Packet Strea= m can have one and only one SSRC.”  So is it possible for a part= icular packet stream to have one SSRC value at one time, and then have a different SSRC value some other time, but it is still the = same packet stream? What are some examples of this?

 

For a media switching mixer (from rtp-topologi= es-update document), it sends a packet stream with its own SSRC value. = ; So when it switches between available sources, the outgoing SSRC from the= mixer doesn’t change, so all those packets with the same SSRC belong to the same packet stream both before and after = a switch occurs, is that right?

 

And what about a selective forwarding middlebo= x? In this case the SSRC changes when a switch occurs, so does this mean a = new packet stream starts and the previous packet stream ends? Or do you con= sider it all the same packet stream even though the SSRC has changed?

 

Mark Duckworth


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

 

--_000_949EF20990823C4C85C18D59AA11AD8B0CD953FR712WXCHMBA11zeu_-- From Mark.Duckworth@polycom.com Fri Nov 8 10:52:55 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCF311E80E9 for ; Fri, 8 Nov 2013 10:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK0jXiBjKSdf for ; Fri, 8 Nov 2013 10:52:41 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5988511E8145 for ; Fri, 8 Nov 2013 10:52:34 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 8 Nov 2013 10:52:28 -0800 From: "Duckworth, Mark" To: "avtext@ietf.org" Date: Fri, 8 Nov 2013 10:52:26 -0800 Thread-Topic: taxonomy synchronization context and CLUE Thread-Index: Ac7csV87lurYxvz1S8u3HXnTAV6lqw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D604069BA0@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D604069BA0CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [avtext] taxonomy synchronization context and CLUE X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 18:52:56 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D604069BA0CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.1.1.3 CLUE Scenes says this: "In CLUE "Capture Scene", "Capture Scene Entry" and "Captures" define an im= plied Synchronization Context." This isn't generally true. I don't think CLUE is attempting to define any n= ew way to associate streams for synchronization. Sometimes the media captur= es in a CLUE scene should be synchronized, but the synchronization would be= based on something else like CNAME, not because they are in the same CLUE = scene. Sometimes the captures in a CLUE scene do not need to be synchronize= d, for example when their source streams originated from different endpoint= s and then were combined into the same scene by a media switching mixer. So I don't think there is any value in mentioning this in the taxonomy draf= t. I suggest we just delete section 3.1.1.3. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D604069BA0CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.1.1.3 = CLUE Scenes says this:

“In CLUE &q= uot;Capture Scene", "Capture Scene Entry" and "Captures= " define an implied Synchronization Context.”

 

This isn’t= generally true. I don’t think CLUE is attempting to define any new w= ay to associate streams for synchronization. Sometimes the media captures i= n a CLUE scene should be synchronized, but the synchronization would be bas= ed on something else like CNAME, not because they are in the same CLUE scen= e. Sometimes the captures in a CLUE scene do not need to be synchronized, f= or example when their source streams originated from different endpoints an= d then were combined into the same scene by a media switching mixer.

 

So I= don’t think there is any value in mentioning this in the taxonomy dr= aft. I suggest we just delete section 3.1.1.3.

 

Mark

<= /body>= --_000_49E45C59CA48264997FEBFB29B6BC2D604069BA0CRPMBOXPRD07pol_-- From Christian.Groves@nteczone.com Tue Nov 12 19:25:33 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F98A11E8163 for ; Tue, 12 Nov 2013 19:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bFz-ZfS7cjz for ; Tue, 12 Nov 2013 19:25:33 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id D0D3E11E80FC for ; Tue, 12 Nov 2013 19:25:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgVAN3wglJ20SI6PGdsb2JhbAANTYM/vy9LgTIDAQEBATiCWgEBAQQBAQEvAQUbGwoRCxgJFg8JAwIBAgEVHBQTBgIBAYgKq0mTRgSPZhaEGwOtVw Received: from ppp118-209-34-58.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.34.58]) by ipmail06.adl2.internode.on.net with ESMTP; 13 Nov 2013 13:55:19 +1030 Message-ID: <5282F11A.2000607@nteczone.com> Date: Wed, 13 Nov 2013 14:25:14 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: avtext@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D604069BA0@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D604069BA0@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [avtext] taxonomy synchronization context and CLUE X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 03:25:33 -0000 I would tend to agree with Mark. Clock synchronisation isn't assumed by the capture scene, CSE and captures concept. Regards, Christian On 9/11/2013 5:52 AM, Duckworth, Mark wrote: > > Section 3.1.1.3 CLUE Scenes says this: > > “In CLUE "Capture Scene", "Capture Scene Entry" and "Captures" define > an implied Synchronization Context.” > > This isn’t generally true. I don’t think CLUE is attempting to define > any new way to associate streams for synchronization. Sometimes the > media captures in a CLUE scene should be synchronized, but the > synchronization would be based on something else like CNAME, not > because they are in the same CLUE scene. Sometimes the captures in a > CLUE scene do not need to be synchronized, for example when their > source streams originated from different endpoints and then were > combined into the same scene by a media switching mixer. > > So I don’t think there is any value in mentioning this in the taxonomy > draft. I suggest we just delete section 3.1.1.3. > > Mark > > > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From Christian.Groves@nteczone.com Tue Nov 12 19:37:14 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7754D11E816D for ; Tue, 12 Nov 2013 19:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTazeoByTBj7 for ; Tue, 12 Nov 2013 19:37:13 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 70FE211E8163 for ; Tue, 12 Nov 2013 19:37:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkVAPvyglJ20SI6PGdsb2JhbAANRAmDP78vS4ExAwEBAQE4gloBAQEEAQEBLwEFGxsKEQsYCRYPCQMCAQIBFRwUEwYCAQGICqtKk0YEjh2BSRaEGwOtVw Received: from ppp118-209-34-58.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.34.58]) by ipmail06.adl2.internode.on.net with ESMTP; 13 Nov 2013 14:07:12 +1030 Message-ID: <5282F3E3.9040100@nteczone.com> Date: Wed, 13 Nov 2013 14:37:07 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: avtext@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D604069BA0@CRPMBOXPRD07.polycom.com> <5282F11A.2000607@nteczone.com> In-Reply-To: <5282F11A.2000607@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [avtext] taxonomy synchronization context and CLUE X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 03:37:14 -0000 Pressed send too early. The draft references the CLUE framework which isn't the same as the CLUE protocol. e.g. in section 2.1.4.1 it says: "A CLUE Media Capture is identified via indexed notation." The CLUE framework uses the convention AC1, VC1 etc. however from a protocol perspective my understanding is that it would just be an "identity". Likewise the framework primarily discusses audio and video captures but the protocol will support any media type (i.e. text) supported by RTP. Christian On 13/11/2013 2:25 PM, Christian Groves wrote: > I would tend to agree with Mark. Clock synchronisation isn't assumed > by the capture scene, CSE and captures concept. > > Regards, Christian > > On 9/11/2013 5:52 AM, Duckworth, Mark wrote: >> >> Section 3.1.1.3 CLUE Scenes says this: >> >> “In CLUE "Capture Scene", "Capture Scene Entry" and "Captures" define >> an implied Synchronization Context.” >> >> This isn’t generally true. I don’t think CLUE is attempting to define >> any new way to associate streams for synchronization. Sometimes the >> media captures in a CLUE scene should be synchronized, but the >> synchronization would be based on something else like CNAME, not >> because they are in the same CLUE scene. Sometimes the captures in a >> CLUE scene do not need to be synchronized, for example when their >> source streams originated from different endpoints and then were >> combined into the same scene by a media switching mixer. >> >> So I don’t think there is any value in mentioning this in the >> taxonomy draft. I suggest we just delete section 3.1.1.3. >> >> Mark >> >> >> >> _______________________________________________ >> 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 > From bo.burman@ericsson.com Thu Nov 14 02:24:26 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E8B21F9D0F for ; Thu, 14 Nov 2013 02:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.491 X-Spam-Level: X-Spam-Status: No, score=-5.491 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0R2RqNDA478 for ; Thu, 14 Nov 2013 02:24:20 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 682F521F9CE9 for ; Thu, 14 Nov 2013 02:24:19 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-5a-5284a4d2dbc4 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AC.DB.23787.2D4A4825; Thu, 14 Nov 2013 11:24:18 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.17]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 11:24:17 +0100 From: Bo Burman To: Roni Even , "avtext@ietf.org" Thread-Topic: [avtext] taxonomy question about endpoint and participant Thread-Index: Ac7afQgfceQDdM8DR4S5BGtJjZQHkAGnXYBA Date: Thu, 14 Nov 2013 10:24:17 +0000 Message-ID: References: <057e01ceda7d$0ae41510$20ac3f30$@gmail.com> In-Reply-To: <057e01ceda7d$0ae41510$20ac3f30$@gmail.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_BBE9739C2C302046BD34B42713A1E2A22DFE0FE3ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre6lJS1BBqtnKFh8vHeD1eJvO7MD k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfGyZT17QYtXxe4nQg2Mqxy6GDk5JARMJC4d /8kOYYtJXLi3nq2LkYtDSOAQo8STMzDOYkaJNVe+sIJUsQloSMzfcZcRxBYR8JbY9+Utcxcj B4ewgJvEtiN1EGF3iambP7JB2EYSb05PYwGxWQRUJbZfeQk2hlfAV+LurT1gi4UEzCUevJ0D Vs8pYCHx8O49MJtRQFbi/vd7YL3MAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWxFifanDYwQ 9fkSf7o7mSB2CUqcnPmEZQKjyCwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUX MLKvYmTPTczMSS833MQIjJuDW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWl OanFhxiZODilGhgLZWQW/KtO5JcRuT3Zy0zj84Ettb/nuymkFi308Ji+6rVkTKOx9rz7C3O/ 7brJfCd0t/csD/P5CpJdqpVbO1Xini4TWH4wJuXgww8h2XMX9T29GZ9a5rhYUMNJJ81k3avt e5veCLf47cxV37JUXftQws5vC3e/dw0KvpAnFOHw98aFJVu/PJ6uxFKckWioxVxUnAgAUAvy B2kCAAA= Subject: Re: [avtext] taxonomy question about endpoint and participant X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 10:24:26 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22DFE0FE3ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The intent of a "Participant" in the taxonomy seems to be very similar to a= n H.323 "endpoint" below. The reason to also have an "Endpoint" in the taxonomy comes from the possib= ility that the "terminal" (in below H.323 terms) used by a single Participa= nt can consist of several "boxes" (Endpoints) with separate transport addre= sses. For example, a single Participant uses separately addressable equipme= nt for audio codec, for video codec (even several of them) and for signalin= g logic. The current definition of "Endpoint" in the taxonomy includes a single tran= sport address. If you use the "addressable" definition below, I guess that = there could be several "addressable" "sub-parts" of an H.323 "endpoint", ri= ght? Do we need a separate name for those H.323 "endpoint sub-parts"? If not, we could merge the current taxonomy Participant and Endpoint into a= common concept, similar to the H.323 definition. /Bo From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Roni Even Sent: den 6 november 2013 00:16 To: avtext@ietf.org Subject: [avtext] taxonomy question about endpoint and participant Hi, I am not sure what is the difference between endpoint and participant. Some terms from H.323 endpoint: An H.323 terminal, Gateway, or MCU. An endpoint can call and be c= alled. It generates and/or terminates information streams. addressable: An H.323 entity on the network having a Transport Address is a= ddressable. Not the same as being callable. A terminal, Gateway, or MCU is = addressable and callable. A Gatekeeper is addressable but not callable. An = MC or MP is neither callable nor addressable but is contained within an end= point or Gatekeeper that is. In a composite Gateway, both the MGC and the M= G are addressable, but only the MGC is callable. terminal: An H.323 Terminal is an endpoint on the network which provides fo= r real-time, two-way communications with another H.323 terminal, Gateway, o= r Multipoint Control Unit. This communication consists of control, indicati= ons, audio, moving colour video pictures, and/or data between the two termi= nals. A terminal may provide speech only, speech and data, speech and video= , or speech, data and video. Note the distinction between terminal and intermediaries like MCUs and Gate= ways Roni --_000_BBE9739C2C302046BD34B42713A1E2A22DFE0FE3ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The intent of a “= ;Participant” in the taxonomy seems to be very similar to an H.323 &#= 8220;endpoint” below.

 

The reason to also hav= e an “Endpoint” in the taxonomy comes from the possibility that= the “terminal” (in below H.323 terms) used by a single Partici= pant can consist of several “boxes” (Endpoints) with separate transport addresses. For example, a single Participant uses separately add= ressable equipment for audio codec, for video codec (even several of them) = and for signaling logic.

 

The current definition= of “Endpoint” in the taxonomy includes a single transport addr= ess. If you use the “addressable” definition below, I guess tha= t there could be several “addressable” “sub-parts” = of an H.323 “endpoint”, right?

 

Do we need a separate = name for those H.323 “endpoint sub-parts”?

 

If not, we could merge= the current taxonomy Participant and Endpoint into a common concept, simil= ar to the H.323 definition.

 

/Bo<= /p>

 

From: avtext-b= ounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Roni Even
Sent: den 6 november 2013 00:16
To: avtext@ietf.org
Subject: [avtext] taxonomy question about endpoint and participant

 

Hi,

I am not sure what is the difference between endpoin= t and participant.

 

Some terms from H.323

 

endpoi= nt: An H.323 terminal= , Gateway, or MCU. An endpoint can call and be called. It generates and/or = terminates information streams.

 

addres= sable: An H.323 entit= y on the network having a Transport Address is addressable. Not the same as= being callable. A terminal, Gateway, or MCU is addressable and callable. A Gatekeeper is addressable but not ca= llable. An MC or MP is neither callable nor addressable but is contained wi= thin an endpoint or Gatekeeper that is. In a composite Gateway, both the MG= C and the MG are addressable, but only the MGC is callable.

 

termin= al: An H.323 Terminal= is an endpoint on the network which provides for real-time, two-way commun= ications with another H.323 terminal, Gateway, or Multipoint Control Unit. This communication consists of contro= l, indications, audio, moving colour video pictures, and/or data between th= e two terminals. A terminal may provide speech only, speech and data, speec= h and video, or speech, data and video.

 

 

Note the distinction between terminal and intermedia= ries like MCUs and Gateways

 

Roni

--_000_BBE9739C2C302046BD34B42713A1E2A22DFE0FE3ESESSMB105erics_-- From bo.burman@ericsson.com Thu Nov 14 02:48:15 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9366B11E80F9 for ; Thu, 14 Nov 2013 02:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.708 X-Spam-Level: X-Spam-Status: No, score=-3.708 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSlvitrS4MOa for ; Thu, 14 Nov 2013 02:48:09 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9C48D21E81FA for ; Thu, 14 Nov 2013 02:48:08 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-ca-5284aa64d3da Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C4.03.27941.46AA4825; Thu, 14 Nov 2013 11:48:05 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.17]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 11:48:04 +0100 From: Bo Burman To: "DRAGE, Keith (Keith)" , "Duckworth, Mark" , "avtext@ietf.org" Thread-Topic: [avtext] taxonomy Packet Stream Thread-Index: Ac7bYu/3hvd+kbf+T9iQZ/eEXznqDwAHTJjcABLmRoAAAS5/gAA0qC+AAAEKvIABHzwB8A== Date: Thu, 14 Nov 2013 10:48:03 +0000 Message-ID: References: <49E45C59CA48264997FEBFB29B6BC2D604069561@CRPMBOXPRD07.polycom.com> <760B7D45D1EFF74988DBF5C2122830C23E53D558@szxpml507-mbx.exmail.huawei.com>, <760B7D45D1EFF74988DBF5C2122830C23E53D786@szxpml507-mbx.exmail.huawei.com> <49E45C59CA48264997FEBFB29B6BC2D604069B31@CRPMBOXPRD07.polycom.com> <949EF20990823C4C85C18D59AA11AD8B0CD953@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0CD953@FR712WXCHMBA11.zeu.alcatel-lucent.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_BBE9739C2C302046BD34B42713A1E2A22DFE1021ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+JvrW7qqpYgg9/zBSw+3rvBavG08Syj xbojT5kdmD1an+1l9Viy5CeTx4sHSgHMUVw2Kak5mWWpRfp2CVwZB05/YCk4uJuxYtK5u4wN jNeWMXYxcnJICJhI3Pm3nx3CFpO4cG89WxcjF4eQwBFGiTsnHjNBOIsZJX5tOcsEUsUmoCEx f8ddRpCEiMAkRokrh3vARgkL6Ehs65wENkpEQFdi89q7rBB2mMS2H3+AxnJwsAioSqxZkAoS 5hXwlZg2+QIrxIITzBJL535kAUlwCkRLXP66C6yXUUBW4v73e2BxZgFxiVtP5jNBnCogsWTP eWYIW1Ti5eN/rBC2okT70wZGiPp8iRcHvrBALBOUODnzCcsERpFZSEbNQlI2C0kZRFxHYsHu T2wQtrbEsoWvmWHsMwceMyGLL2BkX8XIUZxanJSbbmSwiREYVwe3/LbYwXj5r80hRmkOFiVx 3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MBorP3Xc7vOz5Yk9k/+XivC1R3wcXk5Q XD/zyMoz9574Tr/DtMpqt9LDOz9vzefc3KrIde+S986ahpn2C637mRYd+vl9QUbcFH2miA1X mFlXFM3bGvhHmOGbQ+ncn1PvMpmFiE27aMi/YXLmFpdqgdKHxVNrLvDNWmikf1Ci5ldBXOjq 2jw54SglluKMREMt5qLiRAB6auUCeQIAAA== Subject: Re: [avtext] taxonomy Packet Stream X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 10:48:15 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22DFE1021ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the moment, SSRC collision is the only valid reason I can come to think= of. I will add a sentence about that in the draft. Suggestions of other po= ssible reasons are welcome. With the current taxonomy, Mark is correct on the consequences of the topol= ogy-related questions: * A media-switching mixer that uses its own SSRC on the outgoing Pa= cket Stream across switches should be regarded as generating a single Packe= t Stream. * A selective forwarding middlebox that keeps original SSRC intact = across switches generates a time multiplex of different Packet Streams. /Bo From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= DRAGE, Keith (Keith) Sent: den 8 november 2013 19:24 To: Duckworth, Mark; avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream If you have any suggestions on what the text in the taxonomy draft should s= ay, that always helps the editors Keith ________________________________ From: avtext-bounces@ietf.org [mailto:avtex= t-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 08 November 2013 17:54 To: avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream Thanks Roni. It makes sense that SSRC collision is one reason why the SSRC= in a packet stream can change. Is that the only reason? I suggest we make = this more clear in section 2.1.10.2, the characteristics of a packet stream= . I will ask the other questions in avtcore. Mark From: Roni Even [mailto:roni.even@mail01.huawei.com] Sent: Thursday, November 07, 2013 8:46 AM To: Mary Barnes Cc: Duckworth, Mark; avtext@ietf.org Subject: RE: [avtext] taxonomy Packet Stream Mary, The taxonomy question was "So is it possible for a particular packet stream to have one SSRC value at= one time, and then have a different SSRC value some other time, but it is = still the same packet stream? What are some examples of this?" and one exmple is SSRC collison The other topics are about toplogies and maybe should be sent to avtcore ma= iling list with regards to the topologies draft Roni ________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Thursday, November 07, 2013 6:12 PM To: Roni Even Cc: Duckworth, Mark; avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream Roni, Can you elaborate a bit more - i.e., answer each of Mark's questions? Mary. On Thu, Nov 7, 2013 at 12:11 AM, Roni Even > wrote: Mark, SSRC collison Roni ________________________________ From: avtext-bounces@ietf.org [avtext-bounc= es@ietf.org] on behalf of Duckworth, Mark [= Mark.Duckworth@polycom.com] Sent: Thursday, November 07, 2013 4:49 AM To: avtext@ietf.org Subject: [avtext] taxonomy Packet Stream I have questions about the Packet Stream in the taxonomy. It says "At any = given point in time, a Packet Stream can have one and only one SSRC." So i= s it possible for a particular packet stream to have one SSRC value at one = time, and then have a different SSRC value some other time, but it is still= the same packet stream? What are some examples of this? For a media switching mixer (from rtp-topologies-update document), it sends= a packet stream with its own SSRC value. So when it switches between avai= lable sources, the outgoing SSRC from the mixer doesn't change, so all thos= e packets with the same SSRC belong to the same packet stream both before a= nd after a switch occurs, is that right? And what about a selective forwarding middlebox? In this case the SSRC chan= ges when a switch occurs, so does this mean a new packet stream starts and = the previous packet stream ends? Or do you consider it all the same packet = stream even though the SSRC has changed? Mark Duckworth _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_BBE9739C2C302046BD34B42713A1E2A22DFE1021ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For the moment, SSRC coll= ision is the only valid reason I can come to think of. I will add a sentenc= e about that in the draft. Suggestions of other possible reasons are welcome.

 <= /p>

With the current taxonomy= , Mark is correct on the consequences of the topology-related questions:

·     &nbs= p;   A media-switching= mixer that uses its own SSRC on the outgoing Packet Stream across switches= should be regarded as generating a single Packet Stream.=

·     &nbs= p;   A selective forwa= rding middlebox that keeps original SSRC intact across switches generates a= time multiplex of different Packet Streams.

 <= /p>

/Bo

 <= /p>

From: avtext-b= ounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: den 8 november 2013 19:24
To: Duckworth, Mark; avtext@ietf.org
Subject: Re: [avtext] taxonomy Packet Stream

 

If you have any suggestions on= what the text in the taxonomy draft should say, that always helps the edit= ors

 

Keith

 

From:<= /span> avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 08 November 2013 17:54
To: avtext@ietf.org
Subject: Re: [avtext] taxonomy Packet Stream

Thanks Roni.  It mak= es sense that SSRC collision is one reason why the SSRC in a packet stream = can change. Is that the only reason? I suggest we make this more clear in section 2.1.10.2, the characteristics of a packet stream.

 <= /p>

I will ask the other ques= tions in avtcore.

 <= /p>

Mark

 <= /p>

From: Roni Eve= n [mailto:roni.even@mail01.h= uawei.com]
Sent: Thursday, November 07, 2013 8:46 AM
To: Mary Barnes
Cc: Duckworth, Mark; avtext@ietf.= org
Subject: RE: [avtext] taxonomy Packet Stream

 

Mary,

The taxonomy  question was

"So is it possible for a particular packet stream to have o= ne SSRC value at one time, and then have a different SSRC value some other = time, but it is still the same packet stream? What are some examples of this?"

 and one exmple is SSRC collison

 

The other topics are about toplogies and maybe should be sent to= avtcore mailing list with regards to the topologies draft

Roni

 

From: Mary Barnes [mary.ietf.barne= s@gmail.com]
Sent: Thursday, November 07, 2013 6:12 PM
To: Roni Even
Cc: Duckworth, Mark; avtext@ietf.= org
Subject: Re: [avtext] taxonomy Packet Stream

Roni, =

 =

Can you elaborate a bit = more - i.e., answer each of Mark's questions?

 =

Mary.<= /p>

 

On Thu, Nov 7, 2013 at 1= 2:11 AM, Roni Even <roni.even@mail01.huawei.com> wrote:

Mark,

SSRC collison

Roni

From: avtext-bounces= @ietf.org [avtext-bounces@ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com= ]
Sent: Thursday, November 07, 2013 4:49 AM
To: avtext@ietf= .org
Subject: [avtext] taxonomy Packet Stream

I have questions about the Packet Stre= am in the taxonomy.  It says “At any given point in time, a Pack= et Stream can have one and only one SSRC.”  So is it possible for a particular packet stream to have one SSRC value at one t= ime, and then have a different SSRC value some other time, but it is still = the same packet stream? What are some examples of this?

 

For a media switching mixer (from rtp-= topologies-update document), it sends a packet stream with its own SSRC val= ue.  So when it switches between available sources, the outgoing SSRC from the mixer doesn’t change, so all tho= se packets with the same SSRC belong to the same packet stream both before = and after a switch occurs, is that right?

 

And what about a selective forwarding = middlebox? In this case the SSRC changes when a switch occurs, so does this= mean a new packet stream starts and the previous packet stream ends? Or do you consider it all the same packet str= eam even though the SSRC has changed?

 

Mark Duckworth


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

 =

--_000_BBE9739C2C302046BD34B42713A1E2A22DFE1021ESESSMB105erics_-- From jonathan@vidyo.com Thu Nov 14 08:58:59 2013 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8497F21F9AE3 for ; Thu, 14 Nov 2013 08:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFdgnsUN-V9Q for ; Thu, 14 Nov 2013 08:58:54 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8885E21F9BB1 for ; Thu, 14 Nov 2013 08:58:51 -0800 (PST) X-Note-AR-ScanTimeLocal: 11/14/2013 11:58:49 AM X-Policy: GLOBAL - vidyo.com 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 11/14/2013 11:58:46 AM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.961064 p=-0.969897 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 31.2006 ms. Fail:2 Chk:1348 of 1348 total X-Note: SCH-CT/SI:2-1348/SG:1 11/14/2013 11:58:48 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNKNOWN->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: G325 G326 G327 G328 G332 G333 G443 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 73127745; Thu, 14 Nov 2013 11:58:48 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::250:56ff:fe85:4a71%11]) with mapi id 14.03.0146.000; Thu, 14 Nov 2013 10:58:47 -0600 From: Jonathan Lennox To: Bo Burman , "DRAGE, Keith (Keith)" , "Duckworth, Mark" , "avtext@ietf.org" Thread-Topic: [avtext] taxonomy Packet Stream Thread-Index: Ac7bYu/3hvd+kbf+T9iQZ/eEXznqDwAHTJjcABLmRoAAAS5/gAA0qC+AAAEKvIABHzwB8AANicig Date: Thu, 14 Nov 2013 16:58:47 +0000 Message-ID: References: <49E45C59CA48264997FEBFB29B6BC2D604069561@CRPMBOXPRD07.polycom.com> <760B7D45D1EFF74988DBF5C2122830C23E53D558@szxpml507-mbx.exmail.huawei.com>, <760B7D45D1EFF74988DBF5C2122830C23E53D786@szxpml507-mbx.exmail.huawei.com> <49E45C59CA48264997FEBFB29B6BC2D604069B31@CRPMBOXPRD07.polycom.com> <949EF20990823C4C85C18D59AA11AD8B0CD953@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: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_C486BE72B7CD6A4DAC1F29CC8B755348738B15492132EXCH1vidyoc_" MIME-Version: 1.0 Subject: Re: [avtext] taxonomy Packet Stream X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2013 16:58:59 -0000 --_000_C486BE72B7CD6A4DAC1F29CC8B755348738B15492132EXCH1vidyoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another case for an SSRC change is a clock rate change, following the recom= mendation of draft-ietf-avtext-multiple-clock-rates. Also - a selective forwarding middlebox doesn't necessarily keep the origin= al SSRCs intact. Its important feature is that each forwarded stream gets = a distinct SSRC, but these SSRCs might be locally-generated rather than bei= ng the original ones. Despite this quibble, I agree with your characteriza= tions, though. From: Bo Burman [mailto:bo.burman@ericsson.com] Sent: Thursday, November 14, 2013 5:48 AM To: DRAGE, Keith (Keith); Duckworth, Mark; avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream For the moment, SSRC collision is the only valid reason I can come to think= of. I will add a sentence about that in the draft. Suggestions of other po= ssible reasons are welcome. With the current taxonomy, Mark is correct on the consequences of the topol= ogy-related questions: * A media-switching mixer that uses its own SSRC on the outgoing Pa= cket Stream across switches should be regarded as generating a single Packe= t Stream. * A selective forwarding middlebox that keeps original SSRC intact = across switches generates a time multiplex of different Packet Streams. /Bo From: avtext-bounces@ietf.org [mailto:avtex= t-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: den 8 november 2013 19:24 To: Duckworth, Mark; avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream If you have any suggestions on what the text in the taxonomy draft should s= ay, that always helps the editors Keith ________________________________ From: avtext-bounces@ietf.org [mailto:avtex= t-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 08 November 2013 17:54 To: avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream Thanks Roni. It makes sense that SSRC collision is one reason why the SSRC= in a packet stream can change. Is that the only reason? I suggest we make = this more clear in section 2.1.10.2, the characteristics of a packet stream= . I will ask the other questions in avtcore. Mark From: Roni Even [mailto:roni.even@mail01.huawei.com] Sent: Thursday, November 07, 2013 8:46 AM To: Mary Barnes Cc: Duckworth, Mark; avtext@ietf.org Subject: RE: [avtext] taxonomy Packet Stream Mary, The taxonomy question was "So is it possible for a particular packet stream to have one SSRC value at= one time, and then have a different SSRC value some other time, but it is = still the same packet stream? What are some examples of this?" and one exmple is SSRC collison The other topics are about toplogies and maybe should be sent to avtcore ma= iling list with regards to the topologies draft Roni ________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Thursday, November 07, 2013 6:12 PM To: Roni Even Cc: Duckworth, Mark; avtext@ietf.org Subject: Re: [avtext] taxonomy Packet Stream Roni, Can you elaborate a bit more - i.e., answer each of Mark's questions? Mary. On Thu, Nov 7, 2013 at 12:11 AM, Roni Even > wrote: Mark, SSRC collison Roni ________________________________ From: avtext-bounces@ietf.org [avtext-bounc= es@ietf.org] on behalf of Duckworth, Mark [= Mark.Duckworth@polycom.com] Sent: Thursday, November 07, 2013 4:49 AM To: avtext@ietf.org Subject: [avtext] taxonomy Packet Stream I have questions about the Packet Stream in the taxonomy. It says "At any = given point in time, a Packet Stream can have one and only one SSRC." So i= s it possible for a particular packet stream to have one SSRC value at one = time, and then have a different SSRC value some other time, but it is still= the same packet stream? What are some examples of this? For a media switching mixer (from rtp-topologies-update document), it sends= a packet stream with its own SSRC value. So when it switches between avai= lable sources, the outgoing SSRC from the mixer doesn't change, so all thos= e packets with the same SSRC belong to the same packet stream both before a= nd after a switch occurs, is that right? And what about a selective forwarding middlebox? In this case the SSRC chan= ges when a switch occurs, so does this mean a new packet stream starts and = the previous packet stream ends? Or do you consider it all the same packet = stream even though the SSRC has changed? Mark Duckworth _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_C486BE72B7CD6A4DAC1F29CC8B755348738B15492132EXCH1vidyoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another case for an SSRC = change is a clock rate change, following the recommendation of draft-ietf-a= vtext-multiple-clock-rates.

 <= /p>

Also – a selective = forwarding middlebox doesn’t necessarily keep the original SSRCs inta= ct.  Its important feature is that each forwarded stream gets a distin= ct SSRC, but these SSRCs might be locally-generated rather than being the ori= ginal ones.  Despite this quibble, I agree with your characterizations= , though.

 <= /p>

From: Bo Burma= n [mailto:bo.burman@ericsson.com]
Sent: Thursday, November 14, 2013 5:48 AM
To: DRAGE, Keith (Keith); Duckworth, Mark; avtext@ietf.org
Subject: Re: [avtext] taxonomy Packet Stream

 

For the moment, SSRC coll= ision is the only valid reason I can come to think of. I will add a sentenc= e about that in the draft. Suggestions of other possible reasons are welcome.

 <= /p>

With the current taxonomy= , Mark is correct on the consequences of the topology-related questions:

·      = ;   A media-switching= mixer that uses its own SSRC on the outgoing Packet Stream across switches= should be regarded as generating a single Packet Stream.=

·      = ;   A selective forwa= rding middlebox that keeps original SSRC intact across switches generates a= time multiplex of different Packet Streams.

 <= /p>

/Bo

 <= /p>

From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: den 8 november 2013 19:24
To: Duckworth, Mark; avtext@ietf.= org
Subject: Re: [avtext] taxonomy Packet Stream

 

If you have any suggestions on= what the text in the taxonomy draft should say, that always helps the edit= ors

 

Keith

 

From:<= /span> avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 08 November 2013 17:54
To: avtext@ietf.org
Subject: Re: [avtext] taxonomy Packet Stream

Thanks Roni.  It mak= es sense that SSRC collision is one reason why the SSRC in a packet stream = can change. Is that the only reason? I suggest we make this more clear in section 2.1.10.2, the characteristics of a packet stream.

 <= /p>

I will ask the other ques= tions in avtcore.

 <= /p>

Mark

 <= /p>

From: Roni Eve= n [mailto:roni.even@mail01.h= uawei.com]
Sent: Thursday, November 07, 2013 8:46 AM
To: Mary Barnes
Cc: Duckworth, Mark; avtext@ietf.= org
Subject: RE: [avtext] taxonomy Packet Stream

 

Mary,

The taxonomy  question was

"So is it possible for a particular packet stream to have o= ne SSRC value at one time, and then have a different SSRC value some other = time, but it is still the same packet stream? What are some examples of this?"

 and one exmple is SSRC collison

 

The other topics are about toplogies and maybe should be sent to= avtcore mailing list with regards to the topologies draft

Roni

 

From: Mary Barnes [mary.ietf.barne= s@gmail.com]
Sent: Thursday, November 07, 2013 6:12 PM
To: Roni Even
Cc: Duckworth, Mark; avtext@ietf.= org
Subject: Re: [avtext] taxonomy Packet Stream

Roni, =

 =

Can you elaborate a bit = more - i.e., answer each of Mark's questions?

 =

Mary.<= /p>

 

On Thu, Nov 7, 2013 at 1= 2:11 AM, Roni Even <roni.even@mail01.huawei.com> wrote:

Mark,

SSRC collison

Roni

From: avtext-bounces= @ietf.org [avtext-bounces@ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com= ]
Sent: Thursday, November 07, 2013 4:49 AM
To: avtext@ietf= .org
Subject: [avtext] taxonomy Packet Stream

I have questions about the Packet Stre= am in the taxonomy.  It says “At any given point in time, a Pack= et Stream can have one and only one SSRC.”  So is it possible for a particular packet stream to have one SSRC value at one t= ime, and then have a different SSRC value some other time, but it is still = the same packet stream? What are some examples of this?

 

For a media switching mixer (from rtp-= topologies-update document), it sends a packet stream with its own SSRC val= ue.  So when it switches between available sources, the outgoing SSRC from the mixer doesn’t change, so all tho= se packets with the same SSRC belong to the same packet stream both before = and after a switch occurs, is that right?

 

And what about a selective forwarding = middlebox? In this case the SSRC changes when a switch occurs, so does this= mean a new packet stream starts and the previous packet stream ends? Or do you consider it all the same packet str= eam even though the SSRC has changed?

 

Mark Duckworth


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

 =

--_000_C486BE72B7CD6A4DAC1F29CC8B755348738B15492132EXCH1vidyoc_-- From espeberg@cisco.com Tue Nov 19 14:22:07 2013 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 536801AE133 for ; Tue, 19 Nov 2013 14:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, 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 Lo5iWqxVVX2p for ; Tue, 19 Nov 2013 14:22:06 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 162DC1AE0B6 for ; Tue, 19 Nov 2013 14:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1434; q=dns/txt; s=iport; t=1384899720; x=1386109320; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=R33GOU5PyIwpttUMfmhUXvwwv1HtfZqZ7m7g2v/YI4U=; b=YKTAVw2TBSYo3ke1Gt0v6/0RYSI0d73n4uWuXn+Bi9kjQXkIBx/2kFEY G2ExXU/IDS3PruJK8D6fsMnYf7SbwEikIE+5KpnyZQLow99EpAbA3VqRQ PpBAfAfGcmcYXT+kHAhp39lvOBHKz6GQ+6LBSMpTGxP2218LiavG/47+J M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUFAN/ji1KtJV2b/2dsb2JhbABZgwc4U4J2vEkYgQkWbQeCJwEEIxFXASICBiACBDAVEQEEGwGHeA2fLY8IkTMXgSmNfYMjNYESA5lBkF6DKIIq X-IronPort-AV: E=Sophos;i="4.93,732,1378857600"; d="scan'208";a="286209037" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 19 Nov 2013 22:22:00 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAJMLxge020109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Nov 2013 22:21:59 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.124]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 16:21:59 -0600 From: "Espen Berger (espeberg)" To: "avtext@ietf.org" Thread-Topic: draft-avtext-berger-framemarking-00.txt Thread-Index: Ac7ldSeKJwzdX6qgR7CewAg/rFeArg== Date: Tue, 19 Nov 2013 22:21:59 +0000 Message-ID: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.162.107] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [avtext] draft-avtext-berger-framemarking-00.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: Tue, 19 Nov 2013 22:22:07 -0000 VGhlIGRyYWZ0IGRpc2N1c3MgdXNhZ2Ugb2YgUlRQIGhlYWRlciBleHRlbnNpb24gdG8gZG8gUlRQ IHNpbXVsY2FzdCBvcGVyYXRpb24gb24gZW5jcnlwdGVkIHBheWxvYWQuIA0KDQpDb21tZW50cz8g IA0KDQotRXNwZW4gDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWF2dGV4dC1iZXJn ZXItZnJhbWVtYXJraW5nLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBFc3BlbiBCZXJnZXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxl bmFtZToJIGRyYWZ0LWF2dGV4dC1iZXJnZXItZnJhbWVtYXJraW5nDQpSZXZpc2lvbjoJIDAwDQpU aXRsZToJCSBGcmFtZSBtYXJraW5nIGZvciBSVFAgcGFja2V0cw0KQ3JlYXRpb24gZGF0ZToJIDIw MTMtMTAtMjENCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2Vz OiA3DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWF2dGV4dC1iZXJnZXItZnJhbWVtYXJraW5nLTAwLnR4dA0KU3RhdHVzOiAgICAgICAg ICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWF2dGV4dC1iZXJnZXItZnJh bWVtYXJraW5nDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWF2dGV4dC1iZXJnZXItZnJhbWVtYXJraW5nLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbXMgdG8gcHJvdmlkZSBmcmFtZSBtYXJraW5n cyB0bw0KICAgYWxsb3cgUlRQIHN3aXRjaGVzIHRvIHBlcmZvcm0gc3RyZWFtIG9wZXJhdGlvbnMg b24gZW5jcnlwdGVkIHBheWxvYWQuDQogICBUaGUgbWVjaGFuaXNtcyBzdXBwb3J0IGV4dGVuc2lv bnMgdG8gYWxsb3cgZm9yIGNvZGVjIHNwZWNpZmljDQogICBpbmZvcm1hdGlvbi4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0K From internet-drafts@ietf.org Sat Nov 23 00:18:55 2013 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 1807C1AE10A; Sat, 23 Nov 2013 00:18: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 FO__-_Oy7yIS; Sat, 23 Nov 2013 00:18:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50ADD1AE108; Sat, 23 Nov 2013 00:18:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131123081853.19823.28631.idtracker@ietfa.amsl.com> Date: Sat, 23 Nov 2013 00:18:53 -0800 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-multiple-clock-rates-11.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: Sat, 23 Nov 2013 08:18:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Working = Group of the IETF. Title : Support for Multiple Clock Rates in an RTP Session Author(s) : Marc Petit-Huguenin Glen Zorn Filename : draft-ietf-avtext-multiple-clock-rates-11.txt Pages : 12 Date : 2013-11-22 Abstract: This document clarifies the RTP specification when different clock rates are used in an RTP session. It also provides guidance on how to interoperate with legacy RTP implementations that use multiple clock rates. It updates RFC 3550. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-multiple-clock-rates-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-multiple-clock-rates-11 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/