From nobody Fri Jul 1 12:28:22 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9440B12D5BF; Fri, 1 Jul 2016 12:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 GmF-CtRxNAqq; Fri, 1 Jul 2016 12:28:19 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E363B12D1B8; Fri, 1 Jul 2016 12:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1204; q=dns/txt; s=iport; t=1467401298; x=1468610898; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=c9nqG/pJyKINlB8DVjTYnFAY3/ZVQF1gn/D5q62EE8M=; b=JP+GOGkGZALJdxf8GIKEoYGJsbq5Q71Pr4H5x+lKlhD46FKw0W/0t8iq N0FO2KzjWkJZEx3oVv/A+zk00g1mXQKHjbAqqaBWlDfkXeaZxRs6gm2qe 4ChVckUK/c++tZXZCqSqXcEGgdgrGGnrA+zHXgPD3LDVePSEbtVdckgSQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAgAqw3ZX/4MNJK1dgz5WKlK5KYF7I?= =?us-ascii?q?oUsSgKBMTgUAQEBAQEBAWUnhE0BBQEBNjYLEAsYLicwBg0GAgEBiCwOxHsBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEaBYYogXcIgk6KGwEEmRCORoFqhFaDC4VfkAkeNoIIH?= =?us-ascii?q?IFoIDIBiHMBAQE?= X-IronPort-AV: E=Sophos;i="5.26,558,1459814400"; d="scan'208";a="290737328" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2016 19:28:18 +0000 Received: from [10.98.149.203] (bxb-fandreas-88110.cisco.com [10.98.149.203]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u61JSHrp032005; Fri, 1 Jul 2016 19:28:17 GMT To: mmusic References: <0e2be118-9e2c-95f2-f9a3-29968590af4b@cisco.com> From: Flemming Andreasen Message-ID: <35db34c4-5879-fa72-147b-4e10759b5109@cisco.com> Date: Fri, 1 Jul 2016 15:28:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <0e2be118-9e2c-95f2-f9a3-29968590af4b@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-dtls-sdp@ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-dtls-sdp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 19:28:20 -0000 The only person that seems to have reviewed the document during this WGLC is the document author - we really need somebody else to review the document. Please let us know if you did indeed review the document but just didn't have any comments. Thanks -- Flemming On 6/7/16 9:51 AM, Flemming Andreasen wrote: > Greetings MMUSIC > > This is to announce a 2 week WGLC on > > https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-13.txt > > as Proposed Standard. Please note that we previously issued a WGLC on > the -06 version (in February), however since there has been a few > changes to the document subsequently, we want to give people a chance > to review those one last time. Please take a look at the document and > provide any comments you may have by Tuesday, June 21, 2016. Comments > should be sent to the document authors and the MMUSIC WG list. If you > review the document but do not have any comments, please send a note > to that effect as well. > > Thanks > > -- Flemming (MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Fri Jul 1 12:51:38 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB2E12D7C8 for ; Fri, 1 Jul 2016 12:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 otp0JMfc7I2w for ; Fri, 1 Jul 2016 12:51:22 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C11112D7D1 for ; Fri, 1 Jul 2016 12:51:21 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-06v.sys.comcast.net with SMTP id J4SibDoIjE8zeJ4TBbla6q; Fri, 01 Jul 2016 19:51:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467402681; bh=e/nGWVazK1dYkVaVw5kEyc4qQSb11VFMh8gwB/S0YRY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=IkzDUm6oGcFTW4VK6taNsP70jsX9m33MARuGSiQ2dXuD/kwGRdFQMA4Nog20aFEUm 71g5AoyMtYOpc+ls/eGLI536MIHosqcl5bM2a5RRVuJKZ1sEurpoLDmA3Kqd+Bu7jC nJyCVkeIRcTDmYWVY90btE8VSgzn9w2DHdxdUllsFnEo2eSFQB/ykEEG8DqmlyvTZ9 Pcb9UdqHEfGt9f6VFmBlbTagIPqxW6HxyARF7ahBrrBkqY0PeCjVrZEbVbnYL1FbVE 2Mpkh6GbJaeY2Bko4gbvh1xFU0D3rJPQBJIJcTRpHH60x1QEdjg1eYXOzPqfJXOoxO Ur95X3NSmuOdg== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with comcast id DXrL1t00U3KdFy101XrMYX; Fri, 01 Jul 2016 19:51:21 +0000 To: mmusic@ietf.org References: <0e2be118-9e2c-95f2-f9a3-29968590af4b@cisco.com> <35db34c4-5879-fa72-147b-4e10759b5109@cisco.com> From: Paul Kyzivat Message-ID: Date: Fri, 1 Jul 2016 15:51:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <35db34c4-5879-fa72-147b-4e10759b5109@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-dtls-sdp-13 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 19:51:24 -0000 On 7/1/16 3:28 PM, Flemming Andreasen wrote: > The only person that seems to have reviewed the document during this > WGLC is the document author - we really need somebody else to review the > document. > > Please let us know if you did indeed review the document but just didn't > have any comments. For *this* version I only reviewed the diffs, but I have been following it closely since the beginning. I reviewed -11 thoroughly and the changes since then have satisfied me. So I'm good with this. Thanks, Paul > Thanks > > -- Flemming > > > On 6/7/16 9:51 AM, Flemming Andreasen wrote: >> Greetings MMUSIC >> >> This is to announce a 2 week WGLC on >> >> https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-13.txt >> >> as Proposed Standard. Please note that we previously issued a WGLC on >> the -06 version (in February), however since there has been a few >> changes to the document subsequently, we want to give people a chance >> to review those one last time. Please take a look at the document and >> provide any comments you may have by Tuesday, June 21, 2016. Comments >> should be sent to the document authors and the MMUSIC WG list. If you >> review the document but do not have any comments, please send a note >> to that effect as well. >> >> Thanks >> >> -- Flemming (MMUSIC co-chair) >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Sun Jul 3 01:46:29 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E2C12B00E; Sun, 3 Jul 2016 01:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSl64BGOEDN9; Sun, 3 Jul 2016 01:46:25 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECADA12B03A; Sun, 3 Jul 2016 01:46:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0987D7C843B; Sun, 3 Jul 2016 10:46:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdK4BdBPX8DP; Sun, 3 Jul 2016 10:46:19 +0200 (CEST) Received: from [192.168.8.102] (238-11-8.connect.netcom.no [89.8.11.238]) by mork.alvestrand.no (Postfix) with ESMTPSA id 269357C8433; Sun, 3 Jul 2016 10:46:19 +0200 (CEST) To: Benoit Claise , The IESG References: <20160614164459.19274.66428.idtracker@ietfa.amsl.com> From: Harald Alvestrand Message-ID: <5778D0DA.6000905@alvestrand.no> Date: Sun, 3 Jul 2016 10:46:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160614164459.19274.66428.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-msid@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Benoit Claise's No Objection on draft-ietf-mmusic-msid-14: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 08:46:27 -0000 On 06/14/2016 06:44 PM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-mmusic-msid-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No sure the following is useful information: > > This document is a work item of the MMUSIC WG, whose discussion list > is mmusic@ietf.org. > > First time I see this in an abstract. I've actually been doing this for the last 10 years - especially for individual contributions, I find it important to make a note of where it's going to be discussed. The RFC Editor may choose to take it out. > > -- Surveillance is pervasive. Go Dark. From nobody Sun Jul 3 01:58:57 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AFF12B03C; Sun, 3 Jul 2016 01:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-v_XZWeXZ-g; Sun, 3 Jul 2016 01:58:53 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D060712B00E; Sun, 3 Jul 2016 01:58:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 319A77C843B; Sun, 3 Jul 2016 10:58:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaUy6R-DcSiT; Sun, 3 Jul 2016 10:58:49 +0200 (CEST) Received: from [192.168.8.102] (238-11-8.connect.netcom.no [89.8.11.238]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5A81A7C8433; Sun, 3 Jul 2016 10:58:49 +0200 (CEST) To: Stephen Farrell , Alissa Cooper References: <20160616113938.10476.41211.idtracker@ietfa.amsl.com> <547EB0D6-0F63-4334-9D06-F15C5EF607C0@cooperw.in> <5762B602.8030502@cs.tcd.ie> From: Harald Alvestrand Message-ID: <5778D3C8.5030409@alvestrand.no> Date: Sun, 3 Jul 2016 10:58:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5762B602.8030502@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-msid@ietf.org, IESG , mmusic@ietf.org Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-msid-14: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 08:58:55 -0000 On 06/16/2016 04:21 PM, Stephen Farrell wrote: > > On 16/06/16 15:20, Alissa Cooper wrote: >>> On Jun 16, 2016, at 4:39 AM, Stephen Farrell wrote: >>> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-mmusic-msid-14: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> I'm not sure that the answer to this question will require any >>> change to the document but wanted to check... >>> >>> I wondered about the privacy properties of these (and related) >>> WebRTC identifiers, esp. if they are being handled at various >>> different layers. Is there work somewhere in the WebRTC space >>> that's analysing that? For example, one concern might be that >>> msid-appdata could end up with some kind of privacy sensitive >>> value, but there's no guidance here about that and as the >>> examples use UUIDs it's not clear to me those represent nor what >>> typical values will be used. (Note: I'm not saying that I >>> believe this is a problem, I'm just checking if it's been >>> considered.) >> I wonder if adding a reference to https://www.w3.org/TR/mediacapture-streams/#dom-mediastream-id or parroting that guidance would help. >> > That'd certainly be good enough to clear the discuss. I'd still > be interested in an answer to the general question as well, but > that'd not be blocking. Sorry for belated followup - yes, mediacapture-streams makes note of the privacy issues with IDs, and specifically recommends using UUID type 3 or 4 as a basis for generation, since these have less incidental information than other types. > > Cheers, > S. > >> Alissa >> >>> I hope that there's no reason why these can't be very ephemeral >>> values that don't identify (or help re-identification of) people >>> or their preferences, locations etc., and I'd imagine there's >>> little reason to e.g. log them. If that's the case wouldn't it >>> be useful to add such guidance (somewhere, maybe not here) >>> to help developers to do the right thing? >>> >>> >>> >>> >> -- Surveillance is pervasive. Go Dark. From nobody Tue Jul 5 09:28:09 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB96F12D635; Tue, 5 Jul 2016 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXP8wdB6a9VF; Tue, 5 Jul 2016 09:27:56 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC31C12D640; Tue, 5 Jul 2016 09:27:49 -0700 (PDT) Received: from [IPv6:2601:648:8380:d0:b000:c523:5e3:37d3] (unknown [IPv6:2601:648:8380:d0:b000:c523:5e3:37d3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 57672207C7; Tue, 5 Jul 2016 18:27:47 +0200 (CEST) To: Magnus Westerlund , IETF AVTCore WG , "tram@ietf.org" , ice@ietf.org, "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> From: Marc Petit-Huguenin Message-ID: <4da07aaf-6340-e866-801e-1c6bd78d0d2e@petit-huguenin.org> Date: Tue, 5 Jul 2016 09:27:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd" Archived-At: Subject: Re: [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 16:27:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd Content-Type: multipart/mixed; boundary="kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i" From: Marc Petit-Huguenin To: Magnus Westerlund , IETF AVTCore WG , "tram@ietf.org" , ice@ietf.org, "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" Message-ID: <4da07aaf-6340-e866-801e-1c6bd78d0d2e@petit-huguenin.org> Subject: Re: [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 References: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> In-Reply-To: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> --kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Magnus, We just published version -10. See below for some comments. On 06/28/2016 07:35 AM, Magnus Westerlund wrote: > Authors and WGs, >=20 > In my review for the publication writeup I did spot some issues in the = draft. Please consider the following issues: >=20 > 1. Abstract: With the addition of the ZRTP the abstract should benefit = from being updated. The ZRTP protocol being possible to multiplex is miss= ing as well as that there are now 4 issues. Fixed. >=20 > 2. Abstract contains [ref] to RFC 5764. This is an ID nit. Fixed. >=20 > 3. Section 1. The introduction is not explicitly saying that it updates= RFC 5764. I think that can be put as a sentence after: >=20 > This is achieved by > modifying the IANA registries with instructions for coordination > between the protocols at risk. We incorporated this in that sentence and also added it into the abstract= =2E >=20 > 4. Reference ID-nits: >=20 > =3D=3D Outdated reference: A later version (-31) exists of > draft-ietf-mmusic-sdp-bundle-negotiation-23 Fixed. >=20 > 5. Section 2: >=20 > ID-nits complains about the modified boilerplate for the RFC2119 text. = First of all one usually don't cut down the list to only the used ones. T= he requirement on all caps ones I am very divided about. I do have a pref= erence for unmodified boilerplate, this as I otherwise have to explain in= the write-up the ID-nit. Fixed. >=20 > 6. Section 6: >=20 > In order to prevent future documents from assigning values from the > unused range to a new protocol, this document modifies the RFC 5764 > demultiplexing algorithm to properly account for TURN channels by > allocating the values from 64 to 79 for this purpose. >=20 > I think this text fails to be explicit about that this restricts the TU= RN Channel space to a more limited set of possible channels when the TURN= client does the channel binding request. Thus affecting the TURN channel= allocation algorithm in the client implementations, at least when used i= n combination of muxing. Fixed. >=20 > Based on this and the fact that this specification changes the IANA reg= istrations performed by RFC5766, I think this document to have "Updates" = for RFC5766 also. So please add that in header, abstract and introduction= =2E Based on our understanding and looking at other RFCs, just updating an IA= NA registry does not imply a update to the core specification, so we did = not made that change. >=20 > 7. Updates RFC5389: >=20 > Looking at the impact also on the STUN protocol I would also think that= this requires and "Updates" also for RFC 5389. >=20 Based on the argument above, we do not think that this warrants an "Updat= es" status. >=20 > 8. Section 10.3: >=20 > The IANA registry name is not the correct one. The IANA page says that = the registry name is: >=20 > Traversal Using Relays around NAT (TURN) Channel Numbers > http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#t= urn-channel >=20 > Please update. Fixed. >=20 > 9. Section 12.2: >=20 > The reference to ZRTP [RFC6189] is likely in the wrong category, at the= same time moving this to a normative one creates a downref. I guess it o= ne that has to be accepted in this case. I suggest that you move it to th= e normative references. We are keeping it informative for now, but we will forward the discussion= with the AD to the mailing-list as requested. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i-- --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXe9/6AAoJECnERZXWan7E8JwQAMkUHV3c2Q1MK8TWsMTs/q5q r4eb5gLyaoxSV6x9ufYs42lJ3j6hr7t3GabA5ANFFI1tOx+eN3iMwTgH/2ylugoE fnyGgbal/vZ6pEj01goPALATYSk0m6KtFwS7+QPVvNoEan6oHbLA5iH5oc73FY8x B5cBFq89Do1ATeTKEX0a0FeSZmE5r4N4xrsjZpnMBXt1Unm+1SG0Ku24PJHCbEWN Tx68bmLODh+65pTVUzewDOo3urSlwjxStVqf/jQHh4fx/tDnxGH8c8cGMSW18jl/ PuanYrAv7pg0rMdhQMkeEs5Y6UaInE3B3zADdXEET0QSw6U4oiXVvzP8GH/QC8Ml z4zNDEcDn+wlPMWcmwOhrVtqbuUAcdHlMB4oynOzcVZpKciXvIpDlKKWJXdo9ERU l4/GCog8yq0HgQ2Mv5mGLHO3x5CIs+zgKFvAz6uWK3Qq4i12Wgxga+aJt3OFgwAn qvaMVuAr4ajUkYzF8iHJpXqUD15E48MvYHm4ps6ExtHhXcWqBUv8FxxGixTDZWAX lj5K6jpYdSddwY6nMc3BMS1XZrCX2TBmTaCm9MZWQjqRao0IEdVehfAh4+D1eeUb nUgIzFjjyQ73kZ2FHkyXBm6FYxAuXSI5MU9H1kjh78KDvUlGTStjb0azCrBNWG0c 0hmVb/kE0WTHDCIYklcY =qxAO -----END PGP SIGNATURE----- --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd-- From nobody Wed Jul 6 01:47:30 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657FD12D0FB; Wed, 6 Jul 2016 01:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFpXJPbtanj1; Wed, 6 Jul 2016 01:47:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F54C12D0A4; Wed, 6 Jul 2016 01:47:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-ea-577cc59ce276 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.00.18043.C95CC775; Wed, 6 Jul 2016 10:47:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.294.0; Wed, 6 Jul 2016 10:47:23 +0200 To: IETF AVTCore WG , "tram@ietf.org" , , "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: From: Magnus Westerlund Message-ID: Date: Wed, 6 Jul 2016 10:47:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM2K7lu6cozXhBu86tCxe9qxktzjwcSqz xbcLtRZTlz9msfh0vovR4sPaC2wObB5LlvxkCmCM4rJJSc3JLEst0rdL4Mp4vWQLa8Fa4Yq5 X7uZGxhv83cxcnJICJhIPFvxgR3CFpO4cG89WxcjF4eQwBFGibcL1kA5yxglbvX9Aari4BAW CJE4vj8JJC4i8I9R4uPGmywg3UIC9hK/djYyg9hsAhYSN380soHYvEDxnZMmgNksAioSE1cf AbNFBWIkGm8fZoeoEZQ4OfMJ2BxOAQeJ4z83sIDsYgbqfbC1DCTMLCAv0bx1NjPEKm2JhqYO 1gmMArOQdM9C6JiFpGMBI/MqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMCAPbjlt9UOxoPP HQ8xCnAwKvHwLvhaHS7EmlhWXJl7iFGCg1lJhFfwUE24EG9KYmVValF+fFFpTmrxIUZpDhYl cV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsbk35xzJsUsUmXvqnhYwLbwa8nSCSl/ebr+cWSG nXkre/3qfvc7sQlOm4/pzJLdtszO+Lzdttccrg7LFn6NZTb/MDcwtXun2uyIsBlsLHHra8JV f5iaZlY+iGZ4sYsnBhhnirbz9BsbefaqOGhfYmVl6/h0Lu7c7SNxN344TA5++HvZJ/uV35VY ijMSDbWYi4oTAU6aP69UAgAA Archived-At: Subject: Re: [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 08:47:29 -0000 Hi, The call has now ended. The authors have updated the document to address the issues I raised. The writeup has been uploaded and I have requested publication. If anyone has late feedback, please provide it. We will address it at the latest at the end of the IETF last call, most likely earlier. Cheers Magnus Westerlund Chair AVTCORE WG and Document Shepherd. Den 2016-06-28 kl. 15:04, skrev Magnus Westerlund: > WGs, > > I as WG chair earlier made a mistake in failing to include the relevant > WGs in our previous WG last call. Thus I would like to make a one week > confirmation call on the content of > draft-ietf-avtcore-rfc5764-mux-fixes-09 prior to publication request. > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ > > > TRAM WG: Please check that you are okay with the restrictions and > updates to the TURN channel allocations as well as STUN Method > restrictions. > > TLS WG: I believe you are satisfied with the impact on the TLS IANA > registry after previous discussions, but you are welcome to confirm this. > > ICE: For your information as this impacts protocol mechanism your are > dependent on. > > MMUSIC: For your information due to some notes in regards to BUNDLE and > RFC7345. > > Please provide any feedback by 5th of July. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jul 7 01:50:02 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8317212D169; Thu, 7 Jul 2016 01:49:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707084957.23634.80115.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 01:49:57 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msid-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 08:49:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : WebRTC MediaStream Identification in the Session Description Protocol Author : Harald Alvestrand Filename : draft-ietf-mmusic-msid-15.txt Pages : 18 Date : 2016-07-07 Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-msid-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 05:05:03 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA1412B046; Thu, 7 Jul 2016 05:04:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707120459.23701.80687.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 05:04:59 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-06.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 12:04:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : RTP Payload Format Constraints Authors : Peter Thatcher Mo Zanaty Suhas Nandakumar Bo Burman Adam Roach Byron Campen Filename : draft-ietf-mmusic-rid-06.txt Pages : 24 Date : 2016-07-07 Abstract: In this specification, we define a framework for specifying constraints on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and constrain the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the constraints defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 07:42:06 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B127412D797 for ; Thu, 7 Jul 2016 07:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 KmmE-v-V0rEp for ; Thu, 7 Jul 2016 07:41:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3E712D568 for ; Thu, 7 Jul 2016 07:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=485; q=dns/txt; s=iport; t=1467902517; x=1469112117; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=NSFlB1MxLIWL4RBwxoVSsZMUHy8vQC5k6PFhcakroR4=; b=Tg0x64CWTSzlc0K92nRYFc85l1Sw9woM05uvgj1N7d4vPZns8XF/NV+w 13+YsatUFujsg++udCL993A4Exfgcjt4s14/PwHhXICUVWSegy+H/cH1P 1jkpDUDCWqVOoozO57h2KwSTh6H82xnb+tGnARmJHx/0eoD0oFGE7DWM5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AwDwaX5X/5tdJa1cgz5WKlK3AIIPg?= =?us-ascii?q?XsihXaBKzgUAQEBAQEBAWUnhHYVQTUCJgJfDQgBAYgsDq4OjzABAQEBAQEEAQE?= =?us-ascii?q?BAQEBHAWBAYUmgXiKFoJaAQSZE45HgVQBFYRWgwuERIEbkAoeNoQNIDIBiHsBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.28,324,1464652800"; d="scan'208";a="126114544" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jul 2016 14:41:53 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u67EfrES004801; Thu, 7 Jul 2016 14:41:53 GMT To: mmusic From: Flemming Andreasen Message-ID: <5ff3d1d2-1d3f-738c-ce16-11dc26508516@cisco.com> Date: Thu, 7 Jul 2016 10:41:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-sdp-simulcast-05@ietf.org Subject: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:42:05 -0000 Greetings MMUSIC This is to announce a 3 week WGLC on the draft: https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt as Proposed Standard. Please review and provide any comments you may have on the document by Thursday, July 28, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks -- Flemming (MMUSIC co-chair) From nobody Thu Jul 7 07:42:37 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A2F12D7B7; Thu, 7 Jul 2016 07:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 5cGJkU9Jr-L9; Thu, 7 Jul 2016 07:42:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74CFB12D76E; Thu, 7 Jul 2016 07:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=474; q=dns/txt; s=iport; t=1467902553; x=1469112153; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=QCWiALmCaQrSrAY/iOWBsWa8yNwtFqAZrL/Da3LMl28=; b=cazYngPfBDNtebhoS8xvNkd26+yAQMqdPasHqxCOJQaAy54Vnd+4aUS2 P7W8phMDQPAxLtxDcycmV76OcToIs+jgioZ/uqFFW2mr1ERG/I3Rxq7Hk 88PpZ87saFhUfuERYGZacl/wDqW8w6cn6OtlkvU+pxYYvg2D3DTNgW0oX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AwAXaX5X/5pdJa1cgz5WKlK3AIIPg?= =?us-ascii?q?XsihXaBKzgUAQEBAQEBAWUnhHYVQTUCJgJfDQgBAYgsDq4MjzABAQEBAQEEAQE?= =?us-ascii?q?BAQEBHAWBAYUmgXiKFoJaAQSZE45HgVQBFYRWgwuERIEbkAoeNoIJHIFoIDIBi?= =?us-ascii?q?HsBAQE?= X-IronPort-AV: E=Sophos;i="5.28,324,1464652800"; d="scan'208";a="294161403" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jul 2016 14:42:32 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u67EgWib016112; Thu, 7 Jul 2016 14:42:32 GMT To: mmusic From: Flemming Andreasen Message-ID: <9f237771-3d8c-edf7-6b28-3e8f214075a5@cisco.com> Date: Thu, 7 Jul 2016 10:42:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-rid@ietf.org Subject: [MMUSIC] WGLC on draft-ietf-mmusic-rid-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:42:35 -0000 Greetings MMUSIC This is to announce a 3 week WGLC on the draft: https://www.ietf.org/id/draft-ietf-mmusic-rid-06.txt as Proposed Standard. Please review and provide any comments you may have on the document by Thursday, July 28, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks -- Flemming (MMUSIC co-chair) From nobody Thu Jul 7 07:47:26 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CB112D692; Thu, 7 Jul 2016 07:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 4tFcpPmG629H; Thu, 7 Jul 2016 07:47:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FA612D7CA; Thu, 7 Jul 2016 07:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=733; q=dns/txt; s=iport; t=1467902821; x=1469112421; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Uz8/ZtnK1H2uX1A3iWdt+IdliAAZPppcjXsIxW1GBx4=; b=kJTzroe3v9nZTXMhr1mjL3JEuzHovIK3nyrl72vfH6KLAiKCkgo1EAUO e6OsYU7+vDS7VLn+YeoWrlBnONkqDUZjpewV4seHfIX+H9sETJlq0FE4n 2auqVHwNgR+NmeDFJwPEzx+W1HYrctKyHsybKA7tm9Awvs7WDXfVtfuzU Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AwD4an5X/4oNJK1cgz5WKlK5D4F7I?= =?us-ascii?q?oUsSgKBKTgUAQEBAQEBAWUnhE0BBQEBNjYLEAsYLicwBg0GAgEBiCwOvUUBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEaBYYngXiCVYobAQSZE45HgWqEVoMLhESBG5AKHjaED?= =?us-ascii?q?SAyAYh7AQEB?= X-IronPort-AV: E=Sophos;i="5.28,324,1464652800"; d="scan'208";a="121490734" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jul 2016 14:46:47 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u67EkkjS019914; Thu, 7 Jul 2016 14:46:47 GMT To: mmusic References: <5ff3d1d2-1d3f-738c-ce16-11dc26508516@cisco.com> From: Flemming Andreasen Message-ID: Date: Thu, 7 Jul 2016 10:46:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5ff3d1d2-1d3f-738c-ce16-11dc26508516@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-sdp-simulcast@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:47:25 -0000 [fixing address typo] On 7/7/16 10:41 AM, Flemming Andreasen wrote: > Greetings MMUSIC > > This is to announce a 3 week WGLC on the draft: > > https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt > > as Proposed Standard. Please review and provide any comments you may > have on the document by Thursday, July 28, 2016. Comments should be > sent to the document authors and the MMUSIC WG list. If you review the > document but do not have any comments, please send a note to that > effect as well. > > Thanks > > -- Flemming (MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Thu Jul 7 15:36:45 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E436F12D5C9; Thu, 7 Jul 2016 15:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWLQoPTDa-bt; Thu, 7 Jul 2016 15:36:42 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60367127071; Thu, 7 Jul 2016 15:36:42 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u67MaOTq005126; Thu, 7 Jul 2016 18:36:42 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 241vjvr43g-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Jul 2016 18:36:42 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 7 Jul 2016 17:36:41 -0500 From: Jonathan Lennox To: IETF AVTCore WG , mmusic Thread-Topic: BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR2KAHze27W5Jfo0ybRgYSx8aBWQ== Date: Thu, 7 Jul 2016 22:36:40 +0000 Message-ID: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <1194365E18A71641BBCC242A8BF1DA5C@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-07_12:2016-07-07,2016-07-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607070214 Archived-At: Subject: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 22:36:44 -0000 SGksIGFsbCDigJQNCg0KKFRoaXMgd2FzIGFuIGlzc3VlIEkgcmFpc2VkIGluIEFWVENPUkUgaW4g QnVlbm9zIEFpcmVzIOKAlCBJIHByb21pc2VkIHRvIHNlbmQgZS1tYWlsIHRvIHRoZSBsaXN0IGJ1 dCBoYWRu4oCZdCByZW1lbWJlcmVkIHRvIGdldCBhcm91bmQgdG8gaXQgdW50aWwgbm93LikNCg0K V2hlbiBmaW5pc2hpbmcgdXAgdGhlIENMVUUgUlRQIG1hcHBpbmcgZHJhZnQsIEkgcmVhbGl6ZWQg dGhhdCBvbmUgb2YgQ0xVReKAmXMgUlRQIHJlcXVpcmVtZW50cyBkaWRu4oCZdCBhY3R1YWxseSBl bmQgdXAgZ2V0dGluZyBzYXRpc2ZpZWQgYnkgQlVORExFICh3aGljaCBpcyB0aGUgc29sdXRpb24g Q0xVRSBjb252ZXJnZWQgb24pLiAgVGhpcyBpc27igJl0IGEgQ0xVRS1zcGVjaWZpYyBpc3N1ZSwg c28gSeKAmW0gcmFpc2luZyBpdCBoZXJlLg0KDQpUaGUgaXNzdWUgaXMgd2hldGhlciB3ZSB3YW50 IHRvIHN1cHBvcnQgYSB1c2UgY2FzZSwgaW4gQlVORExFLCB3aGVyZSBhIHNpbmdsZSBSVFAgc3Ry ZWFtIGNvcnJlc3BvbmRzIHRvIG1vcmUgdGhhbiBtZWRpYSBkZXNjcmlwdGlvbiAoYW5kIHRodXMg aGFzIG1vcmUgdGhhbiBvbmUgTUlEIHZhbHVlKT8NCg0KVGhlIHVzZSBjYXNlIGlzIHdoZXJlIG9u ZSBtLWxpbmUgaGFzIGEgc2VtYW50aWMgb2Yg4oCcYWx3YXlzIHZpZXcgdGhpcyBwZXJzb27igJ0g KG15IGJvc3MsIHNheSwgb3IgbXkgY3VzdG9tZXIpOyBhbmQgYW5vdGhlciBtLWxpbmUgaGFzIGEg c2VtYW50aWMgb2Yg4oCcdGhlIGN1cnJlbnQgbG91ZGVzdCBzcGVha2Vy4oCdLiAoSW4gQ0xVRSwg dGhlc2Ugd291bGQgYmUgYSBzaW5nbGUgY29udGVudCBjYXB0dXJlIGluIHRoZSBmb3JtZXIgY2Fz ZSwgYW5kIGEgc3dpdGNoZWQgY2FwdHVyZSBmb3IgdGhlIGxhdHRlci4pICBXaGVuZXZlciB0aGUg Ym9zcyAqaXMqIHRoZSBjdXJyZW50IGxvdWRlc3Qgc3BlYWtlciwgdGhlIHNhbWUgY29udGVudCB3 b3VsZCBiZSBzZW50IGZvciBib3RoIG0tbGluZXMuDQoNCkEgbmFpdmUgaW1wbGVtZW50YXRpb24g d291bGQgc2ltcGx5IGR1cGxpY2F0ZSBhbGwgdGhlIHBhY2tldHMgZm9yIHRoZSB0d28gbS1saW5l cywgd2l0aCBkaWZmZXJlbnQgTUlEIHZhbHVlcywgYnV0IHRoaXMgaGFzIHR3byBwcm9ibGVtcy4g IEZpcnN0IG9mZiBhbGwsIGl0IG9idmlvdXNseSB3YXN0ZXMgYmFuZHdpZHRoLiAgUG90ZW50aWFs bHkgbW9yZSBzZXJpb3VzbHksIGl0IHByZWNsdWRlcyBhbnkgUlRQIG1pZGRsZWJveCB0b3BvbG9n eSB3aGljaCBkb2VzbuKAmXQgcmV3cml0ZSBTU1JDIHZhbHVlcywgc2luY2UgdGhlIHNhbWUgY29u dGVudCAoYXJyaXZpbmcgd2l0aCBhIHNpbmdsZSBTU1JDIHZhbHVlIGF0IHRoZSBtaWRkbGVib3gp IHdvdWxkIG5lZWQgdG8gYmUgc2VudCB3aXRoIHR3byBkaWZmZXJlbnQgU1NSQyB2YWx1ZXMgZG93 biBmcm9tIHRoZSBtaWRkbGVib3guICBJZiBQRVJDIGdvZXMgd2l0aCBpdHMgY3VycmVudCBjb25z ZW5zdXMgb2Ygbm8gU1NSQyByZXdyaXRpbmcsIHRoaXMgd2lsbCBwYXJ0aWN1bGFybHkgYmUgYSBw cm9ibGVtIGZvciBQRVJDLg0KDQpJIGNlcnRhaW5seSBkb27igJl0IHRoaW5rIHRoaXMgaXMgc29t ZXRoaW5nIHRoYXQgc2hvdWxkIGJsb2NrIEJVTkRMReKAmXMgY29tcGxldGlvbiwgYnV0IEkgdGhp bmsgaXQgY291bGQgYmUgYSBwcmV0dHkgZWFzeSBleHRlbnNpb24uICANCg0KKE15IGluaXRpYWwg ZGVzaWduIHByb3Bvc2FsIHdhcyB0byBhbGxvdyBtdWx0aXBsZSBTREVTIHZhbHVlcyBvZiB0aGUg c2FtZSB0eXBlLCBhbmQgbXVsdGlwbGUgU0RFUyBoZWFkZXIgZXh0ZW5zaW9ucyBpdGVtcyBvZiB0 aGUgc2FtZSB0eXBlLCB0byBiZSBzZW50IHNpbXVsdGFuZW91c2x5IGluIFJUUCDigJQgcHJvdG9j b2wtc3ludGFjdGljYWxseSB0aGlzIGlzIHRyaXZpYWwsIHlvdeKAmWQganVzdCBuZWVkIHRvIG5l Z290aWF0ZSB0aGF0IHlvdSBzdXBwb3J0IGl0LiAgQnV0IEnigJltIG5vdCB3ZWRkZWQgdG8gdGhp cyBzb2x1dGlvbi4pDQoNCldoYXQgZG8gcGVvcGxlIHRoaW5rIOKAlCBpcyB0aGlzIHdvcnRoIHdv cmtpbmcgb24/ICBJcyB0aGVyZSBpbnRlcmVzdCBpbiBkaXNjdXNzaW5nIGl0IGluIEJlcmxpbiwg YW5kIGlmIHNvLCBpbiB3aGF0IHZlbnVlPw== From nobody Thu Jul 7 17:52:09 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA6512B03E; Thu, 7 Jul 2016 17:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7MfXNe5mP18P; Thu, 7 Jul 2016 17:52:02 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B55612D77C; Thu, 7 Jul 2016 17:52:02 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id b72so28977617ywa.3; Thu, 07 Jul 2016 17:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gjmWZK7iQC/FlOfylS1mi/06vgw8LzS4joz+ySladjk=; b=jkoo6HANfI3PutrDTvVoh27e8cPdxT1Th6QA979PFVScJZQ88QWCeHP+9RnPq7MJGg PjOJAoa349rjjBfswIHs33+rfBq56Pz9sqYrSKdidDjETSnc5uCq3hQ6i0YNj08nN9QV MOIm2dRlkYikYasWBewVFtaQhfyhv9jbqO5lFhOBFbdrY8t2om1b3/jdKIs5WlAV12HZ PAnpRp0DlSuDett/9MHA0kPQB6zoLT2yQPIzMHjEmZiEV/vnbbmQPs6eESKs++t5H7Q1 KCM/RAJecO2nRFcMjeKWdja8E/YfSTnGL6MwGmCsnrdeEk9zjH5Zb2j+oHAYEef1BO44 TTeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gjmWZK7iQC/FlOfylS1mi/06vgw8LzS4joz+ySladjk=; b=Xe6LRESGk3ztuI2Hmoed+MEY98oCvUUdgXDhnVsN/hpzGxV5Bn8Gql23Aov0NoWuU3 O1VY5kvRpCKOBg0/Avnq9IMEMA+zu5AgfCZTehizighZhYkKMTquyQ3NPp0zUBM0Bgbg SgGZNBqRz75bhGZBiqPOuVykD3eGwjP+lVKMQswm9qCslY/GZXmVJSfHtsxUtTDlncQX qR0+tF1cHRSA1s2MwybHhIsmpWbabOCkoFjyMkcuH2LU5rIgNUXXzivZQiJankX/UowQ vTLuz2Ek3S9M/xdqfw5d71QIvcyxU2QiuxrjsZHUcgrDo0y9ZcRQQ2P6vUNzb8vo3ovz 2GHw== X-Gm-Message-State: ALyK8tJyp34+hybMACNvnHZyB4a5tynsQtBDXFHsU+FMPAiYkFq+TNvHJqBF4D/H3tlAQkXLZpa3cist5Ka1MA== X-Received: by 10.129.108.143 with SMTP id h137mr2661832ywc.273.1467939121921; Thu, 07 Jul 2016 17:52:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.33.195 with HTTP; Thu, 7 Jul 2016 17:52:01 -0700 (PDT) In-Reply-To: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> From: Suhas Nandakumar Date: Fri, 8 Jul 2016 06:22:01 +0530 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a114da5a0ea050f05371535cc Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 00:52:05 -0000 --001a114da5a0ea050f05371535cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jonathan Clarification question : if we have 2 m=3Dlines m =3D ... a=3Dmid1 m=3D... a=3Dmid2 does these 2 correspond to same media source ? It felt so from the duplicate design you mentioned but wanted to confirm Thanks Suhas On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox wrote: > Hi, all =E2=80=94 > > (This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promis= ed to > send e-mail to the list but hadn=E2=80=99t remembered to get around to it= until > now.) > > When finishing up the CLUE RTP mapping draft, I realized that one of > CLUE=E2=80=99s RTP requirements didn=E2=80=99t actually end up getting sa= tisfied by BUNDLE > (which is the solution CLUE converged on). This isn=E2=80=99t a CLUE-spe= cific > issue, so I=E2=80=99m raising it here. > > The issue is whether we want to support a use case, in BUNDLE, where a > single RTP stream corresponds to more than media description (and thus ha= s > more than one MID value)? > > The use case is where one m-line has a semantic of =E2=80=9Calways view t= his > person=E2=80=9D (my boss, say, or my customer); and another m-line has a = semantic > of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these would b= e a single content > capture in the former case, and a switched capture for the latter.) > Whenever the boss *is* the current loudest speaker, the same content woul= d > be sent for both m-lines. > > A naive implementation would simply duplicate all the packets for the two > m-lines, with different MID values, but this has two problems. First off > all, it obviously wastes bandwidth. Potentially more seriously, it > precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC v= alues, > since the same content (arriving with a single SSRC value at the middlebo= x) > would need to be sent with two different SSRC values down from the > middlebox. If PERC goes with its current consensus of no SSRC rewriting, > this will particularly be a problem for PERC. > > I certainly don=E2=80=99t think this is something that should block BUNDL= E=E2=80=99s > completion, but I think it could be a pretty easy extension. > > (My initial design proposal was to allow multiple SDES values of the same > type, and multiple SDES header extensions items of the same type, to be > sent simultaneously in RTP =E2=80=94 protocol-syntactically this is trivi= al, you=E2=80=99d > just need to negotiate that you support it. But I=E2=80=99m not wedded t= o this > solution.) > > What do people think =E2=80=94 is this worth working on? Is there intere= st in > discussing it in Berlin, and if so, in what venue? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a114da5a0ea050f05371535cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jonathan=C2=A0

=C2=A0 Clarification = question :

=C2=A0 =C2=A0if we have 2 m=3Dlines
=C2=A0 =C2=A0
m =3D ...
a=3Dmid1
<m= anager>

m=3D...
a=3Dmid2
&l= t;loudest speaker>

does these 2 correspond to s= ame media source ? It felt so from the duplicate design you mentioned but w= anted to confirm

Thanks
Suhas
=
=C2=A0 =C2=A0

On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox <j= onathan@vidyo.com> wrote:
H= i, all =E2=80=94

(This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promised= to send e-mail to the list but hadn=E2=80=99t remembered to get around to = it until now.)

When finishing up the CLUE RTP mapping draft, I realized that one of CLUE= =E2=80=99s RTP requirements didn=E2=80=99t actually end up getting satisfie= d by BUNDLE (which is the solution CLUE converged on).=C2=A0 This isn=E2=80= =99t a CLUE-specific issue, so I=E2=80=99m raising it here.

The issue is whether we want to support a use case, in BUNDLE, where a sing= le RTP stream corresponds to more than media description (and thus has more= than one MID value)?

The use case is where one m-line has a semantic of =E2=80=9Calways view thi= s person=E2=80=9D (my boss, say, or my customer); and another m-line has a = semantic of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these = would be a single content capture in the former case, and a switched captur= e for the latter.)=C2=A0 Whenever the boss *is* the current loudest speaker= , the same content would be sent for both m-lines.

A naive implementation would simply duplicate all the packets for the two m= -lines, with different MID values, but this has two problems.=C2=A0 First o= ff all, it obviously wastes bandwidth.=C2=A0 Potentially more seriously, it= precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC va= lues, since the same content (arriving with a single SSRC value at the midd= lebox) would need to be sent with two different SSRC values down from the m= iddlebox.=C2=A0 If PERC goes with its current consensus of no SSRC rewritin= g, this will particularly be a problem for PERC.

I certainly don=E2=80=99t think this is something that should block BUNDLE= =E2=80=99s completion, but I think it could be a pretty easy extension.

(My initial design proposal was to allow multiple SDES values of the same t= ype, and multiple SDES header extensions items of the same type, to be sent= simultaneously in RTP =E2=80=94 protocol-syntactically this is trivial, yo= u=E2=80=99d just need to negotiate that you support it.=C2=A0 But I=E2=80= =99m not wedded to this solution.)

What do people think =E2=80=94 is this worth working on?=C2=A0 Is there int= erest in discussing it in Berlin, and if so, in what venue?
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--001a114da5a0ea050f05371535cc-- From nobody Fri Jul 8 05:55:03 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D14B12D686; Fri, 8 Jul 2016 05:55:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708125500.32193.8828.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 05:55:00 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:55:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP) Authors : Marc Petit-Huguenin Ari Keranen Suhas Nandakumar Filename : draft-ietf-mmusic-ice-sip-sdp-09.txt Pages : 42 Date : 2016-07-08 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 05:58:58 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97B312D0B2 for ; Fri, 8 Jul 2016 05:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 URoH367rT_e4 for ; Fri, 8 Jul 2016 05:58:55 -0700 (PDT) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D4812D58D for ; Fri, 8 Jul 2016 05:58:55 -0700 (PDT) Received: by mail-yw0-x244.google.com with SMTP id c13so7371796ywh.2 for ; Fri, 08 Jul 2016 05:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=AEywdteIM1QzsdaWgXGUv1yRuWB5eNrQkhGV3VpU4gU=; b=yHtO19GVPoP1woV6EySgO0KD6SL8O91I4Q/wuG0K/5eXbbiUOe1oLqHUlHZMvdMqw0 /xmMm1FfYyLULaiPQN1SEgmcyNBJtMXSFtE6XN0B2j6+9MLBmWC/U3Bc0//BfkQYjizh 3fEN6ca2TkMQUlCRkYiZQqDw7UYZeDgxd5fL+BohB0gdSMaFxeUyTnSoT32DRaGKuIt1 w77hLiQB2bmVk1BRbzlOmf29KkaPTkl6zj6f7EKHkiLGCsrRkhTTP/MSpFUCrcm0tvAJ kd6MX2m0IrS+/bIgyVR/8a/roisgakwQuUauWf3PVcpNUNRc/9XzSC9SpoxS40rrBseE gh/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AEywdteIM1QzsdaWgXGUv1yRuWB5eNrQkhGV3VpU4gU=; b=GLfEzqpuUnJ4E7bFaXNHBKBzwTBWZ3fllFxHPBWXZ5y78GIzGmgh85R3ho0lCQD33A e08qJL/WbsJjH5aMk0FGcbJWtlZLSJcUY/hAVFiAcdMB9g/GJybaLY07XMJPAlLBTCCV kzY+UkaDDIHjjV4s861CKTJ7bcihN5TR+y6fOhJcJMTV8H2122LIvNfWd5aN6z68+423 xKmtY8Xwv40jL5cnq3qKowQEpt65unIl/EghYLGSN3DWvQefnoANZr5eZVw3ovppD0O7 jTXk7b7Si4g60f/Yo94mar918hATTNrWV1SBT1QnR92iMCxCltsbex1HaZ7lHdPq98lQ D0ew== X-Gm-Message-State: ALyK8tL7aPRzqKiTtEOULptmivAfNqle74ht6iUn1JUXP6eV35u+vOA/vOwV3K+G1RhmP2s7eCqWegU7bXbeCA== X-Received: by 10.129.156.78 with SMTP id t75mr4593122ywg.295.1467982734480; Fri, 08 Jul 2016 05:58:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.33.195 with HTTP; Fri, 8 Jul 2016 05:58:54 -0700 (PDT) From: Suhas Nandakumar Date: Fri, 8 Jul 2016 18:28:54 +0530 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=94eb2c0b7ce86cd7f405371f5d53 Archived-At: Subject: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:58:57 -0000 --94eb2c0b7ce86cd7f405371f5d53 Content-Type: text/plain; charset=UTF-8 Hello All We submitted -09 version of the ice-sip-sdp draft with the following changes 1. Added Section 5 for dealing with ice2 2. updated an example in Appendix A to be IPv6 based end-point 3. Updated Section 13.2 to say about the aggregation rules for ice2 ice-option 4. Restructured Offer/Answer sections into a single place as can be seen in Section 4 Thanks to Christer for feedback on the restructuring the offer/answer sections. We hope that this version incorporates all the outstanding issues. Please let us know if we are missing anything. Cheers Suhas --94eb2c0b7ce86cd7f405371f5d53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 We submitted -09 versi= on of the ice-sip-sdp draft with the following changes

=
=C2=A0=C2=A0=C2=A01. Added Section 5 for dealing with ice2
=
=C2=A0 =C2=A02. updated an example in Appen= dix A to be IPv6 based end-point
=C2= =A0 =C2=A03. Updated Section 13.2 to say about the aggregation rules for ic= e2 ice-option
=C2=A0 =C2=A04. Restruct= ured Offer/Answer sections into a single place as can be seen in Section 4<= /div>
=C2=A0=C2=A0
Thanks to Christer for feedback on the restructuring the offer/= answer sections.


We hope tha= t this version incorporates all the outstanding issues. Please let us know = if we are missing anything.

=
Cheers
Suhas
--94eb2c0b7ce86cd7f405371f5d53-- From nobody Fri Jul 8 08:51:39 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446C812D098; Fri, 8 Jul 2016 08:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DA79sxrEFMj; Fri, 8 Jul 2016 08:51:32 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79D112D0E6; Fri, 8 Jul 2016 08:51:31 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u68FoHSX008488; Fri, 8 Jul 2016 11:51:29 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 241uh68n5p-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 08 Jul 2016 11:51:29 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Fri, 8 Jul 2016 10:51:28 -0500 From: Jonathan Lennox To: Suhas Nandakumar Thread-Topic: [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR2KAHglPM/iUn/kOx+O/DTOsKb6AOCHGAgAD7UYA= Date: Fri, 8 Jul 2016 15:51:28 +0000 Message-ID: <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_7E00EB1672FE4A1EA26866674361FB2Bvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-08_09:2016-07-08,2016-07-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607080148 Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:51:34 -0000 --_000_7E00EB1672FE4A1EA26866674361FB2Bvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGludGVudGlvbiBvZiBteSBwcm9wb3NhbCBpcyB0aGF0IHRoZXNlIGNvdWxkIGluZGVlZCBi ZSAodGVtcG9yYXJpbHkpIHRoZSBzYW1lIFJUUCBtZWRpYSBzb3VyY2UsIGV2ZW4gdGhvdWdoIHRo ZXnigJlyZSB0d28gc2VwYXJhdGUgbS1saW5lcy4NCg0KT24gSnVsIDcsIDIwMTYsIGF0IDg6NTIg UE0sIFN1aGFzIE5hbmRha3VtYXIgPHN1aGFzaWV0ZkBnbWFpbC5jb208bWFpbHRvOnN1aGFzaWV0 ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgSm9uYXRoYW4NCg0KICBDbGFyaWZpY2F0aW9uIHF1 ZXN0aW9uIDoNCg0KICAgaWYgd2UgaGF2ZSAyIG09bGluZXMNCg0KbSA9IC4uLg0KYT1taWQxDQo8 bWFuYWdlcj4NCg0KbT0uLi4NCmE9bWlkMg0KPGxvdWRlc3Qgc3BlYWtlcj4NCg0KZG9lcyB0aGVz ZSAyIGNvcnJlc3BvbmQgdG8gc2FtZSBtZWRpYSBzb3VyY2UgPyBJdCBmZWx0IHNvIGZyb20gdGhl IGR1cGxpY2F0ZSBkZXNpZ24geW91IG1lbnRpb25lZCBidXQgd2FudGVkIHRvIGNvbmZpcm0NCg0K VGhhbmtzDQpTdWhhcw0KDQoNCg0KT24gRnJpLCBKdWwgOCwgMjAxNiBhdCA0OjA2IEFNLCBKb25h dGhhbiBMZW5ub3ggPGpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRoYW5AdmlkeW8uY29t Pj4gd3JvdGU6DQpIaSwgYWxsIOKAlA0KDQooVGhpcyB3YXMgYW4gaXNzdWUgSSByYWlzZWQgaW4g QVZUQ09SRSBpbiBCdWVub3MgQWlyZXMg4oCUIEkgcHJvbWlzZWQgdG8gc2VuZCBlLW1haWwgdG8g dGhlIGxpc3QgYnV0IGhhZG7igJl0IHJlbWVtYmVyZWQgdG8gZ2V0IGFyb3VuZCB0byBpdCB1bnRp bCBub3cuKQ0KDQpXaGVuIGZpbmlzaGluZyB1cCB0aGUgQ0xVRSBSVFAgbWFwcGluZyBkcmFmdCwg SSByZWFsaXplZCB0aGF0IG9uZSBvZiBDTFVF4oCZcyBSVFAgcmVxdWlyZW1lbnRzIGRpZG7igJl0 IGFjdHVhbGx5IGVuZCB1cCBnZXR0aW5nIHNhdGlzZmllZCBieSBCVU5ETEUgKHdoaWNoIGlzIHRo ZSBzb2x1dGlvbiBDTFVFIGNvbnZlcmdlZCBvbikuICBUaGlzIGlzbuKAmXQgYSBDTFVFLXNwZWNp ZmljIGlzc3VlLCBzbyBJ4oCZbSByYWlzaW5nIGl0IGhlcmUuDQoNClRoZSBpc3N1ZSBpcyB3aGV0 aGVyIHdlIHdhbnQgdG8gc3VwcG9ydCBhIHVzZSBjYXNlLCBpbiBCVU5ETEUsIHdoZXJlIGEgc2lu Z2xlIFJUUCBzdHJlYW0gY29ycmVzcG9uZHMgdG8gbW9yZSB0aGFuIG1lZGlhIGRlc2NyaXB0aW9u IChhbmQgdGh1cyBoYXMgbW9yZSB0aGFuIG9uZSBNSUQgdmFsdWUpPw0KDQpUaGUgdXNlIGNhc2Ug aXMgd2hlcmUgb25lIG0tbGluZSBoYXMgYSBzZW1hbnRpYyBvZiDigJxhbHdheXMgdmlldyB0aGlz IHBlcnNvbuKAnSAobXkgYm9zcywgc2F5LCBvciBteSBjdXN0b21lcik7IGFuZCBhbm90aGVyIG0t bGluZSBoYXMgYSBzZW1hbnRpYyBvZiDigJx0aGUgY3VycmVudCBsb3VkZXN0IHNwZWFrZXLigJ0u IChJbiBDTFVFLCB0aGVzZSB3b3VsZCBiZSBhIHNpbmdsZSBjb250ZW50IGNhcHR1cmUgaW4gdGhl IGZvcm1lciBjYXNlLCBhbmQgYSBzd2l0Y2hlZCBjYXB0dXJlIGZvciB0aGUgbGF0dGVyLikgIFdo ZW5ldmVyIHRoZSBib3NzICppcyogdGhlIGN1cnJlbnQgbG91ZGVzdCBzcGVha2VyLCB0aGUgc2Ft ZSBjb250ZW50IHdvdWxkIGJlIHNlbnQgZm9yIGJvdGggbS1saW5lcy4NCg0KQSBuYWl2ZSBpbXBs ZW1lbnRhdGlvbiB3b3VsZCBzaW1wbHkgZHVwbGljYXRlIGFsbCB0aGUgcGFja2V0cyBmb3IgdGhl IHR3byBtLWxpbmVzLCB3aXRoIGRpZmZlcmVudCBNSUQgdmFsdWVzLCBidXQgdGhpcyBoYXMgdHdv IHByb2JsZW1zLiAgRmlyc3Qgb2ZmIGFsbCwgaXQgb2J2aW91c2x5IHdhc3RlcyBiYW5kd2lkdGgu ICBQb3RlbnRpYWxseSBtb3JlIHNlcmlvdXNseSwgaXQgcHJlY2x1ZGVzIGFueSBSVFAgbWlkZGxl Ym94IHRvcG9sb2d5IHdoaWNoIGRvZXNu4oCZdCByZXdyaXRlIFNTUkMgdmFsdWVzLCBzaW5jZSB0 aGUgc2FtZSBjb250ZW50IChhcnJpdmluZyB3aXRoIGEgc2luZ2xlIFNTUkMgdmFsdWUgYXQgdGhl IG1pZGRsZWJveCkgd291bGQgbmVlZCB0byBiZSBzZW50IHdpdGggdHdvIGRpZmZlcmVudCBTU1JD IHZhbHVlcyBkb3duIGZyb20gdGhlIG1pZGRsZWJveC4gIElmIFBFUkMgZ29lcyB3aXRoIGl0cyBj dXJyZW50IGNvbnNlbnN1cyBvZiBubyBTU1JDIHJld3JpdGluZywgdGhpcyB3aWxsIHBhcnRpY3Vs YXJseSBiZSBhIHByb2JsZW0gZm9yIFBFUkMuDQoNCkkgY2VydGFpbmx5IGRvbuKAmXQgdGhpbmsg dGhpcyBpcyBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmxvY2sgQlVORExF4oCZcyBjb21wbGV0aW9u LCBidXQgSSB0aGluayBpdCBjb3VsZCBiZSBhIHByZXR0eSBlYXN5IGV4dGVuc2lvbi4NCg0KKE15 IGluaXRpYWwgZGVzaWduIHByb3Bvc2FsIHdhcyB0byBhbGxvdyBtdWx0aXBsZSBTREVTIHZhbHVl cyBvZiB0aGUgc2FtZSB0eXBlLCBhbmQgbXVsdGlwbGUgU0RFUyBoZWFkZXIgZXh0ZW5zaW9ucyBp dGVtcyBvZiB0aGUgc2FtZSB0eXBlLCB0byBiZSBzZW50IHNpbXVsdGFuZW91c2x5IGluIFJUUCDi gJQgcHJvdG9jb2wtc3ludGFjdGljYWxseSB0aGlzIGlzIHRyaXZpYWwsIHlvdeKAmWQganVzdCBu ZWVkIHRvIG5lZ290aWF0ZSB0aGF0IHlvdSBzdXBwb3J0IGl0LiAgQnV0IEnigJltIG5vdCB3ZWRk ZWQgdG8gdGhpcyBzb2x1dGlvbi4pDQoNCldoYXQgZG8gcGVvcGxlIHRoaW5rIOKAlCBpcyB0aGlz IHdvcnRoIHdvcmtpbmcgb24/ICBJcyB0aGVyZSBpbnRlcmVzdCBpbiBkaXNjdXNzaW5nIGl0IGlu IEJlcmxpbiwgYW5kIGlmIHNvLCBpbiB3aGF0IHZlbnVlPw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0Bp ZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQo= --_000_7E00EB1672FE4A1EA26866674361FB2Bvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <016D6E52B0847E4F83227B9249CFDA49@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaGUgaW50 ZW50aW9uIG9mIG15IHByb3Bvc2FsIGlzIHRoYXQgdGhlc2UgY291bGQgaW5kZWVkIGJlICh0ZW1w b3JhcmlseSkgdGhlIHNhbWUgUlRQIG1lZGlhIHNvdXJjZSwgZXZlbiB0aG91Z2ggdGhleeKAmXJl IHR3byBzZXBhcmF0ZSBtLWxpbmVzLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwgNywgMjAx NiwgYXQgODo1MiBQTSwgU3VoYXMgTmFuZGFrdW1hciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1aGFz aWV0ZkBnbWFpbC5jb20iIGNsYXNzPSIiPnN1aGFzaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGkgSm9uYXRoYW4mbmJzcDsNCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyBDbGFy aWZpY2F0aW9uIHF1ZXN0aW9uIDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtpZiB3ZSBoYXZlIDIgbT1saW5lczwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPm0g PSAuLi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YT1taWQxPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZs dDttYW5hZ2VyJmd0OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+bT0uLi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YT1taWQyPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZsdDtsb3VkZXN0IHNwZWFrZXImZ3Q7PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5kb2VzIHRoZXNlIDIgY29ycmVz cG9uZCB0byBzYW1lIG1lZGlhIHNvdXJjZSA/IEl0IGZlbHQgc28gZnJvbSB0aGUgZHVwbGljYXRl IGRlc2lnbiB5b3UgbWVudGlvbmVkIGJ1dCB3YW50ZWQgdG8gY29uZmlybTwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlN1aGFzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+T24gRnJpLCBKdWwgOCwgMjAxNiBhdCA0OjA2IEFNLCBKb25hdGhhbiBMZW5ub3ggPHNwYW4g ZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5j b20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+DQpIaSwgYWxsIOKAlDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CihUaGlzIHdhcyBhbiBpc3N1ZSBJIHJhaXNlZCBpbiBBVlRDT1JFIGluIEJ1ZW5vcyBBaXJlcyDi gJQgSSBwcm9taXNlZCB0byBzZW5kIGUtbWFpbCB0byB0aGUgbGlzdCBidXQgaGFkbuKAmXQgcmVt ZW1iZXJlZCB0byBnZXQgYXJvdW5kIHRvIGl0IHVudGlsIG5vdy4pPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KV2hlbiBmaW5pc2hpbmcgdXAgdGhlIENMVUUgUlRQIG1hcHBpbmcgZHJhZnQs IEkgcmVhbGl6ZWQgdGhhdCBvbmUgb2YgQ0xVReKAmXMgUlRQIHJlcXVpcmVtZW50cyBkaWRu4oCZ dCBhY3R1YWxseSBlbmQgdXAgZ2V0dGluZyBzYXRpc2ZpZWQgYnkgQlVORExFICh3aGljaCBpcyB0 aGUgc29sdXRpb24gQ0xVRSBjb252ZXJnZWQgb24pLiZuYnNwOyBUaGlzIGlzbuKAmXQgYSBDTFVF LXNwZWNpZmljIGlzc3VlLCBzbyBJ4oCZbSByYWlzaW5nIGl0IGhlcmUuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KVGhlIGlzc3VlIGlzIHdoZXRoZXIgd2Ugd2FudCB0byBzdXBwb3J0IGEg dXNlIGNhc2UsIGluIEJVTkRMRSwgd2hlcmUgYSBzaW5nbGUgUlRQIHN0cmVhbSBjb3JyZXNwb25k cyB0byBtb3JlIHRoYW4gbWVkaWEgZGVzY3JpcHRpb24gKGFuZCB0aHVzIGhhcyBtb3JlIHRoYW4g b25lIE1JRCB2YWx1ZSk/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHVzZSBjYXNl IGlzIHdoZXJlIG9uZSBtLWxpbmUgaGFzIGEgc2VtYW50aWMgb2Yg4oCcYWx3YXlzIHZpZXcgdGhp cyBwZXJzb27igJ0gKG15IGJvc3MsIHNheSwgb3IgbXkgY3VzdG9tZXIpOyBhbmQgYW5vdGhlciBt LWxpbmUgaGFzIGEgc2VtYW50aWMgb2Yg4oCcdGhlIGN1cnJlbnQgbG91ZGVzdCBzcGVha2Vy4oCd LiAoSW4gQ0xVRSwgdGhlc2Ugd291bGQgYmUgYSBzaW5nbGUgY29udGVudCBjYXB0dXJlIGluIHRo ZSBmb3JtZXIgY2FzZSwgYW5kIGEgc3dpdGNoZWQNCiBjYXB0dXJlIGZvciB0aGUgbGF0dGVyLikm bmJzcDsgV2hlbmV2ZXIgdGhlIGJvc3MgKmlzKiB0aGUgY3VycmVudCBsb3VkZXN0IHNwZWFrZXIs IHRoZSBzYW1lIGNvbnRlbnQgd291bGQgYmUgc2VudCBmb3IgYm90aCBtLWxpbmVzLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkEgbmFpdmUgaW1wbGVtZW50YXRpb24gd291bGQgc2ltcGx5 IGR1cGxpY2F0ZSBhbGwgdGhlIHBhY2tldHMgZm9yIHRoZSB0d28gbS1saW5lcywgd2l0aCBkaWZm ZXJlbnQgTUlEIHZhbHVlcywgYnV0IHRoaXMgaGFzIHR3byBwcm9ibGVtcy4mbmJzcDsgRmlyc3Qg b2ZmIGFsbCwgaXQgb2J2aW91c2x5IHdhc3RlcyBiYW5kd2lkdGguJm5ic3A7IFBvdGVudGlhbGx5 IG1vcmUgc2VyaW91c2x5LCBpdCBwcmVjbHVkZXMgYW55IFJUUCBtaWRkbGVib3ggdG9wb2xvZ3kg d2hpY2gNCiBkb2VzbuKAmXQgcmV3cml0ZSBTU1JDIHZhbHVlcywgc2luY2UgdGhlIHNhbWUgY29u dGVudCAoYXJyaXZpbmcgd2l0aCBhIHNpbmdsZSBTU1JDIHZhbHVlIGF0IHRoZSBtaWRkbGVib3gp IHdvdWxkIG5lZWQgdG8gYmUgc2VudCB3aXRoIHR3byBkaWZmZXJlbnQgU1NSQyB2YWx1ZXMgZG93 biBmcm9tIHRoZSBtaWRkbGVib3guJm5ic3A7IElmIFBFUkMgZ29lcyB3aXRoIGl0cyBjdXJyZW50 IGNvbnNlbnN1cyBvZiBubyBTU1JDIHJld3JpdGluZywgdGhpcyB3aWxsDQogcGFydGljdWxhcmx5 IGJlIGEgcHJvYmxlbSBmb3IgUEVSQy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGNl cnRhaW5seSBkb27igJl0IHRoaW5rIHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJsb2Nr IEJVTkRMReKAmXMgY29tcGxldGlvbiwgYnV0IEkgdGhpbmsgaXQgY291bGQgYmUgYSBwcmV0dHkg ZWFzeSBleHRlbnNpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKE15IGluaXRpYWwg ZGVzaWduIHByb3Bvc2FsIHdhcyB0byBhbGxvdyBtdWx0aXBsZSBTREVTIHZhbHVlcyBvZiB0aGUg c2FtZSB0eXBlLCBhbmQgbXVsdGlwbGUgU0RFUyBoZWFkZXIgZXh0ZW5zaW9ucyBpdGVtcyBvZiB0 aGUgc2FtZSB0eXBlLCB0byBiZSBzZW50IHNpbXVsdGFuZW91c2x5IGluIFJUUCDigJQgcHJvdG9j b2wtc3ludGFjdGljYWxseSB0aGlzIGlzIHRyaXZpYWwsIHlvdeKAmWQganVzdCBuZWVkIHRvIG5l Z290aWF0ZSB0aGF0IHlvdSBzdXBwb3J0DQogaXQuJm5ic3A7IEJ1dCBJ4oCZbSBub3Qgd2VkZGVk IHRvIHRoaXMgc29sdXRpb24uKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldoYXQgZG8g cGVvcGxlIHRoaW5rIOKAlCBpcyB0aGlzIHdvcnRoIHdvcmtpbmcgb24/Jm5ic3A7IElzIHRoZXJl IGludGVyZXN0IGluIGRpc2N1c3NpbmcgaXQgaW4gQmVybGluLCBhbmQgaWYgc28sIGluIHdoYXQg dmVudWU/PGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnIgY2xhc3M9IiI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIi Pg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgY2xhc3M9IiI+bW11c2ljQGlldGYu b3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7E00EB1672FE4A1EA26866674361FB2Bvidyocom_-- From nobody Mon Jul 11 05:22:41 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5883712D185 for ; Mon, 11 Jul 2016 05:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yc5YGFj77Hi for ; Mon, 11 Jul 2016 05:22:28 -0700 (PDT) Received: from smtp146.dfw.emailsrvr.com (smtp146.dfw.emailsrvr.com [67.192.241.146]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A16912D16F for ; Mon, 11 Jul 2016 05:22:20 -0700 (PDT) Received: from smtp19.relay.dfw1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A7E23380269; Mon, 11 Jul 2016 08:22:19 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 62784380204; Mon, 11 Jul 2016 08:22:19 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.82.176.50] ([UNAVAILABLE]. [173.38.117.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Mon, 11 Jul 2016 08:22:19 -0400 From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_4DF3B869-1E94-4A20-8850-E85B182EF845" Message-Id: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Mon, 11 Jul 2016 08:22:18 -0400 References: To: RTCWeb IETF , mmusic WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 12:22:30 -0000 --Apple-Mail=_4DF3B869-1E94-4A20-8850-E85B182EF845 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Quick questions for folks =E2=80=A6 is an idea that we should explore a = bit deeper before making decisions about it? or should we not proceed? = or should we proceed? Just looking for feedback on where this should go = next=20 Thanks, Cullen > On Apr 18, 2016, at 7:59 AM, Roman Shpount > wrote: >=20 > On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla > wrote: > I wanted to call your attention to a draft I just published with a = possibly stupid > idea. >=20 > https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >=20 > A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. > This document describes how to piggyback the first few handshake = messages > in the SDP offer/answer exchange, thus reducing latency. >=20 > Comments welcome. >=20 >=20 > One other issue I thought off was that with DTLS SDP either offerer or = answerer can start a new DTLS association. When answerer starts a new = session it will have exactly the same problems as forking, since this = will create multiple DTLS sessions with the same client random. This can = be solved with some sort of fallback mechanism to either regular DTLS = setup or to sending a ClientHello in the answer. >=20 > Regards, > _____________ > Roman Shpount > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_4DF3B869-1E94-4A20-8850-E85B182EF845 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Quick questions for = folks =E2=80=A6  is an idea that we should explore a bit deeper = before making decisions about it? or should we not proceed? or should we = proceed? Just looking for feedback on where this should go = next 

Thanks, = Cullen


On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com> = wrote:

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla = <ekr@rtfm.com> wrote:
I wanted to call your attention to a draft I just published = with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A = nontrivial fraction of call setup time in WebRTC is the DTLS = handshake.
This document describes how to piggyback = the first few handshake messages
in the SDP = offer/answer exchange, thus reducing latency.

Comments welcome.


One other issue I thought off was that = with DTLS SDP either offerer or answerer can start a new DTLS = association. When answerer starts a new session it will have exactly the = same problems as forking, since this will create multiple DTLS sessions = with the same client random. This can be solved with some sort of = fallback mechanism to either regular DTLS setup or to sending a = ClientHello in the answer.

Regards,
_____________
Roman = Shpount
 
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_4DF3B869-1E94-4A20-8850-E85B182EF845-- From nobody Mon Jul 11 06:55:07 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2C812D1C1 for ; Mon, 11 Jul 2016 06:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 1CJJKNGYuEac for ; Mon, 11 Jul 2016 06:55:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DE812D18B for ; Mon, 11 Jul 2016 06:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=384; q=dns/txt; s=iport; t=1468245303; x=1469454903; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=gxDFbUBsj+RbdagkyTBBeB9t96gJygZq9izkZ/MQOxo=; b=WIPBsyuvKiGNOoamV6xXz70jYuHIH9AQFw9ie+FRNp5shDV7vHru6eZ6 ncT7kHFrOOFiypHQH/+I1bSePc1nIdFUTqCOLRc4FEs2v5i0tfAyOlOJj 0iXU2h9RUGlA+jPG8ui9oic22narneIHuRnB+TXs2JOW922ERbKdBuJ5Q M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeBgD9o4NX/4sNJK1cgz5WKrJAhEpSg?= =?us-ascii?q?g+BeiKHIToSAQEBAQEBAWUnhQYVdgImAl8NCAEBiCwOoFmPYo5gAQEBAQYBAQE?= =?us-ascii?q?BHgWBAYUmgXiKF4JaAQSZGIsLgmtcgVQBh3iFX5APJQQrhA0giXEBAQE?= X-IronPort-AV: E=Sophos;i="5.28,346,1464652800"; d="scan'208";a="124786002" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jul 2016 13:55:02 +0000 Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u6BDt2oa011496 for ; Mon, 11 Jul 2016 13:55:02 GMT To: mmusic From: Flemming Andreasen Message-ID: Date: Mon, 11 Jul 2016 09:55:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] MMUSIC Agenda for IETF 96 (Berlin) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 13:55:05 -0000 Greetings MMUSIC will be meeting for 1 hour in Berlin, and we have a correspondingly light agenda looking at overall status and specificially focusing on drafts that RTCWeb is dependent on and what we need to do to finish those. You can see the agenda at: https://www.ietf.org/proceedings/96/agenda/agenda-96-mmusic Thanks -- Bo & Flemming (MMUSIC co-chairs) From nobody Mon Jul 11 09:19:18 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8442212B03C for ; Mon, 11 Jul 2016 09:19:14 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 RfeQw19HGxhg for ; Mon, 11 Jul 2016 09:19:12 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B52B12D592 for ; Mon, 11 Jul 2016 09:19:12 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id b62so8496142iod.3 for ; Mon, 11 Jul 2016 09:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yQugzfB58RESYgJ4U7fopIYcLQnLTyELgXsfFX4oKKI=; b=isuesdAJGJgJJegqn+n6vFQvb6cueUn14U1yTqOpHQT0Naqa/oFhkUvEsJTneWRB9y 0N3XS4nRDazv0pbJi8f3RkvW6zMzoYyyKogidVOxZZsP5XUxrA1KtluHKoSRPwq5j4e/ /AjkXKYY2Uj9RvjPWGdcRaD71kyySzPldlV1EYc7MizYXwQXnHfB/LjZW7if+LOr5RrX sq0zFAO8XMJLTE04CkdcRixTVCXsWHEkAxNxnOPo6KW1UytRcWmJzmxHJi9grrrmvpN9 Ze9dX846vxKbc0GA55A6T+RVMKgcjsc2ELZCF+wP6s8rmFjI3s9JB7uiXBSto4Hwz0/i YzzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yQugzfB58RESYgJ4U7fopIYcLQnLTyELgXsfFX4oKKI=; b=Cx45f3BKeFExDh/f4dst84j8KJVcrR5gEGXivhH4O2LVx/b4Ok3iJD45tepabd3yb/ nrY0UZr5gOq22f28K9qHkHm80/mqreMFYxZPNu0h4ATw5O1qyo0sD0yJzret7kLAkyFD CnUy5weMrt05hyCl56lF26A5mrXIIVj+ac0bujiINLbnKHSyzjUuaNt0MjK3NNckxeTb PAu7cjSRqYaQFf9Ofn38UJAi8RgjmYrD+grUlMRTmSW6LbFuaghd0h1PdqxPBM4LHe48 iVe/3tnCmEn3BClTNrlVmS8bOYm9hnR+vAaxewjcMz+njv3/70XW+o+V6NlgMriu7jln YmEQ== X-Gm-Message-State: ALyK8tIvgM55Ip0FTkx8uK3b8rlyM2uveH79wdz48v946hPH6qMQ0QOMKTHX3+6SlNw5iw== X-Received: by 10.107.164.202 with SMTP id d71mr20978058ioj.80.1468253951879; Mon, 11 Jul 2016 09:19:11 -0700 (PDT) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com. [209.85.214.51]) by smtp.gmail.com with ESMTPSA id 92sm4195254iok.22.2016.07.11.09.19.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 09:19:11 -0700 (PDT) Received: by mail-it0-f51.google.com with SMTP id f6so9944297ith.0; Mon, 11 Jul 2016 09:19:11 -0700 (PDT) X-Received: by 10.36.23.210 with SMTP id 201mr7275369ith.18.1468253950824; Mon, 11 Jul 2016 09:19:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.62.139 with HTTP; Mon, 11 Jul 2016 09:19:10 -0700 (PDT) In-Reply-To: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> From: Roman Shpount Date: Mon, 11 Jul 2016 12:19:10 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a114370be2dff9405375e8335 Archived-At: Cc: RTCWeb IETF , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:19:14 -0000 --001a114370be2dff9405375e8335 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would definitely like to proceed with this. There are certain issues related to forking and new associations being setup by the answering party, but I think they are resolvable. On the other hand, the benefits of reduced call setup up time definitely make this worthwhile. _____________ Roman Shpount On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings wrote: > > Quick questions for folks =E2=80=A6 is an idea that we should explore a = bit > deeper before making decisions about it? or should we not proceed? or > should we proceed? Just looking for feedback on where this should go next > > Thanks, Cullen > > > On Apr 18, 2016, at 7:59 AM, Roman Shpount wrote: > > On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla wrote: > >> I wanted to call your attention to a draft I just published with a >> possibly stupid >> idea. >> >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >> >> A nontrivial fraction of call setup time in WebRTC is the DTLS handshake= . >> This document describes how to piggyback the first few handshake message= s >> in the SDP offer/answer exchange, thus reducing latency. >> >> Comments welcome. >> >> > One other issue I thought off was that with DTLS SDP either offerer or > answerer can start a new DTLS association. When answerer starts a new > session it will have exactly the same problems as forking, since this wil= l > create multiple DTLS sessions with the same client random. This can be > solved with some sort of fallback mechanism to either regular DTLS setup = or > to sending a ClientHello in the answer. > > Regards, > _____________ > Roman Shpount > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a114370be2dff9405375e8335 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would definitely like to proceed with this. There are ce= rtain issues related to forking and new associations being setup by the ans= wering party, but I think they are resolvable. On the other hand, the benef= its of reduced call setup up time definitely make this worthwhile.

_____________
Roman Shpount
<= /div>
On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jenn= ings <fluffy@cisco.com> wrote:

Quick questions for = folks =E2=80=A6 =C2=A0is an idea that we should explore a bit deeper before= making decisions about it? or should we not proceed? or should we proceed?= Just looking for feedback on where this should go next=C2=A0

Thanks, Cullen


=
On Apr 18, 2016, at 7:59 AM, Roman Shpount <= roman@telurix.com> wrote:

I wanted to call your att= ention to a draft I just published with a possibly stupid
ide= a.


A nontrivial fract= ion of call setup time in WebRTC is the DTLS handshake.
This docu= ment describes how to piggyback the first few handshake messages
= in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.


One other issue I thought off was that with DTLS SDP either offere= r or answerer can start a new DTLS association. When answerer starts a new = session it will have exactly the same problems as forking, since this will = create multiple DTLS sessions with the same client random. This can be solv= ed with some sort of fallback mechanism to either regular DTLS setup or to = sending a ClientHello in the answer.

Regards,
_____________
Roman Shpount
=C2=A0
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb


________________________________________= _______
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--001a114370be2dff9405375e8335-- From nobody Mon Jul 11 09:33:37 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2571912D5CA for ; Mon, 11 Jul 2016 09:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40dAFHwTTYpZ for ; Mon, 11 Jul 2016 09:33:31 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9CA12D5AE for ; Mon, 11 Jul 2016 09:33:30 -0700 (PDT) Received: (qmail 98660 invoked from network); 11 Jul 2016 16:33:28 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 8895 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 11 Jul 2016 16:33:28 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id E16A518A0347; Mon, 11 Jul 2016 17:33:24 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id CF8EA18A0627; Mon, 11 Jul 2016 17:33:24 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id AD37F18A0347; Mon, 11 Jul 2016 17:33:24 +0100 (BST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4D84090A-9399-4B02-8FA3-F1FE227809B0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: T H Panton In-Reply-To: Date: Mon, 11 Jul 2016 17:33:23 +0100 Message-Id: <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Cullen Jennings , RTCWeb IETF , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:33:34 -0000 --Apple-Mail=_4D84090A-9399-4B02-8FA3-F1FE227809B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jul 2016, at 17:19, Roman Shpount wrote: >=20 > I would definitely like to proceed with this. There are certain issues = related to forking and new associations being setup by the answering = party, but I think they are resolvable. On the other hand, the benefits = of reduced call setup up time definitely make this worthwhile. As I said (remotely) at the last meeting, =20 I am distinctly _unkeen_ on the aesthetics of this - it ties us to ever = uglier and larger SDP, it breaks software layer separation in the = stacks,=20 it will no doubt presume a single DTLS implementation, it will be _fun_ = to test, and I anticipate it will open some ugly attack vectors to the javascript kiddies.=20 Last I heard EKR was going to experiment with it and come back with a = view on how (in)accurate my doom-saying was.=20 I haven't heard the reply... - If folks want a corridor conversation about this next week in Berlin, = I'll be there. T. >=20 > _____________ > Roman Shpount >=20 > On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings > wrote: >=20 > Quick questions for folks =E2=80=A6 is an idea that we should explore = a bit deeper before making decisions about it? or should we not proceed? = or should we proceed? Just looking for feedback on where this should go = next=20 >=20 > Thanks, Cullen >=20 >=20 >> On Apr 18, 2016, at 7:59 AM, Roman Shpount > wrote: >>=20 >> On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla > wrote: >> I wanted to call your attention to a draft I just published with a = possibly stupid >> idea. >>=20 >> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 = >>=20 >> A nontrivial fraction of call setup time in WebRTC is the DTLS = handshake. >> This document describes how to piggyback the first few handshake = messages >> in the SDP offer/answer exchange, thus reducing latency. >>=20 >> Comments welcome. >>=20 >>=20 >> One other issue I thought off was that with DTLS SDP either offerer = or answerer can start a new DTLS association. When answerer starts a new = session it will have exactly the same problems as forking, since this = will create multiple DTLS sessions with the same client random. This can = be solved with some sort of fallback mechanism to either regular DTLS = setup or to sending a ClientHello in the answer. >>=20 >> Regards, >> _____________ >> Roman Shpount >> =20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb = >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_4D84090A-9399-4B02-8FA3-F1FE227809B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 11 Jul 2016, at 17:19, Roman Shpount <roman@telurix.com> = wrote:

I would = definitely like to proceed with this. There are certain issues related = to forking and new associations being setup by the answering party, but = I think they are resolvable. On the other hand, the benefits of reduced = call setup up time definitely make this = worthwhile.

As I = said (remotely) at the last meeting,  
I am distinctly = _unkeen_ on the aesthetics of this - it ties us to ever uglier and = larger SDP, it breaks software layer separation in the = stacks, 
it will no doubt presume a single DTLS = implementation, it will be _fun_ to test, and I anticipate it will open = some ugly attack vectors
to the javascript = kiddies. 

Last I heard EKR was going = to experiment with it and come back with a view on how (in)accurate my = doom-saying was. 
I haven't heard the = reply...

- If folks want a corridor = conversation about this next week in Berlin, I'll be = there.

T.


_____________
Roman = Shpount

On Mon, Jul = 11, 2016 at 8:22 AM, Cullen Jennings <fluffy@cisco.com> wrote:

Quick questions for folks =E2=80=A6  is an idea = that we should explore a bit deeper before making decisions about it? or = should we not proceed? or should we proceed? Just looking for feedback = on where this should go next 

Thanks, Cullen


On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com> wrote:

On Mon, Apr 4, 2016 at 9:10 AM, Eric = Rescorla <ekr@rtfm.com> wrote:
I wanted to call your attention to a draft I just published = with a possibly stupid
idea.

https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00

A = nontrivial fraction of call setup time in WebRTC is the DTLS = handshake.
This document describes how to piggyback = the first few handshake messages
in the SDP = offer/answer exchange, thus reducing latency.

Comments welcome.


One other issue I thought off was that = with DTLS SDP either offerer or answerer can start a new DTLS = association. When answerer starts a new session it will have exactly the = same problems as forking, since this will create multiple DTLS sessions = with the same client random. This can be solved with some sort of = fallback mechanism to either regular DTLS setup or to sending a = ClientHello in the answer.

Regards,
_____________
Roman Shpount
 
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


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


_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
= --Apple-Mail=_4D84090A-9399-4B02-8FA3-F1FE227809B0-- From nobody Mon Jul 11 09:59:00 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFF212D182; Mon, 11 Jul 2016 09:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igR6fTyPXOu4; Mon, 11 Jul 2016 09:58:57 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE09128E18; Mon, 11 Jul 2016 09:58:56 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-2e-5783d04ee109 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5A.4B.12516.E40D3875; Mon, 11 Jul 2016 18:58:55 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0294.000; Mon, 11 Jul 2016 18:58:54 +0200 From: Christer Holmberg To: T H Panton , Roman Shpount Thread-Topic: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP Thread-Index: AQHR25H7RNZN26dRbUODj/n1LGaMCaATc9/F Date: Mon, 11 Jul 2016 16:58:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4768FEBB@ESESSMB208.ericsson.se> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> , <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> In-Reply-To: <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4768FEBBESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7pa7/heZwg0c32S06JrNZTF3+mMVi xoWpzBZr/7WzW1zcfovRgdVjyu+NrB5Llvxk8lgyqZHN49aUggCWKC6blNSczLLUIn27BK6M UzMvsxXsKqmY8/MEewPj3tQuRk4OCQETidvLTrFC2GISF+6tZ+ti5OIQEjjCKHHr3R8mCGcx o8STVfPYuxg5ONgELCS6/2mDNIgIeEos/j+DHcRmFkiT+H2vgxGkRFjAXGLZM6gSC4nZbx8w Q9hGEgvOnmcEsVkEVCWOXlvAAmLzCvhKnGn4wwyx6hSTxPWbT8FWcQq4SnzYEwNSwwh02/dT a5ggVolLNH1ZCXWzgMSSPeeZIWxRiZeP/7FC1ORLzD74jwlivqDEyZlPWCYwisxC0j4LSdks JGUQcQOJL+9vQ9naEssWvmaGsPUlut+fZkIWX8DIvopRtDi1uDg33chYL7UoM7m4OD9PLy+1 ZBMjMAYPbvmtu4Nx9WvHQ4wCHIxKPLwJR5vChVgTy4orcw8xSnAwK4nwzjnbHC7Em5JYWZVa lB9fVJqTWnyIUZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBsbW9pe0Gn2lFdlbD8nnh 32oUZ9nJ3A69vfbJVOs59j+VZb/o3vzIPM1CKeJQeuGPrOsrDs6vXudzY8e1dZfNd174JfeC d52mj46nZ/O7JR2xYjuXJiyQe1hu5GVaKHm/7J40++yfa2M/J9ruL5gVWcPeUqkgLBt1JICb VfKKxSulW6eO/3XxVmIpzkg01GIuKk4EABS9Z+y9AgAA Archived-At: Cc: Cullen Jennings , RTCWeb IETF , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 16:58:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4768FEBBESESSMB208erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, All I'll say at this point is that you cannot assume that forking entities = will remove the attribute. You either need to have a fallback procedure in = case of forking, or say that the mechanism MUST NOT be used in environments= where forking can occur (which makes the mechanism more or less useless in= virtually all SIP environments). Regards, Christer Sent from my Windows Phone ________________________________ From: T H Panton Sent: =FD11/=FD07/=FD2016 19:33 To: Roman Shpount Cc: Cullen Jennings; RTCWeb IETF; mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP On 11 Jul 2016, at 17:19, Roman Shpount > wrote: I would definitely like to proceed with this. There are certain issues rela= ted to forking and new associations being setup by the answering party, but= I think they are resolvable. On the other hand, the benefits of reduced ca= ll setup up time definitely make this worthwhile. As I said (remotely) at the last meeting, I am distinctly _unkeen_ on the aesthetics of this - it ties us to ever ugl= ier and larger SDP, it breaks software layer separation in the stacks, it will no doubt presume a single DTLS implementation, it will be _fun_ to = test, and I anticipate it will open some ugly attack vectors to the javascript kiddies. Last I heard EKR was going to experiment with it and come back with a view = on how (in)accurate my doom-saying was. I haven't heard the reply... - If folks want a corridor conversation about this next week in Berlin, I'l= l be there. T. _____________ Roman Shpount On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings > wrote: Quick questions for folks =85 is an idea that we should explore a bit deep= er before making decisions about it? or should we not proceed? or should we= proceed? Just looking for feedback on where this should go next Thanks, Cullen On Apr 18, 2016, at 7:59 AM, Roman Shpount > wrote: On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla > wrote: I wanted to call your attention to a draft I just published with a possibly= stupid idea. https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 A nontrivial fraction of call setup time in WebRTC is the DTLS handshake. This document describes how to piggyback the first few handshake messages in the SDP offer/answer exchange, thus reducing latency. Comments welcome. One other issue I thought off was that with DTLS SDP either offerer or answ= erer can start a new DTLS association. When answerer starts a new session i= t will have exactly the same problems as forking, since this will create mu= ltiple DTLS sessions with the same client random. This can be solved with s= ome sort of fallback mechanism to either regular DTLS setup or to sending a= ClientHello in the answer. Regards, _____________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B4768FEBBESESSMB208erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

All I'll say at this point is that you cannot assume that forking entities = will remove the attribute. You either need to have a fallback procedure in = case of forking, or say that the mechanism MUST NOT be used in environments= where forking can occur (which makes the mechanism more or less useless in virtually all SIP environments= ).

Regards,

Christer


Sent from my Windows Phone
From: T H Panton
Sent: =FD11= /=FD07/=FD2016 19:33
To: Roman Shpount
Cc: Cullen Jennings; RTCWeb IETF; mmusic WG
Subject: Re: [= MMUSIC] [rtcweb]   Tunnelling DTLS in SDP


On 11 Jul 2016, at 17:19, Roman Shpount <roman@telurix.com> wrote:

I would definitely like to proceed with this. There are certain issues rela= ted to forking and new associations being setup by the answering party, but= I think they are resolvable. On the other hand, the benefits of reduced ca= ll setup up time definitely make this worthwhile.

As I said (remotely) at the last meeting,  
I am distinctly _unkeen_ on the aesthetics of this - it ties us to eve= r uglier and larger SDP, it breaks software layer separation in the stacks,=  
it will no doubt presume a single DTLS implementation, it will be _fun= _ to test, and I anticipate it will open some ugly attack vectors
to the javascript kiddies. 

Last I heard EKR was going to experiment with it and come back with a view = on how (in)accurate my doom-saying was. 
I haven't heard the reply...

- If folks want a corridor conversation about this next week in Berlin= , I'll be there.

T.


_____________
Roman Shpount

On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings=  <= fluffy@cisco.com> = wrote:

Quick questions for folks =85  is an idea that we should explore a bit= deeper before making decisions about it? or should we not proceed? or shou= ld we proceed? Just looking for feedback on where this should go next 

Thanks, Cullen


On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com= > wrote:

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <ekr@rtfm.com>= ; wrote:
I wanted to call your attention to a draft I just published= with a possibly stupid
idea.

https://tools.ietf.org/html/draft-r= escorla-dtls-in-sdp-00

A nontrivial fraction of call setup time in WebRTC is the D= TLS handshake.
This document describes how to piggyback the first few hand= shake messages
in the SDP offer/answer exchange, thus reducing latency.

Comments welcome.


One other issue I thought off was that with DTLS SDP either= offerer or answerer can start a new DTLS association. When answerer starts= a new session it will have exactly the same problems as forking, since thi= s will create multiple DTLS sessions with the same client random. This can be solved with some sort of fallback= mechanism to either regular DTLS setup or to sending a ClientHello in the = answer.

Regards,
_____________
Roman Shpount
 
_______________________________________________
rtcweb mailing list
rtcweb@ietf= .org
https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic<= /a>


______________= _________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--_000_7594FB04B1934943A5C02806D1A2204B4768FEBBESESSMB208erics_-- From nobody Mon Jul 11 10:11:57 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C478512D5E7 for ; Mon, 11 Jul 2016 10:11:55 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com 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 tf5sstQ1vreY for ; Mon, 11 Jul 2016 10:11:54 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD9E12D5C9 for ; Mon, 11 Jul 2016 10:11:54 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id b72so98492198ywa.3 for ; Mon, 11 Jul 2016 10:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UTt4HIgF58JUBfdQhHwLW6oXqkePBpfRlPz51tUvJPY=; b=Ei6XrCegv38uiw5OcTBH9f91ymYE7g6QXgoAlr7541T+2yMlH8/T6as/nJzZyMWpZJ v0z6ifcp1z9JCFCvgsOaMyaJAyyv6b6vvcWJqoVfWF+zL8a+wLLb8CzpU9LI7GJdezA/ H7JcMjtyXIfQPtmxtNz6FvEmY0U+IEVYNsl7fmedO9N2p4mDxWjqQHX/2Eun7PFriGJY zFAZNvlJDDXskTpN/+oCQdd4lAsXZqvnt7jMBNYZtAKduQ5UoaK5sz6rij3ORuIbZnC5 HcN6YYMqTFVmGuibHHiz/9+0c9c0hrbIe1Q+aw/yEN0s44s1jJ/GaX8Vz67cY4/XYq2N NvMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UTt4HIgF58JUBfdQhHwLW6oXqkePBpfRlPz51tUvJPY=; b=Oq2vomsmQP7pacftRM/3h0cdy0J+tWSGqi/uLVobGgBabr4GgqYJaNojLLHeEsbqNi UyXDnMbvaizXvcAqrXjKquY8MPWLYE9arIosW2TIeodSiwlPmD/FNowJr/xKBCqlVYZx KzY2FRQKECkC4WYM5gimpdq4Wm88/emoOpws0lKL2Sg8HUwDooqK58dPjSozBNPepyid wGzBktuo4f4rVzwwyDK3ZzdF8d7siRbzodwMIx6UE9VhBgnE7Uu0BFsj4dN8EthZ7hhx 6UgZmi7RCevVmT/xO6vlOH62UwS4LwiyCWxI/yHO35ur4tifWsS1lTVyV1+UHs4upAS5 efTQ== X-Gm-Message-State: ALyK8tL/W3jqIo2/3LWOVR2ACNKr4r0EJ+rYjzJqO0/lMfCBnp3WaYpivgeDPSOkJtYW6s9Kn0JB4s6BDwSbfA== X-Received: by 10.37.223.206 with SMTP id w197mr13737594ybg.172.1468257113587; Mon, 11 Jul 2016 10:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.33.213 with HTTP; Mon, 11 Jul 2016 10:11:34 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4768FEBB@ESESSMB208.ericsson.se> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> <7594FB04B1934943A5C02806D1A2204B4768FEBB@ESESSMB208.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 11 Jul 2016 19:11:34 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Cullen Jennings , RTCWeb IETF , T H Panton , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:11:56 -0000 2016-07-11 18:58 GMT+02:00 Christer Holmberg : > All I'll say at this point is that you cannot assume that forking entitie= s > will remove the attribute. You either need to have a fallback procedure i= n > case of forking, or say that the mechanism MUST NOT be used in environmen= ts > where forking can occur (which makes the mechanism more or less useless i= n > virtually all SIP environments). SIP devices can just ignore this spec like if it was Outbound or GRUU. --=20 I=C3=B1aki Baz Castillo From nobody Mon Jul 11 10:43:32 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C9B126D74 for ; Mon, 11 Jul 2016 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 MKPVOkN_rg-s for ; Mon, 11 Jul 2016 10:43:25 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C5612D0B7 for ; Mon, 11 Jul 2016 10:43:24 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p74so64897571qka.0 for ; Mon, 11 Jul 2016 10:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e45INFwL28M1vH3r+LhV4Gs518fiFebmAk/SjezQOg4=; b=LIciFRR31F4UlQGZor654pi61dAAhWxWBCuexEV516l/pWa366FwvfY1bWJ9IBOLjJ 9Q2TpELXXGUrq0ht/puWdlnSvziWFCNZpY4VRjhkL16Awxs3bQ3fzukIwxnzHmRbmeLl aofhMSjerSiVptlKFEtVuCekrEhqIM81xKe5huvvuPWXW2XJYN2/BJBDQ3RmmeumsDgf cMhCHvA6e/Anpm9FeB8omeFpM1qgTdLg2lhSOSvByZ5gMK+CWf9b4JQuByK7YAQaS/5v X4eTLpTjsv0ECiHxN9H5+1+CaKf0Zfy+j+TqnlmsvmVqHQJbX0ClLFaQ1d8+dsjgHMyi cglA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e45INFwL28M1vH3r+LhV4Gs518fiFebmAk/SjezQOg4=; b=eAfw50LmkHpIFL0q+qc8ly5tcKefS4iCdbyVbwK8GO/0Ex+WLFBK8dhb+xhE+h53Tf VscUjml6LErNqe/yP1UdxWjKjNuUK1F86vsjOtoYC7wvPtMU9DjBXjmDInladz+56nJz BYBPJD8Bx9wlv3+kuqb3m/PoFs8kmjUDGKM31XC45tHSkP1n6gTf7BYCQ/9y7Wa85BES 4XAGI3bNTMntuEA/rm+2DYTyRabxcSJebkLKMcPGi+yuXSPoJG7koOgp05pm02SnG4Gk y4Y/U9XsLYBz22/fL3yAeheHwUhZ7yQar4+ClWRHu2GPiNI92X1IxPkhtl6dMI7cs77X 9Vkg== X-Gm-Message-State: ALyK8tKjlEY2dgjPemev+IxGNGAwIuwLGpbgdGeoVZQsWaxDxg3gLq6FMn/c292SZ6hDHR/lpzy3LT/pBGZNMjRl X-Received: by 10.55.106.135 with SMTP id f129mr28381911qkc.118.1468259003892; Mon, 11 Jul 2016 10:43:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Mon, 11 Jul 2016 10:42:44 -0700 (PDT) In-Reply-To: <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> From: Peter Thatcher Date: Mon, 11 Jul 2016 10:42:44 -0700 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a11487fd65e0f0f05375fb047 Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:43:27 -0000 --001a11487fd65e0f0f05375fb047 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Basically what your're asking for is header extension that says "Not only am I MID X, but I'm also, temporarily, MID Y"? Why not just have a second, separate, header extension for "I'm also temporarily MID Y"? Then the existing semantics of BUNDLE and MID (and RIDs, which are scoped to MIDs) need not change, but you get the information you need (I think). On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox wrote: > The intention of my proposal is that these could indeed be (temporarily) > the same RTP media source, even though they=E2=80=99re two separate m-lin= es. > > On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar wrote: > > Hi Jonathan > > Clarification question : > > if we have 2 m=3Dlines > > m =3D ... > a=3Dmid1 > > > m=3D... > a=3Dmid2 > > > does these 2 correspond to same media source ? It felt so from the > duplicate design you mentioned but wanted to confirm > > Thanks > Suhas > > > > On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox > wrote: > >> Hi, all =E2=80=94 >> >> (This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promi= sed to >> send e-mail to the list but hadn=E2=80=99t remembered to get around to i= t until >> now.) >> >> When finishing up the CLUE RTP mapping draft, I realized that one of >> CLUE=E2=80=99s RTP requirements didn=E2=80=99t actually end up getting s= atisfied by BUNDLE >> (which is the solution CLUE converged on). This isn=E2=80=99t a CLUE-sp= ecific >> issue, so I=E2=80=99m raising it here. >> >> The issue is whether we want to support a use case, in BUNDLE, where a >> single RTP stream corresponds to more than media description (and thus h= as >> more than one MID value)? >> >> The use case is where one m-line has a semantic of =E2=80=9Calways view = this >> person=E2=80=9D (my boss, say, or my customer); and another m-line has a= semantic >> of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these would = be a single content >> capture in the former case, and a switched capture for the latter.) >> Whenever the boss *is* the current loudest speaker, the same content wou= ld >> be sent for both m-lines. >> >> A naive implementation would simply duplicate all the packets for the tw= o >> m-lines, with different MID values, but this has two problems. First of= f >> all, it obviously wastes bandwidth. Potentially more seriously, it >> precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC = values, >> since the same content (arriving with a single SSRC value at the middleb= ox) >> would need to be sent with two different SSRC values down from the >> middlebox. If PERC goes with its current consensus of no SSRC rewriting= , >> this will particularly be a problem for PERC. >> >> I certainly don=E2=80=99t think this is something that should block BUND= LE=E2=80=99s >> completion, but I think it could be a pretty easy extension. >> >> (My initial design proposal was to allow multiple SDES values of the sam= e >> type, and multiple SDES header extensions items of the same type, to be >> sent simultaneously in RTP =E2=80=94 protocol-syntactically this is triv= ial, you=E2=80=99d >> just need to negotiate that you support it. But I=E2=80=99m not wedded = to this >> solution.) >> >> What do people think =E2=80=94 is this worth working on? Is there inter= est in >> discussing it in Berlin, and if so, in what venue? >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a11487fd65e0f0f05375fb047 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Basically what your're asking for is header extensi= on that says "Not only am I MID X, but I'm also, temporarily, MID = Y"? =C2=A0 Why not just have a second, separate, header extension for = "I'm also temporarily MID Y"? =C2=A0 Then the existing semant= ics of BUNDLE and MID (and RIDs, which are scoped to MIDs) need not change,= but you get the information you need (I think).


<= /div>

On Fri= , Jul 8, 2016 at 8:51 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
The intention of my proposal is that these could indeed be (temporaril= y) the same RTP media source, even though they=E2=80=99re two separate m-li= nes.

On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
Hi Jonathan=C2=A0

=C2=A0 Clarification question :

=C2=A0 =C2=A0if we have 2 m=3Dlines
=C2=A0 =C2=A0
m =3D ...
a=3Dmid1
<manager>

m=3D...
a=3Dmid2
<loudest speaker>

does these 2 correspond to same media source ? It felt so from the dup= licate design you mentioned but wanted to confirm

Thanks
Suhas

=C2=A0 =C2=A0

On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
Hi, all =E2=80=94

(This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promised= to send e-mail to the list but hadn=E2=80=99t remembered to get around to = it until now.)

When finishing up the CLUE RTP mapping draft, I realized that one of CLUE= =E2=80=99s RTP requirements didn=E2=80=99t actually end up getting satisfie= d by BUNDLE (which is the solution CLUE converged on).=C2=A0 This isn=E2=80= =99t a CLUE-specific issue, so I=E2=80=99m raising it here.

The issue is whether we want to support a use case, in BUNDLE, where a sing= le RTP stream corresponds to more than media description (and thus has more= than one MID value)?

The use case is where one m-line has a semantic of =E2=80=9Calways view thi= s person=E2=80=9D (my boss, say, or my customer); and another m-line has a = semantic of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these = would be a single content capture in the former case, and a switched capture for the latter.)=C2=A0 Whenever the boss *is* the current loudest = speaker, the same content would be sent for both m-lines.

A naive implementation would simply duplicate all the packets for the two m= -lines, with different MID values, but this has two problems.=C2=A0 First o= ff all, it obviously wastes bandwidth.=C2=A0 Potentially more seriously, it= precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC values, since the same content (arriving with= a single SSRC value at the middlebox) would need to be sent with two diffe= rent SSRC values down from the middlebox.=C2=A0 If PERC goes with its curre= nt consensus of no SSRC rewriting, this will particularly be a problem for PERC.

I certainly don=E2=80=99t think this is something that should block BUNDLE= =E2=80=99s completion, but I think it could be a pretty easy extension.

(My initial design proposal was to allow multiple SDES values of the same t= ype, and multiple SDES header extensions items of the same type, to be sent= simultaneously in RTP =E2=80=94 protocol-syntactically this is trivial, yo= u=E2=80=99d just need to negotiate that you support it.=C2=A0 But I=E2=80=99m not wedded to this solution.)

What do people think =E2=80=94 is this worth working on?=C2=A0 Is there int= erest in discussing it in Berlin, and if so, in what venue?
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic



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


--001a11487fd65e0f0f05375fb047-- From nobody Mon Jul 11 15:41:24 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF3D12D0AE for ; Mon, 11 Jul 2016 15:41:23 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 XUjCiq6i-4kS for ; Mon, 11 Jul 2016 15:41:21 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C1D12B02A for ; Mon, 11 Jul 2016 15:41:20 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id l125so105618045ywb.2 for ; Mon, 11 Jul 2016 15:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pa8KOKHuQkqdPMXJ3OimSiXtzmqcfibWJlbxGsUBGvc=; b=pcSN9/RJGLAbmvtdWWB6KBFKF9lbRsnlS9eSc4u2BrrLyLZoAk3aYU4vy3r9DdNJZb yIgndB1/675HnDFN03TW1UYUEzSpYbfSyMlIkmydZC/uXe0GBOfrmnSeYNtoIEG0BGbg r8NGXPbgAyp4UWE9d6u1DAbsJUPlwKlEcASZn0M/jLHKO4f/M084cwgC72bN73HLwlqt Ih5QF7LjiWsUGe+QXC0csYqM6LUnlD4ttfMA7ZfzL6F+13obEeNBFYNspVvFOyHcgSs2 6weaF+T1VxLfX4RUAbK+kflns8xfqw62qkFdYxV5XM1mod7uQmbzmkToGTvWdk5V54rM trEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pa8KOKHuQkqdPMXJ3OimSiXtzmqcfibWJlbxGsUBGvc=; b=gb4oAIUS6JFLBrbMCBx+R0lx/CSyV1LfB7bGkWhKNOtVrDsGu35f/nuL0v8UTcVYrX aXt2PV6cg9r+6GRDEsbeB2bKet2D1UBq5zpIW2iYIbT77BlPUj8QoVTUygijP5/smtbB /2k41ytBzi77olYe0w5ZrDuVoR26UaPoKsLNK91iw4BHydfxVhu8KFNZ/SYeFmhj4gHK sCkXzitKQi7kPF+mFo7WePMcNL4NEqo7nWOdY6yk9999r59E1uYqXw4b53kiEBtuL3ws V6VUxV+JRkhCvWlrbgO+4msk27zzOCPrHC6oGwvULejYDJ8xGlnGxeF5ibUFaae2QJlq Qrig== X-Gm-Message-State: ALyK8tIlAmotC3Z/+r8BpGNFqoIxopqDpyCLcpKmdcDLVo4e4/VLoj8YjLFqKqE3tWyWeuabllHDlVfPn0JQ3Q== X-Received: by 10.37.209.5 with SMTP id i5mr13716680ybg.146.1468276880162; Mon, 11 Jul 2016 15:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Mon, 11 Jul 2016 15:40:40 -0700 (PDT) In-Reply-To: <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> References: <16EBD211-7FAD-43F1-A855-639EC17A17FE@cisco.com> <7DF2166A-3AF4-4591-AB25-8C5415875E8D@phonefromhere.com> From: Eric Rescorla Date: Mon, 11 Jul 2016 15:40:40 -0700 Message-ID: To: T H Panton Content-Type: multipart/alternative; boundary=94eb2c06fc0adff3f1053763d960 Archived-At: Cc: Cullen Jennings , RTCWeb IETF , mmusic WG Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 22:41:23 -0000 --94eb2c06fc0adff3f1053763d960 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2016 at 9:33 AM, T H Panton wrote: > > On 11 Jul 2016, at 17:19, Roman Shpount wrote: > > I would definitely like to proceed with this. There are certain issues > related to forking and new associations being setup by the answering part= y, > but I think they are resolvable. On the other hand, the benefits of reduc= ed > call setup up time definitely make this worthwhile. > > > As I said (remotely) at the last meeting, > I am distinctly _unkeen_ on the aesthetics of this - it ties us to ever > uglier and larger SDP, it breaks software layer separation in the stacks, > it will no doubt presume a single DTLS implementation, it will be _fun_ t= o > test, and I anticipate it will open some ugly attack vectors > to the javascript kiddies. > > Last I heard EKR was going to experiment with it and come back with a vie= w > on how (in)accurate my doom-saying was. > I haven't heard the reply... > We're working on an implementation now but it took a while to divert the staff. -Ekr > > - If folks want a corridor conversation about this next week in Berlin, > I'll be there. > > T. > > > _____________ > Roman Shpount > > On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings wrote= : > >> >> Quick questions for folks =E2=80=A6 is an idea that we should explore a= bit >> deeper before making decisions about it? or should we not proceed? or >> should we proceed? Just looking for feedback on where this should go nex= t >> >> Thanks, Cullen >> >> >> On Apr 18, 2016, at 7:59 AM, Roman Shpount wrote: >> >> On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla wrote: >> >>> I wanted to call your attention to a draft I just published with a >>> possibly stupid >>> idea. >>> >>> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00 >>> >>> A nontrivial fraction of call setup time in WebRTC is the DTLS handshak= e. >>> This document describes how to piggyback the first few handshake messag= es >>> in the SDP offer/answer exchange, thus reducing latency. >>> >>> Comments welcome. >>> >>> >> One other issue I thought off was that with DTLS SDP either offerer or >> answerer can start a new DTLS association. When answerer starts a new >> session it will have exactly the same problems as forking, since this wi= ll >> create multiple DTLS sessions with the same client random. This can be >> solved with some sort of fallback mechanism to either regular DTLS setup= or >> to sending a ClientHello in the answer. >> >> Regards, >> _____________ >> Roman Shpount >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c06fc0adff3f1053763d960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 11, 2016 at 9:33 AM, T H Panton <tim@phonefromhere.com= > wrote:

= On 11 Jul 2016, at 17:19, Roman Shpount <roman@telurix.com> wrote:

I would definitel= y like to proceed with this. There are certain issues related to forking an= d new associations being setup by the answering party, but I think they are= resolvable. On the other hand, the benefits of reduced call setup up time = definitely make this worthwhile.

As I said (remotely) at the last meeting, =C2=A0
I am di= stinctly _unkeen_ on the aesthetics of this - it ties us to ever uglier and= larger SDP, it breaks software layer separation in the stacks,=C2=A0
=
it will no doubt presume a single DTLS implementation, it will be _fun= _ to test, and I anticipate it will open some ugly attack vectors
to the javascript kiddies.=C2=A0

Last I heard EKR was going to experiment with it and come back with a view= on how (in)accurate my doom-saying was.=C2=A0
I haven't hear= d the reply...

We're workin= g on an implementation now but it took a while to divert the staff.

-Ekr
=C2=A0

- If folks want a = corridor conversation about this next week in Berlin, I'll be there.

T.


_____________
Roman Shpount

On Mon, Jul 11, 2016 at 8:22 AM, Cullen Jennings=C2=A0<fluff= y@cisco.com>=C2=A0wrote:

Quick questions for folks = =E2=80=A6 =C2=A0is an idea that we should explore a bit deeper before makin= g decisions about it? or should we not proceed? or should we proceed? Just = looking for feedback on where this should go next=C2=A0

= Thanks, Cullen


<= div>
On Apr 18, 2016, at 7:59 AM, Roman Shpount <roman@telurix.com> wrote:
<= br>
<= div>
On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla=C2=A0<ekr@r= tfm.com>=C2=A0wrote:
I wanted to call yo= ur attention to a draft I just published with a possibly stupid
idea.


A nontrivial= fraction of call setup time in WebRTC is the DTLS handshake.
Thi= s document describes how to piggyback the first few handshake messages
in the SDP offer/answer exchange, thus reducing latency.
Comments welcome.

=
One other issue I thought off was that with DTLS SDP either = offerer or answerer can start a new DTLS association. When answerer starts = a new session it will have exactly the same problems as forking, since this= will create multiple DTLS sessions with the same client random. This can b= e solved with some sort of fallback mechanism to either regular DTLS setup = or to sending a ClientHello in the answer.

Regards= ,
_____________
Roman Shpount
=C2=A0
______________________________________= _________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/= rtcweb


___= ____________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


_____________________________________= __________
rtcweb mailing list
rtcweb@ietf.org
https://www= .ietf.org/mailman/listinfo/rtcweb


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


--94eb2c06fc0adff3f1053763d960-- From nobody Tue Jul 12 08:01:17 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649DA12DE60; Tue, 12 Jul 2016 08:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGbxrJkf_0JI; Tue, 12 Jul 2016 08:01:03 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D380112DAF9; Tue, 12 Jul 2016 07:30:03 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-c6-5784feeb637e Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DF.96.12516.BEEF4875; Tue, 12 Jul 2016 16:30:03 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.294.0; Tue, 12 Jul 2016 16:30:03 +0200 To: Flemming Andreasen , mmusic References: <9f237771-3d8c-edf7-6b28-3e8f214075a5@cisco.com> From: Magnus Westerlund Message-ID: <61d550ef-32a2-f759-1cbd-1b2d937da1a0@ericsson.com> Date: Tue, 12 Jul 2016 16:30:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9f237771-3d8c-edf7-6b28-3e8f214075a5@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM2K7je7rfy3hBrf3KVtMXL+OyeL9BV2L qcsfszgwe0z5vZHVY8mSn0wBTFFcNimpOZllqUX6dglcGS+mChY8CK34+GA1UwPjAacuRk4O CQETiU1Lv7JB2GISF+6tB7OFBI4wSuxfkNLFyAVkL2eUuPbvBBNIQljATOLAy5PsILaIgKvE kYV3mSAabCQaFh8Ba2YWUJHoetfICmKzCVhI3PzRCBbnFbCXeP6qn7mLkYODRUBV4sVMOxBT VCBGYn1fAkSFoMTJmU9YQGxOAVuJ7hOfGUFKmIE6H2wtgxguL9G8dTYzxFJtiYamDtYJjIKz kHTPQuiYhaRjASPzKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAYD245bfuDsbVrx0PMQpw MCrx8C641xwuxJpYVlyZe4hRgoNZSYS35WdLuBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK 4UIC6YklqdmpqQWpRTBZJg5OqQZG+cVTYt02JTqc9NF/+0Ntalq53YQdkX+FdDQW50yrko2R PBWzclnI+usMT3/ly17iLu9xdf3tGHH6paT29sMzGm+rrnG4X1o1XeeZQmbyCoa9ds0xrBGV 2e8Ml/j8OOd4eJMS68pHD1/pfnj1/OfFbS1rLDL6TCvC5atPmq2fPW+6dvGT+gnzlFiKMxIN tZiLihMBLJ3i71ICAAA= Archived-At: Cc: draft-ietf-mmusic-rid@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rid-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:01:16 -0000 Hi, Here are my WG last call comments. 1. Section 2: However, the assignment of static mapping of RTP payload type numbers to payload formats and multiplexing of RTP with other protocols (such as RTCP) could result in limited number of payload type numbers available for application usage. Is still the state of the implementations such that overriding a static payload doesn't work? Already RFC 3264 is quite clear that this is possible. If possible I would avoid repeating this as a reason. I think RTP/RTCP MUX is a more relevant limitation that takes a significant chunk out of the PT range. 2. Section 4: This value binds the restriction to the RTP Stream identified by its RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. The draft is missing a statement making clear that if one implements mmusic-rid, then one is required to also implement avtext-rid using RFC 2119 langauge. Yes, I realize implicitly that this is the case, but I think one should make it explicit so that no one glancing it through misses this aspect and to avoid future debates. I also think there exist a question if one MUST include the SDES item, in the RTP stream, even when the PT is 3. Section 4: This framework MAY be used in combination with the "a=fmtp" SDP attribute for describing the media format parameters for a given RTP Payload Type. In such scenarios, the "a=rid" constraints (Section 5) further constrain the equivalent "a=fmtp" attributes. I wonder if this should include a bit of clearer purpose declration here. By using rid one can hopefully create more generic PTs that are focused on the codec and basic payload type configuration, and thus put the more detailed contrains to the rid. The introduction hints at this but I would prefer if this is made clearer as intended result of using rid. Possibly this may better belong in this Section 2 paragraph: The additional constraints on individual streams are indicated with a new "a=rid" SDP attribute. Note that the constraints communicated via this attribute only serve to further constrain the parameters that are established on a PT format. They do not relax any existing restrictions. 4. Section 4: This framework MAY be used in combination with the "a=fmtp" SDP attribute for describing the media format parameters for a given RTP Payload Type. I wonder if "MAY" is really the right RFC2119 word here. I don't see how you can't use a=fmtp to define the PTs. Because this leads my thought in the direction that you can use a=rid only and not use the whole PT declration mechansism with m= lines, a=rtpmap and a=fmtp. I don't believe this is the intention here. 5. Section 4: A given "rid-id" MUST NOT be repeated in a given media description ("m=" section). So this indicates a uniqueness requirement on media description level, but does not discuss how a receiver gets to correctly identify the RTP Stream within an RTP session to the Media Description, as this is what an actual receiver needs to deal with. Section 6 says: Note that "rid-id" values are only required to be unique within a media section ("m-line"); they do not necessarily need to be unique within an entire RTP session. In traditional usage, each media section is sent on its own unique 5-tuple, which provides an unambiguous scope. Similarly, when using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP streams uniquely to a single media description. What the above section 6 text doesn't cover is multiparty cases, when a receiver can receive RTP streams from multiple endpoints matching a particular media description, something that can occur in declarative use cases. In this case, one could add the CNAME will work as clear separator. Then there are the declarative interpretation that each media description is an RTP session. And in some cases, that could mean that one thinks multiple media sources fits a particular media description. I have no idea if there are actual deployed cases of this. However, I think the reasonable way forward here is to document the assumption that this is based on that even in declarative cases where there might be multiple endpoints that sends according to a specific media description, this only supports one media source. To conclude, I think the text about this needs be extended to cover the different cases better and make clear that there exist a requirement here. And the assumption that we don't need to solve multiple media sources from the same endpoint sent according to one media description (declarative usage). 6. Section 5: o max-bpp, for maximum number of bits per pixel, calculated as an average of all samples of any given coded picture. This is expressed as a floating point value, with an allowed range of 0.0001 to 48.0. Does this need a clarification that any values outside of the range will be encoded with the closest value allowed? Secondly, the floating point value, how many digits of decimals are allowed? Is this intended to fit in an 32-bit or 64-bit floating point representation or something else? 7. Section 5: While this document does not define constraints for audio codecs, there is no reason such constraints should be precluded from definition and registration by other documents. I think this could add that additional media types are also possible. Possible formulation: While this document does not define constraints for audio codecs or any other media types than video, there is no reason such constraints should be precluded from definition and registration by other documents. 8. section 6.2.2: 3. If the "a=rid" line contains a "pt=", the list of payload types is verified against the list of valid payload types for the media section (that is, those listed on the "m=" line). Any PT missing from the "m=" line is removed from the set of valued in the "pt=". This may need handling of the case if the last action results in that the set of PTs in "pt=" becomes empty, then the whole a=rid line needs to be discarded. This as the RID was intended for a limited set of PTs, rather than the default any PT which no "pt=" implies. 9. Section 6.2.2: 5. If the "depend" constraint is included, the answerer MUST make sure that the listed rid-ids unambiguously match the rid-ids in the SDP offer. Any "a=rid" lines that do not are removed. I fail to find a definition of the "depend" constraint in the document. I do find an example using it in addition to the above text. 10. Section 6.4: Note that this matching must be performed semantically rather than on literal PT values, as the remote end may not be using symmetric PTs. For the purpose of this comparison: for each PT listed on the "a=rid" line in the answer, the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" lines in the answer. I am a bit worried that this is still misunderstood to mean that one can do "byte comparison" of the parameters for a PT. The reality of this comparison is after all that you must compare the parameters that are required to be the same between offer and answer. And that is payload format specific. I would suggest that one makes it clear that in many cases this semantically comparison requires payload format understanding. 11. Section 7. Needs to be clarified requirements on being able to determine which rid-identifier that applies to a received RTP stream. So if multiple m= lines are defined and they are not all separate RTP sessions, additional method for determining media description to RTP stream are required. Multi-party also needs to be handled. 12. Section 8.2.3 and 8.2.4: So even if H.264 supports macroblock internal partitions for 4x4 and 8x8 sub-blocks the calculation for the constraints are done on the macroblock sizes that is 16x16 for luminance, see Section 3.78 of H.264 specification. Thus the conversion factor should in both these cases be 256 pixels per MB. https://www.itu.int/rec/T-REC-H.264-201602-I/en (pdf version is free) 13. Section 10: rid-fmt-list = "pt=" fmt *( "," fmt ) ; fmt defined in {{RFC4566}} When I verified the ABNF by running Bill Fenner's parser on it I got the "fmt undefinded". One way of avoiding this is to actually define fmt as prose value, by saying that it is an external reference. fmt = 14. Section 10: "alpah-numeric" is also undefined. And it is not obvious from where this definition is taken. SP and DIGIT are present in RFC5234 and I assume those definitions are to be used. In addition I have to note that if one would use the "alpha-numeric" definition from SDP (RFC4566) then one can't use any of the allowed UTF-8 values from the SDES item in the SDP rid-identifier as the alpha-numeric only support 7-bit ascii characters. 15. Section 10: Discrepancy between SDES item and "rid-identifer". To my understanding there exist no limitations in the SDES item against using space or other separators. Such free form is not supported by current "rid-identifier" definition. This effiects both "rid-syntax" and rid-list constructs. 16. Section 11.2: I understand the desire to have this example is "depend" is defined. However, I do note that this is an simulcast example which you in Section 11 refer to the simulcast document. 17. Section 12.1: I don't think this section manages to hit all of the registration requirements for new SDP attributes: From RFC4566: o contact name, email address, and telephone number o attribute name (as it will appear in SDP) o long-form attribute name in English o type of attribute (session level, media level, or both) o whether the attribute value is subject to the charset attribute o a one-paragraph explanation of the purpose of the attribute o a specification of appropriate attribute values for this attribute I think actually doing this like a form ensures that all is covered. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jul 12 09:27:31 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C652A12D542 for ; Tue, 12 Jul 2016 09:27:29 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com 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 ZZIlXc_nnklB for ; Tue, 12 Jul 2016 09:27:28 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286D312D1E4 for ; Tue, 12 Jul 2016 09:27:28 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id i12so18397141ywa.1 for ; Tue, 12 Jul 2016 09:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sf5/JjTUsZviK/vKEPMBgH5aoZqeT+lPFwH7wFS/ewY=; b=A17oEBZ2T1LNyTUjCdXq8It/9LXHtJYFDwnYPugKBF4+j69ijT1Q0oc/5YoPY9Qe4O m88/iaM+bQnDuTRHfJgFeADMslbm6xISMCyYiAlqCAQ/EKT1UUuccBTwFvzebdbwQMGf iE/EqnOG8V3poaQAEJFPVkCGaS3xPnBUf6NxiFFtPY2/s+zh/5tp14MjvG3qcAZqsNNL J+luD69SnnwamUocC7xMTuUVmJTdJtDdd2Xd1mJ0VCN9Japhv02FYPnoP1LeQCCHq3ZC SJ3+E9a8YLmh5fVoAqU54j2vAZmqqr+sKnkwuhHUZ2fFgCLSu/Y4E7SonPTMFHHlo1JU 5Vqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sf5/JjTUsZviK/vKEPMBgH5aoZqeT+lPFwH7wFS/ewY=; b=G7LQ8TnIH81RGS2DZDN49jEUpkXaStKXN+g7J3YTLikl0Litucd2BrTwM2AFMDQgCn yyU8Srq0ymyOZEWfticnzjkTn1ZN/wR+LvFq2YJGuhxYg5+xZSy5ZNywPzmk1iHJRpOO Pd/g3y0Pmrqi5t3ICrJrzV1Zt0LaOj3kwKx3wyNg1Yv/hqzjGm34VnmwY8hBaTX5iYbn YDCqn6M3TujQENKw70eHlD/mqYhdHZdSEA1ciLVFH4tHUYKsMQxQCZt8ViRlxcVtye1N VK41MwvUr3g+D8Qj3lencNlvOmY5pWpYgD2RQqssVKTn/Y1iRzUB62x5zblM0+TkQQGv EFmw== X-Gm-Message-State: ALyK8tJIEQaEk0qTsjkqPhwZoqOhCvYWqfokjzu2tlIupYE4IaOkcm81BDFGr+Lb9ib1mdMnH9ajThQkLuWhKg== X-Received: by 10.13.255.71 with SMTP id p68mr2362223ywf.101.1468340847518; Tue, 12 Jul 2016 09:27:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.33.213 with HTTP; Tue, 12 Jul 2016 09:27:08 -0700 (PDT) In-Reply-To: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 12 Jul 2016 18:27:08 +0200 Message-ID: To: Peter Thatcher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 16:27:30 -0000 2016-07-11 19:42 GMT+02:00 Peter Thatcher : > Basically what your're asking for is header extension that says "Not only= am > I MID X, but I'm also, temporarily, MID Y"? Why not just have a second, > separate, header extension for "I'm also temporarily MID Y"? Then the > existing semantics of BUNDLE and MID (and RIDs, which are scoped to MIDs) > need not change, but you get the information you need (I think). Agreed. --=20 I=C3=B1aki Baz Castillo From nobody Tue Jul 12 09:42:25 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7301012D56C; Tue, 12 Jul 2016 09:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsq2nS3fP0HM; Tue, 12 Jul 2016 09:42:20 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAEC12D544; Tue, 12 Jul 2016 09:42:20 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u6CGejee000888; Tue, 12 Jul 2016 12:42:19 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 241vjvtvw4-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Jul 2016 12:42:19 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 12 Jul 2016 11:42:18 -0500 From: Jonathan Lennox To: Google-Peter Thatcher Thread-Topic: [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR2KAHglPM/iUn/kOx+O/DTOsKb6AOCHGAgAD7UYCABNYRAIABgXGA Date: Tue, 12 Jul 2016 16:42:17 +0000 Message-ID: <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_3BECBA70B73C4E878A6955AAA406A8B9vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-12_08:2016-07-12,2016-07-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607120149 Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 16:42:23 -0000 --_000_3BECBA70B73C4E878A6955AAA406A8B9vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgMTEsIDIwMTYsIGF0IDE6NDIgUE0sIFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJA Z29vZ2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KQmFzaWNh bGx5IHdoYXQgeW91cidyZSBhc2tpbmcgZm9yIGlzIGhlYWRlciBleHRlbnNpb24gdGhhdCBzYXlz ICJOb3Qgb25seSBhbSBJIE1JRCBYLCBidXQgSSdtIGFsc28sIHRlbXBvcmFyaWx5LCBNSUQgWSI/ ICAgV2h5IG5vdCBqdXN0IGhhdmUgYSBzZWNvbmQsIHNlcGFyYXRlLCBoZWFkZXIgZXh0ZW5zaW9u IGZvciAiSSdtIGFsc28gdGVtcG9yYXJpbHkgTUlEIFkiPyAgIFRoZW4gdGhlIGV4aXN0aW5nIHNl bWFudGljcyBvZiBCVU5ETEUgYW5kIE1JRCAoYW5kIFJJRHMsIHdoaWNoIGFyZSBzY29wZWQgdG8g TUlEcykgbmVlZCBub3QgY2hhbmdlLCBidXQgeW91IGdldCB0aGUgaW5mb3JtYXRpb24geW91IG5l ZWQgKEkgdGhpbmspLg0KDQpUaGUgdGhpbmcgaXMsIGFsbCBNSUQgdmFsdWVzIGFyZSwgY29uY2Vw dHVhbGx5LCB0ZW1wb3Jhcnkg4oCUIHRoZXkgY2FuIGNoYW5nZSBhdCBhbnkgdGltZS4gIFNvIGlz IGl0IHJlYWxseSBtZWFuaW5nZnVsIHRvIGRpc3Rpbmd1aXNoIHNob3J0LXRlcm0gdGVtcG9yYXJ5 IGZyb20gbG9uZy10ZXJtIHRlbXBvcmFyeT8gIFdoZXJlIGRvIHlvdSBkcmF3IHRoZSBsaW5lPw0K DQpPbiBGcmksIEp1bCA4LCAyMDE2IGF0IDg6NTEgQU0sIEpvbmF0aGFuIExlbm5veCA8am9uYXRo YW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PiB3cm90ZToNClRoZSBpbnRl bnRpb24gb2YgbXkgcHJvcG9zYWwgaXMgdGhhdCB0aGVzZSBjb3VsZCBpbmRlZWQgYmUgKHRlbXBv cmFyaWx5KSB0aGUgc2FtZSBSVFAgbWVkaWEgc291cmNlLCBldmVuIHRob3VnaCB0aGV54oCZcmUg dHdvIHNlcGFyYXRlIG0tbGluZXMuDQoNCk9uIEp1bCA3LCAyMDE2LCBhdCA4OjUyIFBNLCBTdWhh cyBOYW5kYWt1bWFyIDxzdWhhc2lldGZAZ21haWwuY29tPG1haWx0bzpzdWhhc2lldGZAZ21haWwu Y29tPj4gd3JvdGU6DQoNCkhpIEpvbmF0aGFuDQoNCiAgQ2xhcmlmaWNhdGlvbiBxdWVzdGlvbiA6 DQoNCiAgIGlmIHdlIGhhdmUgMiBtPWxpbmVzDQoNCm0gPSAuLi4NCmE9bWlkMQ0KPG1hbmFnZXI+ DQoNCm09Li4uDQphPW1pZDINCjxsb3VkZXN0IHNwZWFrZXI+DQoNCmRvZXMgdGhlc2UgMiBjb3Jy ZXNwb25kIHRvIHNhbWUgbWVkaWEgc291cmNlID8gSXQgZmVsdCBzbyBmcm9tIHRoZSBkdXBsaWNh dGUgZGVzaWduIHlvdSBtZW50aW9uZWQgYnV0IHdhbnRlZCB0byBjb25maXJtDQoNClRoYW5rcw0K U3VoYXMNCg0KDQoNCk9uIEZyaSwgSnVsIDgsIDIwMTYgYXQgNDowNiBBTSwgSm9uYXRoYW4gTGVu bm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT4+IHdyb3Rl Og0KSGksIGFsbCDigJQNCg0KKFRoaXMgd2FzIGFuIGlzc3VlIEkgcmFpc2VkIGluIEFWVENPUkUg aW4gQnVlbm9zIEFpcmVzIOKAlCBJIHByb21pc2VkIHRvIHNlbmQgZS1tYWlsIHRvIHRoZSBsaXN0 IGJ1dCBoYWRu4oCZdCByZW1lbWJlcmVkIHRvIGdldCBhcm91bmQgdG8gaXQgdW50aWwgbm93LikN Cg0KV2hlbiBmaW5pc2hpbmcgdXAgdGhlIENMVUUgUlRQIG1hcHBpbmcgZHJhZnQsIEkgcmVhbGl6 ZWQgdGhhdCBvbmUgb2YgQ0xVReKAmXMgUlRQIHJlcXVpcmVtZW50cyBkaWRu4oCZdCBhY3R1YWxs eSBlbmQgdXAgZ2V0dGluZyBzYXRpc2ZpZWQgYnkgQlVORExFICh3aGljaCBpcyB0aGUgc29sdXRp b24gQ0xVRSBjb252ZXJnZWQgb24pLiAgVGhpcyBpc27igJl0IGEgQ0xVRS1zcGVjaWZpYyBpc3N1 ZSwgc28gSeKAmW0gcmFpc2luZyBpdCBoZXJlLg0KDQpUaGUgaXNzdWUgaXMgd2hldGhlciB3ZSB3 YW50IHRvIHN1cHBvcnQgYSB1c2UgY2FzZSwgaW4gQlVORExFLCB3aGVyZSBhIHNpbmdsZSBSVFAg c3RyZWFtIGNvcnJlc3BvbmRzIHRvIG1vcmUgdGhhbiBtZWRpYSBkZXNjcmlwdGlvbiAoYW5kIHRo dXMgaGFzIG1vcmUgdGhhbiBvbmUgTUlEIHZhbHVlKT8NCg0KVGhlIHVzZSBjYXNlIGlzIHdoZXJl IG9uZSBtLWxpbmUgaGFzIGEgc2VtYW50aWMgb2Yg4oCcYWx3YXlzIHZpZXcgdGhpcyBwZXJzb27i gJ0gKG15IGJvc3MsIHNheSwgb3IgbXkgY3VzdG9tZXIpOyBhbmQgYW5vdGhlciBtLWxpbmUgaGFz IGEgc2VtYW50aWMgb2Yg4oCcdGhlIGN1cnJlbnQgbG91ZGVzdCBzcGVha2Vy4oCdLiAoSW4gQ0xV RSwgdGhlc2Ugd291bGQgYmUgYSBzaW5nbGUgY29udGVudCBjYXB0dXJlIGluIHRoZSBmb3JtZXIg Y2FzZSwgYW5kIGEgc3dpdGNoZWQgY2FwdHVyZSBmb3IgdGhlIGxhdHRlci4pICBXaGVuZXZlciB0 aGUgYm9zcyAqaXMqIHRoZSBjdXJyZW50IGxvdWRlc3Qgc3BlYWtlciwgdGhlIHNhbWUgY29udGVu dCB3b3VsZCBiZSBzZW50IGZvciBib3RoIG0tbGluZXMuDQoNCkEgbmFpdmUgaW1wbGVtZW50YXRp b24gd291bGQgc2ltcGx5IGR1cGxpY2F0ZSBhbGwgdGhlIHBhY2tldHMgZm9yIHRoZSB0d28gbS1s aW5lcywgd2l0aCBkaWZmZXJlbnQgTUlEIHZhbHVlcywgYnV0IHRoaXMgaGFzIHR3byBwcm9ibGVt cy4gIEZpcnN0IG9mZiBhbGwsIGl0IG9idmlvdXNseSB3YXN0ZXMgYmFuZHdpZHRoLiAgUG90ZW50 aWFsbHkgbW9yZSBzZXJpb3VzbHksIGl0IHByZWNsdWRlcyBhbnkgUlRQIG1pZGRsZWJveCB0b3Bv bG9neSB3aGljaCBkb2VzbuKAmXQgcmV3cml0ZSBTU1JDIHZhbHVlcywgc2luY2UgdGhlIHNhbWUg Y29udGVudCAoYXJyaXZpbmcgd2l0aCBhIHNpbmdsZSBTU1JDIHZhbHVlIGF0IHRoZSBtaWRkbGVi b3gpIHdvdWxkIG5lZWQgdG8gYmUgc2VudCB3aXRoIHR3byBkaWZmZXJlbnQgU1NSQyB2YWx1ZXMg ZG93biBmcm9tIHRoZSBtaWRkbGVib3guICBJZiBQRVJDIGdvZXMgd2l0aCBpdHMgY3VycmVudCBj b25zZW5zdXMgb2Ygbm8gU1NSQyByZXdyaXRpbmcsIHRoaXMgd2lsbCBwYXJ0aWN1bGFybHkgYmUg YSBwcm9ibGVtIGZvciBQRVJDLg0KDQpJIGNlcnRhaW5seSBkb27igJl0IHRoaW5rIHRoaXMgaXMg c29tZXRoaW5nIHRoYXQgc2hvdWxkIGJsb2NrIEJVTkRMReKAmXMgY29tcGxldGlvbiwgYnV0IEkg dGhpbmsgaXQgY291bGQgYmUgYSBwcmV0dHkgZWFzeSBleHRlbnNpb24uDQoNCihNeSBpbml0aWFs IGRlc2lnbiBwcm9wb3NhbCB3YXMgdG8gYWxsb3cgbXVsdGlwbGUgU0RFUyB2YWx1ZXMgb2YgdGhl IHNhbWUgdHlwZSwgYW5kIG11bHRpcGxlIFNERVMgaGVhZGVyIGV4dGVuc2lvbnMgaXRlbXMgb2Yg dGhlIHNhbWUgdHlwZSwgdG8gYmUgc2VudCBzaW11bHRhbmVvdXNseSBpbiBSVFAg4oCUIHByb3Rv Y29sLXN5bnRhY3RpY2FsbHkgdGhpcyBpcyB0cml2aWFsLCB5b3XigJlkIGp1c3QgbmVlZCB0byBu ZWdvdGlhdGUgdGhhdCB5b3Ugc3VwcG9ydCBpdC4gIEJ1dCBJ4oCZbSBub3Qgd2VkZGVkIHRvIHRo aXMgc29sdXRpb24uKQ0KDQpXaGF0IGRvIHBlb3BsZSB0aGluayDigJQgaXMgdGhpcyB3b3J0aCB3 b3JraW5nIG9uPyAgSXMgdGhlcmUgaW50ZXJlc3QgaW4gZGlzY3Vzc2luZyBpdCBpbiBCZXJsaW4s IGFuZCBpZiBzbywgaW4gd2hhdCB2ZW51ZT8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8 bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzpt bXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21t dXNpYw0KDQoNCg0K --_000_3BECBA70B73C4E878A6955AAA406A8B9vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0748E792C75BA6448AAEE6F2A0656848@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwg MTEsIDIwMTYsIGF0IDE6NDIgUE0sIFBldGVyIFRoYXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86 cHRoYXRjaGVyQGdvb2dsZS5jb20iIGNsYXNzPSIiPnB0aGF0Y2hlckBnb29nbGUuY29tPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm Ij5CYXNpY2FsbHkgd2hhdCB5b3VyJ3JlIGFza2luZyBmb3IgaXMgaGVhZGVyIGV4dGVuc2lvbiB0 aGF0IHNheXMgJnF1b3Q7Tm90IG9ubHkgYW0gSSBNSUQgWCwgYnV0IEknbSBhbHNvLCB0ZW1wb3Jh cmlseSwgTUlEIFkmcXVvdDs/ICZuYnNwOyBXaHkgbm90IGp1c3QgaGF2ZSBhIHNlY29uZCwgc2Vw YXJhdGUsIGhlYWRlciBleHRlbnNpb24gZm9yICZxdW90O0knbQ0KIGFsc28gdGVtcG9yYXJpbHkg TUlEIFkmcXVvdDs/ICZuYnNwOyBUaGVuIHRoZSBleGlzdGluZyBzZW1hbnRpY3Mgb2YgQlVORExF IGFuZCBNSUQgKGFuZCBSSURzLCB3aGljaCBhcmUgc2NvcGVkIHRvIE1JRHMpIG5lZWQgbm90IGNo YW5nZSwgYnV0IHlvdSBnZXQgdGhlIGluZm9ybWF0aW9uIHlvdSBuZWVkIChJIHRoaW5rKS48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5UaGUgdGhpbmcgaXMsIGFsbCBNSUQgdmFsdWVzIGFyZSwgY29uY2VwdHVhbGx5 LCB0ZW1wb3Jhcnkg4oCUIHRoZXkgY2FuIGNoYW5nZSBhdCBhbnkgdGltZS4gJm5ic3A7U28gaXMg aXQgcmVhbGx5IG1lYW5pbmdmdWwgdG8gZGlzdGluZ3Vpc2ggc2hvcnQtdGVybSB0ZW1wb3Jhcnkg ZnJvbSBsb25nLXRlcm0gdGVtcG9yYXJ5PyAmbmJzcDtXaGVyZSBkbyB5b3UgZHJhdyB0aGUgbGlu ZT88L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBGcmksIEp1bCA4LCAyMDE2IGF0IDg6NTEgQU0sIEpvbmF0aGFuIExl bm5veCA8c3BhbiBkaXI9Imx0ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmpvbmF0 aGFuQHZpZHlvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmpvbmF0aGFuQHZpZHlvLmNv bTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13 b3JkIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+VGhlIGludGVudGlvbiBvZiBteSBwcm9wb3Nh bCBpcyB0aGF0IHRoZXNlIGNvdWxkIGluZGVlZCBiZSAodGVtcG9yYXJpbHkpIHRoZSBzYW1lIFJU UCBtZWRpYSBzb3VyY2UsIGV2ZW4gdGhvdWdoIHRoZXnigJlyZSB0d28gc2VwYXJhdGUgbS1saW5l cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5PbiBKdWwgNywgMjAxNiwgYXQgODo1MiBQTSwgU3VoYXMgTmFuZGFrdW1hciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj5zdWhhc2lldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGkgSm9uYXRoYW4m bmJzcDsNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PiZuYnNwOyBDbGFyaWZpY2F0aW9uIHF1ZXN0aW9uIDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtpZiB3ZSBoYXZl IDIgbT1saW5lczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPm0gPSAuLi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YT1taWQxPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPiZsdDttYW5hZ2VyJmd0OzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+bT0uLi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YT1t aWQyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZsdDtsb3VkZXN0IHNwZWFrZXImZ3Q7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5kb2VzIHRo ZXNlIDIgY29ycmVzcG9uZCB0byBzYW1lIG1lZGlhIHNvdXJjZSA/IEl0IGZlbHQgc28gZnJvbSB0 aGUgZHVwbGljYXRlIGRlc2lnbiB5b3UgbWVudGlvbmVkIGJ1dCB3YW50ZWQgdG8gY29uZmlybTwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ VGhhbmtzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlN1aGFzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gRnJpLCBKdWwgOCwgMjAxNiBhdCA0OjA2IEFNLCBKb25hdGhhbiBM ZW5ub3ggPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpqb25h dGhhbkB2aWR5by5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5qb25hdGhhbkB2aWR5by5j b208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpIaSwgYWxsIOKAlDxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCihUaGlzIHdhcyBhbiBpc3N1ZSBJIHJhaXNlZCBpbiBBVlRDT1JFIGluIEJ1 ZW5vcyBBaXJlcyDigJQgSSBwcm9taXNlZCB0byBzZW5kIGUtbWFpbCB0byB0aGUgbGlzdCBidXQg aGFkbuKAmXQgcmVtZW1iZXJlZCB0byBnZXQgYXJvdW5kIHRvIGl0IHVudGlsIG5vdy4pPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2hlbiBmaW5pc2hpbmcgdXAgdGhlIENMVUUgUlRQIG1h cHBpbmcgZHJhZnQsIEkgcmVhbGl6ZWQgdGhhdCBvbmUgb2YgQ0xVReKAmXMgUlRQIHJlcXVpcmVt ZW50cyBkaWRu4oCZdCBhY3R1YWxseSBlbmQgdXAgZ2V0dGluZyBzYXRpc2ZpZWQgYnkgQlVORExF ICh3aGljaCBpcyB0aGUgc29sdXRpb24gQ0xVRSBjb252ZXJnZWQgb24pLiZuYnNwOyBUaGlzIGlz buKAmXQgYSBDTFVFLXNwZWNpZmljIGlzc3VlLCBzbyBJ4oCZbSByYWlzaW5nIGl0IGhlcmUuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIGlzc3VlIGlzIHdoZXRoZXIgd2Ugd2FudCB0 byBzdXBwb3J0IGEgdXNlIGNhc2UsIGluIEJVTkRMRSwgd2hlcmUgYSBzaW5nbGUgUlRQIHN0cmVh bSBjb3JyZXNwb25kcyB0byBtb3JlIHRoYW4gbWVkaWEgZGVzY3JpcHRpb24gKGFuZCB0aHVzIGhh cyBtb3JlIHRoYW4gb25lIE1JRCB2YWx1ZSk/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K VGhlIHVzZSBjYXNlIGlzIHdoZXJlIG9uZSBtLWxpbmUgaGFzIGEgc2VtYW50aWMgb2Yg4oCcYWx3 YXlzIHZpZXcgdGhpcyBwZXJzb27igJ0gKG15IGJvc3MsIHNheSwgb3IgbXkgY3VzdG9tZXIpOyBh bmQgYW5vdGhlciBtLWxpbmUgaGFzIGEgc2VtYW50aWMgb2Yg4oCcdGhlIGN1cnJlbnQgbG91ZGVz dCBzcGVha2Vy4oCdLiAoSW4gQ0xVRSwgdGhlc2Ugd291bGQgYmUgYSBzaW5nbGUgY29udGVudCBj YXB0dXJlIGluIHRoZSBmb3JtZXIgY2FzZSwgYW5kIGEgc3dpdGNoZWQNCiBjYXB0dXJlIGZvciB0 aGUgbGF0dGVyLikmbmJzcDsgV2hlbmV2ZXIgdGhlIGJvc3MgKmlzKiB0aGUgY3VycmVudCBsb3Vk ZXN0IHNwZWFrZXIsIHRoZSBzYW1lIGNvbnRlbnQgd291bGQgYmUgc2VudCBmb3IgYm90aCBtLWxp bmVzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkEgbmFpdmUgaW1wbGVtZW50YXRpb24g d291bGQgc2ltcGx5IGR1cGxpY2F0ZSBhbGwgdGhlIHBhY2tldHMgZm9yIHRoZSB0d28gbS1saW5l cywgd2l0aCBkaWZmZXJlbnQgTUlEIHZhbHVlcywgYnV0IHRoaXMgaGFzIHR3byBwcm9ibGVtcy4m bmJzcDsgRmlyc3Qgb2ZmIGFsbCwgaXQgb2J2aW91c2x5IHdhc3RlcyBiYW5kd2lkdGguJm5ic3A7 IFBvdGVudGlhbGx5IG1vcmUgc2VyaW91c2x5LCBpdCBwcmVjbHVkZXMgYW55IFJUUCBtaWRkbGVi b3ggdG9wb2xvZ3kgd2hpY2gNCiBkb2VzbuKAmXQgcmV3cml0ZSBTU1JDIHZhbHVlcywgc2luY2Ug dGhlIHNhbWUgY29udGVudCAoYXJyaXZpbmcgd2l0aCBhIHNpbmdsZSBTU1JDIHZhbHVlIGF0IHRo ZSBtaWRkbGVib3gpIHdvdWxkIG5lZWQgdG8gYmUgc2VudCB3aXRoIHR3byBkaWZmZXJlbnQgU1NS QyB2YWx1ZXMgZG93biBmcm9tIHRoZSBtaWRkbGVib3guJm5ic3A7IElmIFBFUkMgZ29lcyB3aXRo IGl0cyBjdXJyZW50IGNvbnNlbnN1cyBvZiBubyBTU1JDIHJld3JpdGluZywgdGhpcyB3aWxsDQog cGFydGljdWxhcmx5IGJlIGEgcHJvYmxlbSBmb3IgUEVSQy48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpJIGNlcnRhaW5seSBkb27igJl0IHRoaW5rIHRoaXMgaXMgc29tZXRoaW5nIHRoYXQg c2hvdWxkIGJsb2NrIEJVTkRMReKAmXMgY29tcGxldGlvbiwgYnV0IEkgdGhpbmsgaXQgY291bGQg YmUgYSBwcmV0dHkgZWFzeSBleHRlbnNpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K KE15IGluaXRpYWwgZGVzaWduIHByb3Bvc2FsIHdhcyB0byBhbGxvdyBtdWx0aXBsZSBTREVTIHZh bHVlcyBvZiB0aGUgc2FtZSB0eXBlLCBhbmQgbXVsdGlwbGUgU0RFUyBoZWFkZXIgZXh0ZW5zaW9u cyBpdGVtcyBvZiB0aGUgc2FtZSB0eXBlLCB0byBiZSBzZW50IHNpbXVsdGFuZW91c2x5IGluIFJU UCDigJQgcHJvdG9jb2wtc3ludGFjdGljYWxseSB0aGlzIGlzIHRyaXZpYWwsIHlvdeKAmWQganVz dCBuZWVkIHRvIG5lZ290aWF0ZSB0aGF0IHlvdSBzdXBwb3J0DQogaXQuJm5ic3A7IEJ1dCBJ4oCZ bSBub3Qgd2VkZGVkIHRvIHRoaXMgc29sdXRpb24uKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCldoYXQgZG8gcGVvcGxlIHRoaW5rIOKAlCBpcyB0aGlzIHdvcnRoIHdvcmtpbmcgb24/Jm5i c3A7IElzIHRoZXJlIGludGVyZXN0IGluIGRpc2N1c3NpbmcgaXQgaW4gQmVybGluLCBhbmQgaWYg c28sIGluIHdoYXQgdmVudWU/PGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQptbXVzaWMgbWFpbGluZyBsaXN0 PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0i Ij4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bW11 c2ljQGlldGYub3JnIiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHJl bD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3BECBA70B73C4E878A6955AAA406A8B9vidyocom_-- From nobody Tue Jul 12 15:00:06 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618A212D613; Tue, 12 Jul 2016 15:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zu7IlW6Boi6; Tue, 12 Jul 2016 15:00:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4319612D605; Tue, 12 Jul 2016 15:00:02 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6CLxtO6094346 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 12 Jul 2016 16:59:55 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: IESG Date: Tue, 12 Jul 2016 16:59:55 -0500 Message-ID: MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-mmusic-msid.all@ietf.org, mmusic Subject: [MMUSIC] Approved: draft-ietf-mmusic-msid-15 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 22:00:03 -0000 Hi IESG Secretary (bcc'd) draft-ietf-mmusic-msid-15 is approved. There are no RFC editor notes. Thanks! Ben. From nobody Tue Jul 12 16:18:05 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CC612DB01; Tue, 12 Jul 2016 16:18:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160712231800.8797.36093.idtracker@ietfa.amsl.com> Date: Tue, 12 Jul 2016 16:18:00 -0700 Archived-At: Cc: ben@nostrum.com, mmusic@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, draft-ietf-mmusic-msid@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [MMUSIC] Protocol Action: 'WebRTC MediaStream Identification in the Session Description Protocol' to Proposed Standard (draft-ietf-mmusic-msid-15.txt) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 23:18:00 -0000 The IESG has approved the following document: - 'WebRTC MediaStream Identification in the Session Description Protocol' (draft-ietf-mmusic-msid-15.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/ Technical Summary This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. Working Group Summary The document has undergone a number of revisions. Originally, it was believed the mechansim was more generally applicable than WebRTC. As the work progressed, the general applicability became increasingly unclear and a resulting reduction in scope and significant simplication resulted. The WG is fully supportive of this. Document Quality Chrome implements an earlier version of the specification and is committed to implementing the specified version at a later stage. There are no special reviewers or other expert reviews of the document. Personnel Flemming Andreasen is the document shepherd and Ben Campbell is the responsible Area Director From nobody Tue Jul 12 17:39:49 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FBD12D5C7 for ; Tue, 12 Jul 2016 17:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com 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 vF0vJGdxrb4n for ; Tue, 12 Jul 2016 17:39:45 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3742912D5F2 for ; Tue, 12 Jul 2016 17:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BGCwcwtve0+vrMLWRXXaUWS2i56+RdoKwuvUz6IEyjs=; b=C1ZK3kKMZFNmkbRrFxxgmwJIq2 BhsQICNPb1ki5lxIM43vAziNe2y8dMtPYkz5WZ7OPdahn62vkOZjOXFQjpjK1kWmO7HUc3DgxFu9n PVukEXZR94+bjxVHbLutClZPWs1S6NuvmYjaXgcIWCgpsvJhHtq1q4UPnxK+Si6y8gufS3hbmJLpF vqS72m5wzlxTUUkKrS2S2n5nZ3xT+U6HLLe8tRjZcsAkK9qUpD6x2MZsJWhDqEyUKH6boPD4DcTAX phAQoeNqXQqeg/SGDaR2/0t9pqdTnWD4l53GwFwfmbmFaMkUknelz11A0Nideip0yxO2QJFRABmDf CWp7W1gA==; Received: from ppp118-209-27-150.lns20.mel4.internode.on.net ([118.209.27.150]:50158 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bN8DG-000EC9-3Z for mmusic@ietf.org; Wed, 13 Jul 2016 10:39:42 +1000 To: mmusic@ietf.org References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> From: Christian Groves Message-ID: <65a37f2d-7674-c05f-d732-95af17a08e09@nteczone.com> Date: Wed, 13 Jul 2016 10:39:37 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 00:39:48 -0000 I agree for CLUE the RTP sender doesn't really know how long it will be sending the two MIDs for. Its the peer endpoint that initiates a CLUE configure that results in a particular RTP stream/s being sent. You could have a situations where more than two RTP streams could be sent. E.g. Capture 1: See Boss, Capture 2: See active speaker, Capture 3: 2nd previous speaker Capture 4: 3rd previous speaker. Where the boss is the active and 3rd previous speaker. So I don't think you can limit the use to two MIDs. It seems like allowing multiple MIDs is a reasonable solution. Christian On 13/07/2016 2:42 AM, Jonathan Lennox wrote: > >> On Jul 11, 2016, at 1:42 PM, Peter Thatcher > > wrote: >> >> Basically what your're asking for is header extension that says "Not >> only am I MID X, but I'm also, temporarily, MID Y"? Why not just >> have a second, separate, header extension for "I'm also temporarily >> MID Y"? Then the existing semantics of BUNDLE and MID (and RIDs, >> which are scoped to MIDs) need not change, but you get the >> information you need (I think). > > The thing is, all MID values are, conceptually, temporary — they can > change at any time. So is it really meaningful to distinguish > short-term temporary from long-term temporary? Where do you draw the > line? > >> On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox > > wrote: >> >> The intention of my proposal is that these could indeed be >> (temporarily) the same RTP media source, even though they’re two >> separate m-lines. >> >>> On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar >>> > wrote: >>> >>> Hi Jonathan >>> >>> Clarification question : >>> >>> if we have 2 m=lines >>> m = ... >>> a=mid1 >>> >>> >>> m=... >>> a=mid2 >>> >>> >>> does these 2 correspond to same media source ? It felt so from >>> the duplicate design you mentioned but wanted to confirm >>> >>> Thanks >>> Suhas >>> >>> >>> On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox >>> > wrote: >>> >>> Hi, all — >>> >>> (This was an issue I raised in AVTCORE in Buenos Aires — I >>> promised to send e-mail to the list but hadn’t remembered to >>> get around to it until now.) >>> >>> When finishing up the CLUE RTP mapping draft, I realized >>> that one of CLUE’s RTP requirements didn’t actually end up >>> getting satisfied by BUNDLE (which is the solution CLUE >>> converged on). This isn’t a CLUE-specific issue, so I’m >>> raising it here. >>> >>> The issue is whether we want to support a use case, in >>> BUNDLE, where a single RTP stream corresponds to more than >>> media description (and thus has more than one MID value)? >>> >>> The use case is where one m-line has a semantic of “always >>> view this person” (my boss, say, or my customer); and >>> another m-line has a semantic of “the current loudest >>> speaker”. (In CLUE, these would be a single content capture >>> in the former case, and a switched capture for the latter.) >>> Whenever the boss *is* the current loudest speaker, the same >>> content would be sent for both m-lines. >>> >>> A naive implementation would simply duplicate all the >>> packets for the two m-lines, with different MID values, but >>> this has two problems. First off all, it obviously wastes >>> bandwidth. Potentially more seriously, it precludes any RTP >>> middlebox topology which doesn’t rewrite SSRC values, since >>> the same content (arriving with a single SSRC value at the >>> middlebox) would need to be sent with two different SSRC >>> values down from the middlebox. If PERC goes with its >>> current consensus of no SSRC rewriting, this will >>> particularly be a problem for PERC. >>> >>> I certainly don’t think this is something that should block >>> BUNDLE’s completion, but I think it could be a pretty easy >>> extension. >>> >>> (My initial design proposal was to allow multiple SDES >>> values of the same type, and multiple SDES header extensions >>> items of the same type, to be sent simultaneously in RTP — >>> protocol-syntactically this is trivial, you’d just need to >>> negotiate that you support it. But I’m not wedded to this >>> solution.) >>> >>> What do people think — is this worth working on? Is there >>> interest in discussing it in Berlin, and if so, in what venue? >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Jul 13 00:20:34 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0237812DB2A; Wed, 13 Jul 2016 00:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLMEhsazrbmB; Wed, 13 Jul 2016 00:20:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB6F12D0C3; Wed, 13 Jul 2016 00:20:26 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-a2-5785ebb82415 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 83.84.27088.8BBE5875; Wed, 13 Jul 2016 09:20:24 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 09:20:24 +0200 From: Christer Holmberg To: Jonathan Lennox , Google-Peter Thatcher Thread-Topic: [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3FxhgzJSzoB0jUaPyXYYF7JSKaAWB0OA Date: Wed, 13 Jul 2016 07:20:23 +0000 Message-ID: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> In-Reply-To: <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D3ABBD5FBD61christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyM2K7se6O163hBksOalq87FnJbrF/8Xlm i6nLH7NYXFv+mtWBxWPBplKPJUt+Mnm0PbvDHsAcxWWTkpqTWZZapG+XwJVx6kEzU8GrBsaK eV2n2BoYj+V0MXJySAiYSCw4380IYYtJXLi3nq2LkYtDSOAIo8TzuceYIJzFjBKH/k4Ccjg4 2AQsJLr/aYM0iAhESJxpfcMMYjML2EjsXX+LFcQWFnCUeD5/BxtEjZNE/7MWZgjbSOL7vJVg NSwCqhI7vvWA1fAKWEks2nmNFWLXBiaJRXsegl3EKWArcfXLNCYQmxHouu+n1jBBLBOXuPVk PhPE1QISS/acZ4awRSVePv4HtkBUQE/i+9fZUHFFiZ1n26EOjZfYuvUd1GJBiZMzn7BMYBSb hWTsLCRls5CUQcQNJN6fm88MYWtLLFv4GsrWl9j45SwjhG0tcfn+LRQ1Cxg5VjGKFqcWJ+Wm GxnppRZlJhcX5+fp5aWWbGIExu/BLb8NdjC+fO54iFGAg1GJh1fBoDVciDWxrLgy9xCjBAez kgivNDD6hXhTEiurUovy44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgskycXBKNTA2 S1wraip+5xds1/h9serG+ytO3DOab7f7dtxaRpfAreVSokzL+1Oz9vFLpuW49lbyxyzYcZ9r DmtoC2++wqbepoPmoZrWNb2n+Jc8L0taNMlu6mOPMJuyReJpmlwzjDNMnQ7bGNTu0dj7Q0G/ IGPl/vQX3c9rxfIft5+4ll3rtsF/ZotXmBJLcUaioRZzUXEiAD8vAmHbAgAA Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 07:20:31 -0000 --_000_D3ABBD5FBD61christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, A few questions: Q1: If an RTP packet is associated with two or more m- lines, which codecs payl= oad type values, SSRC values should it use? Can it pick from any of the ass= ociated m- lines, or does one of the MIDs have to be the =93primary=94, whi= le the others are =93secondary=94, =93temporary=94, or whatever we want to = call them=85 Q2: Currently, draft-bundle says: "The RTP MID header extension SHOULD be included in some RTP packets at the start of the session and whenever the SSRC changes." Now, when the =93loudest speaker=94 changes, the SSRC does not change (at l= east not the SSRC of the =93boss=94). But, there must still be a =93I am no= longer also MID Y=94 indication. At the same time, if the =93loudest speaker=94 is now associated with anoth= er m- line (e.g. =93secretary=94), there must not be an indication that the= =93secretary=94 MID and =93loudest speaker=94 MID are associated. Regards, Christer From: mmusic > on b= ehalf of Jonathan Lennox > Date: Tuesday 12 July 2016 at 19:42 To: "pthatcher@google.com" > Cc: "avt@ietf.org" >= , "mmusic@ietf.org" > Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? On Jul 11, 2016, at 1:42 PM, Peter Thatcher > wrote: Basically what your're asking for is header extension that says "Not only a= m I MID X, but I'm also, temporarily, MID Y"? Why not just have a second,= separate, header extension for "I'm also temporarily MID Y"? Then the ex= isting semantics of BUNDLE and MID (and RIDs, which are scoped to MIDs) nee= d not change, but you get the information you need (I think). The thing is, all MID values are, conceptually, temporary =97 they can chan= ge at any time. So is it really meaningful to distinguish short-term tempo= rary from long-term temporary? Where do you draw the line? On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox > wrote: The intention of my proposal is that these could indeed be (temporarily) th= e same RTP media source, even though they=92re two separate m-lines. On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar > wrote: Hi Jonathan Clarification question : if we have 2 m=3Dlines m =3D ... a=3Dmid1 m=3D... a=3Dmid2 does these 2 correspond to same media source ? It felt so from the duplicat= e design you mentioned but wanted to confirm Thanks Suhas On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox > wrote: Hi, all =97 (This was an issue I raised in AVTCORE in Buenos Aires =97 I promised to se= nd e-mail to the list but hadn=92t remembered to get around to it until now= .) When finishing up the CLUE RTP mapping draft, I realized that one of CLUE= =92s RTP requirements didn=92t actually end up getting satisfied by BUNDLE = (which is the solution CLUE converged on). This isn=92t a CLUE-specific is= sue, so I=92m raising it here. The issue is whether we want to support a use case, in BUNDLE, where a sing= le RTP stream corresponds to more than media description (and thus has more= than one MID value)? The use case is where one m-line has a semantic of =93always view this pers= on=94 (my boss, say, or my customer); and another m-line has a semantic of = =93the current loudest speaker=94. (In CLUE, these would be a single conten= t capture in the former case, and a switched capture for the latter.) When= ever the boss *is* the current loudest speaker, the same content would be s= ent for both m-lines. A naive implementation would simply duplicate all the packets for the two m= -lines, with different MID values, but this has two problems. First off al= l, it obviously wastes bandwidth. Potentially more seriously, it precludes= any RTP middlebox topology which doesn=92t rewrite SSRC values, since the = same content (arriving with a single SSRC value at the middlebox) would nee= d to be sent with two different SSRC values down from the middlebox. If PE= RC goes with its current consensus of no SSRC rewriting, this will particul= arly be a problem for PERC. I certainly don=92t think this is something that should block BUNDLE=92s co= mpletion, but I think it could be a pretty easy extension. (My initial design proposal was to allow multiple SDES values of the same t= ype, and multiple SDES header extensions items of the same type, to be sent= simultaneously in RTP =97 protocol-syntactically this is trivial, you=92d = just need to negotiate that you support it. But I=92m not wedded to this s= olution.) What do people think =97 is this worth working on? Is there interest in di= scussing it in Berlin, and if so, in what venue? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D3ABBD5FBD61christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

A few questions:


Q1:

If an RTP packet is associated with two or more m- lines, which codecs= payload type values, SSRC values should it use? Can it pick from any of th= e associated m- lines, or does one of the MIDs have to be the =93primary=94= , while the others are =93secondary=94, =93temporary=94, or whatever we want to call them=85


Q2:

Currently, draft-bundle says:
   "The RTP MID header extension SHOULD be =
included in some RTP packets
   at the start of the session and whenever the SSRC changes."
Now, when the =93loudest speaker=94 changes, the SSRC does not change = (at least not the SSRC of the =93boss=94). But, there must still be a =93I = am no longer also MID Y=94 indication.

At the same time, if the =93loudest speaker=94 is now associated with = another m- line (e.g. =93secretary=94), there must not be an indication tha= t the =93secretary=94 MID and =93loudest speaker=94 MID are associated.

Regards,

Christer













From: mmusic <mmusic-bounces@ietf.org> on behalf of Jonat= han Lennox <jonathan@vidyo.com= >
Date: Tuesday 12 July 2016 at 19:42=
To: "pthatcher@google.com" <pthatcher@google.com>
Cc: "avt@ietf.org" <avt@ietf.= org>, "mmusic@ietf.org&q= uot; <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE: a sin= gle stream with multiple MIDs?


On Jul 11, 2016, at 1:42 PM, Peter Thatcher <pthatcher@google.com> wrote:=

Basically what your're asking for is header extension that says "No= t only am I MID X, but I'm also, temporarily, MID Y"?   Why not j= ust have a second, separate, header extension for "I'm also temporarily MID Y"?   Then the existing semantics of BUNDLE= and MID (and RIDs, which are scoped to MIDs) need not change, but you get = the information you need (I think).

The thing is, all MID values are, conceptually, temporary =97 they can= change at any time.  So is it really meaningful to distinguish short-= term temporary from long-term temporary?  Where do you draw the line?<= /div>
On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox = <jona= than@vidyo.com> wrote:
The intention of my proposal is that these could indeed be = (temporarily) the same RTP media source, even though they=92re two separate= m-lines.

On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar <suhasietf@gmail.c= om> wrote:

Hi Jonathan 

  Clarification question :

   if we have 2 m=3Dlines
   
m =3D ...
a=3Dmid1
<manager>

m=3D...
a=3Dmid2
<loudest speaker>

does these 2 correspond to same media source ? It felt so f= rom the duplicate design you mentioned but wanted to confirm

Thanks
Suhas

   

On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox = <jona= than@vidyo.com> wrote:
Hi, all =97

(This was an issue I raised in AVTCORE in Buenos Aires =97 I promised to se= nd e-mail to the list but hadn=92t remembered to get around to it until now= .)

When finishing up the CLUE RTP mapping draft, I realized that one of CLUE= =92s RTP requirements didn=92t actually end up getting satisfied by BUNDLE = (which is the solution CLUE converged on).  This isn=92t a CLUE-specif= ic issue, so I=92m raising it here.

The issue is whether we want to support a use case, in BUNDLE, where a sing= le RTP stream corresponds to more than media description (and thus has more= than one MID value)?

The use case is where one m-line has a semantic of =93always view this pers= on=94 (my boss, say, or my customer); and another m-line has a semantic of = =93the current loudest speaker=94. (In CLUE, these would be a single conten= t capture in the former case, and a switched capture for the latter.)  Whenever the boss *is* the current loudest = speaker, the same content would be sent for both m-lines.

A naive implementation would simply duplicate all the packets for the two m= -lines, with different MID values, but this has two problems.  First o= ff all, it obviously wastes bandwidth.  Potentially more seriously, it= precludes any RTP middlebox topology which doesn=92t rewrite SSRC values, since the same content (arriving with a sin= gle SSRC value at the middlebox) would need to be sent with two different S= SRC values down from the middlebox.  If PERC goes with its current con= sensus of no SSRC rewriting, this will particularly be a problem for PERC.

I certainly don=92t think this is something that should block BUNDLE=92s co= mpletion, but I think it could be a pretty easy extension.

(My initial design proposal was to allow multiple SDES values of the same t= ype, and multiple SDES header extensions items of the same type, to be sent= simultaneously in RTP =97 protocol-syntactically this is trivial, you=92d = just need to negotiate that you support it.  But I=92m not wedded to this solution.)

What do people think =97 is this worth working on?  Is there interest = in discussing it in Berlin, and if so, in what venue?
_______________________________________________
mmusic mailing list
mmusic@ietf= .org
https://www.ietf.org/mailman/listinfo/mmusic<= /a>



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic<= /a>



--_000_D3ABBD5FBD61christerholmbergericssoncom_-- From nobody Wed Jul 13 00:24:13 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B300812DB7C; Wed, 13 Jul 2016 00:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh2UKsMKMZ3z; Wed, 13 Jul 2016 00:24:07 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D9D12D0C3; Wed, 13 Jul 2016 00:24:06 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-1e-5785ec94e055 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A2.77.18043.49CE5875; Wed, 13 Jul 2016 09:24:04 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 09:24:03 +0200 From: Christer Holmberg To: Jonathan Lennox , IETF AVTCore WG , mmusic Thread-Topic: [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3NeIgzJSzoB0jUaPyXYYF7JSKQ== Date: Wed, 13 Jul 2016 07:24:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <56EEFDF4793D0A418628BC1DF650C9C8@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdXnfKm9Zwg2+LtCxe9qxkt9i/+Dyz xdTlj1kcmD2WLPnJ5NH27A57AFMUl01Kak5mWWqRvl0CV8aDzlvMBZNFK5YuuMrawDhNsIuR g0NCwETiwmfdLkZOIFNM4sK99WxdjFwcQgJHGCWOHbnIDpIQEljMKHHgnDhIPZuAhUT3P22Q sIhAikTH+7lgJcICjhLP5+9gg4g7SfQ/a2GGsPUkpvUsZQGxWQRUJU5Mu88KYvMKWEmc2H2e CcRmBNr7/dQaMJtZQFzi1pP5TBD3CEgs2XOeGcIWlXj5+B9YryjQzO9fZzNDnK8kMW1rGkSr gcT7c/OZIWxriYZp09ghbG2JZQtfM0OsFZQ4OfMJywRG0VlIts1C0j4LSfssJO2zkLQvYGRd xShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYQwe3/LbawXjwueMhRgEORiUeXgWD1nAh1sSy 4srcQ4wSHMxKIrzSr4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbB ZJk4OKUaGG0vRb2UVthlcmr6hhnxZ5+sWJ+6Y+b++ZKLJmsbR148MPG6TFRW3/9edp/rLH1v vZLPbZl45cvCBHFHocr7AVUTDlpsuaZuH+4tJ7jrTuiRG+FCbjsX1MznWZSWu124tGvtH4XP Z7MilqgdWpa0dpp9F6fIRbn/X96fUbs2c/rN5VqbMi8fe39ciaU4I9FQi7moOBEAkgGkuZ0C AAA= Archived-At: Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 07:24:08 -0000 Hi, I assume this would only work for bundled m- lines, right? If the =B3boss=B2 and =B3loudest speaker=B2 m- lines are non-bundled, both = RTP streams would be sent even if they are identical, or? Regards, Christer On 08/07/16 01:36, "mmusic on behalf of Jonathan Lennox" wrote: >Hi, all =8B > >(This was an issue I raised in AVTCORE in Buenos Aires =8B I promised to >send e-mail to the list but hadn=B9t remembered to get around to it until >now.) > >When finishing up the CLUE RTP mapping draft, I realized that one of >CLUE=B9s RTP requirements didn=B9t actually end up getting satisfied by >BUNDLE (which is the solution CLUE converged on). This isn=B9t a >CLUE-specific issue, so I=B9m raising it here. > >The issue is whether we want to support a use case, in BUNDLE, where a >single RTP stream corresponds to more than media description (and thus >has more than one MID value)? > >The use case is where one m-line has a semantic of =B3always view this >person=B2 (my boss, say, or my customer); and another m-line has a semanti= c >of =B3the current loudest speaker=B2. (In CLUE, these would be a single >content capture in the former case, and a switched capture for the >latter.) Whenever the boss *is* the current loudest speaker, the same >content would be sent for both m-lines. > >A naive implementation would simply duplicate all the packets for the two >m-lines, with different MID values, but this has two problems. First off >all, it obviously wastes bandwidth. Potentially more seriously, it >precludes any RTP middlebox topology which doesn=B9t rewrite SSRC values, >since the same content (arriving with a single SSRC value at the >middlebox) would need to be sent with two different SSRC values down from >the middlebox. If PERC goes with its current consensus of no SSRC >rewriting, this will particularly be a problem for PERC. > >I certainly don=B9t think this is something that should block BUNDLE=B9s >completion, but I think it could be a pretty easy extension. > >(My initial design proposal was to allow multiple SDES values of the same >type, and multiple SDES header extensions items of the same type, to be >sent simultaneously in RTP =8B protocol-syntactically this is trivial, >you=B9d just need to negotiate that you support it. But I=B9m not wedded = to >this solution.) > >What do people think =8B is this worth working on? Is there interest in >discussing it in Berlin, and if so, in what venue? >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Jul 13 01:55:23 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9219112B00A for ; Wed, 13 Jul 2016 01:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com 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 3tJT44kpaOed for ; Wed, 13 Jul 2016 01:55:16 -0700 (PDT) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com [209.85.161.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8949412D69A for ; Wed, 13 Jul 2016 01:55:15 -0700 (PDT) Received: by mail-yw0-f178.google.com with SMTP id j17so37598718ywg.0 for ; Wed, 13 Jul 2016 01:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+t45jW5fzH3QGGggCvqOCmPLSRtesRC3T/OY29kSU9Q=; b=BU7n7qtOGJFq9Srw6MJWfWg3Xj74UuD+wXqf8GNSDnCRhjLHXjfRt7UHTTbemjKxYM NAxhX7FnwAyYBsKT5clwqp0EZ9LoFVJOdD25cnAh5S8yDGXYeZujRLncd3fiZlfI3kgv 3Q/wfJF7af0KCab93dGDEVv6lDE0g7K/lUTu/NK+HklhOWUQa3T4TTwMSPEryCuodztl JnZ9HfSesos6CHLGR1g1VLRPyl/QMxbdgbPJOKSOHWxLCNG0pr9f2OIpFB9Wzqo/8K8K KDvIHxUhdKbTvX8s5WLfFuXtFn/W+nktJ6YcWBt37rCi5Xz94GOJ2nNr1+KmbUbaDTZq 1fJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+t45jW5fzH3QGGggCvqOCmPLSRtesRC3T/OY29kSU9Q=; b=U6dMBF43wvUvLEU4JGDgqZe1aS/kgct6xIXpiGKL4Ieb39CBl0n7jYhtMxQAcIGnpk XUvp/IYgz/5YaLNaKUIzdakpSEZFKP03PLabymp6tgGXApGVTQ2ezAdmKpMweoVC+yJC QcATceCOR5kfSfeeVJccre6YQj6RzUGIhviOortsvBJHqB8EnyW/tAnomg450CP7Shdp xBlLxvuJT2ntqTFXnMnkxBIyHahMDkKL/f/UFtL+qH9CpDzqJOVh7VknAVPjrBOFRp62 vpZ5KrFvnlBvxVTMJzqcudOxfbvbbVXnAT06vxXcbaajfhllIV4Y3P2QcP1W/jdu2WAH bUZA== X-Gm-Message-State: ALyK8tLgpuEyfWQd0ZhNFm8tiheEkAqM5Uao7KqNedlJuSMhWXIwvQy8xxWnhpX/K1fGZqqvJUG5Z8ApOLqXEQ== X-Received: by 10.13.234.211 with SMTP id t202mr4629622ywe.262.1468400054785; Wed, 13 Jul 2016 01:54:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.33.213 with HTTP; Wed, 13 Jul 2016 01:53:55 -0700 (PDT) In-Reply-To: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 13 Jul 2016 10:53:55 +0200 Message-ID: To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 08:55:19 -0000 2016-07-08 0:36 GMT+02:00 Jonathan Lennox : > The use case is where one m-line has a semantic of =E2=80=9Calways view t= his person=E2=80=9D (my boss, say, or my customer); and another m-line has = a semantic of =E2=80=9Cthe current loudest speaker=E2=80=9D. Why is another m-line required for the "current loudest speaker" at all? Who the current speaker is can be known by means of RTP header extensions in client side. It can be also signaled by the server in any custom way (out of the scope of SDP). Any of those mechanisms is better than having yet another artificial m-line for that purpose. I don't know CLUE, but assuming it pursuits similar aim than BUNDLE, I think we should keep to a more declarative SDP syntax in which each m-line represents a specific "media stream track" from a single participant in the session, identified by a fixed MID (plus RID if the sender switches to another media encoding). If we can not even guarantee that, then SDP becomes extremely hard to understand. --=20 I=C3=B1aki Baz Castillo From nobody Wed Jul 13 02:27:48 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136C412D746; Wed, 13 Jul 2016 02:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMK7VDghLkWj; Wed, 13 Jul 2016 02:27:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F31012D741; Wed, 13 Jul 2016 02:27:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-46-578609870ecb Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 56.95.18043.78906875; Wed, 13 Jul 2016 11:27:36 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 11:27:35 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Jonathan Lennox Thread-Topic: [AVTCORE] [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR2KAHze27W5Jfo0ybRgYSx8aBWaAV9WSAgAA84wA= Date: Wed, 13 Jul 2016 09:27:35 +0000 Message-ID: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <64843FC95984DE49A2A725766418344B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM2J7oG4HZ1u4wbctjBYve1ayW0zfZ2Ox f/F5Zoupyx+zOLB4nGt4z+6xZMlPJo+2Z3fYA5ijuGxSUnMyy1KL9O0SuDIubN/IUnCFu6Lp wQbGBsaDnF2MnBwSAiYSPau+MULYYhIX7q1n62Lk4hASOMIo8eJ/KyuEs5hR4unUJpYuRg4O NgELie5/2iANIgKJEjvegNRwcjAL2EjsXX8LzBYW8Jbo//GRCaLGR+LUp2NQtpXEv+1PmUHG sAioSjR1coCYvEDhpy89IDY1M0p0TnoDVs4pECix9PstsNsYgW77fmoNE8QqcYlbT+YzQdws ILFkz3lmCFtU4uXjf2AniAroSXz/OhsqriTxY8MlFohePYkbU6ewQdjWEh9eTWGGsLUlli18 DWbzCghKnJz5hGUCo8QsJOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tLs5NNzLSSy3KTC4uzs/T y0st2cQIjNCDW35b7WA8+NzxEKMAB6MSD6+CQWu4EGtiWXFl7iFGCQ5mJRHeIPa2cCHelMTK qtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2MGz8pCW94+dL5Xd6J +LMbelpe//EH+mDX54btHNfEGXPuvPKx5jE5E7Yx5p6gn25k98nysDfTr0xUS9SLfbTqduf0 g1kq3qt8mSTn7z0dInrLM89f0K6kcGVQaK2BbNIDpZ+CpTYxdu8OzF4y41XXFZm2jjbH7fsL 5KzvCm7V9KnJ1enUT1ZiKc5INNRiLipOBAAFhE9RzAIAAA== Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 09:27:46 -0000 Hi, CLUE and BUNDLE are two separate things, and CLUE doesn=B9t require usage o= f BUNDLE. Regards, Christer On 13/07/16 11:53, "avt on behalf of I=F1aki Baz Castillo" wrote: >2016-07-08 0:36 GMT+02:00 Jonathan Lennox : >> The use case is where one m-line has a semantic of =B3always view this >>person=B2 (my boss, say, or my customer); and another m-line has a >>semantic of =B3the current loudest speaker=B2. > >Why is another m-line required for the "current loudest speaker" at all? > >Who the current speaker is can be known by means of RTP header >extensions in client side. It can be also signaled by the server in >any custom way (out of the scope of SDP). Any of those mechanisms is >better than having yet another artificial m-line for that purpose. > >I don't know CLUE, but assuming it pursuits similar aim than BUNDLE, I >think we should keep to a more declarative SDP syntax in which each >m-line represents a specific "media stream track" from a single >participant in the session, identified by a fixed MID (plus RID if the >sender switches to another media encoding). > >If we can not even guarantee that, then SDP becomes extremely hard to >understand. > > >--=20 >I=F1aki Baz Castillo > > >_______________________________________________ >Audio/Video Transport Core Maintenance >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt From nobody Wed Jul 13 02:29:27 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3453112D69F; Wed, 13 Jul 2016 02:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSj1nHpfuVwD; Wed, 13 Jul 2016 02:29:25 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95BD12D5D6; Wed, 13 Jul 2016 02:29:24 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-ea-578609f29b4d Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B0.16.18043.2F906875; Wed, 13 Jul 2016 11:29:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.294.0; Wed, 13 Jul 2016 11:29:22 +0200 To: Jonathan Lennox , IETF AVTCore WG , mmusic References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> From: Magnus Westerlund Message-ID: <3c392b30-e5a1-9cba-d6a8-e3d2c64da7e0@ericsson.com> Date: Wed, 13 Jul 2016 11:29:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2K7k+5nzrZwg5dz2S1e9qxkt9i/+Dyz xdTlj1kcmD2WLPnJ5NH27A57AFMUl01Kak5mWWqRvl0CV8afl2uZCg4KVuxoFWhg/M/bxcjJ ISFgIvH542xWCFtM4sK99WxdjFwcQgJHGCVeHLsO5SxnlHj57BE7SJWwgKPE8/k72EBsEYEU iY73c8HiQgI2ErN/bQWbxCZgIXHzRyNYDa+AvUT3369gNSwCqhJ/1q1h7GLk4BAViJFY35cA USIocXLmExYQm1PAVuLp37VMIDYz0JiZ888zQtjyEs1bZzNDrNKWaGjqYJ3AKDALSfssJC2z kLQsYGRexShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYnge3/LbawXjwueMhRgEORiUeXgWD 1nAh1sSy4srcQ4wSHMxKIrxB7G3hQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5ak ZqemFqQWwWSZODilGhjLUh+tftBzUjvitsSKFUILWZfOZpt0wPn0ZcdjW5c8ffGBj2OeurK3 xNkds3/NkXY5t1h4UcykjRfXbGBZWOgUMX3rPXWbrgZNdac906InnV7Q8GBDK89y1d1Vfa92 rlzUOW9dQbco38fDBZkcizZbnW6r4b9seUVu2/vv8Rs88o9cF9+kp3blvxJLcUaioRZzUXEi AF23oX1LAgAA Archived-At: Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 09:29:26 -0000 Den 2016-07-08 kl. 00:36, skrev Jonathan Lennox: > (My initial design proposal was to allow multiple SDES values of the > same type, and multiple SDES header extensions items of the same > type, to be sent simultaneously in RTP — protocol-syntactically this > is trivial, you’d just need to negotiate that you support it. But > I’m not wedded to this solution.) > So, if one is going to enable multiple concurrent values for SDES items that clearly needs an RTP extension which defines how one does. It also needs to discuss which SDES items of the existing that can be used in this way and what it means. There also needs to be clear procedures for how one deals with updates of the current set. Clearly this needs to be a signalled extension as you say. I think this is clearly work belonging to the AVTCORE WG. > What do people think — is this worth working on? Is there interest > in discussing it in Berlin, and if so, in what venue? I think this is worth some more thinking. My review of the RID drafts mad it clear to me that we might not have sufficiently thought through how the scoping and interactions are between the different new labellings we have for RTP stream. And this also points at another aspect, the expectations of what is produced from a media description. For media source that are what I call conceptual, like the "current speaker" or role based like "meeting chair", there clearly need to be understanding how this interacts in the signalling solutions. I am sorry to say that I have lost track of where CLUE has ended up and the interaction between SDP and the CLUE layer. I don't want to commit to anything, but I am happy to continue discussing this. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jul 13 02:48:59 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A478E12D6B5 for ; Wed, 13 Jul 2016 02:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com 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 jxbhiZy7z-zg for ; Wed, 13 Jul 2016 02:48:53 -0700 (PDT) Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com [209.85.161.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D221A12D6B8 for ; Wed, 13 Jul 2016 02:48:52 -0700 (PDT) Received: by mail-yw0-f175.google.com with SMTP id w127so38449194ywf.3 for ; Wed, 13 Jul 2016 02:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GGmBGZ7f6o8vuHf9e74IbXavbWVK/DzcqiCz+ISghwk=; b=gD5NzgHV8GUAu6WhXMWt++VVkP8/YUBpKQ1Bp5HnOrIqIqGb5Q4DSLRYwD6mOORpWr qXWRmiLUARjFFY/WA8PFj8l3LLvVMa//5867RV19F9xGjN93pwRBEYc16091BYEFVtv7 BjcofsrWCU2NqJgKr37oIERShcjmjFhXyHFv9rVBKzh61tk/iduHf+WimtobpGjqS4KG vMI7Uer/aikN0nMM8fQ7VDvQq5xlElEMZO8V0Q6x39jK1OwTVSPy63qMG+yFkqv3XCS6 QxR7LLU3TKnZd11+yut3iguFQWvdX9hPXghIlxpiZx3xo/Z9iG4m37vGpJTzM6KEmS8p y79A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GGmBGZ7f6o8vuHf9e74IbXavbWVK/DzcqiCz+ISghwk=; b=jrhnMs+PftJrvPGb/9xdzIJN/t2+4rOoZpZnOgIf7yg5CkUW7iN5DvuPCveZLDf91k AQyzL6S8u5ENP3pbXor2Ep7kkf7MPGnJhFxFsLVdGpQ9RjTjScBCXgai6+wVm9MrAR5V Cb4JgYQB2ErWPi/ThxHeFvEzRQR11yXpIWtX8mkQ+NTOEraMbIdUQcSk+de6IxdVm76X YsjC3xzMulvwNuYvQnAb7aCZyzAmnydKyNlL/KWJU5hYylAWEmoT6tHsW4TRU6eIkPp1 qWL1h0rXtgpCMkDFAbtjycJboVbYqV9iFC9NuqxLnBVmtJV+wtpzZ9VYoBSaDmRgtJ4x HHaA== X-Gm-Message-State: ALyK8tJ+MZXMDerY75jEIF4f1ZdPSGieeyHkIMkQTqoOn5Ys85t+KLHXqRVeR3fOqUWGnIT0EbMDwcm8/XWxCQ== X-Received: by 10.37.212.7 with SMTP id m7mr4726689ybf.20.1468403271965; Wed, 13 Jul 2016 02:47:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.33.213 with HTTP; Wed, 13 Jul 2016 02:47:32 -0700 (PDT) In-Reply-To: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 13 Jul 2016 11:47:32 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 09:48:54 -0000 2016-07-13 11:27 GMT+02:00 Christer Holmberg : > CLUE and BUNDLE are two separate things, and CLUE doesn=C2=B9t require us= age of > BUNDLE. Fine with me. However, my main question remains valid: Why is another m-line required for the "current loudest speaker" at all? --=20 I=C3=B1aki Baz Castillo From nobody Wed Jul 13 02:52:51 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE6612D74B; Wed, 13 Jul 2016 02:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4q0Z3bbSC9O; Wed, 13 Jul 2016 02:52:47 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FC412D73D; Wed, 13 Jul 2016 02:52:47 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-a9-57860f6d2305 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FC.6A.12516.D6F06875; Wed, 13 Jul 2016 11:52:45 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 11:52:45 +0200 From: Christer Holmberg To: =?Windows-1252?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [AVTCORE] [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR2KAHze27W5Jfo0ybRgYSx8aBWaAV9WSAgAA84wD//9IYAIAANO+A Date: Wed, 13 Jul 2016 09:52:45 +0000 Message-ID: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-ID: <47F82E54585CE8469B563E56FC5D0284@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM2J7iG4uf1u4wZReA4uXPSvZLabvs7HY v/g8s8XU5Y9ZHFg8zjW8Z/dYsuQnk0fbszvsAcxRXDYpqTmZZalF+nYJXBkX9xxjLXjNUtFw /BZ7A+NL5i5GTg4JAROJqw+fsEPYYhIX7q1n62Lk4hASOMIosWXyKUYIZzGjxIvZj1i7GDk4 2AQsJLr/aYM0iAhYSzyaf4YNxGYWSJF40f8AzBYW8Jbo//GRCaLGR+LUp2NQtptE2/RbYMtY BFQl5ny7wwJi8wpYSbStncQKses3o0Trm6+sIAlOgUCJqcsegjUzAl33/dQaJohl4hK3nsxn grhaQGLJnvNQ34hKvHz8D6xXVEBP4vvX2cwgN0sIKEos75eDaDWQeH9uPjOEbS2xo2M6I4St LbFs4WtmiHsEJU7OfMIygVFiFpJts5C0z0LSPgtJ+ywk7QsYWVcxihanFhfnphsZ66UWZSYX F+fn6eWllmxiBMbowS2/dXcwrn7teIhRgINRiYdXwaA1XIg1say4MvcQowQHs5II71futnAh 3pTEyqrUovz4otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjKtZuzP+2Kbu ve5g8N1T6R3bqt0t+hKby1YfXHP77t7HUR/1z2huPS/iZTVXu/G/rK7pYrnlv5RVu49EzmnI KRGdwqTdvE39X4WS4sJqVyO1inDBT7w3N+wwn5G1rOb0w/liOY7e7UeT8nWUBWvuP/uk+bOE Yf8R8TjHWXyxk8PiGD/OmHrkhRJLcUaioRZzUXEiAJy4Kf3NAgAA Archived-At: Cc: Jonathan Lennox , IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 09:52:49 -0000 Hi, >>CLUE and BUNDLE are two separate things, and CLUE doesn=B9t require usage >>of >> BUNDLE. > >Fine with me. However, my main question remains valid: > >Why is another m-line required for the "current loudest speaker" at all? Assume you have a conference client with two screens: one constantly shows the =93boss=94, and one shows the =93loudest speaker=94. You have one m- line to describe the =93boss=94 RTP stream. But, you also need an m- line to describe the =93loudest speaker=94 RTP stream, because often it will NOT be the same as the =93boss=94 RTP stream. Regards, Christer From nobody Wed Jul 13 02:58:13 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCF112D770 for ; Wed, 13 Jul 2016 02:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com 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 klutK5rjlXGz for ; Wed, 13 Jul 2016 02:58:09 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DFC12D766 for ; Wed, 13 Jul 2016 02:58:08 -0700 (PDT) Received: by mail-yw0-f179.google.com with SMTP id l125so38290631ywb.2 for ; Wed, 13 Jul 2016 02:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vniIhplQbBTjZQ9bIEg3AaIUwrdKHpZuY2db43gbe2o=; b=cvbUzEYvINVMpotO8NmS22eM97gHnRy29LqNLNdQ3GhzTCAVn8Wsq8Ed7fIEYk/yyG Qsyuw8nWDBVlCEfPHhGfHA+ThXOObsBe3u0ScdfJ7E1zIgNR3t4h/DNvvcGZKe2roRS3 wIWD9WGuWWa80gkcKA3iwFFQZ8q4J9Frn93ehWlrxNJrsSE/+EDr5p8x1achNpaU/W7t n0ZKFrqKkfmCJMuo0Go93abYKcT+9w7pb1l5z6ucOFkVpRYwKGVIb+oE2AnbeiEpI+Mx piQ9wc0NhiaO6px4BCmNcauDrb7B/Z5D3kfMCg9YfmvRKstjx3CD4xOJCNr2siFo7uRA QroQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vniIhplQbBTjZQ9bIEg3AaIUwrdKHpZuY2db43gbe2o=; b=Ta1jyw0zHhlm/8sC4Ax9Ht3hUwv2vJffuM033bo1TNv3x7tGHeOTmmMEAj49eANEdI I5LvA0h9ytRENg8GSOBBoofibEUGvvQK0y/Oeldj6Ptfk9HpLTGZyhlWe3zkpYIfz9hq /Y+q3/646osyZ/mh9lt4XhEX19HHoXIbCwFRKWUNooPwFxSq0Q+Gnw9Ycs0ADu5Wa3cj XgrEFz3zts6A6xPHGh6P4oxyik4JoRkIoVWzwUGKZU382p9IT+pWie+yYeJUUlI0vHHm b4PkYsatszV32/cKmRg4aIAyeW0H1XIdpojOxRisnIvUDfgR7I1EBBtzvgAsnXUW6FBv u2rQ== X-Gm-Message-State: ALyK8tLIw4m6PqPinzYln9PhFrLmrn2dTVT5mqZD5OitQmRQhB4ZXK9PCGrlC6oNfFrVTUVO+qhbP/WJPUCF3A== X-Received: by 10.37.11.19 with SMTP id 19mr4777806ybl.178.1468403826826; Wed, 13 Jul 2016 02:57:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.33.213 with HTTP; Wed, 13 Jul 2016 02:56:47 -0700 (PDT) In-Reply-To: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 13 Jul 2016 11:56:47 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 09:58:11 -0000 2016-07-13 11:52 GMT+02:00 Christer Holmberg : > Assume you have a conference client with two screens: one constantly show= s > the =E2=80=9Cboss=E2=80=9D, and one shows the =E2=80=9Cloudest speaker=E2= =80=9D. > > You have one m- line to describe the =E2=80=9Cboss=E2=80=9D RTP stream. > > But, you also need an m- line to describe the =E2=80=9Cloudest speaker=E2= =80=9D RTP > stream, because often it will NOT be the same as the =E2=80=9Cboss=E2=80= =9D RTP stream. Why should a remote video representation be tiled to a specific m-line? How media streams/tracks are represented in the SDP and how the frontend app renders them are different things. --=20 I=C3=B1aki Baz Castillo From nobody Wed Jul 13 03:10:54 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A777212D776; Wed, 13 Jul 2016 03:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7zxXsoCkLmC; Wed, 13 Jul 2016 03:10:46 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4637712D76C; Wed, 13 Jul 2016 03:10:46 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-51-578613a4fd1b Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2B.5C.27088.4A316875; Wed, 13 Jul 2016 12:10:44 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 12:10:44 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [AVTCORE] [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR2KAHze27W5Jfo0ybRgYSx8aBWaAV9WSAgAA84wD//9IYAIAANO+A///Np4CAADdfAA== Date: Wed, 13 Jul 2016 10:10:43 +0000 Message-ID: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1A231658F370C04AA4FE71CC8AD2C50E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM2K7nO4S4bZwgxcTNCxe9qxkt5i+z8Zi /+LzzBZTlz9mcWDxONfwnt1jyZKfTB5tz+6wBzBHcdmkpOZklqUW6dslcGXsP/aTpWAqW8X+ w6/ZGhjfsXQxcnJICJhIfD3UxA5hi0lcuLeerYuRi0NI4AijxPZFNxlBEkICixklTq7N72Lk 4GATsJDo/qcNEhYRsJS4MfcmM4jNLJAi8aL/ARuILSzgLdH/4yMTRI2PxKlPx6DsMInzF26A 1bAIqEr0b9wDFucVsJL4eucrK8Tez0wSkzbvAtvLKRAose9rK9hxjEDHfT+1hglimbjErSfz mSCOFpBYsuc8M4QtKvHy8T9WEFtUQE/i+9fZUHFFiavTl0P16kncmDqFDcK2lpjYsQfqAW2J ZQtfM0McJChxcuYTlgmMErOQrJuFpH0WkvZZSNpnIWlfwMi6ilG0OLU4KTfdyEgvtSgzubg4 P08vL7VkEyMwRg9u+W2wg/Hlc8dDjAIcjEo8vAoGreFCrIllxZW5hxglOJiVRHjXCLSFC/Gm JFZWpRblxxeV5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamAsm2sY+i7tPx/H dQ4tuc+nV968t+vycuerC9b8bfK9s+rFAkFtdRf31byB38Um/1LX+pi4x7jpfa5vtNsN622P mJ/k9WbtnVSnGSylL8y6ZpGW9hr9+kY5Jn3jb0LHzE4tkeZxbXKsmd9ntejb7G2TTXZd/T37 l9mS06KPHtvM32z29Wrut05HJZbijERDLeai4kQA1zce680CAAA= Archived-At: Cc: Jonathan Lennox , IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 10:10:48 -0000 Hi, >>Assume you have a conference client with two screens: one constantly >>shows >> the =B3boss=B2, and one shows the =B3loudest speaker=B2. >> >> You have one m- line to describe the =B3boss=B2 RTP stream. >> >> But, you also need an m- line to describe the =B3loudest speaker=B2 RTP >> stream, because often it will NOT be the same as the =B3boss=B2 RTP stre= am. > >Why should a remote video representation be tiled to a specific m-line? > >How media streams/tracks are represented in the SDP and how the >frontend app renders them are different things. SDP is not used to describe how the streams are rendered. The CLUE protocol is used to define that. >From an SDP perspective, there are two RTP streams, so there are two m- lines. Regards, Christer From nobody Wed Jul 13 07:14:42 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FEA12D81F; Wed, 13 Jul 2016 07:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOWYSdVkgdzi; Wed, 13 Jul 2016 07:14:34 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3318A12D825; Wed, 13 Jul 2016 07:14:34 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u6DE9tPI001747; Wed, 13 Jul 2016 10:14:31 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 241uh6bp6e-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Jul 2016 10:14:30 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 13 Jul 2016 09:14:29 -0500 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR2KAHglPM/iUn/kOx+O/DTOsKb6AOCHGAgAD7UYCABNYRAIABgXGAgAD1V4CAAHOwgA== Date: Wed, 13 Jul 2016 14:14:28 +0000 Message-ID: <4BA5AF95-3E88-4BA4-8DAD-D29F1195BD8D@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_4BA5AF953E884BA48DADD29F1195BD8Dvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-13_04:2016-07-13,2016-07-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607130159 Archived-At: Cc: mmusic , IETF AVTCore WG Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:14:38 -0000 --_000_4BA5AF953E884BA48DADD29F1195BD8Dvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 13, 2016, at 3:20 AM, Christer Holmberg > wrote: Hi, A few questions: Q1: If an RTP packet is associated with two or more m- lines, which codecs payl= oad type values, SSRC values should it use? Can it pick from any of the ass= ociated m- lines, or does one of the MIDs have to be the =93primary=94, whi= le the others are =93secondary=94, =93temporary=94, or whatever we want to = call them=85 It would have to satisfy all of them =97 in situations where that's not pos= sible (e.g. if the two m-lines specify non-overlapping codec sets) this cou= ldn=92t be used. a=3Dssrc would probably not be usable in this model, but it=92s probably in= general not usable for a loudest-speaker-switching m-line which is switchi= ng SSRC (as opposed to CSRC). Q2: Currently, draft-bundle says: "The RTP MID header extension SHOULD be included in some RTP packets at the start of the session and whenever the SSRC changes." Now, when the =93loudest speaker=94 changes, the SSRC does not change (at l= east not the SSRC of the =93boss=94). But, there must still be a =93I am no= longer also MID Y=94 indication. At the same time, if the =93loudest speaker=94 is now associated with anoth= er m- line (e.g. =93secretary=94), there must not be an indication that the= =93secretary=94 MID and =93loudest speaker=94 MID are associated. I think it=92s clearer if you interpret =93when the SSRC changes=94 as if i= t were =93whenever the mapping between SSRC and MID changes=94. This means= the same thing if there=92s only one MID per SSRC, but if you have multipl= e MID values for an SSRC you have to re-send the whole (new) set whenever t= he set changes. Regards, Christer From: mmusic > on b= ehalf of Jonathan Lennox > Date: Tuesday 12 July 2016 at 19:42 To: "pthatcher@google.com" > Cc: "avt@ietf.org" >= , "mmusic@ietf.org" > Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? On Jul 11, 2016, at 1:42 PM, Peter Thatcher > wrote: Basically what your're asking for is header extension that says "Not only a= m I MID X, but I'm also, temporarily, MID Y"? Why not just have a second,= separate, header extension for "I'm also temporarily MID Y"? Then the ex= isting semantics of BUNDLE and MID (and RIDs, which are scoped to MIDs) nee= d not change, but you get the information you need (I think). The thing is, all MID values are, conceptually, temporary =97 they can chan= ge at any time. So is it really meaningful to distinguish short-term tempo= rary from long-term temporary? Where do you draw the line? On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox > wrote: The intention of my proposal is that these could indeed be (temporarily) th= e same RTP media source, even though they=92re two separate m-lines. On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar > wrote: Hi Jonathan Clarification question : if we have 2 m=3Dlines m =3D ... a=3Dmid1 m=3D... a=3Dmid2 does these 2 correspond to same media source ? It felt so from the duplicat= e design you mentioned but wanted to confirm Thanks Suhas On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox > wrote: Hi, all =97 (This was an issue I raised in AVTCORE in Buenos Aires =97 I promised to se= nd e-mail to the list but hadn=92t remembered to get around to it until now= .) When finishing up the CLUE RTP mapping draft, I realized that one of CLUE= =92s RTP requirements didn=92t actually end up getting satisfied by BUNDLE = (which is the solution CLUE converged on). This isn=92t a CLUE-specific is= sue, so I=92m raising it here. The issue is whether we want to support a use case, in BUNDLE, where a sing= le RTP stream corresponds to more than media description (and thus has more= than one MID value)? The use case is where one m-line has a semantic of =93always view this pers= on=94 (my boss, say, or my customer); and another m-line has a semantic of = =93the current loudest speaker=94. (In CLUE, these would be a single conten= t capture in the former case, and a switched capture for the latter.) When= ever the boss *is* the current loudest speaker, the same content would be s= ent for both m-lines. A naive implementation would simply duplicate all the packets for the two m= -lines, with different MID values, but this has two problems. First off al= l, it obviously wastes bandwidth. Potentially more seriously, it precludes= any RTP middlebox topology which doesn=92t rewrite SSRC values, since the = same content (arriving with a single SSRC value at the middlebox) would nee= d to be sent with two different SSRC values down from the middlebox. If PE= RC goes with its current consensus of no SSRC rewriting, this will particul= arly be a problem for PERC. I certainly don=92t think this is something that should block BUNDLE=92s co= mpletion, but I think it could be a pretty easy extension. (My initial design proposal was to allow multiple SDES values of the same t= ype, and multiple SDES header extensions items of the same type, to be sent= simultaneously in RTP =97 protocol-syntactically this is trivial, you=92d = just need to negotiate that you support it. But I=92m not wedded to this s= olution.) What do people think =97 is this worth working on? Is there interest in di= scussing it in Berlin, and if so, in what venue? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_4BA5AF953E884BA48DADD29F1195BD8Dvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 13, 2016, at 3:20 AM, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:


Hi,

A few questions:


Q1:

If an RTP packet is associated with two or more m- lines, w= hich codecs payload type values, SSRC values should it use? Can it pick fro= m any of the associated m- lines, or does one of the MIDs have to be the = =93primary=94, while the others are =93secondary=94, =93temporary=94, or whatever we want to call them=85

It would have to satisfy all of them =97 in situations where that's no= t possible (e.g. if the two m-lines specify non-overlapping codec sets) thi= s couldn=92t be used.

a=3Dssrc would probably not be usable in this model, but it=92s probab= ly in general not usable for a loudest-speaker-switching m-line which is sw= itching SSRC (as opposed to CSRC).


Q2:

Currently, draft-bundle says:
   "The RTP MID header extension=
 SHOULD be included in some RTP packets
   at the start of the session and whenever the SSRC changes."
Now, when the =93loudest speaker=94 changes, the SSRC does = not change (at least not the SSRC of the =93boss=94). But, there must still= be a =93I am no longer also MID Y=94 indication.

At the same time, if the =93loudest speaker=94 is now assoc= iated with another m- line (e.g. =93secretary=94), there must not be an ind= ication that the =93secretary=94 MID and =93loudest speaker=94 MID are asso= ciated.

I think it=92s clearer if you interpret =93when the SSRC changes=94 as= if it were =93whenever the mapping between SSRC and MID changes=94.  = This means the same thing if there=92s only one MID per SSRC, but if you ha= ve multiple MID values for an SSRC you have to re-send the whole (new) set whenever the set changes.


Regards,

Christer













From: mmusic <mmusic-bounces@ietf.org&= gt; on behalf of Jonathan Lennox <jonathan@vidyo.com>
Date: Tuesday 12 July 20= 16 at 19:42
To: "pthatcher@google.com" <pthatcher@google.com>= ;
Cc: "avt@ietf.org" <avt@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BU= NDLE: a single stream with multiple MIDs?


On Jul 11, 2016, at 1:42 PM, Peter Thatcher <pthatcher@google.com> wrote:=

Basically what your're asking for is header extension that says "No= t only am I MID X, but I'm also, temporarily, MID Y"?   Why not j= ust have a second, separate, header extension for "I'm also temporarily MID Y"?   Then the existing semantics of BUNDLE= and MID (and RIDs, which are scoped to MIDs) need not change, but you get = the information you need (I think).

The thing is, all MID values are, conceptually, temporary = =97 they can change at any time.  So is it really meaningful to distin= guish short-term temporary from long-term temporary?  Where do you dra= w the line?

On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox = <jona= than@vidyo.com> wrote:
The intention of my proposal is that these could indeed be = (temporarily) the same RTP media source, even though they=92re two separate= m-lines.

On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar <suhasietf@gmail.c= om> wrote:

Hi Jonathan 

  Clarification question :

   if we have 2 m=3Dlines
   
m =3D ...
a=3Dmid1
<manager>

m=3D...
a=3Dmid2
<loudest speaker>

does these 2 correspond to same media source ? It felt so f= rom the duplicate design you mentioned but wanted to confirm

Thanks
Suhas

   

On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox = <jona= than@vidyo.com> wrote:
Hi, all =97

(This was an issue I raised in AVTCORE in Buenos Aires =97 I promised to se= nd e-mail to the list but hadn=92t remembered to get around to it until now= .)

When finishing up the CLUE RTP mapping draft, I realized that one of CLUE= =92s RTP requirements didn=92t actually end up getting satisfied by BUNDLE = (which is the solution CLUE converged on).  This isn=92t a CLUE-specif= ic issue, so I=92m raising it here.

The issue is whether we want to support a use case, in BUNDLE, where a sing= le RTP stream corresponds to more than media description (and thus has more= than one MID value)?

The use case is where one m-line has a semantic of =93always view this pers= on=94 (my boss, say, or my customer); and another m-line has a semantic of = =93the current loudest speaker=94. (In CLUE, these would be a single conten= t capture in the former case, and a switched capture for the latter.)  Whenever the boss *is* the current loudest = speaker, the same content would be sent for both m-lines.

A naive implementation would simply duplicate all the packets for the two m= -lines, with different MID values, but this has two problems.  First o= ff all, it obviously wastes bandwidth.  Potentially more seriously, it= precludes any RTP middlebox topology which doesn=92t rewrite SSRC values, since the same content (arriving with a sin= gle SSRC value at the middlebox) would need to be sent with two different S= SRC values down from the middlebox.  If PERC goes with its current con= sensus of no SSRC rewriting, this will particularly be a problem for PERC.

I certainly don=92t think this is something that should block BUNDLE=92s co= mpletion, but I think it could be a pretty easy extension.

(My initial design proposal was to allow multiple SDES values of the same t= ype, and multiple SDES header extensions items of the same type, to be sent= simultaneously in RTP =97 protocol-syntactically this is trivial, you=92d = just need to negotiate that you support it.  But I=92m not wedded to this solution.)

What do people think =97 is this worth working on?  Is there interest = in discussing it in Berlin, and if so, in what venue?
_______________________________________________
mmusic mailing list
mmusic@ietf= .org
https://www.ietf.org/mailman/listinfo/mmusic<= /a>



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic<= /a>




--_000_4BA5AF953E884BA48DADD29F1195BD8Dvidyocom_-- From nobody Wed Jul 13 07:16:19 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C38712D81C; Wed, 13 Jul 2016 07:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4UIiLsI3IZN; Wed, 13 Jul 2016 07:16:10 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15DD712D81F; Wed, 13 Jul 2016 07:16:10 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u6DEG5Ur008783; Wed, 13 Jul 2016 10:16:05 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 241uh6bp88-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Jul 2016 10:16:05 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 13 Jul 2016 09:16:05 -0500 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3NeIglPM/iUn/kOx+O/DTOsKb6AWvE+A Date: Wed, 13 Jul 2016 14:16:04 +0000 Message-ID: <765E6FD8-1FBC-4EE7-8E55-C6F017391279@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-13_06:2016-07-13,2016-07-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607130160 Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:16:15 -0000 DQo+IE9uIEp1bCAxMywgMjAxNiwgYXQgMzoyNCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IEkgYXNz dW1lIHRoaXMgd291bGQgb25seSB3b3JrIGZvciBidW5kbGVkIG0tIGxpbmVzLCByaWdodD8NCj4g DQo+IElmIHRoZSDFgmJvc3PLmyBhbmQgxYJsb3VkZXN0IHNwZWFrZXLLmyBtLSBsaW5lcyBhcmUg bm9uLWJ1bmRsZWQsIGJvdGggUlRQDQo+IHN0cmVhbXMgd291bGQgYmUgc2VudCBldmVuIGlmIHRo ZXkgYXJlIGlkZW50aWNhbCwgb3I/DQoNClllcywgdGhhdOKAmXMgcmlnaHQsIHlvdeKAmWQgaGF2 ZSBubyBjaG9pY2UgYnV0IHRvIGR1cGxpY2F0ZSB0aGUgcGFja2V0cyBpbiB0aGF0IGNhc2UuIChC dXQgaWYgeW914oCZcmUgaW4gYSBub24tU1NSQy1jaGFuZ2luZyB0b3BvbG9neSwgeW91IGNhbiBy ZS11c2UgdGhlIHNhbWUgU1NSQyBmb3IgdGhlIHR3byBub24tYnVuZGxlZCBzb3VyY2VzLikNCj4g DQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQo+IE9uIDA4LzA3LzE2IDAxOjM2 LCAibW11c2ljIG9uIGJlaGFsZiBvZiBKb25hdGhhbiBMZW5ub3giDQo+IDxtbXVzaWMtYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam9uYXRoYW5AdmlkeW8uY29tPiB3cm90ZToNCj4gDQo+ PiBIaSwgYWxsIOKAuQ0KPj4gDQo+PiAoVGhpcyB3YXMgYW4gaXNzdWUgSSByYWlzZWQgaW4gQVZU Q09SRSBpbiBCdWVub3MgQWlyZXMg4oC5IEkgcHJvbWlzZWQgdG8NCj4+IHNlbmQgZS1tYWlsIHRv IHRoZSBsaXN0IGJ1dCBoYWRuxIV0IHJlbWVtYmVyZWQgdG8gZ2V0IGFyb3VuZCB0byBpdCB1bnRp bA0KPj4gbm93LikNCj4+IA0KPj4gV2hlbiBmaW5pc2hpbmcgdXAgdGhlIENMVUUgUlRQIG1hcHBp bmcgZHJhZnQsIEkgcmVhbGl6ZWQgdGhhdCBvbmUgb2YNCj4+IENMVUXEhXMgUlRQIHJlcXVpcmVt ZW50cyBkaWRuxIV0IGFjdHVhbGx5IGVuZCB1cCBnZXR0aW5nIHNhdGlzZmllZCBieQ0KPj4gQlVO RExFICh3aGljaCBpcyB0aGUgc29sdXRpb24gQ0xVRSBjb252ZXJnZWQgb24pLiAgVGhpcyBpc27E hXQgYQ0KPj4gQ0xVRS1zcGVjaWZpYyBpc3N1ZSwgc28gScSFbSByYWlzaW5nIGl0IGhlcmUuDQo+ PiANCj4+IFRoZSBpc3N1ZSBpcyB3aGV0aGVyIHdlIHdhbnQgdG8gc3VwcG9ydCBhIHVzZSBjYXNl LCBpbiBCVU5ETEUsIHdoZXJlIGENCj4+IHNpbmdsZSBSVFAgc3RyZWFtIGNvcnJlc3BvbmRzIHRv IG1vcmUgdGhhbiBtZWRpYSBkZXNjcmlwdGlvbiAoYW5kIHRodXMNCj4+IGhhcyBtb3JlIHRoYW4g b25lIE1JRCB2YWx1ZSk/DQo+PiANCj4+IFRoZSB1c2UgY2FzZSBpcyB3aGVyZSBvbmUgbS1saW5l IGhhcyBhIHNlbWFudGljIG9mIMWCYWx3YXlzIHZpZXcgdGhpcw0KPj4gcGVyc29uy5sgKG15IGJv c3MsIHNheSwgb3IgbXkgY3VzdG9tZXIpOyBhbmQgYW5vdGhlciBtLWxpbmUgaGFzIGEgc2VtYW50 aWMNCj4+IG9mIMWCdGhlIGN1cnJlbnQgbG91ZGVzdCBzcGVha2Vyy5suIChJbiBDTFVFLCB0aGVz ZSB3b3VsZCBiZSBhIHNpbmdsZQ0KPj4gY29udGVudCBjYXB0dXJlIGluIHRoZSBmb3JtZXIgY2Fz ZSwgYW5kIGEgc3dpdGNoZWQgY2FwdHVyZSBmb3IgdGhlDQo+PiBsYXR0ZXIuKSAgV2hlbmV2ZXIg dGhlIGJvc3MgKmlzKiB0aGUgY3VycmVudCBsb3VkZXN0IHNwZWFrZXIsIHRoZSBzYW1lDQo+PiBj b250ZW50IHdvdWxkIGJlIHNlbnQgZm9yIGJvdGggbS1saW5lcy4NCj4+IA0KPj4gQSBuYWl2ZSBp bXBsZW1lbnRhdGlvbiB3b3VsZCBzaW1wbHkgZHVwbGljYXRlIGFsbCB0aGUgcGFja2V0cyBmb3Ig dGhlIHR3bw0KPj4gbS1saW5lcywgd2l0aCBkaWZmZXJlbnQgTUlEIHZhbHVlcywgYnV0IHRoaXMg aGFzIHR3byBwcm9ibGVtcy4gIEZpcnN0IG9mZg0KPj4gYWxsLCBpdCBvYnZpb3VzbHkgd2FzdGVz IGJhbmR3aWR0aC4gIFBvdGVudGlhbGx5IG1vcmUgc2VyaW91c2x5LCBpdA0KPj4gcHJlY2x1ZGVz IGFueSBSVFAgbWlkZGxlYm94IHRvcG9sb2d5IHdoaWNoIGRvZXNuxIV0IHJld3JpdGUgU1NSQyB2 YWx1ZXMsDQo+PiBzaW5jZSB0aGUgc2FtZSBjb250ZW50IChhcnJpdmluZyB3aXRoIGEgc2luZ2xl IFNTUkMgdmFsdWUgYXQgdGhlDQo+PiBtaWRkbGVib3gpIHdvdWxkIG5lZWQgdG8gYmUgc2VudCB3 aXRoIHR3byBkaWZmZXJlbnQgU1NSQyB2YWx1ZXMgZG93biBmcm9tDQo+PiB0aGUgbWlkZGxlYm94 LiAgSWYgUEVSQyBnb2VzIHdpdGggaXRzIGN1cnJlbnQgY29uc2Vuc3VzIG9mIG5vIFNTUkMNCj4+ IHJld3JpdGluZywgdGhpcyB3aWxsIHBhcnRpY3VsYXJseSBiZSBhIHByb2JsZW0gZm9yIFBFUkMu DQo+PiANCj4+IEkgY2VydGFpbmx5IGRvbsSFdCB0aGluayB0aGlzIGlzIHNvbWV0aGluZyB0aGF0 IHNob3VsZCBibG9jayBCVU5ETEXEhXMNCj4+IGNvbXBsZXRpb24sIGJ1dCBJIHRoaW5rIGl0IGNv dWxkIGJlIGEgcHJldHR5IGVhc3kgZXh0ZW5zaW9uLg0KPj4gDQo+PiAoTXkgaW5pdGlhbCBkZXNp Z24gcHJvcG9zYWwgd2FzIHRvIGFsbG93IG11bHRpcGxlIFNERVMgdmFsdWVzIG9mIHRoZSBzYW1l DQo+PiB0eXBlLCBhbmQgbXVsdGlwbGUgU0RFUyBoZWFkZXIgZXh0ZW5zaW9ucyBpdGVtcyBvZiB0 aGUgc2FtZSB0eXBlLCB0byBiZQ0KPj4gc2VudCBzaW11bHRhbmVvdXNseSBpbiBSVFAg4oC5IHBy b3RvY29sLXN5bnRhY3RpY2FsbHkgdGhpcyBpcyB0cml2aWFsLA0KPj4geW91xIVkIGp1c3QgbmVl ZCB0byBuZWdvdGlhdGUgdGhhdCB5b3Ugc3VwcG9ydCBpdC4gIEJ1dCBJxIVtIG5vdCB3ZWRkZWQg dG8NCj4+IHRoaXMgc29sdXRpb24uKQ0KPj4gDQo+PiBXaGF0IGRvIHBlb3BsZSB0aGluayDigLkg aXMgdGhpcyB3b3J0aCB3b3JraW5nIG9uPyAgSXMgdGhlcmUgaW50ZXJlc3QgaW4NCj4+IGRpc2N1 c3NpbmcgaXQgaW4gQmVybGluLCBhbmQgaWYgc28sIGluIHdoYXQgdmVudWU/DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbW11c2ljIG1haWxp bmcgbGlzdA0KPj4gbW11c2ljQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21tdXNpYw0KPiANCg0K From nobody Wed Jul 13 07:50:29 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CE212D8C8; Wed, 13 Jul 2016 07:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bgVY80MZC_tu; Wed, 13 Jul 2016 07:50:19 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F6812DB4D; Wed, 13 Jul 2016 07:50:18 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id i12so44838021ywa.1; Wed, 13 Jul 2016 07:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fo1G9+tEgj0/xShsYWlVvsfgJ+pmNHOOQp/aQ5X30Pg=; b=thy3snwNH/ObzWefxBoqDV0TuUr+uJW+14Z4oNY6HnU8pOeYZIUTmYYwysNiUL+tKp UBz85suGH6HFymCwR7cltUPxVWE1X3Q54Z68UjMvzZEA6lGSUnZzMdtQTQgcMoQbVPrw ZUyx6SfCAFY/6nzi0F25YxVTi/61UU5Zeux89k4bv14KKvQA2pyNBstrTleEBfusyBXf JChEu9bO0yNSi56xzwLrOpeioEPHMChhT718lFZlyxrwBt+ucEPbJCy5oMB4yEJdCjEe J4nAj5l7QyX8VJ18gbc2pw/qDeWgf142WZjE2VrfMYg96JBkMBTKCNrI4Xkq9/ROaxfG RVOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fo1G9+tEgj0/xShsYWlVvsfgJ+pmNHOOQp/aQ5X30Pg=; b=X+GGi3Wc1b0dx2EjBFhsufIzm9QpKdBTF5veCbr0pvtbmpUvoN8Yj3UlN46PtHFOw6 5aL7H/Ez7OAOUXhGcHNQt9mKJGLpSwYq9I8pHiSFY0AbSqyI4fc76VzyrJPy4R8IsBVT d514bO5tOKb+F4qCRUKi5BjRxjL8mT6zuGC64vTNsfzsG5R1uiEnFWLflpX/azyhvFTK 3eVwv84bPeZsL+BZAvQ8okg3TYZQrMgOBulzCbKe8DPO+wD8U7laho1NaxOGHl/IigVg dPDPaAXLMvk4WwYf5z36WfVH3oFCWRP9fEgTVbQ9uNsSMeD6IlGYmEn6ZzGu8Xxn2pe0 hABg== X-Gm-Message-State: ALyK8tKw13mjjDp61R5/vWtqj9Lsvo/ufWxfa3CFumyC5t5EW5A48ohjx7GtzKGYSEISEE/GUubPrppO5Di77A== X-Received: by 10.37.114.2 with SMTP id n2mr5748389ybc.54.1468421418057; Wed, 13 Jul 2016 07:50:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Wed, 13 Jul 2016 07:50:17 -0700 (PDT) In-Reply-To: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> From: Suhas Nandakumar Date: Wed, 13 Jul 2016 20:20:17 +0530 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a11488ec40104f105378581a8 Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:50:24 -0000 --001a11488ec40104f105378581a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox wrote: > Hi, all =E2=80=94 > > (This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promis= ed to > send e-mail to the list but hadn=E2=80=99t remembered to get around to it= until > now.) > > When finishing up the CLUE RTP mapping draft, I realized that one of > CLUE=E2=80=99s RTP requirements didn=E2=80=99t actually end up getting sa= tisfied by BUNDLE > (which is the solution CLUE converged on). This isn=E2=80=99t a CLUE-spe= cific > issue, so I=E2=80=99m raising it here. > > The issue is whether we want to support a use case, in BUNDLE, where a > single RTP stream corresponds to more than media description (and thus ha= s > more than one MID value)? > > The use case is where one m-line has a semantic of =E2=80=9Calways view t= his > person=E2=80=9D (my boss, say, or my customer); and another m-line has a = semantic > of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these would b= e a single content > capture in the former case, and a switched capture for the latter.) > Whenever the boss *is* the current loudest speaker, the same content woul= d > be sent for both m-lines. > > A naive implementation would simply duplicate all the packets for the two > m-lines, with different MID values, but this has two problems. First off > all, it obviously wastes bandwidth. Potentially more seriously, it > precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC v= alues, > since the same content (arriving with a single SSRC value at the middlebo= x) > would need to be sent with two different SSRC values down from the > middlebox. If PERC goes with its current consensus of no SSRC rewriting, > this will particularly be a problem for PERC. > > I certainly don=E2=80=99t think this is something that should block BUNDL= E=E2=80=99s > completion, but I think it could be a pretty easy extension. > > (My initial design proposal was to allow multiple SDES values of the same > type, and multiple SDES header extensions items of the same type, to be > sent simultaneously in RTP =E2=80=94 protocol-syntactically this is trivi= al, you=E2=80=99d > just need to negotiate that you support it. But I=E2=80=99m not wedded t= o this > solution.) > > Thinking a bit more on this .. it seems like a nice way forward . I agree with Magnus that it needs a way for the recipient to understand addition/removal of an item from the set .. If the set represent duplicates , then when the boss is the loud speaker, the set will contain 2 mids .. when the loudest speaker is not the boss, the set will have just one item in this example and the receiver will do the normal processing of the loudest speaker .. From the mux point of view these MIDs must be IDENTICAL-PER-PT > What do people think =E2=80=94 is this worth working on? Is there intere= st in > discussing it in Berlin, and if so, in what venue? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11488ec40104f105378581a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox <<= a href=3D"mailto:jonathan@vidyo.com" target=3D"_blank">jonathan@vidyo.com> wrote:
Hi, all =E2=80=94
(This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promised= to send e-mail to the list but hadn=E2=80=99t remembered to get around to = it until now.)

When finishing up the CLUE RTP mapping draft, I realized that one of CLUE= =E2=80=99s RTP requirements didn=E2=80=99t actually end up getting satisfie= d by BUNDLE (which is the solution CLUE converged on).=C2=A0 This isn=E2=80= =99t a CLUE-specific issue, so I=E2=80=99m raising it here.

The issue is whether we want to support a use case, in BUNDLE, where a sing= le RTP stream corresponds to more than media description (and thus has more= than one MID value)?

The use case is where one m-line has a semantic of =E2=80=9Calways view thi= s person=E2=80=9D (my boss, say, or my customer); and another m-line has a = semantic of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these = would be a single content capture in the former case, and a switched captur= e for the latter.)=C2=A0 Whenever the boss *is* the current loudest speaker= , the same content would be sent for both m-lines.

A naive implementation would simply duplicate all the packets for the two m= -lines, with different MID values, but this has two problems.=C2=A0 First o= ff all, it obviously wastes bandwidth.=C2=A0 Potentially more seriously, it= precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC va= lues, since the same content (arriving with a single SSRC value at the midd= lebox) would need to be sent with two different SSRC values down from the m= iddlebox.=C2=A0 If PERC goes with its current consensus of no SSRC rewritin= g, this will particularly be a problem for PERC.

I certainly don=E2=80=99t think this is something that should block BUNDLE= =E2=80=99s completion, but I think it could be a pretty easy extension.

(My initial design proposal was to allow multiple SDES values of the same t= ype, and multiple SDES header extensions items of the same type, to be sent= simultaneously in RTP =E2=80=94 protocol-syntactically this is trivial, yo= u=E2=80=99d just need to negotiate that you support it.=C2=A0 But I=E2=80= =99m not wedded to this solution.)


Thinking a bit more on this .. it seem= s like a nice way forward . I agree with Magnus that it needs a way for the= recipient to understand addition/removal of an item from the set ..
<= div>If the set represent duplicates , then when the boss is the loud speake= r, the set will contain 2 mids .. when the loudest speaker is not the boss,= the set will have just one item in this example and the receiver will do t= he normal processing of the loudest speaker .. From the mux point of view t= hese MIDs must be IDENTICAL-PER-PT

=C2=A0
What do people think =E2=80=94 is this worth working on?=C2=A0 Is there int= erest in discussing it in Berlin, and if so, in what venue?
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--001a11488ec40104f105378581a8-- From nobody Wed Jul 13 07:58:57 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F143C12DA13; Wed, 13 Jul 2016 07:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4vYVKQOR9_V; Wed, 13 Jul 2016 07:58:54 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E45512D9C6; Wed, 13 Jul 2016 07:58:54 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u6DEv3tL015206; Wed, 13 Jul 2016 10:58:51 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 241uh6bqmr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Jul 2016 10:58:51 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 13 Jul 2016 09:58:51 -0500 From: Jonathan Lennox To: Suhas Nandakumar Thread-Topic: [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR2KAHglPM/iUn/kOx+O/DTOsKb6AWzk6AgAACZAA= Date: Wed, 13 Jul 2016 14:58:50 +0000 Message-ID: <2C352584-0489-4410-A2AC-10BE19BF9094@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_2C35258404894410A2AC10BE19BF9094vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-13_06:2016-07-13,2016-07-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607130166 Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 14:58:56 -0000 --_000_2C35258404894410A2AC10BE19BF9094vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgMTMsIDIwMTYsIGF0IDEwOjUwIEFNLCBTdWhhcyBOYW5kYWt1bWFyIDxzdWhhc2ll dGZAZ21haWwuY29tPG1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KDQpP biBGcmksIEp1bCA4LCAyMDE2IGF0IDQ6MDYgQU0sIEpvbmF0aGFuIExlbm5veCA8am9uYXRoYW5A dmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PiB3cm90ZToNCkhpLCBhbGwg4oCU DQoNCihUaGlzIHdhcyBhbiBpc3N1ZSBJIHJhaXNlZCBpbiBBVlRDT1JFIGluIEJ1ZW5vcyBBaXJl cyDigJQgSSBwcm9taXNlZCB0byBzZW5kIGUtbWFpbCB0byB0aGUgbGlzdCBidXQgaGFkbuKAmXQg cmVtZW1iZXJlZCB0byBnZXQgYXJvdW5kIHRvIGl0IHVudGlsIG5vdy4pDQoNCldoZW4gZmluaXNo aW5nIHVwIHRoZSBDTFVFIFJUUCBtYXBwaW5nIGRyYWZ0LCBJIHJlYWxpemVkIHRoYXQgb25lIG9m IENMVUXigJlzIFJUUCByZXF1aXJlbWVudHMgZGlkbuKAmXQgYWN0dWFsbHkgZW5kIHVwIGdldHRp bmcgc2F0aXNmaWVkIGJ5IEJVTkRMRSAod2hpY2ggaXMgdGhlIHNvbHV0aW9uIENMVUUgY29udmVy Z2VkIG9uKS4gIFRoaXMgaXNu4oCZdCBhIENMVUUtc3BlY2lmaWMgaXNzdWUsIHNvIEnigJltIHJh aXNpbmcgaXQgaGVyZS4NCg0KVGhlIGlzc3VlIGlzIHdoZXRoZXIgd2Ugd2FudCB0byBzdXBwb3J0 IGEgdXNlIGNhc2UsIGluIEJVTkRMRSwgd2hlcmUgYSBzaW5nbGUgUlRQIHN0cmVhbSBjb3JyZXNw b25kcyB0byBtb3JlIHRoYW4gbWVkaWEgZGVzY3JpcHRpb24gKGFuZCB0aHVzIGhhcyBtb3JlIHRo YW4gb25lIE1JRCB2YWx1ZSk/DQoNClRoZSB1c2UgY2FzZSBpcyB3aGVyZSBvbmUgbS1saW5lIGhh cyBhIHNlbWFudGljIG9mIOKAnGFsd2F5cyB2aWV3IHRoaXMgcGVyc29u4oCdIChteSBib3NzLCBz YXksIG9yIG15IGN1c3RvbWVyKTsgYW5kIGFub3RoZXIgbS1saW5lIGhhcyBhIHNlbWFudGljIG9m IOKAnHRoZSBjdXJyZW50IGxvdWRlc3Qgc3BlYWtlcuKAnS4gKEluIENMVUUsIHRoZXNlIHdvdWxk IGJlIGEgc2luZ2xlIGNvbnRlbnQgY2FwdHVyZSBpbiB0aGUgZm9ybWVyIGNhc2UsIGFuZCBhIHN3 aXRjaGVkIGNhcHR1cmUgZm9yIHRoZSBsYXR0ZXIuKSAgV2hlbmV2ZXIgdGhlIGJvc3MgKmlzKiB0 aGUgY3VycmVudCBsb3VkZXN0IHNwZWFrZXIsIHRoZSBzYW1lIGNvbnRlbnQgd291bGQgYmUgc2Vu dCBmb3IgYm90aCBtLWxpbmVzLg0KDQpBIG5haXZlIGltcGxlbWVudGF0aW9uIHdvdWxkIHNpbXBs eSBkdXBsaWNhdGUgYWxsIHRoZSBwYWNrZXRzIGZvciB0aGUgdHdvIG0tbGluZXMsIHdpdGggZGlm ZmVyZW50IE1JRCB2YWx1ZXMsIGJ1dCB0aGlzIGhhcyB0d28gcHJvYmxlbXMuICBGaXJzdCBvZmYg YWxsLCBpdCBvYnZpb3VzbHkgd2FzdGVzIGJhbmR3aWR0aC4gIFBvdGVudGlhbGx5IG1vcmUgc2Vy aW91c2x5LCBpdCBwcmVjbHVkZXMgYW55IFJUUCBtaWRkbGVib3ggdG9wb2xvZ3kgd2hpY2ggZG9l c27igJl0IHJld3JpdGUgU1NSQyB2YWx1ZXMsIHNpbmNlIHRoZSBzYW1lIGNvbnRlbnQgKGFycml2 aW5nIHdpdGggYSBzaW5nbGUgU1NSQyB2YWx1ZSBhdCB0aGUgbWlkZGxlYm94KSB3b3VsZCBuZWVk IHRvIGJlIHNlbnQgd2l0aCB0d28gZGlmZmVyZW50IFNTUkMgdmFsdWVzIGRvd24gZnJvbSB0aGUg bWlkZGxlYm94LiAgSWYgUEVSQyBnb2VzIHdpdGggaXRzIGN1cnJlbnQgY29uc2Vuc3VzIG9mIG5v IFNTUkMgcmV3cml0aW5nLCB0aGlzIHdpbGwgcGFydGljdWxhcmx5IGJlIGEgcHJvYmxlbSBmb3Ig UEVSQy4NCg0KSSBjZXJ0YWlubHkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHNvbWV0aGluZyB0aGF0 IHNob3VsZCBibG9jayBCVU5ETEXigJlzIGNvbXBsZXRpb24sIGJ1dCBJIHRoaW5rIGl0IGNvdWxk IGJlIGEgcHJldHR5IGVhc3kgZXh0ZW5zaW9uLg0KDQooTXkgaW5pdGlhbCBkZXNpZ24gcHJvcG9z YWwgd2FzIHRvIGFsbG93IG11bHRpcGxlIFNERVMgdmFsdWVzIG9mIHRoZSBzYW1lIHR5cGUsIGFu ZCBtdWx0aXBsZSBTREVTIGhlYWRlciBleHRlbnNpb25zIGl0ZW1zIG9mIHRoZSBzYW1lIHR5cGUs IHRvIGJlIHNlbnQgc2ltdWx0YW5lb3VzbHkgaW4gUlRQIOKAlCBwcm90b2NvbC1zeW50YWN0aWNh bGx5IHRoaXMgaXMgdHJpdmlhbCwgeW914oCZZCBqdXN0IG5lZWQgdG8gbmVnb3RpYXRlIHRoYXQg eW91IHN1cHBvcnQgaXQuICBCdXQgSeKAmW0gbm90IHdlZGRlZCB0byB0aGlzIHNvbHV0aW9uLikN Cg0KDQpUaGlua2luZyBhIGJpdCBtb3JlIG9uIHRoaXMgLi4gaXQgc2VlbXMgbGlrZSBhIG5pY2Ug d2F5IGZvcndhcmQgLiBJIGFncmVlIHdpdGggTWFnbnVzIHRoYXQgaXQgbmVlZHMgYSB3YXkgZm9y IHRoZSByZWNpcGllbnQgdG8gdW5kZXJzdGFuZCBhZGRpdGlvbi9yZW1vdmFsIG9mIGFuIGl0ZW0g ZnJvbSB0aGUgc2V0IC4uDQoNCk15IHRoaW5raW5nIHdhcyB0aGF0IHlvdSBhbHdheXMgc2VuZCB0 aGUgY29tcGxldGUgc2V0LCBpZiB5b3Ugc2VuZCBhbnkgTUlEIGF0IGFsbC4gVGh1cywgd2hlbiB5 b3UgZ28gZnJvbSAyIE1JRHMgdG8gMSBNSUQsIHlvdSBzZW5kIDEgTUlELCBhbmQgdGhlIHJlY2Vp dmVyIGtub3dzIHRoYXQgdGhlIG90aGVyIE1JRCBubyBsb25nZXIgYXBwbGllcy4gIChUaGlzIHJ1 bGUgYXBwbGllcyBib3RoIGZvciBoZWFkZXIgZXh0ZW5zaW9ucyBhbmQgU0RFUyBpdGVtcy4pDQoN CklmIHRoZSBzZXQgcmVwcmVzZW50IGR1cGxpY2F0ZXMgLCB0aGVuIHdoZW4gdGhlIGJvc3MgaXMg dGhlIGxvdWQgc3BlYWtlciwgdGhlIHNldCB3aWxsIGNvbnRhaW4gMiBtaWRzIC4uIHdoZW4gdGhl IGxvdWRlc3Qgc3BlYWtlciBpcyBub3QgdGhlIGJvc3MsIHRoZSBzZXQgd2lsbCBoYXZlIGp1c3Qg b25lIGl0ZW0gaW4gdGhpcyBleGFtcGxlIGFuZCB0aGUgcmVjZWl2ZXIgd2lsbCBkbyB0aGUgbm9y bWFsIHByb2Nlc3Npbmcgb2YgdGhlIGxvdWRlc3Qgc3BlYWtlciAuLiBGcm9tIHRoZSBtdXggcG9p bnQgb2YgdmlldyB0aGVzZSBNSURzIG11c3QgYmUgSURFTlRJQ0FMLVBFUi1QVA0KDQpSaWdodC4N Cg0KDQoNCldoYXQgZG8gcGVvcGxlIHRoaW5rIOKAlCBpcyB0aGlzIHdvcnRoIHdvcmtpbmcgb24/ ICBJcyB0aGVyZSBpbnRlcmVzdCBpbiBkaXNjdXNzaW5nIGl0IGluIEJlcmxpbiwgYW5kIGlmIHNv LCBpbiB3aGF0IHZlbnVlPw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11 c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMNCg0KDQo= --_000_2C35258404894410A2AC10BE19BF9094vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0AB3005174737145A8DFF74073D908E2@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwg MTMsIDIwMTYsIGF0IDEwOjUwIEFNLCBTdWhhcyBOYW5kYWt1bWFyICZsdDs8YSBocmVmPSJtYWls dG86c3VoYXNpZXRmQGdtYWlsLmNvbSIgY2xhc3M9IiI+c3VoYXNpZXRmQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxf cXVvdGUiPk9uIEZyaSwgSnVsIDgsIDIwMTYgYXQgNDowNiBBTSwgSm9uYXRoYW4gTGVubm94IDxz cGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5Admlk eW8uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+am9uYXRoYW5AdmlkeW8uY29tPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KSGksIGFsbCDigJQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQooVGhpcyB3YXMgYW4gaXNzdWUgSSByYWlzZWQgaW4gQVZUQ09SRSBpbiBCdWVub3MgQWly ZXMg4oCUIEkgcHJvbWlzZWQgdG8gc2VuZCBlLW1haWwgdG8gdGhlIGxpc3QgYnV0IGhhZG7igJl0 IHJlbWVtYmVyZWQgdG8gZ2V0IGFyb3VuZCB0byBpdCB1bnRpbCBub3cuKTxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCldoZW4gZmluaXNoaW5nIHVwIHRoZSBDTFVFIFJUUCBtYXBwaW5nIGRy YWZ0LCBJIHJlYWxpemVkIHRoYXQgb25lIG9mIENMVUXigJlzIFJUUCByZXF1aXJlbWVudHMgZGlk buKAmXQgYWN0dWFsbHkgZW5kIHVwIGdldHRpbmcgc2F0aXNmaWVkIGJ5IEJVTkRMRSAod2hpY2gg aXMgdGhlIHNvbHV0aW9uIENMVUUgY29udmVyZ2VkIG9uKS4mbmJzcDsgVGhpcyBpc27igJl0IGEg Q0xVRS1zcGVjaWZpYyBpc3N1ZSwgc28gSeKAmW0gcmFpc2luZyBpdCBoZXJlLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoZSBpc3N1ZSBpcyB3aGV0aGVyIHdlIHdhbnQgdG8gc3VwcG9y dCBhIHVzZSBjYXNlLCBpbiBCVU5ETEUsIHdoZXJlIGEgc2luZ2xlIFJUUCBzdHJlYW0gY29ycmVz cG9uZHMgdG8gbW9yZSB0aGFuIG1lZGlhIGRlc2NyaXB0aW9uIChhbmQgdGh1cyBoYXMgbW9yZSB0 aGFuIG9uZSBNSUQgdmFsdWUpPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSB1c2Ug Y2FzZSBpcyB3aGVyZSBvbmUgbS1saW5lIGhhcyBhIHNlbWFudGljIG9mIOKAnGFsd2F5cyB2aWV3 IHRoaXMgcGVyc29u4oCdIChteSBib3NzLCBzYXksIG9yIG15IGN1c3RvbWVyKTsgYW5kIGFub3Ro ZXIgbS1saW5lIGhhcyBhIHNlbWFudGljIG9mIOKAnHRoZSBjdXJyZW50IGxvdWRlc3Qgc3BlYWtl cuKAnS4gKEluIENMVUUsIHRoZXNlIHdvdWxkIGJlIGEgc2luZ2xlIGNvbnRlbnQgY2FwdHVyZSBp biB0aGUgZm9ybWVyIGNhc2UsIGFuZCBhIHN3aXRjaGVkDQogY2FwdHVyZSBmb3IgdGhlIGxhdHRl ci4pJm5ic3A7IFdoZW5ldmVyIHRoZSBib3NzICppcyogdGhlIGN1cnJlbnQgbG91ZGVzdCBzcGVh a2VyLCB0aGUgc2FtZSBjb250ZW50IHdvdWxkIGJlIHNlbnQgZm9yIGJvdGggbS1saW5lcy48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBIG5haXZlIGltcGxlbWVudGF0aW9uIHdvdWxkIHNp bXBseSBkdXBsaWNhdGUgYWxsIHRoZSBwYWNrZXRzIGZvciB0aGUgdHdvIG0tbGluZXMsIHdpdGgg ZGlmZmVyZW50IE1JRCB2YWx1ZXMsIGJ1dCB0aGlzIGhhcyB0d28gcHJvYmxlbXMuJm5ic3A7IEZp cnN0IG9mZiBhbGwsIGl0IG9idmlvdXNseSB3YXN0ZXMgYmFuZHdpZHRoLiZuYnNwOyBQb3RlbnRp YWxseSBtb3JlIHNlcmlvdXNseSwgaXQgcHJlY2x1ZGVzIGFueSBSVFAgbWlkZGxlYm94IHRvcG9s b2d5IHdoaWNoDQogZG9lc27igJl0IHJld3JpdGUgU1NSQyB2YWx1ZXMsIHNpbmNlIHRoZSBzYW1l IGNvbnRlbnQgKGFycml2aW5nIHdpdGggYSBzaW5nbGUgU1NSQyB2YWx1ZSBhdCB0aGUgbWlkZGxl Ym94KSB3b3VsZCBuZWVkIHRvIGJlIHNlbnQgd2l0aCB0d28gZGlmZmVyZW50IFNTUkMgdmFsdWVz IGRvd24gZnJvbSB0aGUgbWlkZGxlYm94LiZuYnNwOyBJZiBQRVJDIGdvZXMgd2l0aCBpdHMgY3Vy cmVudCBjb25zZW5zdXMgb2Ygbm8gU1NSQyByZXdyaXRpbmcsIHRoaXMgd2lsbA0KIHBhcnRpY3Vs YXJseSBiZSBhIHByb2JsZW0gZm9yIFBFUkMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K SSBjZXJ0YWlubHkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBi bG9jayBCVU5ETEXigJlzIGNvbXBsZXRpb24sIGJ1dCBJIHRoaW5rIGl0IGNvdWxkIGJlIGEgcHJl dHR5IGVhc3kgZXh0ZW5zaW9uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCihNeSBpbml0 aWFsIGRlc2lnbiBwcm9wb3NhbCB3YXMgdG8gYWxsb3cgbXVsdGlwbGUgU0RFUyB2YWx1ZXMgb2Yg dGhlIHNhbWUgdHlwZSwgYW5kIG11bHRpcGxlIFNERVMgaGVhZGVyIGV4dGVuc2lvbnMgaXRlbXMg b2YgdGhlIHNhbWUgdHlwZSwgdG8gYmUgc2VudCBzaW11bHRhbmVvdXNseSBpbiBSVFAg4oCUIHBy b3RvY29sLXN5bnRhY3RpY2FsbHkgdGhpcyBpcyB0cml2aWFsLCB5b3XigJlkIGp1c3QgbmVlZCB0 byBuZWdvdGlhdGUgdGhhdCB5b3Ugc3VwcG9ydA0KIGl0LiZuYnNwOyBCdXQgSeKAmW0gbm90IHdl ZGRlZCB0byB0aGlzIHNvbHV0aW9uLik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5UaGlua2luZyBhIGJpdCBtb3JlIG9uIHRoaXMgLi4gaXQgc2VlbXMgbGlrZSBhIG5pY2Ug d2F5IGZvcndhcmQgLiBJIGFncmVlIHdpdGggTWFnbnVzIHRoYXQgaXQgbmVlZHMgYSB3YXkgZm9y IHRoZSByZWNpcGllbnQgdG8gdW5kZXJzdGFuZCBhZGRpdGlvbi9yZW1vdmFsIG9mIGFuIGl0ZW0g ZnJvbSB0aGUgc2V0IC4uPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pk15IHRoaW5raW5n IHdhcyB0aGF0IHlvdSBhbHdheXMgc2VuZCB0aGUgY29tcGxldGUgc2V0LCBpZiB5b3Ugc2VuZCBh bnkgTUlEIGF0IGFsbC4gVGh1cywgd2hlbiB5b3UgZ28gZnJvbSAyIE1JRHMgdG8gMSBNSUQsIHlv dSBzZW5kIDEgTUlELCBhbmQgdGhlIHJlY2VpdmVyIGtub3dzIHRoYXQgdGhlIG90aGVyIE1JRCBu byBsb25nZXIgYXBwbGllcy4gJm5ic3A7KFRoaXMgcnVsZSBhcHBsaWVzIGJvdGggZm9yIGhlYWRl ciBleHRlbnNpb25zIGFuZCBTREVTDQogaXRlbXMuKTwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSIiPklmIHRoZSBzZXQgcmVwcmVzZW50IGR1cGxpY2F0 ZXMgLCB0aGVuIHdoZW4gdGhlIGJvc3MgaXMgdGhlIGxvdWQgc3BlYWtlciwgdGhlIHNldCB3aWxs IGNvbnRhaW4gMiBtaWRzIC4uIHdoZW4gdGhlIGxvdWRlc3Qgc3BlYWtlciBpcyBub3QgdGhlIGJv c3MsIHRoZSBzZXQgd2lsbCBoYXZlIGp1c3Qgb25lIGl0ZW0gaW4gdGhpcyBleGFtcGxlIGFuZCB0 aGUgcmVjZWl2ZXIgd2lsbCBkbyB0aGUgbm9ybWFsIHByb2Nlc3Npbmcgb2YNCiB0aGUgbG91ZGVz dCBzcGVha2VyIC4uIEZyb20gdGhlIG11eCBwb2ludCBvZiB2aWV3IHRoZXNlIE1JRHMgbXVzdCBi ZSBJREVOVElDQUwtUEVSLVBUPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlJpZ2h0Ljwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KV2hhdCBkbyBwZW9wbGUgdGhpbmsg 4oCUIGlzIHRoaXMgd29ydGggd29ya2luZyBvbj8mbmJzcDsgSXMgdGhlcmUgaW50ZXJlc3QgaW4g ZGlzY3Vzc2luZyBpdCBpbiBCZXJsaW4sIGFuZCBpZiBzbywgaW4gd2hhdCB2ZW51ZT88YnIgY2xh c3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi ciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJt YWlsdG86bW11c2ljQGlldGYub3JnIiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyIGNs YXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_2C35258404894410A2AC10BE19BF9094vidyocom_-- From nobody Wed Jul 13 08:02:29 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E468E12D9C6; Wed, 13 Jul 2016 08:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2RuRfZ5QclVu; Wed, 13 Jul 2016 08:02:22 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE58012D838; Wed, 13 Jul 2016 08:02:21 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l125so45578552ywb.2; Wed, 13 Jul 2016 08:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ExIleZxv1h5R06qgwl+IUGuLaABp3/Dvyt3aRJPoDcg=; b=d3GIR0sxUR/kVeZP5Ge6BK5/7iRGjMPde5pniYYU+B+XbFHvHnuHqP6SChxqf6gi7C RGK8s24edGbfnLPdurPjvVptuW+wu5/UTyVVLIKYBCdfysPY/EPwFRf9bIGgEqGAzkcn Q8g/FqVdN2UxGOXVBgXlGYCUvThSH8U2RR6ExzkEU0JU87MigQvGPfJnknGkEqiIZnb5 ycrdJMVdcyxYd1HNChwlnAnuKOhYNHybMtFM+hZWtjDyz6AlSb/zEoWFtjRvQC2/5ua8 pqp39tcwwWblOf99bYxLlbjrTzpWX97tlrdJg6DL+mV4cAnMrG3GqYvcnjlQOuUtzGsJ Z80w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ExIleZxv1h5R06qgwl+IUGuLaABp3/Dvyt3aRJPoDcg=; b=Y7euUeTn693dM0jKgPIb0QXrYbSQTLuGyxBsJbwvMqyoTbnUo85I8d6xNU8TByHQ7O h0aITz8AQhYdp+P3zsoj3ikv9RCmxlXh153TmpH8Jba+66IQC53/Hm9sUpsKbfO5XZe7 BrW3HOPhVi849THbsaCNFXVgLv/ZZY6eCcqa1baWRzb6PKaMQa3wXJXaaoSEDLT94wQ5 l6QBfDbSlCtKtgDHH1ttteC5SgFyXY4vLWvtYa0MW7+k+DgAO6CiBCiE3xW6/FlFYgzV IPO2yGHGEL/g/KieXMP3fx2fr+4JHfyRd5hq5U47aNVyYVk+FapytH6Dng9AJtI4P3uQ B/mQ== X-Gm-Message-State: ALyK8tI/a3p7g3ee0SDU3zUT/btVBVXj3hefud0Lewe/cfv++PP6dayrN9canqe+LmBiUrLnSKEOA3zPW3nRHw== X-Received: by 10.37.5.13 with SMTP id 13mr5858191ybf.95.1468422141011; Wed, 13 Jul 2016 08:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Wed, 13 Jul 2016 08:02:20 -0700 (PDT) In-Reply-To: <2C352584-0489-4410-A2AC-10BE19BF9094@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <2C352584-0489-4410-A2AC-10BE19BF9094@vidyo.com> From: Suhas Nandakumar Date: Wed, 13 Jul 2016 20:32:20 +0530 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a11c00f7218705b053785ac03 Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:02:24 -0000 --001a11c00f7218705b053785ac03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 13, 2016 at 8:28 PM, Jonathan Lennox wrote= : > > On Jul 13, 2016, at 10:50 AM, Suhas Nandakumar > wrote: > > > > On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox > wrote: > >> Hi, all =E2=80=94 >> >> (This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promi= sed to >> send e-mail to the list but hadn=E2=80=99t remembered to get around to i= t until >> now.) >> >> When finishing up the CLUE RTP mapping draft, I realized that one of >> CLUE=E2=80=99s RTP requirements didn=E2=80=99t actually end up getting s= atisfied by BUNDLE >> (which is the solution CLUE converged on). This isn=E2=80=99t a CLUE-sp= ecific >> issue, so I=E2=80=99m raising it here. >> >> The issue is whether we want to support a use case, in BUNDLE, where a >> single RTP stream corresponds to more than media description (and thus h= as >> more than one MID value)? >> >> The use case is where one m-line has a semantic of =E2=80=9Calways view = this >> person=E2=80=9D (my boss, say, or my customer); and another m-line has a= semantic >> of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these would = be a single content >> capture in the former case, and a switched capture for the latter.) >> Whenever the boss *is* the current loudest speaker, the same content wou= ld >> be sent for both m-lines. >> >> A naive implementation would simply duplicate all the packets for the tw= o >> m-lines, with different MID values, but this has two problems. First of= f >> all, it obviously wastes bandwidth. Potentially more seriously, it >> precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC = values, >> since the same content (arriving with a single SSRC value at the middleb= ox) >> would need to be sent with two different SSRC values down from the >> middlebox. If PERC goes with its current consensus of no SSRC rewriting= , >> this will particularly be a problem for PERC. >> >> I certainly don=E2=80=99t think this is something that should block BUND= LE=E2=80=99s >> completion, but I think it could be a pretty easy extension. >> >> (My initial design proposal was to allow multiple SDES values of the sam= e >> type, and multiple SDES header extensions items of the same type, to be >> sent simultaneously in RTP =E2=80=94 protocol-syntactically this is triv= ial, you=E2=80=99d >> just need to negotiate that you support it. But I=E2=80=99m not wedded = to this >> solution.) >> >> > Thinking a bit more on this .. it seems like a nice way forward . I agree > with Magnus that it needs a way for the recipient to understand > addition/removal of an item from the set .. > > > My thinking was that you always send the complete set, if you send any MI= D > at all. Thus, when you go from 2 MIDs to 1 MID, you send 1 MID, and the > receiver knows that the other MID no longer applies. (This rule applies > both for header extensions and SDES items.) > Agreed.. That's the point i was probably trying to make in my example earlier. There might be few explanations needed on handling as you implied. > If the set represent duplicates , then when the boss is the loud speaker, > the set will contain 2 mids .. when the loudest speaker is not the boss, > the set will have just one item in this example and the receiver will do > the normal processing of the loudest speaker .. From the mux point of vie= w > these MIDs must be IDENTICAL-PER-PT > > > Right. > > > > >> What do people think =E2=80=94 is this worth working on? Is there inter= est in >> discussing it in Berlin, and if so, in what venue? >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > > --001a11c00f7218705b053785ac03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 13, 2016 at 8:28 PM, Jonathan Lennox <= jonathan@vidyo.com<= /a>> wrote:

On Jul 13, 2016, at 10:50 AM, Suhas Nandakumar <suhasietf@gmail.com> wrote:


On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
Hi, all =E2=80=94

(This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promised= to send e-mail to the list but hadn=E2=80=99t remembered to get around to = it until now.)

When finishing up the CLUE RTP mapping draft, I realized that one of CLUE= =E2=80=99s RTP requirements didn=E2=80=99t actually end up getting satisfie= d by BUNDLE (which is the solution CLUE converged on).=C2=A0 This isn=E2=80= =99t a CLUE-specific issue, so I=E2=80=99m raising it here.

The issue is whether we want to support a use case, in BUNDLE, where a sing= le RTP stream corresponds to more than media description (and thus has more= than one MID value)?

The use case is where one m-line has a semantic of =E2=80=9Calways view thi= s person=E2=80=9D (my boss, say, or my customer); and another m-line has a = semantic of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these = would be a single content capture in the former case, and a switched capture for the latter.)=C2=A0 Whenever the boss *is* the current loudest = speaker, the same content would be sent for both m-lines.

A naive implementation would simply duplicate all the packets for the two m= -lines, with different MID values, but this has two problems.=C2=A0 First o= ff all, it obviously wastes bandwidth.=C2=A0 Potentially more seriously, it= precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC values, since the same content (arriving with= a single SSRC value at the middlebox) would need to be sent with two diffe= rent SSRC values down from the middlebox.=C2=A0 If PERC goes with its curre= nt consensus of no SSRC rewriting, this will particularly be a problem for PERC.

I certainly don=E2=80=99t think this is something that should block BUNDLE= =E2=80=99s completion, but I think it could be a pretty easy extension.

(My initial design proposal was to allow multiple SDES values of the same t= ype, and multiple SDES header extensions items of the same type, to be sent= simultaneously in RTP =E2=80=94 protocol-syntactically this is trivial, yo= u=E2=80=99d just need to negotiate that you support it.=C2=A0 But I=E2=80=99m not wedded to this solution.)


Thinking a bit more on this .. it seems like a nice way forward . I ag= ree with Magnus that it needs a way for the recipient to understand additio= n/removal of an item from the set ..

My thinking was that you always send the complete set, if you s= end any MID at all. Thus, when you go from 2 MIDs to 1 MID, you send 1 MID,= and the receiver knows that the other MID no longer applies. =C2=A0(This r= ule applies both for header extensions and SDES items.)

Agreed..=C2=A0 T= hat's the point i was probably trying to make in my example earlier. Th= ere might be few explanations needed on handling as you implied.
=

If the set represent duplicates , then when the boss is the loud speak= er, the set will contain 2 mids .. when the loudest speaker is not the boss= , the set will have just one item in this example and the receiver will do = the normal processing of the loudest speaker .. From the mux point of view these MIDs must be IDENT= ICAL-PER-PT

Right.


=C2=A0
What do people think =E2=80=94 is this worth working on?=C2=A0 Is there int= erest in discussing it in Berlin, and if so, in what venue?
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic



--001a11c00f7218705b053785ac03-- From nobody Wed Jul 13 09:18:05 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 934CF12D137; Wed, 13 Jul 2016 09:18:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.27.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160713161804.16141.52470.idtracker@ietfa.amsl.com> Date: Wed, 13 Jul 2016 09:18:04 -0700 Archived-At: Cc: ben@nostrum.com, draft-ietf-mmusic-sdp-mux-attributes@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org Subject: [MMUSIC] Last Call: (A Framework for SDP Attributes when Multiplexing) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 16:18:04 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'A Framework for SDP Attributes when Multiplexing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. The last call is extended due to crossing an IETF meeting, and due to the length of the draft. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions. This specification also categorizes the existing SDP attributes based on the framework described herein. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jul 13 09:54:19 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734A412D0E0 for ; Wed, 13 Jul 2016 09:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 GdvK-hVFcxkE for ; Wed, 13 Jul 2016 09:54:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4184112B006 for ; Wed, 13 Jul 2016 09:54:15 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-a9-5786723464e0 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 30.0C.18043.43276875; Wed, 13 Jul 2016 18:54:13 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 13 Jul 2016 18:53:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wXAc4YfU41aC/JeIw3Ow3ayXk4ys3xqF8Nxk2Y0Oyho=; b=hH4h2GJpH9NkhswM3BkSrAmTXPi0NpvuPEP53j24k/6EVbPQh8YuHTQw5jHQI5TDD4FeGPpsS3xAsqGlahQOXVhHhZVYA8Rt+s1RWG8CVVz1XpwESNB6ZQMxkJ1aSgdfPM9CJxMZRLCuCfgu0nUfQqmybkvtupwSJdiGAr1vvpo= Received: from AM3PR07MB1188.eurprd07.prod.outlook.com (10.163.188.26) by AM3PR07MB1187.eurprd07.prod.outlook.com (10.163.188.25) with Microsoft SMTP Server (TLS) id 15.1.539.14; Wed, 13 Jul 2016 16:53:12 +0000 Received: from AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::c918:f7a3:5bb8:fbcd]) by AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::c918:f7a3:5bb8:fbcd%14]) with mapi id 15.01.0539.019; Wed, 13 Jul 2016 16:53:12 +0000 From: Bo Burman To: Santiago Carot Nemesio Thread-Topic: [MMUSIC] rfc5888: Multigroup management Thread-Index: AQHRyH6qwvVi/Rc6WU6N7AQmbRyFRJ/yXDfAgAFI7gCAIw/5IA== Date: Wed, 13 Jul 2016 16:53:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-office365-filtering-correlation-id: f241c8ac-0b40-46cb-d89d-08d3ab3e2d17 x-microsoft-exchange-diagnostics: 1; AM3PR07MB1187; 6:NH4NV8PLjAz+8Xw3yf6yg2FuKIgcLghfEw3rUZ3iyZZ27aOreSlFORdAEgc95Ob7iclteKRvUd7OUZ0O2XdxJmctsdsaTP+NH/ZsRI/ioN5f+KV0YLd1NzJF6VZNiSITWgvRuoVGqhIqUp8zq5egqC2SWBKotiCrkijoFdUFGboFwr9WnCkj1shB0xn08bXGiZgfa6E6y+3ldbEwEDRm4cof0DK7buaZVpS80ja5k9ctuUS6BNa3yUOGdedZEGlq0yd7gdsbWf9+O5hrcqyAU00meySJNUdQaUYNNWzb6ow=; 5:wQd4OdPeh9cwzdiHIHIDFdEDmDG15XBRrU/j6Xwxl0wC+fJxpZ5JroyizfbY6ynJkHhUEOvo28oGM0XDV0R5c18HTMYCtD6aNjM+1m3gRN+iKnD87hlOmrnW/7lkmkGKPvFDvuhjaKO37/sHaxkW/w==; 24:IghcdNMZhkNtrvMnzx7Y9//ECvkUyHwbOoruJT/Hsuc4As6L/nTdBAoqMgntO3587qqGn3lU/Fl0EaZHcj+EARNEyYq9J+ou3g2nWL9nAZc=; 7:GPxaYNk/M+huUcEG6sl8Uel9rzx3Osu2oW8c/20qYbIVZVF32+N8vBWtKHpo216jUGnF0qIT1wZT0KDt2k5C8MlBAUS3jrTnEb1/GhD8I4/2gbzt2aMDSK9bMVpuzwlP9LQIbxaXfHvo9oKPbz3Tw6efmPVOePOtBR0l3yr+g5mCpEcdx2hdCvkPteFiuRPlzfZ8m7xbU5GAc/AgHRnD1PK+nmJjJdBFkvfJjk3kovTO3rw0dEswalO5efRHIBTl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB1187; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM3PR07MB1187; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1187; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(13464003)(199003)(76104003)(51694002)(189002)(66066001)(92566002)(102836003)(3846002)(81156014)(33656002)(3660700001)(6116002)(5250100002)(19580395003)(110136002)(101416001)(86362001)(19580405001)(81166006)(189998001)(586003)(87936001)(105586002)(7846002)(5002640100001)(3280700002)(9686002)(305945005)(76176999)(11100500001)(7736002)(5003600100003)(7696003)(2906002)(106356001)(106116001)(74316002)(2950100001)(54356999)(97736004)(8676002)(2900100001)(68736007)(4326007)(8936002)(50986999)(76576001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1187; H:AM3PR07MB1188.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 16:53:12.1711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1187 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42KZGbFdRde0qC3c4NRnFoupyx+zWBx9f4nd gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4sLyFveCJQsW/Xc/YGhh/yHcxcnJICJhI zP78lQ3CFpO4cG89kM3FISRwhFFi+csJjBDOCUaJydMfs4M4LAK9zBJXWy4zg7QICVxjlOif qg9R9ZhRortxBliCTUBDYv6Ou4wgtoiAmUTbtqtAczk4mAXUJa4uDgIJCwOt/vVnJStEianE yym/2CFsJ4ndU2+AxVkEVCWmzbgIdh6vQIzEgbcH2CD2vmKU2PlVDsTmFAiU2Dt3CxOIzQj0 wvdTa8BsZgFxiVtP5jNBvCYgsWTPeWYIW1Ti5eN/rBD1kRKTJ55lBzlNQkBBYslfSYgSX4lj UxsZIex3bBJzJ9RC2G4Sz9Z9hhqZLdF28Q8TRKuVxLwzsRDh9YwSBxutIGwZidV/nzOBQkdC 4AyrxP/mpewQ56dKLF/byjiBUXsWkktngQNIU2L9Ln2IsKLElO6H7LPAnheUODnzCcsCRpZV jKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHp4uCW31Y7GA8+dzzEKMDBqMTDq2DQGi7EmlhW XJl7iFGCg1lJhJensC1ciDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQi mCwTB6dUA2P8zFc9Qlq9Pc92fprjL/lmckZy9yFj3wCdy68WLPw8fXqG1fHW+ArXNWmc/xa9 sH7ot/Huw7KNuz9PD1E4N+eZsOj5La/CSwP1U2LXvM19xnaS9+EWQ//pfz/O0Fqf2mkVk/Uk 0fzfPD6R0FNT5h2R8XTuSfWbZ15iYrCD/aXf9rTw6cet+W8qsRRnJBpqMRcVJwIAF5a2dxMD AAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] rfc5888: Multigroup management X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 16:54:17 -0000 SGksDQoNCkFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5IGluIHJlc3BvbmRpbmcuDQoNCkkgc3RpbGwg ZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBkbywgb3Igd2hh dCB5b3UgdGhpbmsgaXMgbm90IHBvc3NpYmxlIHRvZGF5Pw0KDQpJbiB5b3VyIG9yaWdpbmFsIG1h aWwgeW91IHNhaWQgdGhhdCB0aGUgcHJvYmxlbSBvY2N1cnMgd2hlbiB0aGVyZSBhcmUgc2V2ZXJh bCBncm91cHMgd2l0aCB0aGUgc2FtZSBzZW1hbnRpYy4gVG8gbWUsIHRoYXQgc2VlbXMgcGVyIGRl ZmluaXRpb24gdG8gcmVzdWx0IGluIChhbmQgYmUgaWRlbnRpY2FsIHRvKSBhIHNpbmdsZSBncm91 cCBjb250YWluaW5nIHRoZSB1bmlvbiBvZiBtaWQgaW4gYWxsIHN1Yi1ncm91cHMuDQoNCldoeSBp cyB0aGF0IG5vdCBPSz8gSWYgdGhlcmUgd291bGQgZXhpc3QgYSBuZWVkIHRvIHJlY29nbml6ZSBh bmQgc2VwYXJhdGUgb3V0IHRoZSBzdWItZ3JvdXBzIGZyb20gdGhlIG9mZmVyIGluIHRoZSBhbnN3 ZXIsIHRoZSB1c2VkIChjb21tb24pIHNlbWFudGljIGNvdWxkIG5vdCByZWFsbHkgYmUgc3VmZmlj aWVudCBmb3IgeW91ciBncm91cGluZyBwdXJwb3NlcywgY291bGQgaXQ/IE9uZSBzb2x1dGlvbiBj b3VsZCB0aHVzIGJlIHRvIGludHJvZHVjZSBhbm90aGVyIHN1Yi1ncm91cGluZyBzZW1hbnRpYywg aW4gYWRkaXRpb24gdG8gdGhlICJ1bmlvbiIgc2VtYW50aWMsIHdoaWNoIGlzIHNvbWV0aGluZyB0 aGF0IDU4ODggYWxyZWFkeSBzdXBwb3J0cyBieSBzaW1wbHkgYWxsb3dpbmcgZm9yIG11bHRpcGxl IGdyb3VwaW5ncy4gSG93IHRvIHNldCB0aGlzIGFkZGl0aW9uYWwgc3ViLWdyb3VwaW5nIGluIHRo ZSBvZmZlciBkZXBlbmRzIG9uIHlvdXIgbmVlZCBmb3Igc2VwYXJhdGlvbiBpbiB0aGUgYW5zd2Vy Lg0KDQpZb3UgY2FuIG9idmlvdXNseSBsb29rIHRvIHRoZSBvZmZlciB0byBzZWUgd2hhdCBncm91 cHMgYW5kIG1lZGlhIHRoYXQgYXJlIG9mZmVyZWQsIGFuZCB0byB0aGUgYW5zd2VyIHRvIGtub3cg d2hhdCBncm91cHMgYW5kIG1lZGlhcyB0aGF0IHdlcmUgYWNjZXB0ZWQsIGV2ZW4gcGVyIGdyb3Vw LiBBbnkgbWVkaWEgdGhhdCB3ZXJlIG9mZmVyZWQgYnV0IG5vdCBhY2NlcHRlZCBpbiB0aGUgYW5z d2VyIGlzIG5vdCBpbmNsdWRlZCB0aGVyZSwgc28geW91IGNhbm5vdCBnZXQgYW55IGluZm9ybWF0 aW9uIGFib3V0IG5vbi1hY2NlcHRlZCBtZWRpYSBmcm9tIGp1c3QgbG9va2luZyB0aGUgYW5zd2Vy LiBEbyB5b3Ugc29tZWhvdyB3YW50IGEgdHJhY2stcmVjb3JkIG9mIG5vbi1hY2NlcHRlZCBtZWRp YSBhbmQgZ3JvdXBzIGluIHRoZSBhbnN3ZXI/DQoNClJlZ2FyZHMsDQovQm8NCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTYW50aWFnbyBDYXJvdCBOZW1lc2lvIFttYWls dG86c2FuY2FuZS5rdXJlbnRvQGdtYWlsLmNvbV0NCj4gU2VudDogZGVuIDIxIGp1bmkgMjAxNiAx MDo1OA0KPiBUbzogQm8gQnVybWFuIDxiby5idXJtYW5AZXJpY3Nzb24uY29tPg0KPiBDYzogbW11 c2ljQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTU1VU0lDXSByZmM1ODg4OiBNdWx0aWdyb3Vw IG1hbmFnZW1lbnQNCj4gDQo+IEhpLA0KPiANCj4gdGhhbmtzIGEgbG90IGZvciB5b3VyIHJlcGx5 LCBzZWUgY29tbWVudHMgYmVsb3cuDQo+IA0KPiAyMDE2LTA2LTIwIDE1OjM5IEdNVCswMjowMCBC byBCdXJtYW4gPGJvLmJ1cm1hbkBlcmljc3Nvbi5jb20+Og0KPiA+IEhpLA0KPiA+DQo+ID4gSSB0 aGluayB0aGlzIGxpc3Qgc2hvdWxkIGJlIGNhcGFibGUgdG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24u DQo+ID4NCj4gPiBJdCBzZWVtcyB0byBtZSB0aGF0IHlvdSBpbiBnZW5lcmFsIG5lZWQgdG8gY29u c2lkZXIgdGhlIHNlbWFudGljcyBvZg0KPiA+IHRoZSBncm91cGluZy4gTG9va2luZyB0byB5b3Vy IGV4YW1wbGUgYmVsb3csIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQNCj4gPiB3aGF0IHlvdSB0 cnkgdG8gZXhwcmVzcyB3aXRoIGE9Z3JvdXA6TFMgMSAyIDMgYT1ncm91cDpMUyAxIDINCj4gPiBP YnZpb3VzbHksIGlmIG1lZGlhIGxpbmVzIHdpdGggbWlkIDEsIDIsIGFuZCAzIGFyZSBsaXAtc3lu Y2hyb25pemVkIChMUyksIHNvIGFyZSBtaWQgMSBhbmQgMiwgc2luY2UgaXQgaXMgYSB0cnVlIHN1 YnNldCBvZiB0aGUNCj4gZmlyc3QgZ3JvdXAuIFRoZSBzZWNvbmQgImE9IiBsaW5lIGlzIHJlZHVu ZGFudCBldmVuIHRvIHN0YXJ0IHdpdGguIEFzIHN1Y2gsIGp1c3QgcmVtb3Zpbmcgb3IgZGlzcmVn YXJkaW5nIHRoZSByZXN1bHRpbmcNCj4gcmVwZWF0ZWQgbGluZSBpbiB0aGUgYW5zd2VyIGluIHlv dXIgZXhhbXBsZSBkb2VzIG5vdCBjYXVzZSBhbnkgY29uY2VybiBvciBhbWJpZ3VpdHkuDQo+IA0K PiBUaGlzIGlzIG5vdCBhIHJlYWwgY2FzZSBhdCBhbGwsIEkganVzdCB3YW50ZWQgdG8gcmFpc2Ug YXdhcmVuZXNzIGFib3V0IHRoaXMgY29uY2Vybiwgc28gdGhhdCdzIGp1c3QgYSBzaW1wbGUgZXhh bXBsZSBvZg0KPiBhbWJpZ3VpdHkgaW4gY2FzZSBhbnkgcGVlciBuZWVkcyB0byBkaXN0aW5ndWlz IHRoaXMgY2FzZSwgU28gdGhlIHNlbWFudGljIHJlZ2FyZGluZyBvZiB0aGUgZ3JvdXBpbmcgb2Yg bWVkaWFzIGlzDQo+IGFwcGxpY2F0aW9uIGRlcGVuZGFudCB5b3UgY2FuIG5vdCBtYWtlIGFzc3Vt cHRpb25zIGFib3V0IHdoYXQgYXBwbGljYXRpb24gZG8gb3IgZXZlbiB3aGF0IHRoZXkgYXJlIHRy eWluZyB0byBkbywgYnV0DQo+IGZyb20gdGhlIGltcGxlbWVudGF0aW9uIHBvaW50IG9mIHZpZXcg cGVyaGFwcyB5b3UgbmVlZCB0byBkaXN0aW5ndWlzaCB3aGF0IGdyb3VwIHdhcyBvZmZlcmVkIHdp dGggd2hhdCBtZWRpYXMgYW5kDQo+IHdoYXQgbWVkaWFzIHdlcmUgYWNjZXB0ZWQgZm9yIGFueSBz cGVjaWZpYyBncm91cC4NCj4gDQo+IFNvIEkgc3VzcGVjdHMgdGhhdCBqdXN0IGFzIGl0IGlzIHJp Z2h0IG5vdyB0aGlzIGlzIG5vdCBwb3NzaWJsZS4NCj4gUGxlYXNlLCBmaXhtZSBpZiBJJ20gd3Jv bmcgb3IgSSdtIG1pc3Npbmcgc29tZXRoaW5nLg0KPiANCj4gVGhhbmtzDQo= From nobody Wed Jul 13 11:15:25 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9539212D1D0 for ; Wed, 13 Jul 2016 11:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 yotckTIc2ICk for ; Wed, 13 Jul 2016 11:15:16 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD2012D0C1 for ; Wed, 13 Jul 2016 11:15:16 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id w38so30304502qtb.0 for ; Wed, 13 Jul 2016 11:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9AYysBnuviTZkJ/9xn72f4vOZfMwR+8Ei070Jp807ws=; b=WEH/bNYbDb9WXDDN70qe+ETzrICC1s2Z4cLE+okgtfsdEKbC7lXpjDDJ3moR7vB7sb U2VwoHqhcVuKpAfiepY8yKhYqw/MAzq/Uvt5dQ0Gu0EdlEeLzxG0BqiFAmuswKAJdjap lHYXsymtoJ6ssSHiK0T6kfbmywZQ6ngsszWkhW4KqiZH6PYxyKow2nc6k0HGlId6iDP7 7ne0Grk+FZwVSxgO1bXngxVoC3OwfiTB/kkydSJP7+oa/4khs98xwWi4k1ioZYnFJpC9 LPWXG2CAlG4BkCTRQi45X1LUUjy9UL/dO0U3MWxnXUqDx6n5TqRXoWmiVc+OkuCPHeDQ fiXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9AYysBnuviTZkJ/9xn72f4vOZfMwR+8Ei070Jp807ws=; b=dUNiTpQ3q3c+xrvAngmB7iSBSxIrzAgQby3zwwSHOFO49vuo5Ezjp/B09HnRha2yOK 8UBAE3kamTqwoR08RjPqK/c2RUSK9hypQDFk1WFTOWDyxUby1nKkbTd/28ucqBEl1sII 7qDRS/D33tzOqgZW8gOiAVAo5fPsaqBiA4PP7hi/M80lZpgLiw8GGnlESu9LVPySBlUI gx/5gtcQk13CrPRba7HjK15HbthgFjXE1ulARAxYCSYKMVfUO9obhRC5DhUQNrgSDkRP w6US51VkMjS8N45uVKgi8Cn8/dsX2hP96uyMcxTD55SmLVB+FPKICe/t0ujL7mHAe6Cp DiqA== X-Gm-Message-State: ALyK8tLLF5OLTKItWZ7wZcrsL0oqo0uyX9Tp+8NYsUioFWxbYBrEM7n5r0X4fpgI+gqy7RTrZNT6yLxtTCgS8dGx X-Received: by 10.237.36.38 with SMTP id r35mr14351955qtc.3.1468433715288; Wed, 13 Jul 2016 11:15:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.4 with HTTP; Wed, 13 Jul 2016 11:14:35 -0700 (PDT) In-Reply-To: <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> From: Peter Thatcher Date: Wed, 13 Jul 2016 11:14:35 -0700 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a113d3aacfa2b3a0537885d92 Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 18:15:20 -0000 --001a113d3aacfa2b3a0537885d92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 12, 2016 at 9:42 AM, Jonathan Lennox wrote= : > > On Jul 11, 2016, at 1:42 PM, Peter Thatcher pthatcher@google.com>> wrote: > > Basically what your're asking for is header extension that says "Not only > am I MID X, but I'm also, temporarily, MID Y"? Why not just have a > second, separate, header extension for "I'm also temporarily MID Y"? Th= en > the existing semantics of BUNDLE and MID (and RIDs, which are scoped to > MIDs) need not change, but you get the information you need (I think). > > The thing is, all MID values are, conceptually, temporary =E2=80=94 they = can > change at any time. So is it really meaningful to distinguish short-term > temporary from long-term temporary? Where do you draw the line? > =E2=80=8BThat doesn't match my mental model of MIDs. I've always thought = of an RTP stream as being bound to a particular MID, not able to change between various MIDs. I might be wrong, but it seems like there are weird edge cases with switching MIDs, such as how RIDs play into it (since they are scoped to MIDs). Another is the demux algorithm in WebRTC/ORTC which "locks on" to SSRCs and only looks at MIDs if the SSRCs are unknown (the demux algorithm certainly does not take into account demuxing a packet into multiple RtpReceivers). So it sounds like you are asking for two things: 1. Be able to switch MIDs 2. Be able to have > 1 MIDs. And both of those blow up my mental model of MIDs and could cause problems with other things. I think it would be less risky to define a separate header extension for "multiplicity of changable MIDs" rather than re-using the existing header extension, when the semantics seems so much different (than my mental model, at least). > > On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox > wrote: > The intention of my proposal is that these could indeed be (temporarily) > the same RTP media source, even though they=E2=80=99re two separate m-lin= es. > > On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar suhasietf@gmail.com>> wrote: > > Hi Jonathan > > Clarification question : > > if we have 2 m=3Dlines > > m =3D ... > a=3Dmid1 > > > m=3D... > a=3Dmid2 > > > does these 2 correspond to same media source ? It felt so from the > duplicate design you mentioned but wanted to confirm > > Thanks > Suhas > > > > On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox > wrote: > Hi, all =E2=80=94 > > (This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promis= ed to > send e-mail to the list but hadn=E2=80=99t remembered to get around to it= until > now.) > > When finishing up the CLUE RTP mapping draft, I realized that one of > CLUE=E2=80=99s RTP requirements didn=E2=80=99t actually end up getting sa= tisfied by BUNDLE > (which is the solution CLUE converged on). This isn=E2=80=99t a CLUE-spe= cific > issue, so I=E2=80=99m raising it here. > > The issue is whether we want to support a use case, in BUNDLE, where a > single RTP stream corresponds to more than media description (and thus ha= s > more than one MID value)? > > The use case is where one m-line has a semantic of =E2=80=9Calways view t= his > person=E2=80=9D (my boss, say, or my customer); and another m-line has a = semantic > of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these would b= e a single content > capture in the former case, and a switched capture for the latter.) > Whenever the boss *is* the current loudest speaker, the same content woul= d > be sent for both m-lines. > > A naive implementation would simply duplicate all the packets for the two > m-lines, with different MID values, but this has two problems. First off > all, it obviously wastes bandwidth. Potentially more seriously, it > precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC v= alues, > since the same content (arriving with a single SSRC value at the middlebo= x) > would need to be sent with two different SSRC values down from the > middlebox. If PERC goes with its current consensus of no SSRC rewriting, > this will particularly be a problem for PERC. > > I certainly don=E2=80=99t think this is something that should block BUNDL= E=E2=80=99s > completion, but I think it could be a pretty easy extension. > > (My initial design proposal was to allow multiple SDES values of the same > type, and multiple SDES header extensions items of the same type, to be > sent simultaneously in RTP =E2=80=94 protocol-syntactically this is trivi= al, you=E2=80=99d > just need to negotiate that you support it. But I=E2=80=99m not wedded t= o this > solution.) > > What do people think =E2=80=94 is this worth working on? Is there intere= st in > discussing it in Berlin, and if so, in what venue? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > --001a113d3aacfa2b3a0537885d92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 12, 2016 at 9:42 AM, Jonathan Lennox <jonathan@v= idyo.com> wrote:

On Jul 11, 2016, at 1:42 PM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

Basically what your're asking for is header extension that says "N= ot only am I MID X, but I'm also, temporarily, MID Y"?=C2=A0 =C2= =A0Why not just have a second, separate, header extension for "I'm= also temporarily MID Y"?=C2=A0 =C2=A0Then the existing semantics of B= UNDLE and MID (and RIDs, which are scoped to MIDs) need not change, but you= get the information you need (I think).

The thing is, all MID values are, conceptually, temporary =E2=80=94 = they can change at any time.=C2=A0 So is it really meaningful to distinguis= h short-term temporary from long-term temporary?=C2=A0 Where do you draw th= e line?

=E2=80=8BThat doesn't ma= tch my mental model of MIDs. =C2=A0 I've always thought of an RTP strea= m as being bound to a particular MID, not able to change between various MI= Ds.=C2=A0 I might be wrong, but it seems like there are weird edge cases wi= th switching MIDs, such as how RIDs play into it (since they are scoped to = MIDs).=C2=A0 Another is the demux algorithm in WebRTC/ORTC which "lock= s on" to SSRCs and only looks at MIDs if the SSRCs are unknown (the de= mux algorithm certainly does not take into account demuxing a packet into m= ultiple RtpReceivers). =C2=A0=C2=A0

So it sounds like = you are asking for two things:
1.=C2=A0 Be able to switch MIDs
2.=C2=A0 Be able to have > 1 MIDs.

And both of = those blow up my mental model of MIDs and could cause problems with other t= hings. =C2=A0=C2=A0


I think it would be l= ess risky to define a separate header extension for "multiplicity of c= hangable MIDs" rather than re-using the existing header extension, whe= n the semantics seems so much different (than my mental model, at least).

=C2=A0

On Fri, Jul 8, 2016 at 8:51 AM, Jonathan Lennox <jonathan@vidyo.com<mailto:jonathan@vidyo.com>> wrote:
The intention of my proposal is that these could indeed be (temporarily) th= e same RTP media source, even though they=E2=80=99re two separate m-lines.<= br>
On Jul 7, 2016, at 8:52 PM, Suhas Nandakumar <suhasietf@gmail.com<mailto:suhasietf@gmail.com>> wrote:
Hi Jonathan

=C2=A0 Clarification question :

=C2=A0 =C2=A0if we have 2 m=3Dlines

m =3D ...
a=3Dmid1
<manager>

m=3D...
a=3Dmid2
<loudest speaker>

does these 2 correspond to same media source ? It felt so from the duplicat= e design you mentioned but wanted to confirm

Thanks
Suhas



On Fri, Jul 8, 2016 at 4:06 AM, Jonathan Lennox <= ;jonathan@vidyo.com<mailto:jonathan@vidyo.com>> wrote: Hi, all =E2=80=94

(This was an issue I raised in AVTCORE in Buenos Aires =E2=80=94 I promised= to send e-mail to the list but hadn=E2=80=99t remembered to get around to = it until now.)

When finishing up the CLUE RTP mapping draft, I realized that one of CLUE= =E2=80=99s RTP requirements didn=E2=80=99t actually end up getting satisfie= d by BUNDLE (which is the solution CLUE converged on).=C2=A0 This isn=E2=80= =99t a CLUE-specific issue, so I=E2=80=99m raising it here.

The issue is whether we want to support a use case, in BUNDLE, where a sing= le RTP stream corresponds to more than media description (and thus has more= than one MID value)?

The use case is where one m-line has a semantic of =E2=80=9Calways view thi= s person=E2=80=9D (my boss, say, or my customer); and another m-line has a = semantic of =E2=80=9Cthe current loudest speaker=E2=80=9D. (In CLUE, these = would be a single content capture in the former case, and a switched captur= e for the latter.)=C2=A0 Whenever the boss *is* the current loudest speaker= , the same content would be sent for both m-lines.

A naive implementation would simply duplicate all the packets for the two m= -lines, with different MID values, but this has two problems.=C2=A0 First o= ff all, it obviously wastes bandwidth.=C2=A0 Potentially more seriously, it= precludes any RTP middlebox topology which doesn=E2=80=99t rewrite SSRC va= lues, since the same content (arriving with a single SSRC value at the midd= lebox) would need to be sent with two different SSRC values down from the m= iddlebox.=C2=A0 If PERC goes with its current consensus of no SSRC rewritin= g, this will particularly be a problem for PERC.

I certainly don=E2=80=99t think this is something that should block BUNDLE= =E2=80=99s completion, but I think it could be a pretty easy extension.

(My initial design proposal was to allow multiple SDES values of the same t= ype, and multiple SDES header extensions items of the same type, to be sent= simultaneously in RTP =E2=80=94 protocol-syntactically this is trivial, yo= u=E2=80=99d just need to negotiate that you support it.=C2=A0 But I=E2=80= =99m not wedded to this solution.)

What do people think =E2=80=94 is this worth working on?=C2=A0 Is there int= erest in discussing it in Berlin, and if so, in what venue?
_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/m= music



_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic




--001a113d3aacfa2b3a0537885d92-- From nobody Thu Jul 14 02:03:41 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5E12DC7D; Thu, 14 Jul 2016 02:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAhGQ6A3kB7G; Thu, 14 Jul 2016 02:03:37 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0106812DBED; Thu, 14 Jul 2016 02:03:20 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-f0-578755542107 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A0.A7.18043.55557875; Thu, 14 Jul 2016 11:03:17 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 11:03:16 +0200 From: Christer Holmberg To: Peter Thatcher , Jonathan Lennox Thread-Topic: [AVTCORE] [MMUSIC] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3FxhgzJSzoB0jUaPyXYYF7JSKaAWipKAgAEryIA= Date: Thu, 14 Jul 2016 09:03:16 +0000 Message-ID: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D3AD2F4ABEE3christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyM2K7im5oaHu4Qfc2XouXPSvZLfYvPs9s MXX5YxaLa8tfszqweCzYVOqxZMlPJo+2Z3fYA5ijuGxSUnMyy1KL9O0SuDI2nnjEXvB+G2PF 0i9fWBoY/21k7GLk5JAQMJF4ew/GFpO4cG89WxcjF4eQwBFGiccbL7JAOIsZJaZOewCU4eBg E7CQ6P6nDdIgIhAoMfPmV7BmZgEbib3rb7GC2MIC3hL9Pz4yQdT4SJz6dAzKtpL4cusxG4jN IqAq0b6/AayeFyj+/0oXO8Su70wSfxv/gA3lBFpwcMI2MJsR6Lrvp9YwQSwTl7j1ZD4TxNUC Ekv2nGeGsEUlXj7+BzZUVEBP4vvX2VBxRYn2pw1Qh8ZLvFu5lRFisaDEyZlPWCYwis1CMnYW krJZSMpmAb3PLKApsX6XPkSJosSU7ofsELaGROucuVC2tUTDrR3MyGoWMHKsYhQtTi0uzk03 MtJLLcpMLi7Oz9PLSy3ZxAiM34NbflvtYDz43PEQowAHoxIP74LGtnAh1sSy4srcQ4wSHMxK IrxCIe3hQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhhz q6XNfsRJidXL/u616brf9vnEqdrKHZcDN8/lfHSi4s++easkLG3LqhN+CCSenfcy8RWTrADb BRXBvx48zc4WXTvOTn+tsMN7g4ne8S/db1tNVY90rjXMDRJed+tv1Y7VVw90f51cNZP79z3O 62r9LsxXbQ89SU/QFT2zq4OvPOWQSha340olluKMREMt5qLiRAAwGwpf2wIAAA== Archived-At: Cc: IETF AVTCore WG , mmusic Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 09:03:39 -0000 --_000_D3AD2F4ABEE3christerholmbergericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KRmlyc3QsIHdvdWxkIHRoaXMgcmVhbGx5IGJlIHdvcnRoIHRoZSBlZmZvcnQ/DQoN Ckl04oCZcyB0cnVlIHRoYXQgc2VuZGluZyB0d28gaWRlbnRpY2FsIHN0cmVhbXMgKGluIEpvbmF0 aGFu4oCZcyBjYXNlIHdoZXJlIOKAnGJvc3PigJ0gYW5kIOKAnGxvdWRlc3Qgc3BlYWtlcuKAnSBh cmUgdGhlIHNhbWUgcGVyc29ucykgaXMgYSByZXNvdXJjZSB3YXN0ZS4gQnV0LCB0aGUgbmVlZGVk IHJlc291cmNlcyBtdXN0IGJlIGF2YWlsYWJsZSBhbnl3YXksIGFzIHRoZSDigJxsb3VkZXN0IHNw ZWFrZXLigJ0gY2FuIGNoYW5nZSBhdCBhbnkgdGltZS4NCg0KQWxzbywgdGhlcmUgc2VlbXMgdG8g YmUgc28gbWFueSBjb25zdHJhaW50cyAodGhlIGNvZGVjcywgcGF5bG9hZCB0eXBlcyBldGMgbXVz dCBvdmVybGFwKSwgc28gdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgaXQgd291bGQgYmUgdXNhYmxl IHRvIGJlZ2luIHdpdGguDQoNCg0KU2Vjb25kLCBJRiB3ZSB3YW50IHRvIGRvIHNvbWV0aGluZyBs aWtlIHRoaXMsIHNob3VsZCBpdCBpbnN0ZWFkIGJlIGRvbmUgb24gYSBoaWdoZXIgYXBwbGljYXRp b24vQ0xVRSBsYXllcj8gIFdoeSBzdGFydCBtaXhpbmcgdXAgdGhlIGxvd2VyLWxheWVyIE1JRCBz ZW1hbnRpY3MgZXRjPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBhdnQgPGF2dC1i b3VuY2VzQGlldGYub3JnPG1haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBv ZiAicHRoYXRjaGVyQGdvb2dsZS5jb208bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPiIgPHB0 aGF0Y2hlckBnb29nbGUuY29tPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4+DQpEYXRlOiBX ZWRuZXNkYXkgMTMgSnVseSAyMDE2IGF0IDIxOjE0DQpUbzogSm9uYXRoYW4gTGVubm94IDxqb25h dGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbT4+DQpDYzogImF2dEBpZXRm Lm9yZzxtYWlsdG86YXZ0QGlldGYub3JnPiIgPGF2dEBpZXRmLm9yZzxtYWlsdG86YXZ0QGlldGYu b3JnPj4sICJtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4iIDxtbXVzaWNA aWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0FWVENPUkVd IFtNTVVTSUNdIEJVTkRMRTogYSBzaW5nbGUgc3RyZWFtIHdpdGggbXVsdGlwbGUgTUlEcz8NCg0K DQoNCk9uIFR1ZSwgSnVsIDEyLCAyMDE2IGF0IDk6NDIgQU0sIEpvbmF0aGFuIExlbm5veCA8am9u YXRoYW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PiB3cm90ZToNCg0KT24g SnVsIDExLCAyMDE2LCBhdCAxOjQyIFBNLCBQZXRlciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdvb2ds ZS5jb208bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPjxtYWlsdG86cHRoYXRjaGVyQGdvb2ds ZS5jb208bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPj4+IHdyb3RlOg0KDQpCYXNpY2FsbHkg d2hhdCB5b3VyJ3JlIGFza2luZyBmb3IgaXMgaGVhZGVyIGV4dGVuc2lvbiB0aGF0IHNheXMgIk5v dCBvbmx5IGFtIEkgTUlEIFgsIGJ1dCBJJ20gYWxzbywgdGVtcG9yYXJpbHksIE1JRCBZIj8gICBX aHkgbm90IGp1c3QgaGF2ZSBhIHNlY29uZCwgc2VwYXJhdGUsIGhlYWRlciBleHRlbnNpb24gZm9y ICJJJ20gYWxzbyB0ZW1wb3JhcmlseSBNSUQgWSI/ICAgVGhlbiB0aGUgZXhpc3Rpbmcgc2VtYW50 aWNzIG9mIEJVTkRMRSBhbmQgTUlEIChhbmQgUklEcywgd2hpY2ggYXJlIHNjb3BlZCB0byBNSURz KSBuZWVkIG5vdCBjaGFuZ2UsIGJ1dCB5b3UgZ2V0IHRoZSBpbmZvcm1hdGlvbiB5b3UgbmVlZCAo SSB0aGluaykuDQoNClRoZSB0aGluZyBpcywgYWxsIE1JRCB2YWx1ZXMgYXJlLCBjb25jZXB0dWFs bHksIHRlbXBvcmFyeSDigJQgdGhleSBjYW4gY2hhbmdlIGF0IGFueSB0aW1lLiAgU28gaXMgaXQg cmVhbGx5IG1lYW5pbmdmdWwgdG8gZGlzdGluZ3Vpc2ggc2hvcnQtdGVybSB0ZW1wb3JhcnkgZnJv bSBsb25nLXRlcm0gdGVtcG9yYXJ5PyAgV2hlcmUgZG8geW91IGRyYXcgdGhlIGxpbmU/DQoNCuKA i1RoYXQgZG9lc24ndCBtYXRjaCBteSBtZW50YWwgbW9kZWwgb2YgTUlEcy4gICBJJ3ZlIGFsd2F5 cyB0aG91Z2h0IG9mIGFuIFJUUCBzdHJlYW0gYXMgYmVpbmcgYm91bmQgdG8gYSBwYXJ0aWN1bGFy IE1JRCwgbm90IGFibGUgdG8gY2hhbmdlIGJldHdlZW4gdmFyaW91cyBNSURzLiAgSSBtaWdodCBi ZSB3cm9uZywgYnV0IGl0IHNlZW1zIGxpa2UgdGhlcmUgYXJlIHdlaXJkIGVkZ2UgY2FzZXMgd2l0 aCBzd2l0Y2hpbmcgTUlEcywgc3VjaCBhcyBob3cgUklEcyBwbGF5IGludG8gaXQgKHNpbmNlIHRo ZXkgYXJlIHNjb3BlZCB0byBNSURzKS4gIEFub3RoZXIgaXMgdGhlIGRlbXV4IGFsZ29yaXRobSBp biBXZWJSVEMvT1JUQyB3aGljaCAibG9ja3Mgb24iIHRvIFNTUkNzIGFuZCBvbmx5IGxvb2tzIGF0 IE1JRHMgaWYgdGhlIFNTUkNzIGFyZSB1bmtub3duICh0aGUgZGVtdXggYWxnb3JpdGhtIGNlcnRh aW5seSBkb2VzIG5vdCB0YWtlIGludG8gYWNjb3VudCBkZW11eGluZyBhIHBhY2tldCBpbnRvIG11 bHRpcGxlIFJ0cFJlY2VpdmVycykuDQoNClNvIGl0IHNvdW5kcyBsaWtlIHlvdSBhcmUgYXNraW5n IGZvciB0d28gdGhpbmdzOg0KMS4gIEJlIGFibGUgdG8gc3dpdGNoIE1JRHMNCjIuICBCZSBhYmxl IHRvIGhhdmUgPiAxIE1JRHMuDQoNCkFuZCBib3RoIG9mIHRob3NlIGJsb3cgdXAgbXkgbWVudGFs IG1vZGVsIG9mIE1JRHMgYW5kIGNvdWxkIGNhdXNlIHByb2JsZW1zIHdpdGggb3RoZXIgdGhpbmdz Lg0KDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgbGVzcyByaXNreSB0byBkZWZpbmUgYSBzZXBhcmF0 ZSBoZWFkZXIgZXh0ZW5zaW9uIGZvciAibXVsdGlwbGljaXR5IG9mIGNoYW5nYWJsZSBNSURzIiBy YXRoZXIgdGhhbiByZS11c2luZyB0aGUgZXhpc3RpbmcgaGVhZGVyIGV4dGVuc2lvbiwgd2hlbiB0 aGUgc2VtYW50aWNzIHNlZW1zIHNvIG11Y2ggZGlmZmVyZW50ICh0aGFuIG15IG1lbnRhbCBtb2Rl bCwgYXQgbGVhc3QpLg0KDQoNCg0KT24gRnJpLCBKdWwgOCwgMjAxNiBhdCA4OjUxIEFNLCBKb25h dGhhbiBMZW5ub3ggPGpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRoYW5AdmlkeW8uY29t PjxtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+Pj4g d3JvdGU6DQpUaGUgaW50ZW50aW9uIG9mIG15IHByb3Bvc2FsIGlzIHRoYXQgdGhlc2UgY291bGQg aW5kZWVkIGJlICh0ZW1wb3JhcmlseSkgdGhlIHNhbWUgUlRQIG1lZGlhIHNvdXJjZSwgZXZlbiB0 aG91Z2ggdGhleeKAmXJlIHR3byBzZXBhcmF0ZSBtLWxpbmVzLg0KDQpPbiBKdWwgNywgMjAxNiwg YXQgODo1MiBQTSwgU3VoYXMgTmFuZGFrdW1hciA8c3VoYXNpZXRmQGdtYWlsLmNvbTxtYWlsdG86 c3VoYXNpZXRmQGdtYWlsLmNvbT48bWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb208bWFpbHRvOnN1 aGFzaWV0ZkBnbWFpbC5jb20+Pj4gd3JvdGU6DQoNCkhpIEpvbmF0aGFuDQoNCiAgQ2xhcmlmaWNh dGlvbiBxdWVzdGlvbiA6DQoNCiAgIGlmIHdlIGhhdmUgMiBtPWxpbmVzDQoNCm0gPSAuLi4NCmE9 bWlkMQ0KPG1hbmFnZXI+DQoNCm09Li4uDQphPW1pZDINCjxsb3VkZXN0IHNwZWFrZXI+DQoNCmRv ZXMgdGhlc2UgMiBjb3JyZXNwb25kIHRvIHNhbWUgbWVkaWEgc291cmNlID8gSXQgZmVsdCBzbyBm cm9tIHRoZSBkdXBsaWNhdGUgZGVzaWduIHlvdSBtZW50aW9uZWQgYnV0IHdhbnRlZCB0byBjb25m aXJtDQoNClRoYW5rcw0KU3VoYXMNCg0KDQoNCk9uIEZyaSwgSnVsIDgsIDIwMTYgYXQgNDowNiBB TSwgSm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZp ZHlvLmNvbT48bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbTxtYWlsdG86am9uYXRoYW5AdmlkeW8u Y29tPj4+IHdyb3RlOg0KSGksIGFsbCDigJQNCg0KKFRoaXMgd2FzIGFuIGlzc3VlIEkgcmFpc2Vk IGluIEFWVENPUkUgaW4gQnVlbm9zIEFpcmVzIOKAlCBJIHByb21pc2VkIHRvIHNlbmQgZS1tYWls IHRvIHRoZSBsaXN0IGJ1dCBoYWRu4oCZdCByZW1lbWJlcmVkIHRvIGdldCBhcm91bmQgdG8gaXQg dW50aWwgbm93LikNCg0KV2hlbiBmaW5pc2hpbmcgdXAgdGhlIENMVUUgUlRQIG1hcHBpbmcgZHJh ZnQsIEkgcmVhbGl6ZWQgdGhhdCBvbmUgb2YgQ0xVReKAmXMgUlRQIHJlcXVpcmVtZW50cyBkaWRu 4oCZdCBhY3R1YWxseSBlbmQgdXAgZ2V0dGluZyBzYXRpc2ZpZWQgYnkgQlVORExFICh3aGljaCBp cyB0aGUgc29sdXRpb24gQ0xVRSBjb252ZXJnZWQgb24pLiAgVGhpcyBpc27igJl0IGEgQ0xVRS1z cGVjaWZpYyBpc3N1ZSwgc28gSeKAmW0gcmFpc2luZyBpdCBoZXJlLg0KDQpUaGUgaXNzdWUgaXMg d2hldGhlciB3ZSB3YW50IHRvIHN1cHBvcnQgYSB1c2UgY2FzZSwgaW4gQlVORExFLCB3aGVyZSBh IHNpbmdsZSBSVFAgc3RyZWFtIGNvcnJlc3BvbmRzIHRvIG1vcmUgdGhhbiBtZWRpYSBkZXNjcmlw dGlvbiAoYW5kIHRodXMgaGFzIG1vcmUgdGhhbiBvbmUgTUlEIHZhbHVlKT8NCg0KVGhlIHVzZSBj YXNlIGlzIHdoZXJlIG9uZSBtLWxpbmUgaGFzIGEgc2VtYW50aWMgb2Yg4oCcYWx3YXlzIHZpZXcg dGhpcyBwZXJzb27igJ0gKG15IGJvc3MsIHNheSwgb3IgbXkgY3VzdG9tZXIpOyBhbmQgYW5vdGhl ciBtLWxpbmUgaGFzIGEgc2VtYW50aWMgb2Yg4oCcdGhlIGN1cnJlbnQgbG91ZGVzdCBzcGVha2Vy 4oCdLiAoSW4gQ0xVRSwgdGhlc2Ugd291bGQgYmUgYSBzaW5nbGUgY29udGVudCBjYXB0dXJlIGlu IHRoZSBmb3JtZXIgY2FzZSwgYW5kIGEgc3dpdGNoZWQgY2FwdHVyZSBmb3IgdGhlIGxhdHRlci4p ICBXaGVuZXZlciB0aGUgYm9zcyAqaXMqIHRoZSBjdXJyZW50IGxvdWRlc3Qgc3BlYWtlciwgdGhl IHNhbWUgY29udGVudCB3b3VsZCBiZSBzZW50IGZvciBib3RoIG0tbGluZXMuDQoNCkEgbmFpdmUg aW1wbGVtZW50YXRpb24gd291bGQgc2ltcGx5IGR1cGxpY2F0ZSBhbGwgdGhlIHBhY2tldHMgZm9y IHRoZSB0d28gbS1saW5lcywgd2l0aCBkaWZmZXJlbnQgTUlEIHZhbHVlcywgYnV0IHRoaXMgaGFz IHR3byBwcm9ibGVtcy4gIEZpcnN0IG9mZiBhbGwsIGl0IG9idmlvdXNseSB3YXN0ZXMgYmFuZHdp ZHRoLiAgUG90ZW50aWFsbHkgbW9yZSBzZXJpb3VzbHksIGl0IHByZWNsdWRlcyBhbnkgUlRQIG1p ZGRsZWJveCB0b3BvbG9neSB3aGljaCBkb2VzbuKAmXQgcmV3cml0ZSBTU1JDIHZhbHVlcywgc2lu Y2UgdGhlIHNhbWUgY29udGVudCAoYXJyaXZpbmcgd2l0aCBhIHNpbmdsZSBTU1JDIHZhbHVlIGF0 IHRoZSBtaWRkbGVib3gpIHdvdWxkIG5lZWQgdG8gYmUgc2VudCB3aXRoIHR3byBkaWZmZXJlbnQg U1NSQyB2YWx1ZXMgZG93biBmcm9tIHRoZSBtaWRkbGVib3guICBJZiBQRVJDIGdvZXMgd2l0aCBp dHMgY3VycmVudCBjb25zZW5zdXMgb2Ygbm8gU1NSQyByZXdyaXRpbmcsIHRoaXMgd2lsbCBwYXJ0 aWN1bGFybHkgYmUgYSBwcm9ibGVtIGZvciBQRVJDLg0KDQpJIGNlcnRhaW5seSBkb27igJl0IHRo aW5rIHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGJsb2NrIEJVTkRMReKAmXMgY29tcGxl dGlvbiwgYnV0IEkgdGhpbmsgaXQgY291bGQgYmUgYSBwcmV0dHkgZWFzeSBleHRlbnNpb24uDQoN CihNeSBpbml0aWFsIGRlc2lnbiBwcm9wb3NhbCB3YXMgdG8gYWxsb3cgbXVsdGlwbGUgU0RFUyB2 YWx1ZXMgb2YgdGhlIHNhbWUgdHlwZSwgYW5kIG11bHRpcGxlIFNERVMgaGVhZGVyIGV4dGVuc2lv bnMgaXRlbXMgb2YgdGhlIHNhbWUgdHlwZSwgdG8gYmUgc2VudCBzaW11bHRhbmVvdXNseSBpbiBS VFAg4oCUIHByb3RvY29sLXN5bnRhY3RpY2FsbHkgdGhpcyBpcyB0cml2aWFsLCB5b3XigJlkIGp1 c3QgbmVlZCB0byBuZWdvdGlhdGUgdGhhdCB5b3Ugc3VwcG9ydCBpdC4gIEJ1dCBJ4oCZbSBub3Qg d2VkZGVkIHRvIHRoaXMgc29sdXRpb24uKQ0KDQpXaGF0IGRvIHBlb3BsZSB0aGluayDigJQgaXMg dGhpcyB3b3J0aCB3b3JraW5nIG9uPyAgSXMgdGhlcmUgaW50ZXJlc3QgaW4gZGlzY3Vzc2luZyBp dCBpbiBCZXJsaW4sIGFuZCBpZiBzbywgaW4gd2hhdCB2ZW51ZT8NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVz aWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz48bWFpbHRvOm1tdXNpY0BpZXRmLm9y ZzxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0 bzptbXVzaWNAaWV0Zi5vcmc+PG1haWx0bzptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0Bp ZXRmLm9yZz4+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K DQoNCg0KDQo= --_000_D3AD2F4ABEE3christerholmbergericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SGksPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5GaXJzdCwgd291bGQg dGhpcyByZWFsbHkgYmUgd29ydGggdGhlIGVmZm9ydD8mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pkl04oCZcyB0cnVlIHRoYXQgc2VuZGluZyB0d28gaWRlbnRpY2FsIHN0cmVh bXMgKGluIEpvbmF0aGFu4oCZcyBjYXNlIHdoZXJlIOKAnGJvc3PigJ0gYW5kIOKAnGxvdWRlc3Qg c3BlYWtlcuKAnSBhcmUgdGhlIHNhbWUgcGVyc29ucykgaXMgYSByZXNvdXJjZSB3YXN0ZS4gQnV0 LCB0aGUgbmVlZGVkIHJlc291cmNlcyBtdXN0IGJlIGF2YWlsYWJsZSBhbnl3YXksIGFzIHRoZSDi gJxsb3VkZXN0IHNwZWFrZXLigJ0gY2FuIGNoYW5nZSBhdCBhbnkgdGltZS48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkFsc28sIHRoZXJlIHNlZW1zIHRvIGJlIHNvIG1hbnkgY29uc3Ry YWludHMgKHRoZSBjb2RlY3MsIHBheWxvYWQgdHlwZXMgZXRjIG11c3Qgb3ZlcmxhcCksIHNvIHRo ZSBxdWVzdGlvbiBpcyB3aGV0aGVyIGl0IHdvdWxkIGJlIHVzYWJsZSB0byBiZWdpbiB3aXRoLjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNlY29uZCwg SUYgd2Ugd2FudCB0byBkbyBzb21ldGhpbmcgbGlrZSB0aGlzLCBzaG91bGQgaXQgaW5zdGVhZCBi ZSBkb25lIG9uIGEgaGlnaGVyIGFwcGxpY2F0aW9uL0NMVUUgbGF5ZXI/ICZuYnNwO1doeSBzdGFy dCBtaXhpbmcgdXAgdGhlIGxvd2VyLWxheWVyIE1JRCBzZW1hbnRpY3MgZXRjPzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkNocmlzdGVyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6 ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRp dW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQ QURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRm IDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPmF2dCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnIj5hdnQtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2ds ZS5jb20iPnB0aGF0Y2hlckBnb29nbGUuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnB0aGF0Y2hlckBnb29nbGUuY29tIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXkgMTMg SnVseSAyMDE2IGF0IDIxOjE0PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv OiA8L3NwYW4+Sm9uYXRoYW4gTGVubm94ICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5Admlk eW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5v cmciPmF2dEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5v cmciPmF2dEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGll dGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW11 c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtBVlRDT1JFXSBbTU1VU0lDXSBC VU5ETEU6IGEgc2luZ2xlIHN0cmVhbSB3aXRoIG11bHRpcGxlIE1JRHM/PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZiI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgSnVsIDEyLCAyMDE2IGF0IDk6NDIgQU0sIEpv bmF0aGFuIExlbm5veCA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmpvbmF0 aGFuQHZpZHlvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvbmF0aGFuQHZpZHlvLmNvbTwvYT4mZ3Q7 PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCjxzcGFuIGNsYXNzPSIiPjxicj4NCk9uIEp1bCAxMSwgMjAxNiwgYXQgMTo0MiBQ TSwgUGV0ZXIgVGhhdGNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNv bSI+cHRoYXRjaGVyQGdvb2dsZS5jb208L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cHRo YXRjaGVyQGdvb2dsZS5jb20iPnB0aGF0Y2hlckBnb29nbGUuY29tPC9hPiZndDsmZ3Q7IHdyb3Rl Ojxicj4NCjxicj4NCkJhc2ljYWxseSB3aGF0IHlvdXIncmUgYXNraW5nIGZvciBpcyBoZWFkZXIg ZXh0ZW5zaW9uIHRoYXQgc2F5cyAmcXVvdDtOb3Qgb25seSBhbSBJIE1JRCBYLCBidXQgSSdtIGFs c28sIHRlbXBvcmFyaWx5LCBNSUQgWSZxdW90Oz8mbmJzcDsgJm5ic3A7V2h5IG5vdCBqdXN0IGhh dmUgYSBzZWNvbmQsIHNlcGFyYXRlLCBoZWFkZXIgZXh0ZW5zaW9uIGZvciAmcXVvdDtJJ20gYWxz byB0ZW1wb3JhcmlseSBNSUQgWSZxdW90Oz8mbmJzcDsgJm5ic3A7VGhlbiB0aGUgZXhpc3Rpbmcg c2VtYW50aWNzIG9mIEJVTkRMRSBhbmQgTUlEDQogKGFuZCBSSURzLCB3aGljaCBhcmUgc2NvcGVk IHRvIE1JRHMpIG5lZWQgbm90IGNoYW5nZSwgYnV0IHlvdSBnZXQgdGhlIGluZm9ybWF0aW9uIHlv dSBuZWVkIChJIHRoaW5rKS48YnI+DQo8YnI+DQo8L3NwYW4+VGhlIHRoaW5nIGlzLCBhbGwgTUlE IHZhbHVlcyBhcmUsIGNvbmNlcHR1YWxseSwgdGVtcG9yYXJ5IOKAlCB0aGV5IGNhbiBjaGFuZ2Ug YXQgYW55IHRpbWUuJm5ic3A7IFNvIGlzIGl0IHJlYWxseSBtZWFuaW5nZnVsIHRvIGRpc3Rpbmd1 aXNoIHNob3J0LXRlcm0gdGVtcG9yYXJ5IGZyb20gbG9uZy10ZXJtIHRlbXBvcmFyeT8mbmJzcDsg V2hlcmUgZG8geW91IGRyYXcgdGhlIGxpbmU/PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPuKAi1RoYXQgZG9lc24ndCBtYXRjaCBt eSBtZW50YWwgbW9kZWwgb2YgTUlEcy4gJm5ic3A7IEkndmUgYWx3YXlzIHRob3VnaHQgb2YgYW4g UlRQIHN0cmVhbSBhcyBiZWluZyBib3VuZCB0byBhIHBhcnRpY3VsYXIgTUlELCBub3QgYWJsZSB0 byBjaGFuZ2UgYmV0d2VlbiB2YXJpb3VzIE1JRHMuJm5ic3A7IEkgbWlnaHQgYmUgd3JvbmcsIGJ1 dA0KIGl0IHNlZW1zIGxpa2UgdGhlcmUgYXJlIHdlaXJkIGVkZ2UgY2FzZXMgd2l0aCBzd2l0Y2hp bmcgTUlEcywgc3VjaCBhcyBob3cgUklEcyBwbGF5IGludG8gaXQgKHNpbmNlIHRoZXkgYXJlIHNj b3BlZCB0byBNSURzKS4mbmJzcDsgQW5vdGhlciBpcyB0aGUgZGVtdXggYWxnb3JpdGhtIGluIFdl YlJUQy9PUlRDIHdoaWNoICZxdW90O2xvY2tzIG9uJnF1b3Q7IHRvIFNTUkNzIGFuZCBvbmx5IGxv b2tzIGF0IE1JRHMgaWYgdGhlIFNTUkNzIGFyZSB1bmtub3duICh0aGUgZGVtdXgNCiBhbGdvcml0 aG0gY2VydGFpbmx5IGRvZXMgbm90IHRha2UgaW50byBhY2NvdW50IGRlbXV4aW5nIGEgcGFja2V0 IGludG8gbXVsdGlwbGUgUnRwUmVjZWl2ZXJzKS4gJm5ic3A7Jm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWYiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj5TbyBpdCBzb3VuZHMgbGlr ZSB5b3UgYXJlIGFza2luZyBmb3IgdHdvIHRoaW5nczo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+ MS4mbmJzcDsgQmUgYWJsZSB0byBzd2l0Y2ggTUlEczwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj4y LiZuYnNwOyBCZSBhYmxlIHRvIGhhdmUgJmd0OyAxIE1JRHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2Vy aWYiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj5BbmQgYm90aCBvZiB0aG9zZSBibG93 IHVwIG15IG1lbnRhbCBtb2RlbCBvZiBNSURzIGFuZCBjb3VsZCBjYXVzZSBwcm9ibGVtcyB3aXRo IG90aGVyIHRoaW5ncy4gJm5ic3A7Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZh dWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxicj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+ SSB0aGluayBpdCB3b3VsZCBiZSBsZXNzIHJpc2t5IHRvIGRlZmluZSBhIHNlcGFyYXRlIGhlYWRl ciBleHRlbnNpb24gZm9yICZxdW90O211bHRpcGxpY2l0eSBvZiBjaGFuZ2FibGUgTUlEcyZxdW90 OyByYXRoZXIgdGhhbiByZS11c2luZyB0aGUgZXhpc3RpbmcgaGVhZGVyIGV4dGVuc2lvbiwgd2hl biB0aGUgc2VtYW50aWNzIHNlZW1zDQogc28gbXVjaCBkaWZmZXJlbnQgKHRoYW4gbXkgbWVudGFs IG1vZGVsLCBhdCBsZWFzdCkuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxzcGFuIGNsYXNzPSIiPjxicj4NCk9uIEZyaSwg SnVsIDgsIDIwMTYgYXQgODo1MSBBTSwgSm9uYXRoYW4gTGVubm94ICZsdDs8YSBocmVmPSJtYWls dG86am9uYXRoYW5AdmlkeW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+ Jmd0OyZndDsgd3JvdGU6PGJyPg0KVGhlIGludGVudGlvbiBvZiBteSBwcm9wb3NhbCBpcyB0aGF0 IHRoZXNlIGNvdWxkIGluZGVlZCBiZSAodGVtcG9yYXJpbHkpIHRoZSBzYW1lIFJUUCBtZWRpYSBz b3VyY2UsIGV2ZW4gdGhvdWdoIHRoZXnigJlyZSB0d28gc2VwYXJhdGUgbS1saW5lcy48YnI+DQo8 YnI+DQo8L3NwYW4+PHNwYW4gY2xhc3M9IiI+T24gSnVsIDcsIDIwMTYsIGF0IDg6NTIgUE0sIFN1 aGFzIE5hbmRha3VtYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tIj5z dWhhc2lldGZAZ21haWwuY29tPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnN1aGFzaWV0 ZkBnbWFpbC5jb20iPnN1aGFzaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0K PGJyPg0KSGkgSm9uYXRoYW48YnI+DQo8YnI+DQombmJzcDsgQ2xhcmlmaWNhdGlvbiBxdWVzdGlv biA6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO2lmIHdlIGhhdmUgMiBtPWxpbmVzPGJyPg0KPGJy Pg0KbSA9IC4uLjxicj4NCmE9bWlkMTxicj4NCiZsdDttYW5hZ2VyJmd0Ozxicj4NCjxicj4NCm09 Li4uPGJyPg0KYT1taWQyPGJyPg0KJmx0O2xvdWRlc3Qgc3BlYWtlciZndDs8YnI+DQo8YnI+DQpk b2VzIHRoZXNlIDIgY29ycmVzcG9uZCB0byBzYW1lIG1lZGlhIHNvdXJjZSA/IEl0IGZlbHQgc28g ZnJvbSB0aGUgZHVwbGljYXRlIGRlc2lnbiB5b3UgbWVudGlvbmVkIGJ1dCB3YW50ZWQgdG8gY29u ZmlybTxicj4NCjxicj4NClRoYW5rczxicj4NClN1aGFzPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PC9zcGFuPjxzcGFuIGNsYXNzPSIiPk9uIEZyaSwgSnVsIDgsIDIwMTYgYXQgNDowNiBBTSwgSm9u YXRoYW4gTGVubm94ICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIj5qb25h dGhhbkB2aWR5by5jb208L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86am9uYXRoYW5Admlk eW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KSGksIGFs bCDigJQ8YnI+DQo8YnI+DQooVGhpcyB3YXMgYW4gaXNzdWUgSSByYWlzZWQgaW4gQVZUQ09SRSBp biBCdWVub3MgQWlyZXMg4oCUIEkgcHJvbWlzZWQgdG8gc2VuZCBlLW1haWwgdG8gdGhlIGxpc3Qg YnV0IGhhZG7igJl0IHJlbWVtYmVyZWQgdG8gZ2V0IGFyb3VuZCB0byBpdCB1bnRpbCBub3cuKTxi cj4NCjxicj4NCldoZW4gZmluaXNoaW5nIHVwIHRoZSBDTFVFIFJUUCBtYXBwaW5nIGRyYWZ0LCBJ IHJlYWxpemVkIHRoYXQgb25lIG9mIENMVUXigJlzIFJUUCByZXF1aXJlbWVudHMgZGlkbuKAmXQg YWN0dWFsbHkgZW5kIHVwIGdldHRpbmcgc2F0aXNmaWVkIGJ5IEJVTkRMRSAod2hpY2ggaXMgdGhl IHNvbHV0aW9uIENMVUUgY29udmVyZ2VkIG9uKS4mbmJzcDsgVGhpcyBpc27igJl0IGEgQ0xVRS1z cGVjaWZpYyBpc3N1ZSwgc28gSeKAmW0gcmFpc2luZyBpdCBoZXJlLjxicj4NCjxicj4NClRoZSBp c3N1ZSBpcyB3aGV0aGVyIHdlIHdhbnQgdG8gc3VwcG9ydCBhIHVzZSBjYXNlLCBpbiBCVU5ETEUs IHdoZXJlIGEgc2luZ2xlIFJUUCBzdHJlYW0gY29ycmVzcG9uZHMgdG8gbW9yZSB0aGFuIG1lZGlh IGRlc2NyaXB0aW9uIChhbmQgdGh1cyBoYXMgbW9yZSB0aGFuIG9uZSBNSUQgdmFsdWUpPzxicj4N Cjxicj4NClRoZSB1c2UgY2FzZSBpcyB3aGVyZSBvbmUgbS1saW5lIGhhcyBhIHNlbWFudGljIG9m IOKAnGFsd2F5cyB2aWV3IHRoaXMgcGVyc29u4oCdIChteSBib3NzLCBzYXksIG9yIG15IGN1c3Rv bWVyKTsgYW5kIGFub3RoZXIgbS1saW5lIGhhcyBhIHNlbWFudGljIG9mIOKAnHRoZSBjdXJyZW50 IGxvdWRlc3Qgc3BlYWtlcuKAnS4gKEluIENMVUUsIHRoZXNlIHdvdWxkIGJlIGEgc2luZ2xlIGNv bnRlbnQgY2FwdHVyZSBpbiB0aGUgZm9ybWVyIGNhc2UsIGFuZCBhIHN3aXRjaGVkDQogY2FwdHVy ZSBmb3IgdGhlIGxhdHRlci4pJm5ic3A7IFdoZW5ldmVyIHRoZSBib3NzICppcyogdGhlIGN1cnJl bnQgbG91ZGVzdCBzcGVha2VyLCB0aGUgc2FtZSBjb250ZW50IHdvdWxkIGJlIHNlbnQgZm9yIGJv dGggbS1saW5lcy48YnI+DQo8YnI+DQpBIG5haXZlIGltcGxlbWVudGF0aW9uIHdvdWxkIHNpbXBs eSBkdXBsaWNhdGUgYWxsIHRoZSBwYWNrZXRzIGZvciB0aGUgdHdvIG0tbGluZXMsIHdpdGggZGlm ZmVyZW50IE1JRCB2YWx1ZXMsIGJ1dCB0aGlzIGhhcyB0d28gcHJvYmxlbXMuJm5ic3A7IEZpcnN0 IG9mZiBhbGwsIGl0IG9idmlvdXNseSB3YXN0ZXMgYmFuZHdpZHRoLiZuYnNwOyBQb3RlbnRpYWxs eSBtb3JlIHNlcmlvdXNseSwgaXQgcHJlY2x1ZGVzIGFueSBSVFAgbWlkZGxlYm94IHRvcG9sb2d5 IHdoaWNoDQogZG9lc27igJl0IHJld3JpdGUgU1NSQyB2YWx1ZXMsIHNpbmNlIHRoZSBzYW1lIGNv bnRlbnQgKGFycml2aW5nIHdpdGggYSBzaW5nbGUgU1NSQyB2YWx1ZSBhdCB0aGUgbWlkZGxlYm94 KSB3b3VsZCBuZWVkIHRvIGJlIHNlbnQgd2l0aCB0d28gZGlmZmVyZW50IFNTUkMgdmFsdWVzIGRv d24gZnJvbSB0aGUgbWlkZGxlYm94LiZuYnNwOyBJZiBQRVJDIGdvZXMgd2l0aCBpdHMgY3VycmVu dCBjb25zZW5zdXMgb2Ygbm8gU1NSQyByZXdyaXRpbmcsIHRoaXMgd2lsbA0KIHBhcnRpY3VsYXJs eSBiZSBhIHByb2JsZW0gZm9yIFBFUkMuPGJyPg0KPGJyPg0KSSBjZXJ0YWlubHkgZG9u4oCZdCB0 aGluayB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBibG9jayBCVU5ETEXigJlzIGNvbXBs ZXRpb24sIGJ1dCBJIHRoaW5rIGl0IGNvdWxkIGJlIGEgcHJldHR5IGVhc3kgZXh0ZW5zaW9uLjxi cj4NCjxicj4NCihNeSBpbml0aWFsIGRlc2lnbiBwcm9wb3NhbCB3YXMgdG8gYWxsb3cgbXVsdGlw bGUgU0RFUyB2YWx1ZXMgb2YgdGhlIHNhbWUgdHlwZSwgYW5kIG11bHRpcGxlIFNERVMgaGVhZGVy IGV4dGVuc2lvbnMgaXRlbXMgb2YgdGhlIHNhbWUgdHlwZSwgdG8gYmUgc2VudCBzaW11bHRhbmVv dXNseSBpbiBSVFAg4oCUIHByb3RvY29sLXN5bnRhY3RpY2FsbHkgdGhpcyBpcyB0cml2aWFsLCB5 b3XigJlkIGp1c3QgbmVlZCB0byBuZWdvdGlhdGUgdGhhdCB5b3Ugc3VwcG9ydA0KIGl0LiZuYnNw OyBCdXQgSeKAmW0gbm90IHdlZGRlZCB0byB0aGlzIHNvbHV0aW9uLik8YnI+DQo8YnI+DQpXaGF0 IGRvIHBlb3BsZSB0aGluayDigJQgaXMgdGhpcyB3b3J0aCB3b3JraW5nIG9uPyZuYnNwOyBJcyB0 aGVyZSBpbnRlcmVzdCBpbiBkaXNjdXNzaW5nIGl0IGluIEJlcmxpbiwgYW5kIGlmIHNvLCBpbiB3 aGF0IHZlbnVlPzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWls dG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmx0O21haWx0bzo8YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz cGFuIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW11c2ljIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1t dXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRm Lm9yZyI+bW11c2ljQGlldGYub3JnPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1tdXNp Y0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWM8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_D3AD2F4ABEE3christerholmbergericssoncom_-- From nobody Thu Jul 14 02:16:45 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA7B12DFAD for ; Thu, 14 Jul 2016 02:16:41 -0700 (PDT) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com 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 q2PLBfCECHvW for ; Thu, 14 Jul 2016 02:16:39 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AE112DE57 for ; Thu, 14 Jul 2016 02:14:05 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v186so5287331ywd.0 for ; Thu, 14 Jul 2016 02:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wz7bqGpuSZN8qY6dackoHBi3A9PONOswWMD9OMYwS58=; b=dTw3UjriUWL/e7EPFMB9rwhVRO1pAE17x9bx+vR0ASpr0cxG/rocfGQu6xriHU6c1S GH2Ldep44X4u/20Hz2iOpDjz7M+pCaircubMt+JNDLhj617uwtpuCGfWwBqeI43k/HwU nVmRCc6/XqFw9x96HlrNewk9DVFss4PlnmKAsJwA7oZ4gTzrEizc+PmBKruPXWZTuVhs EPioZXRxm/cas8ARxuXXHfs+KpFJdknwtAwUDwJjsymqT0fU0qVGMCyv0VZdjGgX/dGC sIihxPFrCVnNb6FYfGDLY0g12DR0nFtKbAsPXPED8Pk/u/JrAOH6qmhHRALw16v0Y2EL oyUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wz7bqGpuSZN8qY6dackoHBi3A9PONOswWMD9OMYwS58=; b=AGq6Vbol9cUKYV4QUWaCXTi9IvQ8VH+/edVW57xwn/Taq4YSm69mNfNeBLtZLkh6kg FvOd2ExN0oL0SWfdnjwVOvCK1tJwOVVhroYf46pDRhD2YBi0ugJVlgKEutKkxODLJxW3 WYXsH5E211Uxw/KyZQJQhD+hLmtVq3s+rP4Nrp10JmGgU5PA+6eFkGLXWNHsAKfuAidF 76coBTj9B2ttWjrakQ/8K+qZAlX1KCfHllNFAjXbWrT3eRh3PqsHIfLTMzuS22KrcaCf DTmPS8/rhfZCOKyLjkbYBvNLr4z6W31LeHlqB7gM2VKWIFEmb77siJuwMFSYDY9VSKzO 3DXA== X-Gm-Message-State: ALyK8tIFda4jiLWnJAz4FVifehm733AFRruGv8GHHiWRDes5SA5TCBTtJ8TJ9nxepjRLaF5IiFXAObmj3+kneg== X-Received: by 10.13.255.71 with SMTP id p68mr8832476ywf.101.1468487644622; Thu, 14 Jul 2016 02:14:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.33.213 with HTTP; Thu, 14 Jul 2016 02:13:45 -0700 (PDT) In-Reply-To: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 14 Jul 2016 11:13:45 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jonathan Lennox , mmusic , IETF AVTCore WG Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 09:16:42 -0000 2016-07-14 11:03 GMT+02:00 Christer Holmberg : > Second, IF we want to do something like this, should it instead be done o= n a > higher application/CLUE layer? Why start mixing up the lower-layer MID > semantics etc? Some ugly stuff regarding SDP is the fact that m-lines are indexed by their position, which means that they cannot be removed within the same session. Then a=3Dmid comes to the rescue and provides a per m-line unique identifier, leaving the door open for a future spec change allowing m-lines removal (have you ever seen how an SDP from a SFU with participants entering and leaving the room grows?). The current proposal breaks that. Please let's MID to be a single, unique and mandatory attribute per m-line. --=20 I=C3=B1aki Baz Castillo From nobody Thu Jul 14 02:57:44 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7CD12DF95; Thu, 14 Jul 2016 02:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2jtXnnRLgJ1; Thu, 14 Jul 2016 02:57:42 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1E412E04C; Thu, 14 Jul 2016 02:57:41 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-1f-57876213bf03 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 50.33.12926.31267875; Thu, 14 Jul 2016 11:57:39 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 11:57:38 +0200 From: Christer Holmberg To: =?Windows-1252?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3bAROwJOMhyFBkK2BP9Ud+cjzqAXwuOA Date: Thu, 14 Jul 2016 09:57:38 +0000 Message-ID: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2331E59ABC51A94DB68E83FD934A2092@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyM2K7va5wUnu4we8ZBhYve1ayW0zfZ2Ox f/F5Zoupyx+zWFxb/prVgdXjXMN7do8Fm0o9liz5yeTR9uwOewBLFJdNSmpOZllqkb5dAlfG mpN7WQomsFT827ibqYFxCXMXIyeHhICJxKUZmxghbDGJC/fWs3UxcnEICRxhlDj28CcrhLOY UeJpyxagKg4ONgELie5/2iANIgLWEo/mnwFrYBboZZT40trIDpIQFvCWOLFnPTtEkY/ExsZf bCC9IgJGEn0v9UDCLAKqEo9urQQ7glfASuL07U1MELveM0t0P5vMCpLgFAiU+HP/A5jNCHTd 91NrmEBsZgFxiVtP5jNBXC0gsWTPeahvRCVePv4HVi8qoCfx/etsqLiixNXpy6F6DSTen5vP DHIPM9AD++9EQ4S1JZYtfA11j6DEyZlPWCYwSsxCsm0Wku5ZCN2zkHTPQtK9gJF1FaNocWpx Um66kbFealFmcnFxfp5eXmrJJkZgzB7c8lt1B+PlN46HGAU4GJV4eBc0toULsSaWFVfmHmKU 4GBWEuE9kNAeLsSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNT qoExV4NZ4cNl5U8vj24vZtv1ceFEOyPpXLdtpzOXCGy59d3g65KL7BUmnpGbtb1rNSJj6g2v GzEf8+ZgF5FXPfpJKiJsmz7HXv7QGslda48efa/E+jJcujX9mdjPmQ//z09TVFY/Nu194eN/ 828fNHDRCuL9axDgne8941CA9WI5Vy+7g5fPLItQYinOSDTUYi4qTgQAy5BlK9UCAAA= Archived-At: Cc: Jonathan Lennox , mmusic , IETF AVTCore WG Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 09:57:43 -0000 >... > >The current proposal breaks that. Please let's MID to be a single, >unique and mandatory attribute per m-line. =8Aand let each RTP packet be associated with one, and only one, of those MIDs/m-lines. You can then have application logic saying e.g. =B3If no =8Cloudest-speaker= =B9 media is received, then duplicate the =8Cboss=B9 media on the screen associated with the loudest speaker=B2. It=B9s much more flexible, and with= out any of the constraints mentioned earlier. Regards, Christer From nobody Thu Jul 14 03:00:35 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999DF12B053; Thu, 14 Jul 2016 03:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NN3VRdSqrJY; Thu, 14 Jul 2016 03:00:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1203B12D645; Thu, 14 Jul 2016 03:00:23 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-6e-578762b65e7e Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D1.51.12516.6B267875; Thu, 14 Jul 2016 12:00:22 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 12:00:21 +0200 From: Christer Holmberg To: Christer Holmberg , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3bAROwJOMhyFBkK2BP9Ud+cjzqAXwuOAgAAAwwA= Date: Thu, 14 Jul 2016 10:00:21 +0000 Message-ID: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2K7qO62pPZwgxVXZC1e9qxkt5i+z8Zi /+LzzBZTlz9mcWDxONfwnt1jyZKfTB5tz+6wBzBHcdmkpOZklqUW6dslcGUcnNXEUvCMs6Kp IamB8QhnFyMnh4SAicT0hvlsELaYxIV764FsLg4hgSOMErMXfmSBcBYzSpyZt4mxi5GDg03A QqL7nzaIKSJQJDGrUQGkl1kgTeLvlQ9MILawgLfEiT3r2UFsEQEfiY2Nv9ggbCuJK3+/g9Ww CKhKzDn/gRXE5gWJ96xmhVi1gEVi35IbTCDzOQWsJbb9jQCpYQS67fupNUwQu8Qlbj2ZzwRx s4DEkj3nmSFsUYmXj/+BzRQV0JP4/nU2VFxR4ur05WAjmQU0Jdbv0ocYYy3xee1SRghbUWJK 90N2iHMEJU7OfMIygVFiFpJtsxC6ZyHpnoWkexaS7gWMrKsYRYtTi4tz042M9VKLMpOLi/Pz 9PJSSzYxAmPz4JbfujsYV792PMQowMGoxMO7oLEtXIg1say4MvcQowQHs5II7+XE9nAh3pTE yqrUovz4otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjNoz3hjc/+Z3JuvF t/+Ln+8t1POb6sXGNL3F/8yOxRn5zroqaSs3Zhhz2AZfeJJif+zzmzTP+vcbF4QoHt/0bnui 2QKxnkWdHx+GWlm4uh9v2j13TlbNmn/HZppI2eVyyMhePHFlvZbu0oUNMyMSJ628VB/zNaHO UG+PzWLrf+UpdbyT7r+PtlViKc5INNRiLipOBAC7/B5tyQIAAA== Archived-At: Cc: Jonathan Lennox , mmusic , IETF AVTCore WG Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 10:00:30 -0000 4oCmYW5kIGluIGFkZGl0aW9uLCBkb2luZyBpdCBhcyBhcHBsaWNhdGlvbiBsb2dpYyBhbHNvIGFs bG93cyB5b3UgdG8gZG8gaXQNCndpdGggbm9uLUJVTkRMRS4NCg0KDQpPbiAxNC8wNy8xNiAxMjo1 NywgIm1tdXNpYyBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmciDQo8bW11c2ljLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4N Cndyb3RlOg0KDQo+DQo+Pi4uLg0KPj4NCj4+VGhlIGN1cnJlbnQgcHJvcG9zYWwgYnJlYWtzIHRo YXQuIFBsZWFzZSBsZXQncyBNSUQgdG8gYmUgYSBzaW5nbGUsDQo+PnVuaXF1ZSBhbmQgbWFuZGF0 b3J5IGF0dHJpYnV0ZSBwZXIgbS1saW5lLg0KPg0KPg0KPsWgYW5kIGxldCBlYWNoIFJUUCBwYWNr ZXQgYmUgYXNzb2NpYXRlZCB3aXRoIG9uZSwgYW5kIG9ubHkgb25lLCBvZiB0aG9zZQ0KPk1JRHMv bS1saW5lcy4NCj4NCj4NCj5Zb3UgY2FuIHRoZW4gaGF2ZSBhcHBsaWNhdGlvbiBsb2dpYyBzYXlp bmcgZS5nLiDCs0lmIG5vIMWSbG91ZGVzdC1zcGVha2VywrkNCj5tZWRpYSBpcyByZWNlaXZlZCwg dGhlbiBkdXBsaWNhdGUgdGhlIMWSYm9zc8K5IG1lZGlhIG9uIHRoZSBzY3JlZW4NCj5hc3NvY2lh dGVkIHdpdGggdGhlIGxvdWRlc3Qgc3BlYWtlcsKyLiBJdMK5cyBtdWNoIG1vcmUgZmxleGlibGUs IGFuZCB3aXRob3V0DQo+YW55IG9mIHRoZSBjb25zdHJhaW50cyBtZW50aW9uZWQgZWFybGllci4N Cj4NCj4NCj5SZWdhcmRzLA0KPg0KPkNocmlzdGVyDQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5tbXVzaWMgbWFpbGluZyBsaXN0DQo+bW11c2lj QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMN Cg0K From nobody Thu Jul 14 03:20:03 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A60312D0D9; Thu, 14 Jul 2016 03:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 czLtlc__xP3Z; Thu, 14 Jul 2016 03:19:56 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD6512D1D3; Thu, 14 Jul 2016 03:19:54 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id i5so107107539wmg.0; Thu, 14 Jul 2016 03:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CB/WWh2BThanA4kflaTLhKloCAnTfQGzZNLod+83qRw=; b=LNFnqmzI4Ig8Sv2fIPaHhkhxtnGOeWYqlE7uhz3R/wI57M9E6Yl1sHekDAR82Q1ML6 9VJTE+LignN+aeWxeRQTFIUIx6b7CFq0Z7Z/CoFI/VUjyUxatx6gT+uBCvF5t9g6y1bO bCtM4BnYdCnjh/Qqo4fz6V+2AWHoHyu06/Ah/LjpHgvSjuJDIxVM3tgMXBcyaROVWWsI o3sjqRTAJBCABbTaDDh+bT8t1HfwcLyVG9o17AkAhLzwAGUav6LYKVIE6PO6Fc7SabjJ BXXCgMKC5qZ4nzWnLwq1j03o3I86seSfdaYOPUoyHWQtUtlYOfUYFOkXeM7MNY0bxITS 06kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CB/WWh2BThanA4kflaTLhKloCAnTfQGzZNLod+83qRw=; b=ZApmJ9Sn2dn9WLDX55zF8XHKyTXYOA0eJk6JQlAf7/LPxyD2t3Ojw5beVz8Vn+EWaY xjesnJ7UTBCbMPe4KAodeuzAjJXBMnaP5JnBWUW6hEF6oXMbSVP6BiE1oLGF/tCqcqEh U6CccuIBfGOV29sMr/AIoeK1Ja8m6ReJtMb5mYfVjLpVvtkM+LOVFnxS0mxehlGgKs0H tJes8slTKidlnajW//zvtVyCFoQH8OYFvvuyhBQxjDLs1nMB7ZfQLsVXfCKCEZjrsziA BalcHaD8Db0TLycec830nQJcfhOo2eJiPK108s4eH9/RVDvjoiGsFAZmgDNHlW90rfz0 zBoA== X-Gm-Message-State: ALyK8tKPhyzXQljdAPZ7AZkEYKM48WXLtUpZV9DjSB/CX0BPWuBND+6swKPWVfuAD+LZKT0uGub1qJ/0RjCSLg== X-Received: by 10.28.48.3 with SMTP id w3mr33199852wmw.28.1468491592697; Thu, 14 Jul 2016 03:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.117.67 with HTTP; Thu, 14 Jul 2016 03:19:51 -0700 (PDT) In-Reply-To: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Thu, 14 Jul 2016 12:19:51 +0200 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a114245eabd0fd8053795d7d4 Archived-At: Cc: Jonathan Lennox , mmusic , IETF AVTCore WG , Christer Holmberg Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 10:19:59 -0000 --001a114245eabd0fd8053795d7d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello everyone, firstable, thanks Jonathan to open this interesting discussion. For me it is quite important not only having real time applications/infrastructures working, but also in an efficient way, because it could be the different between success or failure... Why? Because the usage of technology is subject of business, where the costs are essential. Taking this into account and that in the real world: - For conferences with 3 or less participants (usually) the best approach is doing p2p. - Conferences with 4 or more participants (usually) use a midlebox like an SFU, etc. - Most conferences have less than 5/6 participants In the Jonathan's case with a SFU: - Sending all streams, there would be nParticipants input streams and nParticipants * nParticipants output streams. Total streams: (nParticipants + 1) * nParticipants - With his proposal, there would be nParticipants input streams and (nParticipants -1) * nParticipants output streams. Total streams: nParticipants * nParticipants, so we save nParticipants streams. And the percentage of streams saved is: 1 - ( (nParticipants * nParticipants) / (nParticipants + 1) * nParticipants)) =3D 1 - (nParticipan= ts / (nParticipants + 1)) Assuming that in an SFU the cost of receiving and sending streams is almost the same, with this approach we could save CPU and reduce the bandwidth usage with conferences of: - 4 participants: 1 -4/5 =3D 1-0.8 =3D 20 % - 5 participatns =3D 1- 5/6 =3D 1 - 0.833 =3D 16.6 % - 6 participants =3D 1 - 6/7 =3D 1 - 0.857 =3D 14.3 % We also should consider that using simulcast of SVC for video would reduce this percentages. But in conclusion, let's take into account the efficiency, not only for that but in general please ;) Related to that: Then a=3Dmid comes to the rescue and provides a per m-line unique > identifier, leaving the door open for a future spec change allowing > m-lines removal (have you ever seen how an SDP from a SFU with > participants entering and leaving the room grows?). > To avoid huge SDP, there is draft proposing partial offers and answers: https://tools.ietf.org/html/draft-roach-mmusic-pof-pan Best regards!! --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --001a114245eabd0fd8053795d7d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone,
firstable, thanks Jonat= han to open this interesting discussion.

For me it is qui= te important not only having real time applications/infrastructures working= , but also in an efficient way, because it could be the different between s= uccess or failure...
Why? Because the usage of technology is = subject of business, where the costs are essential.

Taking this into account and that in the real world:
=C2= =A0 - For conferences with 3 or less participants (usual= ly) the best approach is doing p2p.
=C2= =A0 - Conferences with 4 or more participants (usually) use a midlebox like= an SFU, etc.
=C2=A0 - Most conferences have les= s than 5/6 participants

In the Jonathan's case= with a SFU:
=C2=A0 - Sending all streams, there would be nPa= rticipants input streams and nParticipants * nParticipants output streams. = Total streams: (nParticipants + 1) * nParticipants
=C2=A0 - W= ith his proposal, there would be nParticipants input streams and (nParticip= ants -1) * nParticipants output streams. Total streams: nParticipants * nPa= rticipants, so we save nParticipants streams.

= And the percentage of streams saved is: 1 - ( (nParticipants * nParticipant= s) / (nParticipants + 1) * nParticipants)) =3D 1 - (nParticipants / (nParti= cipants + 1))

Assuming that in an SFU the cost= of receiving and sending streams is almost the same, with this approach we= could save CPU and reduce the bandwidth usage with conferences of:
=C2=A0 - 4 participants: 1 -4/5 =3D 1-0.8 =3D 20 %
=C2= =A0 - 5 participatns =3D 1- 5/6 =3D 1 - 0.833 =3D 16.6 %
=C2= =A0 - 6 participants =3D 1 - 6/7 =3D 1 - 0.857 =3D 14.3 %
We also should consider that using simulcast of SVC for video w= ould reduce this percentages.
But in conclusion, let's ta= ke into account the efficiency, not only for that but in general please ;)<= br>

Related to that:

Then a=3Dmid comes to the rescue and provides a per m-line unique
identifier, leaving the door open for a future spec change allowing
m-lines removal (have you ever seen how an SDP from a SFU with
participants entering and leaving the room grows?).
To avoid huge SDP, there is draft proposing partial offers and= answers: https://tools.ietf.org/html/draft-roach-mmusic-pof-pan<= /a>

Best r= egards!!

--
--001a114245eabd0fd8053795d7d4-- From nobody Thu Jul 14 05:28:26 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF3612D8C1 for ; Thu, 14 Jul 2016 05:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVn3Nd7RDkMk for ; Thu, 14 Jul 2016 05:28:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC9812D7A9 for ; Thu, 14 Jul 2016 05:28:23 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-2a-578785667046 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4B.9E.12516.66587875; Thu, 14 Jul 2016 14:28:22 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 14:28:21 +0200 From: Christer Holmberg To: Suhas Nandakumar , mmusic WG Thread-Topic: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted Thread-Index: AQHR2Rh/n/TctJ0bc0Gs9BWHxfSwVKAX9i8A Date: Thu, 14 Jul 2016 12:28:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D3AD60CEBFE8christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7jW5aa3u4wfI54hZTlz9msdg5t4PZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MpYd/k0U8EG5YrTmw6xNzCelOti5OSQEDCR mLJ2NwuELSZx4d56ti5GLg4hgSOMEs83f2OEcBYzSqye1cHaxcjBwSZgIdH9TxukQUTAXWLf 9c+sILawgIPE95b/rBBxR4meWedZIGwjiZe3loPZLAKqEhePf2ADsXkFrCQOnbvLDmILCQRI rFz1EqyXUyBQ4vX1f2D1jEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+B9YrKqAn 8f3rbKi4osTHV/sYIXrjJXb+Xgy1V1Di5MwnLBMYRWchGTsLSdksJGUQcQOJ9+fmM0PY2hLL Fr6GsvUlNn45ywhhW0t07NzPiKxmASPHKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAODy4 5bfuDsbVrx0PMQpwMCrx8C5obAsXYk0sK67MPcQowcGsJMJ7rqU9XIg3JbGyKrUoP76oNCe1 +BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVAOjrWaLOlNI3Roh1sVTu6xlzTk97CQl p5jlLjjhu6xHd4qg0i2boh8uKSWyro9iLbeU1DyrNTyw8mOcWGkA51G9S0Z797+pMmpl3KM0 2346k2Lhnq3K10/enT5Nql/+7N/WdVNqU/LWTgp+fmNmQvurJZXf33eeNfQ3Vbt7e/G3yqCW KVxTHWuVWIozEg21mIuKEwGJC+YRvwIAAA== Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 12:28:25 -0000 --_000_D3AD60CEBFE8christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I see that you have added the definition of the ice2 ice-option. However, y= ou have not defined usage of it in the offer/answer procedures, and it=92s = not included in the SDP examples. Regards, Christer From: mmusic > on b= ehalf of Suhas Nandakumar > Date: Friday 8 July 2016 at 15:58 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted Hello All We submitted -09 version of the ice-sip-sdp draft with the following chan= ges 1. Added Section 5 for dealing with ice2 2. updated an example in Appendix A to be IPv6 based end-point 3. Updated Section 13.2 to say about the aggregation rules for ice2 ice-= option 4. Restructured Offer/Answer sections into a single place as can be seen= in Section 4 Thanks to Christer for feedback on the restructuring the offer/answer secti= ons. We hope that this version incorporates all the outstanding issues. Please l= et us know if we are missing anything. Cheers Suhas --_000_D3AD60CEBFE8christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2E4F5ACA75B5EB46ACCCDD8C99FE88A1@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I see that you have added the definition of the ice2 ice-option. Howev= er, you have not defined usage of it in the offer/answer procedures, and it= =92s not included in the SDP examples.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Suhas= Nandakumar <suhasietf@gmail.com<= /a>>
Date: Friday 8 July 2016 at 15:58 To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic= -ice-sip-sdp-09 Submitted

Hello All

  We submitted -09 version of the ice-sip-sdp draft with the foll= owing changes

   1. Added Section 5 for dealing with ice2
   2. updated an example in Appen= dix A to be IPv6 based end-point
   3. Updated Section 13.2 to say= about the aggregation rules for ice2 ice-option
   4. Restructured Offer/Answer s= ections into a single place as can be seen in Section 4
  
Thanks to Christer for feedback on the rest= ructuring the offer/answer sections.


We hope that this version incorporates all = the outstanding issues. Please let us know if we are missing anything.

Cheers
Suhas
--_000_D3AD60CEBFE8christerholmbergericssoncom_-- From nobody Thu Jul 14 06:10:05 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDED12D9E2 for ; Thu, 14 Jul 2016 06:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LtlAbj7WhjjB for ; Thu, 14 Jul 2016 06:10:02 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E233C12D7D3 for ; Thu, 14 Jul 2016 06:10:01 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id w127so72575586ywf.3 for ; Thu, 14 Jul 2016 06:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PebyHnKSGYBO4Cs+GB/I9dNp+BVttReGMrymqnD7Eqc=; b=O1PYsp+2TgI9xHYOPtppHeBYhV6IhEPVyh/wd53dvtTm8uty75ZiQAVK9GTp/8viwK eRoesZVOmh65pWGAmRYntJvHAKS+ZM4JJWCvymp2a/re5BW99ig7dyjZJV7/3wjR18JP yEY9+2kdTg/8CvXIZ49MqD6t/7Xg5d4HeiggwReeFMNUydiYSe++5+BW8JCxwpsnjygF bCIyPqkadsUaVkTY/BRWX02RNbzWgRBWh29Qjpve0pTSanlwtdm41baD2NDHtN8R4JRA r0nbPT6ZhgJ4x0sQdEa7CEYQzpYepmzduEa5jYxhndF1zM0FQI7x7WsmMFDmiZy4pYHi ANtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PebyHnKSGYBO4Cs+GB/I9dNp+BVttReGMrymqnD7Eqc=; b=Cfutqa8DSHNBHR5VbxtdW5jghdr2yUG69VBRqc/GDtb/hTntN9Q/hjBEphMXKfb8t0 3dVdI0rW3qnvY4X0jvcQCwPLA5T6de4Sub7cVRVyOOml/B2LtIb3OiLedUufPaS7HDFg d0R1QIcqDFhrr3Yd7TrQljmtgj3GtyUYpIe0QiJaGGTDzYLvdQn30XftDk9RhqrVsga4 a/eft/anvh/0sVI22VJzMcvMYuIJ2tMNvJmlQjjeyaMKzS/fvL0hMPdHFGUlpGPGPN3z Sp30HH8wtXjIN/ceNLHBDA7VUQrGX/DAlQBqacEMSjY0kZHBqLMRGUMf7o/bKmuGwomS QaVg== X-Gm-Message-State: ALyK8tItUt+KuIUSx2MAW2g0IY22aRfDDnmGHDXif1t5S5qji1vclPAUHLxg8y5hf2Uv7DdsGgKhpT6ElN2RxQ== X-Received: by 10.37.119.20 with SMTP id s20mr9529210ybc.15.1468501800334; Thu, 14 Jul 2016 06:10:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Thu, 14 Jul 2016 06:09:59 -0700 (PDT) In-Reply-To: References: From: Suhas Nandakumar Date: Thu, 14 Jul 2016 18:39:59 +0530 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114bdb32293c730537983896 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 13:10:04 -0000 --001a114bdb32293c730537983896 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Christer The draft currently says the following on Offer/Answer usage for the ice2 option " The ICE option, 'ice2' is used with the SDP session level "a=3Dice- options" attribute in an SDP offer to indicate that the initiator of the ICE exchange is compliant to procedures from [ICE-BIS ] (via "a=3Dice-options: ice2"). The Responding Peer includes this same attribute at the session level in the SDP answer if it is also an [ICE-BIS ] compliant ICE Agent." Are you looking for something more specific than this ? Thanks Suhas On Thu, Jul 14, 2016 at 5:58 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I see that you have added the definition of the ice2 ice-option. However, > you have not defined usage of it in the offer/answer procedures, and it= =E2=80=99s > not included in the SDP examples. > > Regards, > > Christer > > From: mmusic on behalf of Suhas Nandakumar < > suhasietf@gmail.com> > Date: Friday 8 July 2016 at 15:58 > To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted > > Hello All > > We submitted -09 version of the ice-sip-sdp draft with the following > changes > > 1. Added Section 5 for dealing with ice2 > 2. updated an example in Appendix A to be IPv6 based end-point > 3. Updated Section 13.2 to say about the aggregation rules for ice2 > ice-option > 4. Restructured Offer/Answer sections into a single place as can be > seen in Section 4 > > Thanks to Christer for feedback on the restructuring the offer/answer > sections. > > > We hope that this version incorporates all the outstanding issues. Please > let us know if we are missing anything. > > Cheers > Suhas > --001a114bdb32293c730537983896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Christer

=C2=A0The draft currentl= y says the following on Offer/Answer usage for the ice2 option
" Th= e ICE option, 'ice2' is used with the SDP session level "a=3Di= ce-
   options" attribute in an SDP o=
ffer to indicate that the initiator of
   the ICE exchange is compliant to procedures from [ICE-BIS] (via
   "a=3Dice-options: ice2").  The Responding Peer includes this s=
ame
   attribute at the session level in the SDP answer if it is also an
   [ICE-BIS] compliant ICE Agent."


Are y=
ou looking for something more specific than this ?

Thanks
Suhas


On Thu, Jul 14, 2016 at 5:58 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

I see that you have added the definition of the ice2 ice-option. Howev= er, you have not defined usage of it in the offer/answer procedures, and it= =E2=80=99s not included in the SDP examples.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Friday 8 July 2016 at 15:58 To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic= -ice-sip-sdp-09 Submitted

Hello All

=C2=A0 We submitted -09 version of the ice-sip-sdp draft with the foll= owing changes

=C2=A0=C2=A0=C2=A01. Added Section 5 for dealing with ice2
=C2=A0 =C2=A02. updated an example in Appen= dix A to be IPv6 based end-point
=C2=A0 =C2=A03. Updated Section 13.2 to say= about the aggregation rules for ice2 ice-option
=C2=A0 =C2=A04. Restructured Offer/Answer s= ections into a single place as can be seen in Section 4
=C2=A0=C2=A0
Thanks to Christer for feedback on the rest= ructuring the offer/answer sections.


We hope that this version incorporates all = the outstanding issues. Please let us know if we are missing anything.

Cheers
Suhas

--001a114bdb32293c730537983896-- From nobody Thu Jul 14 06:14:32 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459A012DA46 for ; Thu, 14 Jul 2016 06:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXD4_h3KIXmv for ; Thu, 14 Jul 2016 06:14:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEDC12DA50 for ; Thu, 14 Jul 2016 06:14:27 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-79-57879031a77c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9A.9A.18043.13097875; Thu, 14 Jul 2016 15:14:25 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 15:14:24 +0200 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted Thread-Index: AQHR2Rh/n/TctJ0bc0Gs9BWHxfSwVKAX9i8A///YJYCAADS3AA== Date: Thu, 14 Jul 2016 13:14:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D3AD6B68C004christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2K7lq7hhPZwg2st6hZTlz9msdg5t4PZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MqYc+8Dc8Enx4qpC3+wNDD+sehi5OSQEDCR WN70mhHCFpO4cG89WxcjF4eQwBFGiQed/5khnMWMEmuXLgPKcHCwCVhIdP/TBmkQEdCSWL14 LhOIzSwgL3FhyRowW1jAQeJ7y39WiBpHiZ5Z51kgbCeJ/gOHmEFsFgFViVuv9oLV8wpYSdx+ /YERYtcJRon1b46CFXEKBEo83dXJBmIzAl33/dQaqGXiEreezGeCuFpAYsme88wQtqjEy8f/ wBaLCuhJfP86mxnkZgkBJYlpW9MgWuMltn04xQ6xV1Di5MwnLBMYxWYhmToLSdksJGUQcQOJ 9+fmM0PY2hLLFr6GsvUlNn45ywhhW0vc/jqPFVnNAkaOVYyixanFxbnpRkZ6qUWZycXF+Xl6 eaklmxiB8Xlwy2+rHYwHnzseYhTgYFTi4V3Q2BYuxJpYVlyZe4hRgoNZSYTXtK89XIg3JbGy KrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwenVAOjvvCvCRWKR6y9It0N zyq/ZLaZ9IXr5e7kxVutZ0+SsAoyLDXLsFSbcWLDT+9j9uWHv5XuzZouYRo/SzurPq3WvIJz E9fJC/ZdK525Luz+8Wjhk2Wm309HPDD469r7qb8o8XWG8OqG1joR2TMPg48G/LwkU5LM/LQs 9mPIucS3Je/rF8hnGPIosRRnJBpqMRcVJwIAaUfUBssCAAA= Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 13:14:30 -0000 --_000_D3AD6B68C004christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > The draft currently says the following on Offer/Answer usage for the ice2= option > >" The ICE option, 'ice2' is used with the SDP session level "a=3Dice- > options" attribute in an SDP offer to indicate that the initiator of > the ICE exchange is compliant to procedures from [ICE-BIS] (via > "a=3Dice-options: ice2"). The Responding Peer includes this same > attribute at the session level in the SDP answer if it is also an > [ICE-BIS] compliant ICE Agent." > > > Are you looking for something more specific than this ? Since chapter 4 describes how offers and answers are created, I assumed it = should be mentioned there. The text you have is a general description. Regards, Christer On Thu, Jul 14, 2016 at 5:58 PM, Christer Holmberg > wrote: Hi, I see that you have added the definition of the ice2 ice-option. However, y= ou have not defined usage of it in the offer/answer procedures, and it=92s = not included in the SDP examples. Regards, Christer From: mmusic > on b= ehalf of Suhas Nandakumar > Date: Friday 8 July 2016 at 15:58 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted Hello All We submitted -09 version of the ice-sip-sdp draft with the following chan= ges 1. Added Section 5 for dealing with ice2 2. updated an example in Appendix A to be IPv6 based end-point 3. Updated Section 13.2 to say about the aggregation rules for ice2 ice-= option 4. Restructured Offer/Answer sections into a single place as can be seen= in Section 4 Thanks to Christer for feedback on the restructuring the offer/answer secti= ons. We hope that this version incorporates all the outstanding issues. Please l= et us know if we are missing anything. Cheers Suhas --_000_D3AD6B68C004christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1C2375F6F42A1F438BA9702C25360F63@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

> The draft currently says the following on Offer/Answer usage for = the ice2 option
>
>" The IC= E option, 'ice2' is used with the SDP session level "a=3Dice- 
>   options" attribute in an SDP offer to indi=
cate that the initiator of
>   the ICE exchange is compliant to procedures from [ICE-B=
IS] (via
>   "a=3Dice-options: ice2").  The Responding Peer includes th=
is same
>   attribute at the session level in the SDP answer if it is also an
>   [ICE-BIS] compliant ICE Agent."
>
>
> Are you looking for something more specific than =
this ?

Since chapter 4 describes how offers and answers are created, I assume= d it should be mentioned there. The text you have is a general description.=

Regards,

Christer



On Thu, Jul 14, 2016 at 5:58 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

I see that you have added the definition of the ice2 ice-option. Howev= er, you have not defined usage of it in the offer/answer procedures, and it= =92s not included in the SDP examples.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Friday 8 July 2016 at 15:58 To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic= -ice-sip-sdp-09 Submitted

Hello All

  We submitted -09 version of the ice-sip-sdp draft with the foll= owing changes

   1. Added Section 5 for dealing with ice2
   2. updated an example in Appen= dix A to be IPv6 based end-point
   3. Updated Section 13.2 to say= about the aggregation rules for ice2 ice-option
   4. Restructured Offer/Answer s= ections into a single place as can be seen in Section 4
  
Thanks to Christer for feedback on the rest= ructuring the offer/answer sections.


We hope that this version incorporates all = the outstanding issues. Please let us know if we are missing anything.

Cheers
Suhas

 --_000_D3AD6B68C004christerholmbergericssoncom_-- From nobody Thu Jul 14 06:28:48 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8189F12DA65 for ; Thu, 14 Jul 2016 06:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzFU0UQuVQr1 for ; Thu, 14 Jul 2016 06:28:46 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CFD12D7BE for ; Thu, 14 Jul 2016 06:28:45 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-28-5787938b131b Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9D.5A.12516.B8397875; Thu, 14 Jul 2016 15:28:43 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 15:28:43 +0200 From: Christer Holmberg To: Suhas Nandakumar , mmusic WG Thread-Topic: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted - generic ICE text Thread-Index: AQHR3dOjy69HkwAg906NCn0S9E5/sA== Date: Thu, 14 Jul 2016 13:28:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D3AD6E6EC00Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7im735PZwgzPNphZTlz9msdg5t4PZ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4vnQCS8Fk04oJjQ/YGhin6HUxcnJICJhI /O54xghhi0lcuLeerYuRi0NI4AijxL9lTxkhnMWMEjO7frF2MXJwsAlYSHT/0wZpEBFwl9h3 /TMriC0sECqx4MoHZoh4mMS29TeZIGw9ic7P51lAbBYBVYmnPbvBbF4BK4njJ8+C1TACLf5+ ag2YzSwgLnHryXwmiIMEJJbsOc8MYYtKvHz8D2yXKNDM719nQ8UVJdqfNjBC9MZLPJvfwQgx X1Di5MwnLBMYhWchGTsLSdksJGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45ywhhW0sc+bWPDVnN AkaOVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBcXVwy2/dHYyrXzseYhTgYFTi4V3Q2BYu xJpYVlyZe4hRgoNZSYR3+8T2cCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNT UwtSi2CyTBycUg2M7Rtvtr/cuU9BQbIocMO7/eY9XDv044u4Y+bEhpp+7yl/Eufou6HKREp1 AoesrlVZ67b7l1dcLDWc4/ZEZ/t15vI1U0rM7wnqhGllPmRt6vASd53UoZzGfq3GN9UxOyg8 6NOFN0dDF/lwypdLfeJWTmtelptu8Ip9DsPzQw3x0+7dXcZ3ar8SS3FGoqEWc1FxIgAVhd5Q pwIAAA== Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted - generic ICE text X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 13:28:47 -0000 --_000_D3AD6E6EC00Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The draft contains text which seems to be generic ICE text, copy/pasted fro= m draft-ice-5245bis. For example, in section 4.2.1.1.1. (ICE Restart), do we need to repeat what= an ICE restart is, when it can be performed etc? Shouldn=92t we simply des= cribe the SDP aspects of the restart? So, in section 4.2.1.1.1. I think we would only need the 3 last paragraphs. Regards, Christer From: mmusic > on b= ehalf of Suhas Nandakumar > Date: Friday 8 July 2016 at 15:58 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted Hello All We submitted -09 version of the ice-sip-sdp draft with the following chan= ges 1. Added Section 5 for dealing with ice2 2. updated an example in Appendix A to be IPv6 based end-point 3. Updated Section 13.2 to say about the aggregation rules for ice2 ice-= option 4. Restructured Offer/Answer sections into a single place as can be seen= in Section 4 Thanks to Christer for feedback on the restructuring the offer/answer secti= ons. We hope that this version incorporates all the outstanding issues. Please l= et us know if we are missing anything. Cheers Suhas --_000_D3AD6E6EC00Dchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3F7F2B186DFF2C4EBF842B12FEA74BAB@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

The draft contains text which seems to be generic ICE text, copy/pasted fro= m draft-ice-5245bis.

For example, in= section 4.2.1.1.1. (ICE Restart), do = we need to repeat what an ICE restart is, when it can be performed etc? Shouldn=92t we simply describe the SDP aspects of= the restart?

So, in section 4.2.1.1.1. I think we would only need the 3 last paragraphs.

Regards,

Christer



From: mmusic <mmusic-bounces@ietf.org> on behalf of Suhas= Nandakumar <suhasietf@gmail.com<= /a>>
Date: Friday 8 July 2016 at 15:58 To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic= -ice-sip-sdp-09 Submitted

Hello All

  We submitted -09 version of the ice-sip-sdp draft with the foll= owing changes

   1. Added Section 5 for dealing with ice2
   2. updated an example in Appen= dix A to be IPv6 based end-point
   3. Updated Section 13.2 to say= about the aggregation rules for ice2 ice-option
   4. Restructured Offer/Answer s= ections into a single place as can be seen in Section 4
  
Thanks to Christer for feedback on the rest= ructuring the offer/answer sections.


We hope that this version incorporates all = the outstanding issues. Please let us know if we are missing anything.

Cheers
Suhas
--_000_D3AD6E6EC00Dchristerholmbergericssoncom_-- From nobody Thu Jul 14 07:23:15 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7B412D7CA; Thu, 14 Jul 2016 07:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTR8-BKX9EK0; Thu, 14 Jul 2016 07:23:12 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6993312D143; Thu, 14 Jul 2016 07:23:12 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u6EEKhCV016213; Thu, 14 Jul 2016 10:23:06 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 241vjvvmw6-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jul 2016 10:23:06 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Thu, 14 Jul 2016 09:23:05 -0500 From: Jonathan Lennox To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3bAS2iXZNVjDUESNYXQcq89uRqAYTueA Date: Thu, 14 Jul 2016 14:23:04 +0000 Message-ID: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <3EE6A670460C494FA033C84FB1FADC91@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-14_08:2016-07-14,2016-07-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607140154 Archived-At: Cc: mmusic , IETF AVTCore WG , Christer Holmberg Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 14:23:13 -0000 DQo+IE9uIEp1bCAxNCwgMjAxNiwgYXQgNToxMyBBTSwgScOxYWtpIEJheiBDYXN0aWxsbyA8aWJj QGFsaWF4Lm5ldD4gd3JvdGU6DQo+IA0KPiAyMDE2LTA3LTE0IDExOjAzIEdNVCswMjowMCBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjoNCj4+IFNlY29u ZCwgSUYgd2Ugd2FudCB0byBkbyBzb21ldGhpbmcgbGlrZSB0aGlzLCBzaG91bGQgaXQgaW5zdGVh ZCBiZSBkb25lIG9uIGENCj4+IGhpZ2hlciBhcHBsaWNhdGlvbi9DTFVFIGxheWVyPyAgV2h5IHN0 YXJ0IG1peGluZyB1cCB0aGUgbG93ZXItbGF5ZXIgTUlEDQo+PiBzZW1hbnRpY3MgZXRjPw0KPiAN Cj4gU29tZSB1Z2x5IHN0dWZmIHJlZ2FyZGluZyBTRFAgaXMgdGhlIGZhY3QgdGhhdCBtLWxpbmVz IGFyZSBpbmRleGVkIGJ5DQo+IHRoZWlyIHBvc2l0aW9uLCB3aGljaCBtZWFucyB0aGF0IHRoZXkg Y2Fubm90IGJlIHJlbW92ZWQgd2l0aGluIHRoZQ0KPiBzYW1lIHNlc3Npb24uDQo+IA0KPiBUaGVu IGE9bWlkIGNvbWVzIHRvIHRoZSByZXNjdWUgYW5kIHByb3ZpZGVzIGEgcGVyIG0tbGluZSB1bmlx dWUNCj4gaWRlbnRpZmllciwgbGVhdmluZyB0aGUgZG9vciBvcGVuIGZvciBhIGZ1dHVyZSBzcGVj IGNoYW5nZSBhbGxvd2luZw0KPiBtLWxpbmVzIHJlbW92YWwgKGhhdmUgeW91IGV2ZXIgc2VlbiBo b3cgYW4gU0RQIGZyb20gYSBTRlUgd2l0aA0KPiBwYXJ0aWNpcGFudHMgZW50ZXJpbmcgYW5kIGxl YXZpbmcgdGhlIHJvb20gZ3Jvd3M/KS4NCj4gDQo+IFRoZSBjdXJyZW50IHByb3Bvc2FsIGJyZWFr cyB0aGF0LiBQbGVhc2UgbGV0J3MgTUlEIHRvIGJlIGEgc2luZ2xlLA0KPiB1bmlxdWUgYW5kIG1h bmRhdG9yeSBhdHRyaWJ1dGUgcGVyIG0tbGluZS4NCg0KSeKAmW0gbm90IHByb3Bvc2luZyB0byBj aGFuZ2UgdGhpcy4gIFRoZXJlIHdpbGwgc3RpbGwgYmUgYSBzaW5nbGUgTUlEIHBlciBtLWxpbmUu DQoNCldoYXQgSeKAmW0gcHJvcG9zaW5nIGluc3RlYWQgaXMgdGhhdCB0aGUgbWFwcGluZyBiZXR3 ZWVuIFJUUCBTdHJlYW1zIGFuZCBtLWxpbmVzIGlzIG5vdCBuZWNlc3NhcmlseSAxLXRvLTEg4oCU IGFuIFJUUCBzdHJlYW0gY2FuIHByb3ZpZGUgdGhlIG1lZGlhIGZvciBtb3JlIHRoYW4gb25lIG0t bGluZSBhdCBhIHRpbWUuDQoNCg0K From nobody Thu Jul 14 08:43:34 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1596112D53C; Thu, 14 Jul 2016 08:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SnUvm-euq1vc; Thu, 14 Jul 2016 08:43:26 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61FF12D0BB; Thu, 14 Jul 2016 08:43:26 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l125so76348539ywb.2; Thu, 14 Jul 2016 08:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hdcGjrGBgSFLAKI4RmnSqBKaHBPwAIWemqW4iiiRdzw=; b=QvrnjNKQu+BualwUq6doCtFWgxNnC66pQgfRXmCIlfxhr48s7A/0vq9astqenVovCq 36dWM3mI5fZRMQStMrtLB59cEDKlp8Pgp6VpiXu8vxx47tJ+J9gxMIHjULu+Rhlumj7A IVyu+qqOEIdLjgx2nkTkILCt/LhFykCYIfip8urmYGeTUdQMLy2hztgfmPfqR9TBm4pb ZuUi7Kiu6etF18IGpydymeACl7dE68u/SDXqB2FNwWEP3OvdzJKp3bIO9nglyuz88Uxe rBspSqyh7ubOIjExMIzZk5C2qncwNph73vDTbBQtfHdD3C3axZOgGNj4v4I5T8eVXuHc qusw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hdcGjrGBgSFLAKI4RmnSqBKaHBPwAIWemqW4iiiRdzw=; b=F7ZQAN+sL8WGbZP08YjNeaguXUrl5muTEIk6tIezxIcVgRdHfe+HYf44B7Kmx+UOfy YCb/JpVJjVOeJXCm7v2ImwfqXAQGjP18uCWhffuO8EurGx09YGXbU+uULw0lK3lIrcIc cu4fFB5q+zyrkvXSEBTZbVGQxrMp6E7uNgf0wxpC+Q4AOmguZYr9pt0E+gKyL2R3Ym0p XYGkO1DPOqB7GD080GLcviL56FfA7ARKrk2Rusc2zuBOqU49e8GjmzwTu4vJv+IKMZMu 62qzKiT/t9jokwW9mO8joYojVlpfzJLT7Of1BtY4VKQGy8J3FCY3cMM0Ftf9GGzhUX9u QlTA== X-Gm-Message-State: ALyK8tKzn3lCxGHdODw8Yxbu/lSsBdEo4haENprsWRZAFgEom25A3B3y5udDdBMOWp3MQ6xHjaTabfrxeys2pg== X-Received: by 10.13.231.194 with SMTP id q185mr10401597ywe.28.1468511006002; Thu, 14 Jul 2016 08:43:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Thu, 14 Jul 2016 08:43:25 -0700 (PDT) In-Reply-To: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> From: Suhas Nandakumar Date: Thu, 14 Jul 2016 21:13:25 +0530 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c07cbdadc976105379a5c63 Archived-At: Cc: mmusic , IETF AVTCore WG , Jonathan Lennox Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 15:43:29 -0000 --94eb2c07cbdadc976105379a5c63 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2016 at 3:27 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > >... > > > >The current proposal breaks that. Please let's MID to be a single, > >unique and mandatory attribute per m-line. > > > =C5=A0and let each RTP packet be associated with one, and only one, of th= ose > MIDs/m-lines. > > > You can then have application logic saying e.g. =C2=B3If no =C5=92loudest= -speaker=C2=B9 > media is received, then duplicate the =C5=92boss=C2=B9 media on the scree= n > associated with the loudest speaker=C2=B2. It=C2=B9s much more flexible, = and without > any of the constraints mentioned earlier. > > I agree it brings in flexibility and it scares me a bit as well .. Each application needs to define their own logic or need a common logic across all applications .. > > Regards, > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c07cbdadc976105379a5c63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jul 14, 2016 at 3:27 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

>...
>
>The current proposal breaks that. Please let's MID to be a single,<= br> >unique and mandatory attribute per m-line.


=C5=A0and let each RTP packet be associated with one, and only one, = of those
MIDs/m-lines.


You can then have application logic saying e.g. =C2=B3If no =C5=92loudest-s= peaker=C2=B9
media is received, then duplicate the =C5=92boss=C2=B9 media on the screen<= br> associated with the loudest speaker=C2=B2. It=C2=B9s much more flexible, an= d without
any of the constraints mentioned earlier.


I agree it brings in flexibility and i= t scares me a bit as well .. Each application needs to define their own log= ic or need a common logic across all applications ..

=C2=A0

Regards,

Christer

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic<= br>

--94eb2c07cbdadc976105379a5c63-- From nobody Thu Jul 14 08:49:28 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB95D12D0F9; Thu, 14 Jul 2016 08:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZmiFFmCkYsf; Thu, 14 Jul 2016 08:49:21 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4021912D1A7; Thu, 14 Jul 2016 08:49:21 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-42-5787b47f5059 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1D.33.12516.F74B7875; Thu, 14 Jul 2016 17:49:19 +0200 (CEST) Received: from ESESSMB208.ericsson.se ([169.254.8.19]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0294.000; Thu, 14 Jul 2016 17:49:18 +0200 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3bAROwJOMhyFBkK2BP9Ud+cjzqAXwuOAgAAtIICAACMsgQ== Date: Thu, 14 Jul 2016 15:49:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476AA914@ESESSMB208.ericsson.se> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B476AA914ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7jW79lvZwg6ffhCxe9qxkt5i+z8Zi /+LzzBZTlz9msdg5t4PZgdXjXMN7do+ds+6yeyxZ8pPJo+3ZHfYAligum5TUnMyy1CJ9uwSu jI2XdrEX9FhWLD8k0cC4x7yLkZNDQsBE4v6iiawQtpjEhXvr2boYuTiEBI4wSnz8944FwlnM KLF83zygKg4ONgELie5/2iANIgJaEqsXz2UCsZkFFjBKNH8UB7GFBbwlNq65xwZR4yOxsfEX lO0kcXrfIrB6FgFViYWvfoPFeQV8JU6c3M8Isespi8SxOVsYQRKcAoESV+Y9BLMZga77fmoN 1DJxiaYvK6GuFpBYsuc8M4QtKvHy8T9WiJp8iStzmpkgFghKnJz5hGUCo8gsJO2zkJTNQlI2 C+hNZgFNifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KUbQ4tbg4N93IWC+1KDO5uDg/Ty8v tWQTIzAKD275rbuDcfVrx0OMAhyMSjy8CxrbwoVYE8uKK3MPMUpwMCuJ8J7b3B4uxJuSWFmV WpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgbH5p/6rN61hu0WiLrsJ S+ncPHSi6KiAQabJnqjaBd/79z0P23mq1UyOiXX7sZTZTlt+ZZ3ivX/wl9+9XeuO2m95ksrt YaDp6nQqS+hKzo597BKrPO9lxDOsORbJotf5wmt9w8STz1hkNwvwbvh+QmhvU1Lnsd7jqgon A2u0L+hLrZD9oq93cIUSS3FGoqEWc1FxIgAqwAHgvgIAAA== Archived-At: Cc: mmusic , IETF AVTCore WG , Jonathan Lennox Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 15:49:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B476AA914ESESSMB208erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCllvdSBkb24ndCBuZWVkIGEgY29tbW9uIGxvZ2ljLiBZb3UgY2FuIGRlZmluZSBhbiBh cHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCAoZS5nLiBDTFVFKSB0byBkZWZpbmUvY29uZmlndXJl L25lZ290aWF0ZSB0aGVzZSBraW5kIG9mIHRoaW5ncy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBTdWhhcyBOYW5kYWt1bWFyPG1haWx0bzpzdWhhc2lldGZAZ21haWwuY29t Pg0KU2VudDog4oCOMTQv4oCOMDcv4oCOMjAxNiAxODo0Mw0KVG86IENocmlzdGVyIEhvbG1iZXJn PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogScOxYWtpIEJheiBD YXN0aWxsbzxtYWlsdG86aWJjQGFsaWF4Lm5ldD47IEpvbmF0aGFuIExlbm5veDxtYWlsdG86am9u YXRoYW5AdmlkeW8uY29tPjsgbW11c2ljPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+OyBJRVRGIEFW VENvcmUgV0c8bWFpbHRvOmF2dEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbQVZU Q09SRV0gQlVORExFOiBhIHNpbmdsZSBzdHJlYW0gd2l0aCBtdWx0aXBsZSBNSURzPw0KDQoNCg0K T24gVGh1LCBKdWwgMTQsIDIwMTYgYXQgMzoyNyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPj4gd3JvdGU6DQoNCj4uLi4NCj4NCj5UaGUgY3VycmVudCBwcm9wb3NhbCBicmVha3Mg dGhhdC4gUGxlYXNlIGxldCdzIE1JRCB0byBiZSBhIHNpbmdsZSwNCj51bmlxdWUgYW5kIG1hbmRh dG9yeSBhdHRyaWJ1dGUgcGVyIG0tbGluZS4NCg0KDQrFoGFuZCBsZXQgZWFjaCBSVFAgcGFja2V0 IGJlIGFzc29jaWF0ZWQgd2l0aCBvbmUsIGFuZCBvbmx5IG9uZSwgb2YgdGhvc2UNCk1JRHMvbS1s aW5lcy4NCg0KDQpZb3UgY2FuIHRoZW4gaGF2ZSBhcHBsaWNhdGlvbiBsb2dpYyBzYXlpbmcgZS5n LiDCs0lmIG5vIMWSbG91ZGVzdC1zcGVha2VywrkNCm1lZGlhIGlzIHJlY2VpdmVkLCB0aGVuIGR1 cGxpY2F0ZSB0aGUgxZJib3NzwrkgbWVkaWEgb24gdGhlIHNjcmVlbg0KYXNzb2NpYXRlZCB3aXRo IHRoZSBsb3VkZXN0IHNwZWFrZXLCsi4gSXTCuXMgbXVjaCBtb3JlIGZsZXhpYmxlLCBhbmQgd2l0 aG91dA0KYW55IG9mIHRoZSBjb25zdHJhaW50cyBtZW50aW9uZWQgZWFybGllci4NCg0KDQpJIGFn cmVlIGl0IGJyaW5ncyBpbiBmbGV4aWJpbGl0eSBhbmQgaXQgc2NhcmVzIG1lIGEgYml0IGFzIHdl bGwgLi4gRWFjaCBhcHBsaWNhdGlvbiBuZWVkcyB0byBkZWZpbmUgdGhlaXIgb3duIGxvZ2ljIG9y IG5lZWQgYSBjb21tb24gbG9naWMgYWNyb3NzIGFsbCBhcHBsaWNhdGlvbnMgLi4NCg0KDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRv Om1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bW11c2ljDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B476AA914ESESSMB208erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPkhp LDxicj4NCjxicj4NCllvdSBkb24ndCBuZWVkIGEgY29tbW9uIGxvZ2ljLiBZb3UgY2FuIGRlZmlu ZSBhbiBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCAoZS5nLiBDTFVFKSB0byBkZWZpbmUvY29u ZmlndXJlL25lZ290aWF0ZSB0aGVzZSBraW5kIG9mIHRoaW5ncy48YnI+DQo8YnI+DQpSZWdhcmRz LDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhv bmU8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8aHI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6 Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5j b20iPlN1aGFzIE5hbmRha3VtYXI8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xk Ij5TZW50Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZToxMXB0Ij7igI4xNC/igI4wNy/igI4yMDE2IDE4OjQzPC9zcGFuPjxicj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTox MXB0OyBmb250LXdlaWdodDpib2xkIj5UbzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Q2hyaXN0ZXIgSG9sbWJlcmc8L2E+PC9zcGFu Pjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5DYzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFp bHRvOmliY0BhbGlheC5uZXQiPknDsWFraSBCYXogQ2FzdGlsbG88L2E+Ow0KPGEgaHJlZj0ibWFp bHRvOmpvbmF0aGFuQHZpZHlvLmNvbSI+Sm9uYXRoYW4gTGVubm94PC9hPjsgPGEgaHJlZj0ibWFp bHRvOm1tdXNpY0BpZXRmLm9yZyI+DQptbXVzaWM8L2E+OyA8YSBocmVmPSJtYWlsdG86YXZ0QGll dGYub3JnIj5JRVRGIEFWVENvcmUgV0c8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij5SZTogW01NVVNJQ10gW0FWVENPUkVdIEJVTkRMRTog YSBzaW5nbGUgc3RyZWFtIHdpdGggbXVsdGlwbGUgTUlEcz88L3NwYW4+PGJyPg0KPGJyPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEi Pjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIEp1bCAxNCwgMjAxNiBhdCAz OjI3IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0i bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDsg Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KJmd0 Oy4uLjxicj4NCjxzcGFuIGNsYXNzPSIiPiZndDs8YnI+DQomZ3Q7VGhlIGN1cnJlbnQgcHJvcG9z YWwgYnJlYWtzIHRoYXQuIFBsZWFzZSBsZXQncyBNSUQgdG8gYmUgYSBzaW5nbGUsPGJyPg0KJmd0 O3VuaXF1ZSBhbmQgbWFuZGF0b3J5IGF0dHJpYnV0ZSBwZXIgbS1saW5lLjxicj4NCjxicj4NCjxi cj4NCjwvc3Bhbj7FoGFuZCBsZXQgZWFjaCBSVFAgcGFja2V0IGJlIGFzc29jaWF0ZWQgd2l0aCBv bmUsIGFuZCBvbmx5IG9uZSwgb2YgdGhvc2U8YnI+DQpNSURzL20tbGluZXMuPGJyPg0KPGJyPg0K PGJyPg0KWW91IGNhbiB0aGVuIGhhdmUgYXBwbGljYXRpb24gbG9naWMgc2F5aW5nIGUuZy4gwrNJ ZiBubyDFkmxvdWRlc3Qtc3BlYWtlcsK5PGJyPg0KbWVkaWEgaXMgcmVjZWl2ZWQsIHRoZW4gZHVw bGljYXRlIHRoZSDFkmJvc3PCuSBtZWRpYSBvbiB0aGUgc2NyZWVuPGJyPg0KYXNzb2NpYXRlZCB3 aXRoIHRoZSBsb3VkZXN0IHNwZWFrZXLCsi4gSXTCuXMgbXVjaCBtb3JlIGZsZXhpYmxlLCBhbmQg d2l0aG91dDxicj4NCmFueSBvZiB0aGUgY29uc3RyYWludHMgbWVudGlvbmVkIGVhcmxpZXIuPGJy Pg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBhZ3JlZSBp dCBicmluZ3MgaW4gZmxleGliaWxpdHkgYW5kIGl0IHNjYXJlcyBtZSBhIGJpdCBhcyB3ZWxsIC4u IEVhY2ggYXBwbGljYXRpb24gbmVlZHMgdG8gZGVmaW5lIHRoZWlyIG93biBsb2dpYyBvciBuZWVk IGEgY29tbW9uIGxvZ2ljIGFjcm9zcyBhbGwgYXBwbGljYXRpb25zIC4uPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNo cmlzdGVyPGJyPg0KPHNwYW4gY2xhc3M9IiI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp YyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B476AA914ESESSMB208erics_-- From nobody Thu Jul 14 17:58:46 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9DF12D937; Thu, 14 Jul 2016 17:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9LbiQ7o_v2I; Thu, 14 Jul 2016 17:58:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15C112D945; Thu, 14 Jul 2016 17:58:41 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6F0wUlr097250 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Jul 2016 19:58:31 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Magnus Westerlund , Flemming Andreasen , mmusic References: <9f237771-3d8c-edf7-6b28-3e8f214075a5@cisco.com> <61d550ef-32a2-f759-1cbd-1b2d937da1a0@ericsson.com> From: Adam Roach Message-ID: <864374cd-2c6f-05ac-d60f-987134267767@nostrum.com> Date: Thu, 14 Jul 2016 19:58:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <61d550ef-32a2-f759-1cbd-1b2d937da1a0@ericsson.com> Content-Type: multipart/alternative; boundary="------------CC4DBB7174D41BF76D602A7A" Archived-At: Cc: draft-ietf-mmusic-rid@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rid-06 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 00:58:45 -0000 This is a multi-part message in MIME format. --------------CC4DBB7174D41BF76D602A7A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/12/16 09:30, Magnus Westerlund wrote: > 1. Section 2: > > However, the assignment of static mapping of RTP payload > type numbers to payload formats and multiplexing of RTP with other > protocols (such as RTCP) could result in limited number of payload > type numbers available for application usage. > > Is still the state of the implementations such that overriding a > static payload doesn't work? If you're counting by implementation, I don't know how prevalent it is. If you 're counting by deployed instances, it's fiercely high. There is one major, major vendor in the SIP space that uses a stack in many of its endpoints which rejects any offer that attempts to assign values to PTs less than 96. It's wrong and annoying, but it's very widely deployed, and it effectively forces all other implementations to limit their remapping to the 96-127 range. > 2. Section 4: > > This value binds the restriction to the RTP Stream identified by its > RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. > > The draft is missing a statement making clear that if one implements > mmusic-rid, then one is required to also implement avtext-rid using > RFC 2119 langauge. Yes, I realize implicitly that this is the case, > but I think one should make it explicit so that no one glancing it > through misses this aspect and to avoid future debates. Done. > I also think there exist a question if one MUST include the SDES item, > in the RTP stream, even when the PT is I think I know where you're going with this sentence. Updated: An "a=rid" SDP media attribute specifies constraints defining a unique RTP payload configuration identified via the "rid-id" field. This value binds the restriction to the RTP Stream identified by its RTP Stream Identifier SDES item {{I-D.ietf-avtext-rid}}. To be clear, implementations that use the "a=rid" parameter in SDP MUST support the RtpStreamId SDES item described in {{I-D.ietf-avtext-rid}}. Such implementations MUST send it for all streams in an m-section that has "a=rid" lines remaining after applying the rules in {{sec-sdp_o_a}} and its subsections. > 3. Section 4: > > This framework MAY be used in combination with the "a=fmtp" SDP > attribute for describing the media format parameters for a given RTP > Payload Type. In such scenarios, the "a=rid" constraints (Section 5) > further constrain the equivalent "a=fmtp" attributes. > > I wonder if this should include a bit of clearer purpose declration > here. By using rid one can hopefully create more generic PTs that are > focused on the codec and basic payload type configuration, and thus > put the more detailed contrains to the rid. The introduction hints at > this but I would prefer if this is made clearer as intended result of > using rid. > > Possibly this may better belong in this Section 2 paragraph: > > The additional constraints on individual streams are indicated with a > new "a=rid" SDP attribute. Note that the constraints communicated > via this attribute only serve to further constrain the parameters > that are established on a PT format. They do not relax any existing > restrictions. I'm fine moving the paragraph. > 4. Section 4: > > This framework MAY be used in combination with the "a=fmtp" SDP > attribute for describing the media format parameters for a given RTP > Payload Type. > > I wonder if "MAY" is really the right RFC2119 word here. I don't see > how you can't use a=fmtp to define the PTs. Because this leads my > thought in the direction that you can use a=rid only and not use the > whole PT declration mechansism with m= lines, a=rtpmap and a=fmtp. I > don't believe this is the intention here. I don't follow what you're saying here. If we didn't already have text in here requiring a=fmtp if it's needed to interpret the type without a=rid, I'd think it was that. But since we mention that requirement a couple of places, I have to assume that's not what you mean. Can you propose some text? > 5. Section 4: > > A given > "rid-id" MUST NOT be repeated in a given media description ("m=" > section). > > So this indicates a uniqueness requirement on media description level, > but does not discuss how a receiver gets to correctly identify the RTP > Stream within an RTP session to the Media Description, as this is what > an actual receiver needs to deal with. > > Section 6 says: > > Note that "rid-id" values are only required to be unique within a > media section ("m-line"); they do not necessarily need to be unique > within an entire RTP session. In traditional usage, each media > section is sent on its own unique 5-tuple, which provides an > unambiguous scope. Similarly, when using BUNDLE > [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP > streams uniquely to a single media description. > > What the above section 6 text doesn't cover is multiparty cases, when > a receiver can receive RTP streams from multiple endpoints matching a > particular media description, something that can occur in declarative > use cases. In this case, one could add the CNAME will work as clear > separator. Sure. I'm not familiar with declarative receive situations, so I have a hard time reasoning about them. I'm aware of the use of SDP in conjunction with SAP for declarative sending, but can't come up with an analog for receive. Can you give an example? > Then there are the declarative interpretation that each media > description is an RTP session. And in some cases, that could mean that > one thinks multiple media sources fits a particular media description. > I have no idea if there are actual deployed cases of this. However, I > think the reasonable way forward here is to document the assumption > that this is based on that even in declarative cases where there might > be multiple endpoints that sends according to a specific media > description, this only supports one media source. > > To conclude, I think the text about this needs be extended to cover > the different cases better and make clear that there exist a > requirement here. And the assumption that we don't need to solve > multiple media sources from the same endpoint sent according to one > media description (declarative usage). At one point, we debated whether to include declarative uses of RID, with my inclination being to forbid its use (since the rationale for defining it largely doesn't exist with declarative use cases). I was convinced that allowing its use was at worst harmless, and that it would be trivial to specify. It's sounding increasingly less trivial, so my inclination is to go back to disallowing it (or, at least, leaving it to another document to specify if a need arises). > > 6. Section 5: > > o max-bpp, for maximum number of bits per pixel, calculated as an > average of all samples of any given coded picture. This is > expressed as a floating point value, with an allowed range of > 0.0001 to 48.0. > > Does this need a clarification that any values outside of the range > will be encoded with the closest value allowed? I'm not sure we need to accommodate people putting invalid values in here any more than we need to accommodate people putting emoji in here -- and out-of-range values are invalid. > Secondly, the floating point value, how many digits of decimals are > allowed? Is this intended to fit in an 32-bit or 64-bit floating point > representation or something else? Added "These values MUST be encoded with at most four digits to the right of the decimal point." > 7. Section 5: > > While > this document does not define constraints for audio codecs, there is > no reason such constraints should be precluded from definition and > registration by other documents. > > I think this could add that additional media types are also possible. > Possible formulation: > > While this document does not define constraints for audio codecs or > any other media types than video, there is no reason such constraints > should be precluded from definition and registration by other documents. Done. > > 8. section 6.2.2: > > 3. If the "a=rid" line contains a "pt=", the list of payload types > is verified against the list of valid payload types for the media > section (that is, those listed on the "m=" line). Any PT missing > from the "m=" line is removed from the set of valued in the > "pt=". > > This may need handling of the case if the last action results in that > the set of PTs in "pt=" becomes empty, then the whole a=rid line needs > to be discarded. This as the RID was intended for a limited set of > PTs, rather than the default any PT which no "pt=" implies. Good catch. I've added text: If no values are left in the "pt=" parameter after this processing, then the "a=rid" line is removed. > 9. Section 6.2.2: > > 5. If the "depend" constraint is included, the answerer MUST make > sure that the listed rid-ids unambiguously match the rid-ids in > the SDP offer. Any "a=rid" lines that do not are removed. > > I fail to find a definition of the "depend" constraint in the > document. I do find an example using it in addition to the above text. Huh. I don't know how we missed this. I thought it was in here at some point, but it must have been edited out...? Anyway: * depend, to identify other streams that the stream depends on. The value is a comma-separated list of rid-ids. These rid-ids identify RTP streams that this stream depends on in order to allow for proper interpretation. > 10. Section 6.4: > > Note that this matching must be performed > semantically rather than on literal PT values, as the remote end > may not be using symmetric PTs. For the purpose of this > comparison: for each PT listed on the "a=rid" line in the answer, > the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" > lines in the answer. > > I am a bit worried that this is still misunderstood to mean that one > can do "byte comparison" of the parameters for a PT. The reality of > this comparison is after all that you must compare the parameters that > are required to be the same between offer and answer. And that is > payload format specific. I would suggest that one makes it clear that > in many cases this semantically comparison requires payload format > understanding. Added: Note that this semantic comparison necessarily requires an understanding of the meaning of codec parameters, rather than a rote byte-wise comparison of their values. > 11. Section 7. > > Needs to be clarified requirements on being able to determine which > rid-identifier that applies to a received RTP stream. So if multiple > m= lines are defined and they are not all separate RTP sessions, > additional method for determining media description to RTP stream are > required. Multi-party also needs to be handled. Again, since there's no real itch to scratch for declarative SDP, and it's getting (even more!) complicated, I propose removing it, with a statement that we don't define its use, although allow for a future document to do so. > 12. Section 8.2.3 and 8.2.4: > > So even if H.264 supports macroblock internal partitions for 4x4 and > 8x8 sub-blocks the calculation for the constraints are done on the > macroblock sizes that is 16x16 for luminance, see Section 3.78 of > H.264 specification. Thus the conversion factor should in both these > cases be 256 pixels per MB. > > https://www.itu.int/rec/T-REC-H.264-201602-I/en (pdf version is free) Thanks. I've changed it to 256 and added math. > 13. Section 10: > > > rid-fmt-list = "pt=" fmt *( "," fmt ) > ; fmt defined in {{RFC4566}} > > When I verified the ABNF by running Bill Fenner's parser on it I got > the "fmt undefinded". One way of avoiding this is to actually define > fmt as prose value, by saying that it is an external reference. > > fmt = > > > 14. Section 10: > > "alpah-numeric" is also undefined. And it is not obvious from where > this definition is taken. SP and DIGIT are present in RFC5234 and I > assume those definitions are to be used. RFC 4566 defines: ; generic sub-rules: primitives alpha-numeric = ALPHA / DIGIT I have accordingly added: alpha-numeric = < as defined in RFC4566 > > > > In addition I have to note that if one would use the "alpha-numeric" > definition from SDP (RFC4566) then one can't use any of the allowed > UTF-8 values from the SDES item in the SDP rid-identifier as the > alpha-numeric only support 7-bit ascii characters. Because of the nature of these identifiers, we really, really don't need to support esoterica here. Limiting the SDP syntax to alphanumerics is intentional. > 15. Section 10: > > Discrepancy between SDES item and "rid-identifer". To my understanding > there exist no limitations in the SDES item against using space or > other separators. Such free form is not supported by current > "rid-identifier" definition. This effiects both "rid-syntax" and > rid-list constructs. As above, I don't think we need to support arbitrary strings here -- the limited set more than serves our purpose, and the more permissive we are, the more likely SDP parsers are to get get this wrong. In particular, allowing spaces would make our syntax ambiguous. We're going to have to use *some* character as a separator between rid-id and rid-dir, and going through contortions to allow that character to also be allowed in rid-id is a lot of work for literally zero benefit. > 16. Section 11.2: > > I understand the desire to have this example is "depend" is defined. > However, I do note that this is an simulcast example which you in > Section 11 refer to the simulcast document. Sure, I'll add "See {{I-D.ietf-mmusic-sdp-simulcast}} for additional detail about simulcast usage." > > 17. Section 12.1: > > I don't think this section manages to hit all of the registration > requirements for new SDP attributes: > > From RFC4566: > > > o contact name, email address, and telephone number > > o attribute name (as it will appear in SDP) > > o long-form attribute name in English > > o type of attribute (session level, media level, or both) > > o whether the attribute value is subject to the charset attribute > > o a one-paragraph explanation of the purpose of the attribute > > o a specification of appropriate attribute values for this attribute Yep; I've added one. Thanks! /a --------------CC4DBB7174D41BF76D602A7A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/12/16 09:30, Magnus Westerlund wrote:
1. Section 2:

   However, the assignment of static mapping of RTP payload
   type numbers to payload formats and multiplexing of RTP with other
   protocols (such as RTCP) could result in limited number of payload
   type numbers available for application usage.

Is still the state of the implementations such that overriding a static payload doesn't work?

If you're counting by implementation, I don't know how prevalent it is. If you 're counting by deployed instances, it's fiercely high. There is one major, major vendor in the SIP space that uses a stack in many of its endpoints which rejects any offer that attempts to assign values to PTs less than 96. It's wrong and annoying, but it's very widely deployed, and it effectively forces all other implementations to limit their remapping to the 96-127 range.

2. Section 4:

   This value binds the restriction to the RTP Stream identified by its
   RTP Stream Identifier SDES item [I-D.ietf-avtext-rid].

The draft is missing a statement making clear that if one implements mmusic-rid, then one is required to also implement avtext-rid using RFC 2119 langauge. Yes, I realize implicitly that this is the case, but I think one should make it explicit so that no one glancing it through misses this aspect and to avoid future debates.

Done.

I also think there exist a question if one MUST include the SDES item, in the RTP stream, even when the PT is

I think I know where you're going with this sentence. Updated:

An "a=rid" SDP media attribute specifies constraints defining a unique
RTP payload configuration identified via the "rid-id" field. This
value binds the restriction to the RTP Stream identified by its RTP
Stream Identifier SDES item {{I-D.ietf-avtext-rid}}. To be clear, implementations
that use the "a=rid" parameter in SDP MUST support the RtpStreamId
SDES item described in {{I-D.ietf-avtext-rid}}. Such implementations
MUST send it for all streams in an m-section that has "a=rid" lines
remaining after applying the rules in {{sec-sdp_o_a}} and its subsections.


3. Section 4:

   This framework MAY be used in combination with the "a=fmtp" SDP
   attribute for describing the media format parameters for a given RTP
   Payload Type.  In such scenarios, the "a=rid" constraints (Section 5)
   further constrain the equivalent "a=fmtp" attributes.

I wonder if this should include a bit of clearer purpose declration here. By using rid one can hopefully create more generic PTs that are focused on the codec and basic payload type configuration, and thus put the more detailed contrains to the rid. The introduction hints at this but I would prefer if this is made clearer as intended result of using rid.

Possibly this may better belong in this Section 2 paragraph:

  The additional constraints on individual streams are indicated with a
   new "a=rid" SDP attribute.  Note that the constraints communicated
   via this attribute only serve to further constrain the parameters
   that are established on a PT format.  They do not relax any existing
   restrictions.

I'm fine moving the paragraph.

4. Section 4:

   This framework MAY be used in combination with the "a=fmtp" SDP
   attribute for describing the media format parameters for a given RTP
   Payload Type.

I wonder if "MAY" is really the right RFC2119 word here. I don't see how you can't use a=fmtp to define the PTs. Because this leads my thought in the direction that you can use a=rid only and not use the whole PT declration mechansism with m= lines, a=rtpmap and a=fmtp. I don't believe this is the intention here.

I don't follow what you're saying here. If we didn't already have text in here requiring a=fmtp if it's needed to interpret the type without a=rid, I'd think it was that. But since we mention that requirement a couple of places, I have to assume that's not what you mean.

Can you propose some text?

5. Section 4:

   A given
   "rid-id" MUST NOT be repeated in a given media description ("m="
   section).

So this indicates a uniqueness requirement on media description level, but does not discuss how a receiver gets to correctly identify the RTP Stream within an RTP session to the Media Description, as this is what an actual receiver needs to deal with.

Section 6 says:

   Note that "rid-id" values are only required to be unique within a
   media section ("m-line"); they do not necessarily need to be unique
   within an entire RTP session.  In traditional usage, each media
   section is sent on its own unique 5-tuple, which provides an
   unambiguous scope.  Similarly, when using BUNDLE
   [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP
   streams uniquely to a single media description.

What the above section 6 text doesn't cover is multiparty cases, when a receiver can receive RTP streams from multiple endpoints matching a particular media description, something that can occur in declarative use cases. In this case, one could add the CNAME will work as clear separator.

Sure. I'm not familiar with declarative receive situations, so I have a hard time reasoning about them. I'm aware of the use of SDP in conjunction with SAP for declarative sending, but can't come up with an analog for receive. Can you give an example?

Then there are the declarative interpretation that each media description is an RTP session. And in some cases, that could mean that one thinks multiple media sources fits a particular media description. I have no idea if there are actual deployed cases of this. However, I think the reasonable way forward here is to document the assumption that this is based on that even in declarative cases where there might be multiple endpoints that sends according to a specific media description, this only supports one media source.

To conclude, I think the text about this needs be extended to cover the different cases better and make clear that there exist a requirement here. And the assumption that we don't need to solve multiple media sources from the same endpoint sent according to one media description (declarative usage).

At one point, we debated whether to include declarative uses of RID, with my inclination being to forbid its use (since the rationale for defining it largely doesn't exist with declarative use cases). I was convinced that allowing its use was at worst harmless, and that it would be trivial to specify. It's sounding increasingly less trivial, so my inclination is to go back to disallowing it (or, at least, leaving it to another document to specify if a need arises).



6. Section 5:

   o  max-bpp, for maximum number of bits per pixel, calculated as an
      average of all samples of any given coded picture.  This is
      expressed as a floating point value, with an allowed range of
      0.0001 to 48.0.

Does this need a clarification that any values outside of the range will be encoded with the closest value allowed?

I'm not sure we need to accommodate people putting invalid values in here any more than we need to accommodate people putting emoji in here -- and out-of-range values are invalid.

Secondly, the floating point value, how many digits of decimals are allowed? Is this intended to fit in an 32-bit or 64-bit floating point representation or something else?

Added "These values MUST be encoded with at most four digits to the right of the decimal point."

7. Section 5:

   While
   this document does not define constraints for audio codecs, there is
   no reason such constraints should be precluded from definition and
   registration by other documents.

I think this could add that additional media types are also possible. Possible formulation:

   While this document does not define constraints for audio codecs or any other media types than video, there is no reason such constraints should be precluded from definition and registration by other documents.

Done.


8. section 6.2.2:

  3.  If the "a=rid" line contains a "pt=", the list of payload types
       is verified against the list of valid payload types for the media
       section (that is, those listed on the "m=" line).  Any PT missing
       from the "m=" line is removed from the set of valued in the
       "pt=".

This may need handling of the case if the last action results in that the set of PTs in "pt=" becomes empty, then the whole a=rid line needs to be discarded. This as the RID was intended for a limited set of PTs, rather than the default any PT which no "pt=" implies.

Good catch. I've added text:
    If no values are left in the "pt=" parameter after this processing, then the "a=rid" line is removed.



9. Section 6.2.2:

   5.  If the "depend" constraint is included, the answerer MUST make
       sure that the listed rid-ids unambiguously match the rid-ids in
       the SDP offer.  Any "a=rid" lines that do not are removed.

I fail to find a definition of the "depend" constraint in the document. I do find an example using it in addition to the above text.

Huh. I don't know how we missed this. I thought it was in here at some point, but it must have been edited out...?

Anyway:

 * depend, to identify other streams that the stream depends on. The value
   is a comma-separated list of rid-ids. These rid-ids identify RTP streams
   that this stream depends on in order to allow for proper interpretation.


10. Section 6.4:

       Note that this matching must be performed
       semantically rather than on literal PT values, as the remote end
       may not be using symmetric PTs.  For the purpose of this
       comparison: for each PT listed on the "a=rid" line in the answer,
       the offerer looks up the corresponding "a=rtpmap" and "a=fmtp"
       lines in the answer.

I am a bit worried that this is still misunderstood to mean that one can do "byte comparison" of the parameters for a PT. The reality of this comparison is after all that you must compare the parameters that are required to be the same between offer and answer. And that is payload format specific. I would suggest that one makes it clear that in many cases this semantically comparison requires payload format understanding.

Added:

   Note that this semantic comparison
   necessarily requires an understanding of the meaning of codec parameters,
   rather than a rote byte-wise comparison of their values.

11. Section 7.

Needs to be clarified requirements on being able to determine which rid-identifier that applies to a received RTP stream. So if multiple m= lines are defined and they are not all separate RTP sessions, additional method for determining media description to RTP stream are required. Multi-party also needs to be handled.

Again, since there's no real itch to scratch for declarative SDP, and it's getting (even more!) complicated, I propose removing it, with a statement that we don't define its use, although allow for a future document to do so.

12. Section 8.2.3 and 8.2.4:

So even if H.264 supports macroblock internal partitions for 4x4 and 8x8 sub-blocks the calculation for the constraints are done on the macroblock sizes that is 16x16 for luminance, see Section 3.78 of H.264 specification. Thus the conversion factor should in both these cases be 256 pixels per MB.

https://www.itu.int/rec/T-REC-H.264-201602-I/en (pdf version is free)

Thanks. I've changed it to 256 and added math.

13. Section 10:


rid-fmt-list      = "pt=" fmt *( "," fmt )
                     ; fmt defined in {{RFC4566}}

When I verified the ABNF by running Bill Fenner's parser on it I got the "fmt undefinded". One way of avoiding this is to actually define fmt as prose value, by saying that it is an external reference.

fmt          = <as defined in RFC4566>


14. Section 10:

"alpah-numeric" is also undefined. And it is not obvious from where this definition is taken. SP and DIGIT are present in RFC5234 and I assume those definitions are to be used.

RFC 4566 defines:
   ; generic sub-rules: primitives
   alpha-numeric =       ALPHA / DIGIT

I have accordingly added:

alpha-numeric     = < as defined in RFC4566 >




In addition I have to note that if one would use the "alpha-numeric" definition from SDP (RFC4566) then one can't use any of the allowed UTF-8 values from the SDES item in the SDP rid-identifier as the alpha-numeric only support 7-bit ascii characters.

Because of the nature of these identifiers, we really, really don't need to support esoterica here. Limiting the SDP syntax to alphanumerics is intentional.

15. Section 10:

Discrepancy between SDES item and "rid-identifer". To my understanding there exist no limitations in the SDES item against using space or other separators. Such free form is not supported by current "rid-identifier" definition. This effiects both "rid-syntax" and rid-list constructs.

As above, I don't think we need to support arbitrary strings here -- the limited set more than serves our purpose, and the more permissive we are, the more likely SDP parsers are to get get this wrong. In particular, allowing spaces would make our syntax ambiguous. We're going to have to use *some* character as a separator between rid-id and rid-dir, and going through contortions to allow that character to also be allowed in rid-id is a lot of work for literally zero benefit.

16. Section 11.2:

I understand the desire to have this example is "depend" is defined. However, I do note that this is an simulcast example which you in Section 11 refer to the simulcast document.

Sure, I'll add "See {{I-D.ietf-mmusic-sdp-simulcast}} for additional detail about simulcast usage."


17. Section 12.1:

I don't think this section manages to hit all of the registration requirements for new SDP attributes:

From RFC4566:


   o  contact name, email address, and telephone number

   o  attribute name (as it will appear in SDP)

   o  long-form attribute name in English

   o  type of attribute (session level, media level, or both)

   o  whether the attribute value is subject to the charset attribute

   o  a one-paragraph explanation of the purpose of the attribute

   o  a specification of appropriate attribute values for this attribute


Yep; I've added one.

Thanks!

/a
--------------CC4DBB7174D41BF76D602A7A-- From nobody Sun Jul 17 01:51:08 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FB312D0E1 for ; Sun, 17 Jul 2016 01:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 T5GsBB9q8p7g for ; Sun, 17 Jul 2016 01:51:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA6312B02B for ; Sun, 17 Jul 2016 01:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=518; q=dns/txt; s=iport; t=1468745464; x=1469955064; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=Grb1Z+d4h7XisTlWQEU2QEO2FL3JrJOT0WRByv9q5u8=; b=DeeVRUSzyaE9FZclCcPkScdFKWq+VoMl0rP4p9qNiwVCCSDVTxOSXdtM zcDxXncqowH+w1l/c1CuB2xXgOjmVrjxcBdn55zu6PDhKS+mgeoZYwnUQ mWJ4im24CrCxH7yETc7CTwmiYyfbu1eqhlM4Qaiu9SMM6pK2/eU5lWMaK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvLACQRotX/4kNJK1bgz+BALIchEpSh?= =?us-ascii?q?AiHOzwQAQEBAQEBAWUnQQEBAwEIAYQ2FXYCGQ0CXw0IAQGILKB0j2KNWQEBAQc?= =?us-ascii?q?CJYEBhSmBeAiKDoJaAQSZJIsSgnBdgVWHe4VnkB41H4QPIIExSIQngiwBAQE?= X-IronPort-AV: E=Sophos;i="5.28,377,1464652800"; d="scan'208";a="124629553" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2016 08:51:03 +0000 Received: from [10.24.100.87] ([10.24.100.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6H8p2wl001113 for ; Sun, 17 Jul 2016 08:51:03 GMT From: Flemming Andreasen To: mmusic Message-ID: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com> Date: Sun, 17 Jul 2016 04:51:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 08:51:06 -0000 Greetings MMUSIC is currently scheduled to meet Tuesday 11:30-12:30, which partially overlaps with the QUIC BOF (which we expect a lot of people will want to attend). RTCWeb has given up their Friday slot (12:20:13:20) and we have been given the offer to move MMUSIC to that slot. Before doing so we wanted to hear from folks if they are in favor of this or not (we are obviously looking to maximize the attendance, especially from the key stakeholders). Thanks -- Flemming (as MMUSIC co-chair) From nobody Sun Jul 17 02:38:40 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014A212D51C for ; Sun, 17 Jul 2016 02:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go2RZxSZoD5f for ; Sun, 17 Jul 2016 02:38:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8960812D507 for ; Sun, 17 Jul 2016 02:38:37 -0700 (PDT) Received: from [10.119.1.10] ([162.216.46.3]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6H9cXSn010872 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 17 Jul 2016 04:38:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.3] claimed to be [10.119.1.10] From: "Ben Campbell" To: "Flemming Andreasen" Date: Sun, 17 Jul 2016 11:38:32 +0200 Message-ID: <6FBB4E31-F1DE-42B5-BAC5-4EE35AF07378@nostrum.com> In-Reply-To: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com> References: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: mmusic Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 09:38:39 -0000 I note that the MMUSIC agenda is primarily (entirely?) about RTCWEB dependencies. I assume that most interested parties also had planned to attend the Friday RTCWEB meeting. If we do not see major objections really soon[1] (as in the next few hours) I will request the change. [1] I know people may be on airlanes, but the window of opportunity is pretty short. Thanks! Ben. On 17 Jul 2016, at 10:51, Flemming Andreasen wrote: > Greetings > > MMUSIC is currently scheduled to meet Tuesday 11:30-12:30, which > partially overlaps with the QUIC BOF (which we expect a lot of people > will want to attend). RTCWeb has given up their Friday slot > (12:20:13:20) and we have been given the offer to move MMUSIC to that > slot. > > Before doing so we wanted to hear from folks if they are in favor of > this or not (we are obviously looking to maximize the attendance, > especially from the key stakeholders). > > Thanks > > -- Flemming (as MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Sun Jul 17 06:44:27 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A27D12D0AB for ; Sun, 17 Jul 2016 06:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdexCOwO6reo for ; Sun, 17 Jul 2016 06:44:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8056A12D09D for ; Sun, 17 Jul 2016 06:44:24 -0700 (PDT) Received: from dhcp-b26d.meeting.ietf.org (dhcp-b26d.meeting.ietf.org [31.133.178.109]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6HDiHtv032778 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 17 Jul 2016 08:44:19 -0500 (CDT) (envelope-from adam@nostrum.com) To: Ben Campbell , Flemming Andreasen References: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com> <6FBB4E31-F1DE-42B5-BAC5-4EE35AF07378@nostrum.com> From: Adam Roach Message-ID: <9546b8e9-3ff2-bf7f-15f5-d6fa3703f33f@nostrum.com> Date: Sun, 17 Jul 2016 15:44:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6FBB4E31-F1DE-42B5-BAC5-4EE35AF07378@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mmusic Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 13:44:25 -0000 On 7/17/16 11:38, Ben Campbell wrote: > I note that the MMUSIC agenda is primarily (entirely?) about RTCWEB > dependencies. I assume that most interested parties also had planned > to attend the Friday RTCWEB meeting. If we do not see major objections > really soon[1] (as in the next few hours) I will request the change. MMUSIC <-> PERC seems like a pretty unfortunate conflict -- moreso than MMUSIC <-> QUIC, when you consider commonality. /a From nobody Sun Jul 17 06:53:05 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3001412D500 for ; Sun, 17 Jul 2016 06:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFYKHXuNfY5Y for ; Sun, 17 Jul 2016 06:53:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC77412D16D for ; Sun, 17 Jul 2016 06:53:02 -0700 (PDT) Received: from [192.168.99.1] (dhcp-b096.meeting.ietf.org [31.133.176.150]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6HDqwkb033746 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 17 Jul 2016 08:52:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-b096.meeting.ietf.org [31.133.176.150] claimed to be [192.168.99.1] From: "Ben Campbell" To: "Adam Roach" Date: Sun, 17 Jul 2016 15:52:57 +0200 Message-ID: <76A93E1A-EEB9-4039-8FE3-3C13E1457180@nostrum.com> In-Reply-To: <9546b8e9-3ff2-bf7f-15f5-d6fa3703f33f@nostrum.com> References: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com> <6FBB4E31-F1DE-42B5-BAC5-4EE35AF07378@nostrum.com> <9546b8e9-3ff2-bf7f-15f5-d6fa3703f33f@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Flemming Andreasen , mmusic Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 13:53:04 -0000 Perc is at 1000 (Fri morning). The slot we are talking about is at 1220 (friday afternoon I) On 17 Jul 2016, at 15:44, Adam Roach wrote: > On 7/17/16 11:38, Ben Campbell wrote: >> I note that the MMUSIC agenda is primarily (entirely?) about RTCWEB >> dependencies. I assume that most interested parties also had planned >> to attend the Friday RTCWEB meeting. If we do not see major >> objections really soon[1] (as in the next few hours) I will request >> the change. > > MMUSIC <-> PERC seems like a pretty unfortunate conflict -- moreso > than MMUSIC <-> QUIC, when you consider commonality. > > /a From nobody Sun Jul 17 07:12:25 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7348912B010 for ; Sun, 17 Jul 2016 07:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVb_7yKv35iI for ; Sun, 17 Jul 2016 07:12:21 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC8E12B051 for ; Sun, 17 Jul 2016 07:12:21 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-c6-578b92437219 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 99.C7.27088.3429B875; Sun, 17 Jul 2016 16:12:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.208]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0294.000; Sun, 17 Jul 2016 16:12:19 +0200 From: Christer Holmberg To: Ben Campbell , Flemming Andreasen Thread-Topic: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? Thread-Index: AQHR4AhelSZDE+5K1kmo+MoyIUMVS6AcPF4AgABuBbo= Date: Sun, 17 Jul 2016 14:12:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476C4A16@ESESSMB209.ericsson.se> References: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com>, <6FBB4E31-F1DE-42B5-BAC5-4EE35AF07378@nostrum.com> In-Reply-To: <6FBB4E31-F1DE-42B5-BAC5-4EE35AF07378@nostrum.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B476C4A16ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7t67zpO5wg6a/RhbzO0+zW7y/oGsx dfljFgdmjym/N7J6LFnyk8lj1s4nLAHMUVw2Kak5mWWpRfp2CVwZT+73sRcc0KpYsOUyUwPj SZUuRk4OCQETiek/PrNB2GISF+6tB7K5OIQEjjBK/J3UwAzhLGGUuND1mamLkYODTcBCovuf NkiDiIC3xJ0Zk1lAbGYBGYkZZxuZQGxhATuJ6xfes4KUiwjYSyzdywxRbiWxZNEtRpAwi4Cq xM3//CBhXgFfiVvT1zOC2EIC+RKn1k0Fm8gJ1LmofTZYnBHotO+n1jBBbBKXaPqykhXiZAGJ JXvOM0PYohIvH/9jhajJl3g68wUzxHxBiZMzn7BMYBSZhaR9FpKyWUjKIOIGEl/e34aytSWW LXzNDGHrS3S/P82ELL6AkX0Vo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmCUHdzy22AH48vn jocYBTgYlXh4E9Z1hQuxJpYVV+YeYpTgYFYS4T3e3R0uxJuSWFmVWpQfX1Sak1p8iFGag0VJ nNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgdH4waaUXEWdwzzbnc7wXrwqnj9bgrH1WmzYxoTE 0jinWP01Rq9Yd9xtObCvwqrpw/+Fn5fdyLFeYrLG+kNxqSFLvgffc7d1vNXvCis151ZxhChO cJNjWyqi4XVQbHNCyjHOz2vu7TE+x7jS2KNqgarQqVUpTx022nV/3DPdN3GG1KRZM768+6/E UpyRaKjFXFScCADo8s1WrgIAAA== Archived-At: Cc: mmusic Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 14:12:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B476C4A16ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Friday work for me. Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD17/=FD07/=FD2016 12:38 To: Flemming Andreasen Cc: mmusic Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? I note that the MMUSIC agenda is primarily (entirely?) about RTCWEB dependencies. I assume that most interested parties also had planned to attend the Friday RTCWEB meeting. If we do not see major objections really soon[1] (as in the next few hours) I will request the change. [1] I know people may be on airlanes, but the window of opportunity is pretty short. Thanks! Ben. On 17 Jul 2016, at 10:51, Flemming Andreasen wrote: > Greetings > > MMUSIC is currently scheduled to meet Tuesday 11:30-12:30, which > partially overlaps with the QUIC BOF (which we expect a lot of people > will want to attend). RTCWeb has given up their Friday slot > (12:20:13:20) and we have been given the offer to move MMUSIC to that > slot. > > Before doing so we wanted to hear from folks if they are in favor of > this or not (we are obviously looking to maximize the attendance, > especially from the key stakeholders). > > Thanks > > -- Flemming (as MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B476C4A16ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Friday work f= or me.

Regards,

Christer

Sent from my Windows Phone
From: Ben Campbell
Sent: =FD17= /=FD07/=FD2016 12:38
To: Flemming Andreasen
Cc: mmusic
Subject: Re: [= MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ?

I note that the MMUSIC agenda is primarily (entire= ly?) about RTCWEB
dependencies. I assume that most interested parties also had planned to attend the Friday RTCWEB meeting. If we do not see major objections
really soon[1] (as in the next few hours) I will request the change.

[1] I know people may be on airlanes, but the window of opportunity is
pretty short.

Thanks!

Ben.


On 17 Jul 2016, at 10:51, Flemming Andreasen wrote:

> Greetings
>
> MMUSIC is currently scheduled to meet Tuesday 11:30-12:30, which
> partially overlaps with the QUIC BOF (which we expect a lot of people =
> will want to attend). RTCWeb has given up their Friday slot
> (12:20:13:20) and we have been given the offer to move MMUSIC to that =
> slot.
>
> Before doing so we wanted to hear from folks if they are in favor of <= br> > this or not (we are obviously looking to maximize the attendance,
> especially from the key stakeholders).
>
> Thanks
>
> -- Flemming (as MMUSIC co-chair)
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
 --_000_7594FB04B1934943A5C02806D1A2204B476C4A16ESESSMB209erics_-- From nobody Sun Jul 17 07:36:20 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661CB12B010 for ; Sun, 17 Jul 2016 07:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJjPrGCFUUS9 for ; Sun, 17 Jul 2016 07:36:17 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2564112B00F for ; Sun, 17 Jul 2016 07:36:16 -0700 (PDT) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2016 13:16:32 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0210.002; Sun, 17 Jul 2016 10:36:15 -0400 From: Andrew Allen To: Christer Holmberg , Ben Campbell , Flemming Andreasen Thread-Topic: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? Thread-Index: AQHR4AhfjfI7gwSzBECpaDp4gnyC+6AcoPMAgABMfgD//8Oi1w== Date: Sun, 17 Jul 2016 14:36:14 +0000 Message-ID: <20160717143609.6570072.39750.24541@blackberry.com> References: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com>, <6FBB4E31-F1DE-42B5-BAC5-4EE35AF07378@nostrum.com>, <7594FB04B1934943A5C02806D1A2204B476C4A16@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476C4A16@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2016071714360965700723975024541blackberrycom_" MIME-Version: 1.0 Archived-At: Cc: mmusic Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 14:36:19 -0000 --_000_2016071714360965700723975024541blackberrycom_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Works for me too Sent from my BlackBerry 10 smartphone. From: Christer Holmberg Sent: Sunday, July 17, 2016 16:12 To: Ben Campbell; Flemming Andreasen Cc: mmusic Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? Friday work for me. Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD17/=FD07/=FD2016 12:38 To: Flemming Andreasen Cc: mmusic Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? I note that the MMUSIC agenda is primarily (entirely?) about RTCWEB dependencies. I assume that most interested parties also had planned to attend the Friday RTCWEB meeting. If we do not see major objections really soon[1] (as in the next few hours) I will request the change. [1] I know people may be on airlanes, but the window of opportunity is pretty short. Thanks! Ben. On 17 Jul 2016, at 10:51, Flemming Andreasen wrote: > Greetings > > MMUSIC is currently scheduled to meet Tuesday 11:30-12:30, which > partially overlaps with the QUIC BOF (which we expect a lot of people > will want to attend). RTCWeb has given up their Friday slot > (12:20:13:20) and we have been given the offer to move MMUSIC to that > slot. > > Before doing so we wanted to hear from folks if they are in favor of > this or not (we are obviously looking to maximize the attendance, > especially from the key stakeholders). > > Thanks > > -- Flemming (as MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_2016071714360965700723975024541blackberrycom_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Sent from my BlackBerry 10 smartphone.
From: Christer Holmberg
Sent: Sunday, July 17, 2016 16:12
To: Ben Campbell; Flemming Andreasen
Cc: mmusic
Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ?<= /div>

Friday work f= or me.

Regards,

Christer

Sent from my Windows Phone
From: Ben Campbell
Sent: =FD17= /=FD07/=FD2016 12:38
To: Flemming Andreasen
Cc: mmusic
Subject: Re: [= MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ?

I note that the MMUSIC agenda is primarily (entire= ly?) about RTCWEB
dependencies. I assume that most interested parties also had planned to attend the Friday RTCWEB meeting. If we do not see major objections
really soon[1] (as in the next few hours) I will request the change.

[1] I know people may be on airlanes, but the window of opportunity is
pretty short.

Thanks!

Ben.


On 17 Jul 2016, at 10:51, Flemming Andreasen wrote:

> Greetings
>
> MMUSIC is currently scheduled to meet Tuesday 11:30-12:30, which
> partially overlaps with the QUIC BOF (which we expect a lot of people =
> will want to attend). RTCWeb has given up their Friday slot
> (12:20:13:20) and we have been given the offer to move MMUSIC to that =
> slot.
>
> Before doing so we wanted to hear from folks if they are in favor of <= br> > this or not (we are obviously looking to maximize the attendance,
> especially from the key stakeholders).
>
> Thanks
>
> -- Flemming (as MMUSIC co-chair)
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.i= etf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.o= rg/mailman/listinfo/mmusic
--_000_2016071714360965700723975024541blackberrycom_-- From nobody Sun Jul 17 08:13:47 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0018D12B01D for ; Sun, 17 Jul 2016 08:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB0k3WfLLCtB for ; Sun, 17 Jul 2016 08:13:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EB912B00B for ; Sun, 17 Jul 2016 08:13:44 -0700 (PDT) Received: from [192.168.99.1] (dhcp-8dff.meeting.ietf.org [31.133.141.255]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6HFDd7a042236 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 17 Jul 2016 10:13:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-8dff.meeting.ietf.org [31.133.141.255] claimed to be [192.168.99.1] From: "Ben Campbell" To: mmusic Date: Sun, 17 Jul 2016 17:13:39 +0200 Message-ID: In-Reply-To: <6FBB4E31-F1DE-42B5-BAC5-4EE35AF07378@nostrum.com> References: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com> <6FBB4E31-F1DE-42B5-BAC5-4EE35AF07378@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: mmusic-chairs@tools.ietf.org Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 15:13:46 -0000 I have seen no objections and a fair amount of support, so I have requested the Secretariat to make the change. I will be surprised if the change does not go through, but please watch for confirmation. Thanks! Ben. On 17 Jul 2016, at 11:38, Ben Campbell wrote: > I note that the MMUSIC agenda is primarily (entirely?) about RTCWEB > dependencies. I assume that most interested parties also had planned > to attend the Friday RTCWEB meeting. If we do not see major objections > really soon[1] (as in the next few hours) I will request the change. > > [1] I know people may be on airlanes, but the window of opportunity is > pretty short. > > Thanks! > > Ben. > > > On 17 Jul 2016, at 10:51, Flemming Andreasen wrote: > >> Greetings >> >> MMUSIC is currently scheduled to meet Tuesday 11:30-12:30, which >> partially overlaps with the QUIC BOF (which we expect a lot of people >> will want to attend). RTCWeb has given up their Friday slot >> (12:20:13:20) and we have been given the offer to move MMUSIC to that >> slot. >> >> Before doing so we wanted to hear from folks if they are in favor of >> this or not (we are obviously looking to maximize the attendance, >> especially from the key stakeholders). >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Jul 18 01:10:59 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7042112B008; Mon, 18 Jul 2016 01:10:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718081058.12453.85976.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 01:10:58 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 08:10:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-14.txt Pages : 24 Date : 2016-07-18 Abstract: This draft defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The draft also defines the criteria for when a new DTLS association must be established. The draft updates RFC 5763 and RFC 7345, by replacing common SDP offer/ answer procedures with a reference to this specification. This draft defines a new SDP media-level attribute, 'dtls-id'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 18 01:24:42 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE6212D177; Mon, 18 Jul 2016 01:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLOk6f65_xL5; Mon, 18 Jul 2016 01:24:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E7512D09F; Mon, 18 Jul 2016 01:24:39 -0700 (PDT) Received: from [192.168.99.1] (dhcp-b096.meeting.ietf.org [31.133.176.150]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6I8OWBB046656 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Jul 2016 03:24:34 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-b096.meeting.ietf.org [31.133.176.150] claimed to be [192.168.99.1] From: "Ben Campbell" To: "Flemming Andreasen" Date: Mon, 18 Jul 2016 10:24:31 +0200 Message-ID: <257BC9AC-714C-4371-BA72-BE743445259B@nostrum.com> In-Reply-To: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com> References: <5062dbbc-3753-9a4b-22fa-f2a3a3cd1470@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: ART ADs , mmusic-chairs@tools.ietf.org, mmusic Subject: Re: [MMUSIC] IETF 96 MMUSIC Meeting: Move to Friday ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 08:24:41 -0000 Hi, The change to Friday (12:20-13:20) is confirmed. The secretariat will send out the official change later today. Please adjust your schedules accordingly. Thanks! Ben. On 17 Jul 2016, at 10:51, Flemming Andreasen wrote: > Greetings > > MMUSIC is currently scheduled to meet Tuesday 11:30-12:30, which > partially overlaps with the QUIC BOF (which we expect a lot of people > will want to attend). RTCWeb has given up their Friday slot > (12:20:13:20) and we have been given the offer to move MMUSIC to that > slot. > > Before doing so we wanted to hear from folks if they are in favor of > this or not (we are obviously looking to maximize the attendance, > especially from the key stakeholders). > > Thanks > > -- Flemming (as MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Jul 18 01:31:47 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF2C12D150; Mon, 18 Jul 2016 01:31:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718083143.12557.56752.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 01:31:43 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 08:31:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : RTP Payload Format Constraints Authors : Peter Thatcher Mo Zanaty Suhas Nandakumar Bo Burman Adam Roach Byron Campen Filename : draft-ietf-mmusic-rid-07.txt Pages : 25 Date : 2016-07-18 Abstract: In this specification, we define a framework for specifying constraints on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and constrain the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the constraints defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 18 10:40:24 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 910B012D126; Mon, 18 Jul 2016 10:40:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718174020.18096.58522.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 10:40:20 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 17:40:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-09.txt Pages : 12 Date : 2016-07-18 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 19 15:11:47 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D92A12D95C for ; Tue, 19 Jul 2016 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5NdPSyhVjf2 for ; Tue, 19 Jul 2016 15:11:40 -0700 (PDT) Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E497012D97F for ; Tue, 19 Jul 2016 15:11:39 -0700 (PDT) X-Halon-ID: c46d9efd-4dfd-11e6-81a1-005056913f0f Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.156.58]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Wed, 20 Jul 2016 00:11:39 +0200 (CEST) To: "Ali C. Begen" References: <5611A155.1050303@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 20 Jul 2016 00:11:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Clarification for multiple lang attributes in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 22:11:44 -0000 Ali and all, The correspondence below is from a request to clarify language in rfc4566bis for the 'lang' attribute. The proposed modification was successfully done, so, in the current version, the description for the 'lang' attribute is as indicated in the "proposed replacement" a bit down in the earlier mail. Thanks! However, we have discussed this in SLIM and found that there may still be room for different interpretations. One would still be that indication of multiple 'lang' attributes would mean a desire to use them all during the session, and another interpretation that a list of 'lang' attributes mean a list for selection what to use during the session, and usually only one language will be selected and used. We have recommended to have the discussions here in mmusic, where the question belongs. In slim, it is in draft-ietf-slim-negotiating-human-language-01 that we have a section 5 discussing this topic. The discussion is supposed to be drastically reduced in next version. There is also more about the background below. So, again, a wording proposal for section 6.12 of rfc4566bis: ------------------------------Current wording of 6.12---------------------------------------------- Multiple lang attributes can be provided either at session or media level if the session or media has capabilities to use multiple languages, in which case the order of the attributes indicates the order of preference of the various languages in the session or media, from most preferred to least preferred. As a session-level attribute, lang specifies a language capability for the session being described. As a media-level attribute, it specifies a language capability for that media, overriding any session-level language(s) specified. The "lang" attribute value must be a single [RFC5646] language tag in US-ASCII. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session has capabilities in languages different from the locally assumed norm. Events during the session may influence which language(s) are used, and the participants are not strictly bound to only use the declared languages. ---------------------------------------------------------------------------- -----------------------Proposed wording------------------------------- Multiple lang attributes can be provided either at session or media level if the session or media has capabilities in more than one language, in which case the order of the attributes indicates the order of preference of the various languages in the session or media, from most preferred to least preferred. As a session-level attribute, lang specifies a language capability for the session being described. As a media-level attribute, it specifies a language capability for that media, overriding any session-level language(s) specified. The "lang" attribute value must be a single [RFC5646] language tag in US-ASCII. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of participants cannot be assumed, or where the session has capabilities in languages different from the locally assumed norm. The 'lang' attribute is supposed to be used for settling the initial language(s) used in the session. Events during the session may influence which language(s) are used, and the participants are not strictly bound to only use the declared languages. Most real-time use cases start with just one language used, while other cases involve a range of languages, e.g. an interpreted or subtitled session. When more than one 'lang' attribute is specified, the 'lang' attribute itself does not provide any information about if multiple languages are intended to be used during the session, or if the intention is to only select one language. Other attributes or the semantics in which the 'lang' attributes are used may indicate such conditions. Without such indications of usage intent, it should be assumed that for a negotiated session one of the declared languages should be selected and used. --------------------------End of wording proposal-------------------------------- I realize that the last paragraph is fuzzy, and would appreciate a discussion on the best way to handle this, and also the best way to ease the use of the 'lang' attribute already when current RFC4566 is used. Regards Gunnar ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se Den 2015-10-05 kl. 12:04, skrev Ali C. Begen: > Hi Gunnar > > Thanks for bringing this up. I am not against your wording and I dont > think this change causes issues with recorded material, which could > support a single or multiple languages and in that case, you can use > this attribute in the declarative mode. > > if there are no objections, I can implement this change in the next cycle. > > -acbegen > > On Mon, Oct 5, 2015 at 12:59 AM, Gunnar Hellström > wrote: >> There is some uncertainty about interpretation of multiple lang attributes >> in RFC 4566 that would need to be sorted out in rfc4566bis. >> The uncertainty has caused stox to select another mechanism and now also >> slim is hesitating. (see slim and its real-time draft for a deeper >> discussion) >> >> The current text in section 6.12 of rfc4566bis is: >> >> -----------------------------current text from >> 6.12-------------------------------- >> >> Multiple lang attributes can be provided either at session or media >> level if the session or media use multiple languages, in which case >> the order of the attributes indicates the order of importance of the >> various languages in the session or media, from most important to >> least important. >> >> As a session-level attribute, it specifies the default language for >> the session being described. As a media-level attribute, it >> specifies the language for that media, overriding any session-level >> languages specified. >> >> The "lang" attribute value must be a single [RFC5646] language tag in >> US-ASCII. A "lang" attribute SHOULD be specified when a session is >> of sufficient scope to cross geographic boundaries where the language >> of recipients cannot be assumed, or where the session is in a >> different language from the locally assumed norm. >> >> ----------------------------------------------------------------------------------------------- >> >> The uncertainty has been around what the wording "use multiple languages" >> means. >> It can mean that all are provided simultaneously, but it can also mean that >> it is a list of capabilities and >> that events during the session can decide which languages will really be >> used. There is also uncertainty >> about if a negotiation can take place to agree on one or a set of common >> languages to select from as default language(s). >> >> In order to bring some clarity, I suggest to change to the following: >> >> -----------------------------proposed replacement text for >> 6.12-------------------------------- >> >> Multiple lang attributes can be provided either at session or media >> level if the session or media has capabilities to use multiple languages, >> in which case >> the order of the attributes indicates the order of preference of the >> various languages in the session or media, from most preferred to >> least preferred. >> >> As a session-level attribute, lang specifies a language capability for >> the session being described. As a media-level attribute, it >> specifies a language capability for that media, overriding any >> session-level >> language(s) specified. >> >> The "lang" attribute value must be a single [RFC5646] language tag in >> US-ASCII. A "lang" attribute SHOULD be specified when a session is >> of sufficient scope to cross geographic boundaries where the language >> of recipients cannot be assumed, or where the session has capabilities in >> languages different from the locally assumed norm. >> >> Events during the session may influence which language(s) are used, and >> the >> participants are not strictly bound to only use the declared languages. >> >> >> >> ----------------------------------------------------------------------------------------------- >> >> My conclusion from looking at the background of the wording for lang in RFC >> 4566 is that we can safely assume that for real-time sessions, the meaning >> of multiple lang specifications is a range of capabilities, and not a >> requirement to use all languages. >> By that interpretation, we can also assume that an offer/answer exchange can >> negotiate the language(s) to be suitable for use in a session to be a subset >> of what the offer contained. >> >> I traced the introduction of the wording from an announcement in mmusic on >> 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 on >> 1997-12-23. There was no further discussion and the wording has stayed like >> that with merely a swap of the paragraphs in rfc4566bis. >> >> In the mail announcing the introduction it was said that the intention was >> to fulfill requirements from a draft that then became RFC 2277. >> >> A relevant section in RFC 2277 is: >> " >> >> 4.4. Considerations for language negotiation >> >> Protocols where users have text presented to them in response to user >> actions MUST provide for support of multiple languages. >> >> How this is done will vary between protocols; for instance, in some >> cases, a negotiation where the client proposes a set of languages and >> the server replies with one is appropriate; in other cases, a server >> may choose to send multiple variants of a text and let the client >> pick which one to display. >> >> Negotiation is useful in the case where one side of the protocol >> exchange is able to present text in multiple languages to the other >> side, and the other side has a preference for one of these; the most >> common example is the text part of error responses, or Web pages that >> are available in multiple languages. >> >> Negotiating a language should be regarded as a permanent requirement >> of the protocol that will not go away at any time in the future. >> >> In many cases, it should be possible to include it as part of the >> connection establishment, together with authentication and other >> preferences negotiation. " >> >> So it is apparent that the intention for real-time conversational cases is a >> negotiation with >> an offer and a selection, either in an answer or by human agreement in the >> session. >> >> The central word creating the hesitation in interpretation is that all >> languages must be used is "use" in this phrase: >> "if the session description or media use multiple languages". >> >> It is hard to believe that it was the intention that all must be used. The >> proposed wording is made to make the >> interpretation clear that it is a set of capabilities.. >> >> There are multiple reasons for that interpretation: >> >> 1. It aligns with the requirement for language negotiation in RFC 2277 that >> was said to be >> the requirement behind the wording. >> 2. It is usually unrealistic to use multiple languages at the same time in a >> medium. >> It is more in line at least with real-time conversation that events >> during the conversation causes decision to use >> just one language. >> 3. The discussion in the original wording of importance of languages lose >> its meaning if all must be used. "the >> order of the attributes indicates the order of importance of the various >> languages in the session or media". >> There is no use of knowing how important a language is if they all must be >> presented. It is more likely that >> this relates to a possibility to select languages and that the "importance" >> is a grading of preference. >> >> This would mean that we can safely assume that the use of multiple lang >> attributes in SDP were and are intended as >> a selection and that negotiation through offer/answer is possible. >> >> >> I realize that the language about capabilities in my proposal does not match >> an sdp that belongs to a >> static session with recorded material equally well as it does for a >> real-time session between human participants, >> but I want anyway propose the wording. >> >> /Gunnar Hellström >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Wed Jul 20 04:37:06 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A31512D561; Wed, 20 Jul 2016 04:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 16BwIarzrbwV; Wed, 20 Jul 2016 04:37:02 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD2412DBBA; Wed, 20 Jul 2016 04:37:02 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id q128so52526648wma.1; Wed, 20 Jul 2016 04:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=91eKYii4GiwRBxpI7Yt/lX3OBme0KX9ufDNzn+5TgVc=; b=LkGvQX8Bzx1Gng5sctNj9ZTf2ROg0yUbQvi3HsWGsGNyQ8HplgWmJWWngbHdsgkQ1l HN1chCpfIB/RaFCzkCFZSsPRjq1H5/wFS/RQ0lpVqyhEiFHYPaK1HlL+UAHsLWshxXfv GDc1cm3jccnc80QHf6EZqsqrsIxmbt2Jt7GqLLyRdgCZl3OY7/SLoaw+VIFY158nmnT0 FvlQSq7maKMUj65Gjw2BZZ7NfACgUx8ePygTbCjquCrSjuDhjP6MaQpAY8LMjrID8pF8 PBDOk0dWfPVHnNEwOdXk1flBbSsDQYILADZnQBwW2rPdZ/FKmhXwIi55QP0b9f2bHYp3 poAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=91eKYii4GiwRBxpI7Yt/lX3OBme0KX9ufDNzn+5TgVc=; b=S4TDjLGJubCTSXig5XRHn0nlBe+akWf+3vuX7ldyMLpBSQI6XRhg+U72wjgCYbcxwk 6pdKX6RRWmXuL7dJw3EAwpEhuupPhPlVWiN0y7gxuUCFZhNrzdj4C1Y/0QPTu82KuZeX LC+wP0Q9bmBAP3yIcMshVTsImC3vCHXFeBzshEu5NMBm7Ra7KA4sBtbHUoeBwJfbPCFO MMl0wvdRt/1kZjwVZT49WGhEHbDyp82JuburWRHpEvn/mVb7u89vMmb26eG57uZsDWBs 2GLvgfv7goB16a7TKgGjMN4fjJMB/Mg4r6sCDnR6VCIPAFB7TbXvQJPAOp32Ngl+IAtr /XJQ== X-Gm-Message-State: ALyK8tJI5dgjvCJXQ2fiFH+P0497Dta5mk2ITmsIKmAVPUBhK8Bh46A1ZCBln/cLptA4f3VKTBAxY7wa2azWEg== X-Received: by 10.28.26.5 with SMTP id a5mr11824381wma.27.1469014620840; Wed, 20 Jul 2016 04:37:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.117.67 with HTTP; Wed, 20 Jul 2016 04:36:59 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476AA914@ESESSMB208.ericsson.se> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> <7594FB04B1934943A5C02806D1A2204B476AA914@ESESSMB208.ericsson.se> From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Wed, 20 Jul 2016 13:36:59 +0200 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114cbb7aa52b4d05380f9eb5 Archived-At: Cc: Jonathan Lennox , mmusic , IETF AVTCore WG Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:37:05 -0000 --001a114cbb7aa52b4d05380f9eb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, thinking a bit about that idea, if we support that different RTP streams have the same MID, we should provide a kind of version to deal with race conditions. Taking the example of =E2=80=9Cthe current loudest speaker=E2=80=9D (LS) , = if the middle box switches many times Alice <-> Bob streams the endpoint receiving the RTP streams may show the incorrect loudest-speaker due to processing an RTP stream before the other one (network, race condition into the endpoint, etc.) Imagine that case: MidleBox side: Alice LS -> Bob LS -> Alice LS Endpoint side: Process Alice as LS -> Process Alice LS -> Process Bob LS At the end the endpoint would render Bob as LS, but it is wrong. To fix this race condition problem I propose adding a version: MidleBox side: Alice LS-0 -> Bob LS-1 -> Alice LS-2 Endpoint side: Process Alice as LS-0 -> Process Alice LS-2 -> Process Bob LS-1 (discarded because 1<2) What do you think about that? Best regards!! 2016-07-14 17:49 GMT+02:00 Christer Holmberg : > Hi, > > You don't need a common logic. You can define an application layer > protocol (e.g. CLUE) to define/configure/negotiate these kind of things. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Suhas Nandakumar > Sent: =E2=80=8E14/=E2=80=8E07/=E2=80=8E2016 18:43 > To: Christer Holmberg > Cc: I=C3=B1aki Baz Castillo ; Jonathan Lennox > ; mmusic ; IETF AVTCore WG > > Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple > MIDs? > > > > On Thu, Jul 14, 2016 at 3:27 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> >> >... >> > >> >The current proposal breaks that. Please let's MID to be a single, >> >unique and mandatory attribute per m-line. >> >> >> =C5=A0and let each RTP packet be associated with one, and only one, of t= hose >> MIDs/m-lines. >> >> >> You can then have application logic saying e.g. =C2=B3If no =C5=92loudes= t-speaker=C2=B9 >> media is received, then duplicate the =C5=92boss=C2=B9 media on the scre= en >> associated with the loudest speaker=C2=B2. It=C2=B9s much more flexible,= and without >> any of the constraints mentioned earlier. >> >> > I agree it brings in flexibility and it scares me a bit as well .. Each > application needs to define their own logic or need a common logic across > all applications .. > > > >> >> Regards, >> >> Christer >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --001a114cbb7aa52b4d05380f9eb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
thinking a bit about that idea, if we support that different RTP streams= have the same MID, we should provide a kind of version to deal with race c= onditions.

Taking the example of =E2=80=9Cthe current loudest = speaker=E2=80=9D (LS) , if the middle box switches many times Alice <-&g= t; Bob streams the endpoint receiving the RTP streams may show the incorrec= t loudest-speaker due to processing an RTP stream before the other one (net= work, race condition into the endpoint, etc.)

Imagine that cas= e:
MidleBox side: Alice LS -> Bob LS -> Alice LS
En= dpoint side: Process Alice as LS -> Process Alice LS -> Process Bob L= S

At the end the endpoint would render Bob as LS, but it is wr= ong.

To fix this race condition problem I propose adding a ver= sion:
MidleBox side: Alice LS-0 -> Bob LS-1 -> Alice LS-2
Endpo= int side: Process Alice as LS-0 -> Process Alice LS-2 -> Process Bob = LS-1 (discarded because 1<2)

What do you think about that?<= br>
Best regards!!


2016-07-14 17:49 GMT+02:00= Christer Holmberg <christer.holmberg@ericsson.com>:
Hi,

You don't need a common logic. You can define an application layer prot= ocol (e.g. CLUE) to define/configure/negotiate these kind of things.

Regards,

Christer

Sent from my Windows Phone
From: Suhas Nandakumar
Sent: =E2=80= =8E14/=E2=80=8E07/=E2=80=8E2016 18:43
To: Christer Holm= berg
Cc: I=C3=B1aki Baz Castillo; Jonathan Lennox= ; mmusic; IETF AVTCore = WG
Subject: Re: [M= MUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs?



On Thu, Jul 14, 2016 at 3:27 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

>...
>
>The current proposal breaks that. Please let's MID to be a single,<= br> >unique and mandatory attribute per m-line.


=C5=A0and let each RTP packet be associated with one, and only one, = of those
MIDs/m-lines.


You can then have application logic saying e.g. =C2=B3If no =C5=92loudest-s= peaker=C2=B9
media is received, then duplicate the =C5=92boss=C2=B9 media on the screen<= br> associated with the loudest speaker=C2=B2. It=C2=B9s much more flexible, an= d without
any of the constraints mentioned earlier.


I agree it brings in flexibility and it scares me a bit as well .. Eac= h application needs to define their own logic or need a common logic across= all applications ..

=C2=A0

Regards,

Christer

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic<= br>


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




--
Miguel Par= =C3=ADs D=C3=ADaz
------------------------------------------------------= ------------------
Computer/Software engineer.
Researcher and archite= ct in http://www.kuren= to.org
h= ttp://twitter.com/mparisdiaz
---------------------------------------= ---------------------------------
--001a114cbb7aa52b4d05380f9eb5-- From nobody Wed Jul 20 08:46:57 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF7E12D7F6; Wed, 20 Jul 2016 08:46:53 -0700 (PDT) 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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0wM2a-mVCK1; Wed, 20 Jul 2016 08:46:51 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC341120727; Wed, 20 Jul 2016 08:46:50 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u6KFij83025614; Wed, 20 Jul 2016 11:46:47 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 248uh5svvu-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jul 2016 11:46:47 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 20 Jul 2016 10:46:46 -0500 From: Jonathan Lennox To: =?utf-8?B?TWlndWVsIFBhcsOtcyBEw61heg==?= Thread-Topic: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3bAS2iXZNVjDUESNYXQcq89uRqAYBL8AgABgnYCAAAGkAIAJJ36AgABFx4A= Date: Wed, 20 Jul 2016 15:46:45 +0000 Message-ID: <9245E2F8-C683-438F-BD16-0BEA27D813EE@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> <7594FB04B1934943A5C02806D1A2204B476AA914@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.177.193] Content-Type: multipart/alternative; boundary="_000_9245E2F8C683438FBD160BEA27D813EEvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-20_08:2016-07-20,2016-07-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607200179 Archived-At: Cc: mmusic , IETF AVTCore WG , Christer Holmberg Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:46:53 -0000 --_000_9245E2F8C683438FBD160BEA27D813EEvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ZHJhZnQtaWV0Zi1hdnRleHQtc2Rlcy1oZHItZXh0IGRpc2N1c3NlcyB3YXlzIHRvIG5vdGljZSBy ZW9yZGVyaW5nIG9mIHBhY2tldHMgY2FycnlpbmcgU0RFUyBoZWFkZXIgZXh0ZW5zaW9ucyAob2Yg d2hpY2ggTUlEIGlzIGFuIGluc3RhbmNlKS4gIElzIHRoYXQgdGV4dCBzdWZmaWNpZW50Pw0KDQpP biBKdWwgMjAsIDIwMTYsIGF0IDE6MzYgUE0sIE1pZ3VlbCBQYXLDrXMgRMOtYXogPG1wYXJpc2Rp YXpAZ21haWwuY29tPG1haWx0bzptcGFyaXNkaWF6QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIZWxs bywNCnRoaW5raW5nIGEgYml0IGFib3V0IHRoYXQgaWRlYSwgaWYgd2Ugc3VwcG9ydCB0aGF0IGRp ZmZlcmVudCBSVFAgc3RyZWFtcyBoYXZlIHRoZSBzYW1lIE1JRCwgd2Ugc2hvdWxkIHByb3ZpZGUg YSBraW5kIG9mIHZlcnNpb24gdG8gZGVhbCB3aXRoIHJhY2UgY29uZGl0aW9ucy4NCg0KVGFraW5n IHRoZSBleGFtcGxlIG9mIOKAnHRoZSBjdXJyZW50IGxvdWRlc3Qgc3BlYWtlcuKAnSAoTFMpICwg aWYgdGhlIG1pZGRsZSBib3ggc3dpdGNoZXMgbWFueSB0aW1lcyBBbGljZSA8LT4gQm9iIHN0cmVh bXMgdGhlIGVuZHBvaW50IHJlY2VpdmluZyB0aGUgUlRQIHN0cmVhbXMgbWF5IHNob3cgdGhlIGlu Y29ycmVjdCBsb3VkZXN0LXNwZWFrZXIgZHVlIHRvIHByb2Nlc3NpbmcgYW4gUlRQIHN0cmVhbSBi ZWZvcmUgdGhlIG90aGVyIG9uZSAobmV0d29yaywgcmFjZSBjb25kaXRpb24gaW50byB0aGUgZW5k cG9pbnQsIGV0Yy4pDQoNCkltYWdpbmUgdGhhdCBjYXNlOg0KTWlkbGVCb3ggc2lkZTogQWxpY2Ug TFMgLT4gQm9iIExTIC0+IEFsaWNlIExTDQpFbmRwb2ludCBzaWRlOiBQcm9jZXNzIEFsaWNlIGFz IExTIC0+IFByb2Nlc3MgQWxpY2UgTFMgLT4gUHJvY2VzcyBCb2IgTFMNCg0KQXQgdGhlIGVuZCB0 aGUgZW5kcG9pbnQgd291bGQgcmVuZGVyIEJvYiBhcyBMUywgYnV0IGl0IGlzIHdyb25nLg0KDQpU byBmaXggdGhpcyByYWNlIGNvbmRpdGlvbiBwcm9ibGVtIEkgcHJvcG9zZSBhZGRpbmcgYSB2ZXJz aW9uOg0KTWlkbGVCb3ggc2lkZTogQWxpY2UgTFMtMCAtPiBCb2IgTFMtMSAtPiBBbGljZSBMUy0y DQpFbmRwb2ludCBzaWRlOiBQcm9jZXNzIEFsaWNlIGFzIExTLTAgLT4gUHJvY2VzcyBBbGljZSBM Uy0yIC0+IFByb2Nlc3MgQm9iIExTLTEgKGRpc2NhcmRlZCBiZWNhdXNlIDE8MikNCg0KV2hhdCBk byB5b3UgdGhpbmsgYWJvdXQgdGhhdD8NCg0KQmVzdCByZWdhcmRzISENCg0KDQoyMDE2LTA3LTE0 IDE3OjQ5IEdNVCswMjowMCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjoNCkhpLA0K DQpZb3UgZG9uJ3QgbmVlZCBhIGNvbW1vbiBsb2dpYy4gWW91IGNhbiBkZWZpbmUgYW4gYXBwbGlj YXRpb24gbGF5ZXIgcHJvdG9jb2wgKGUuZy4gQ0xVRSkgdG8gZGVmaW5lL2NvbmZpZ3VyZS9uZWdv dGlhdGUgdGhlc2Uga2luZCBvZiB0aGluZ3MuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNClNl bnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRnJvbTogU3VoYXMgTmFuZGFrdW1hcjxtYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbT4NClNl bnQ6IOKAjjE0L+KAjjA3L+KAjjIwMTYgMTg6NDMNClRvOiBDaHJpc3RlciBIb2xtYmVyZzxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IEnDsWFraSBCYXogQ2FzdGls bG88bWFpbHRvOmliY0BhbGlheC5uZXQ+OyBKb25hdGhhbiBMZW5ub3g8bWFpbHRvOmpvbmF0aGFu QHZpZHlvLmNvbT47IG1tdXNpYzxtYWlsdG86bW11c2ljQGlldGYub3JnPjsgSUVURiBBVlRDb3Jl IFdHPG1haWx0bzphdnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gW0FWVENPUkVd IEJVTkRMRTogYSBzaW5nbGUgc3RyZWFtIHdpdGggbXVsdGlwbGUgTUlEcz8NCg0KDQoNCk9uIFRo dSwgSnVsIDE0LCAyMDE2IGF0IDM6MjcgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4+IHdyb3RlOg0KDQo+Li4uDQo+DQo+VGhlIGN1cnJlbnQgcHJvcG9zYWwgYnJlYWtzIHRoYXQu IFBsZWFzZSBsZXQncyBNSUQgdG8gYmUgYSBzaW5nbGUsDQo+dW5pcXVlIGFuZCBtYW5kYXRvcnkg YXR0cmlidXRlIHBlciBtLWxpbmUuDQoNCg0KxaBhbmQgbGV0IGVhY2ggUlRQIHBhY2tldCBiZSBh c3NvY2lhdGVkIHdpdGggb25lLCBhbmQgb25seSBvbmUsIG9mIHRob3NlDQpNSURzL20tbGluZXMu DQoNCg0KWW91IGNhbiB0aGVuIGhhdmUgYXBwbGljYXRpb24gbG9naWMgc2F5aW5nIGUuZy4gwrNJ ZiBubyDFkmxvdWRlc3Qtc3BlYWtlcsK5DQptZWRpYSBpcyByZWNlaXZlZCwgdGhlbiBkdXBsaWNh dGUgdGhlIMWSYm9zc8K5IG1lZGlhIG9uIHRoZSBzY3JlZW4NCmFzc29jaWF0ZWQgd2l0aCB0aGUg bG91ZGVzdCBzcGVha2VywrIuIEl0wrlzIG11Y2ggbW9yZSBmbGV4aWJsZSwgYW5kIHdpdGhvdXQN CmFueSBvZiB0aGUgY29uc3RyYWludHMgbWVudGlvbmVkIGVhcmxpZXIuDQoNCg0KSSBhZ3JlZSBp dCBicmluZ3MgaW4gZmxleGliaWxpdHkgYW5kIGl0IHNjYXJlcyBtZSBhIGJpdCBhcyB3ZWxsIC4u IEVhY2ggYXBwbGljYXRpb24gbmVlZHMgdG8gZGVmaW5lIHRoZWlyIG93biBsb2dpYyBvciBuZWVk IGEgY29tbW9uIGxvZ2ljIGFjcm9zcyBhbGwgYXBwbGljYXRpb25zIC4uDQoNCg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp Yw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpt bXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg0KDQoN Ci0tDQpNaWd1ZWwgUGFyw61zIETDrWF6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNvbXB1dGVyL1NvZnR3 YXJlIGVuZ2luZWVyLg0KUmVzZWFyY2hlciBhbmQgYXJjaGl0ZWN0IGluIGh0dHA6Ly93d3cua3Vy ZW50by5vcmc8aHR0cDovL3d3dy5rdXJlbnRvLm9yZy8+DQpodHRwOi8vdHdpdHRlci5jb20vbXBh cmlzZGlheg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== --_000_9245E2F8C683438FBD160BEA27D813EEvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5kcmFmdC1p ZXRmLWF2dGV4dC1zZGVzLWhkci1leHQgZGlzY3Vzc2VzIHdheXMgdG8gbm90aWNlIHJlb3JkZXJp bmcgb2YgcGFja2V0cyBjYXJyeWluZyBTREVTIGhlYWRlciBleHRlbnNpb25zIChvZiB3aGljaCBN SUQgaXMgYW4gaW5zdGFuY2UpLiAmbmJzcDtJcyB0aGF0IHRleHQgc3VmZmljaWVudD88L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+T24gSnVsIDIwLCAyMDE2LCBhdCAxOjM2IFBNLCBNaWd1ZWwgUGFyw61z IETDrWF6ICZsdDs8YSBocmVmPSJtYWlsdG86bXBhcmlzZGlhekBnbWFpbC5jb20iIGNsYXNzPSIi Pm1wYXJpc2RpYXpAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkhlbGxvLDxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KdGhpbmtpbmcgYSBiaXQgYWJvdXQgdGhhdCBpZGVhLCBpZiB3ZSBzdXBwb3J0 IHRoYXQgZGlmZmVyZW50IFJUUCBzdHJlYW1zIGhhdmUgdGhlIHNhbWUgTUlELCB3ZSBzaG91bGQg cHJvdmlkZSBhIGtpbmQgb2YgdmVyc2lvbiB0byBkZWFsIHdpdGggcmFjZSBjb25kaXRpb25zLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KVGFraW5nIHRoZSBleGFtcGxlIG9m IOKAnHRoZSBjdXJyZW50IGxvdWRlc3Qgc3BlYWtlcuKAnSAoTFMpICwgaWYgdGhlIG1pZGRsZSBi b3ggc3dpdGNoZXMgbWFueSB0aW1lcyBBbGljZSAmbHQ7LSZndDsgQm9iIHN0cmVhbXMgdGhlIGVu ZHBvaW50IHJlY2VpdmluZyB0aGUgUlRQIHN0cmVhbXMgbWF5IHNob3cgdGhlIGluY29ycmVjdCBs b3VkZXN0LXNwZWFrZXIgZHVlIHRvIHByb2Nlc3NpbmcgYW4gUlRQIHN0cmVhbSBiZWZvcmUgdGhl IG90aGVyIG9uZSAobmV0d29yaywNCiByYWNlIGNvbmRpdGlvbiBpbnRvIHRoZSBlbmRwb2ludCwg ZXRjLik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkltYWdpbmUgdGhhdCBj YXNlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KTWlkbGVCb3ggc2lkZTogQWxpY2UgTFMgLSZndDsg Qm9iIExTIC0mZ3Q7IEFsaWNlIExTPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpFbmRwb2ludCBzaWRl OiBQcm9jZXNzIEFsaWNlIGFzIExTIC0mZ3Q7IFByb2Nlc3MgQWxpY2UgTFMgLSZndDsgUHJvY2Vz cyBCb2IgTFM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkF0IHRoZSBlbmQg dGhlIGVuZHBvaW50IHdvdWxkIHJlbmRlciBCb2IgYXMgTFMsIGJ1dCBpdCBpcyB3cm9uZy48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRvIGZpeCB0aGlzIHJhY2UgY29uZGl0 aW9uIHByb2JsZW0gSSBwcm9wb3NlIGFkZGluZyBhIHZlcnNpb246PGJyIGNsYXNzPSIiPg0KTWlk bGVCb3ggc2lkZTogQWxpY2UgTFMtMCAtJmd0OyBCb2IgTFMtMSAtJmd0OyBBbGljZSBMUy0yPGJy IGNsYXNzPSIiPg0KRW5kcG9pbnQgc2lkZTogUHJvY2VzcyBBbGljZSBhcyBMUy0wIC0mZ3Q7IFBy b2Nlc3MgQWxpY2UgTFMtMiAtJmd0OyBQcm9jZXNzIEJvYiBMUy0xIChkaXNjYXJkZWQgYmVjYXVz ZSAxJmx0OzIpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpXaGF0IGRvIHlv dSB0aGluayBhYm91dCB0aGF0PzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K QmVzdCByZWdhcmRzISE8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTYtMDctMTQg MTc6NDkgR01UJiM0MzswMjowMCBDaHJpc3RlciBIb2xtYmVyZyA8c3BhbiBkaXI9Imx0ciIgY2xh c3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTwvYT4mZ3Q7PC9zcGFuPjo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0IiBj bGFzcz0iIj5IaSw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpZb3UgZG9uJ3QgbmVlZCBh IGNvbW1vbiBsb2dpYy4gWW91IGNhbiBkZWZpbmUgYW4gYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9j b2wgKGUuZy4gQ0xVRSkgdG8gZGVmaW5lL2NvbmZpZ3VyZS9uZWdvdGlhdGUgdGhlc2Uga2luZCBv ZiB0aGluZ3MuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmVnYXJkcyw8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpDaHJpc3RlcjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPg0KPGhyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjtmb250LXNpemU6MTFwdDtmb250LXdlaWdodDpib2xkIiBjbGFzcz0iIj5G cm9tOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 Zm9udC1zaXplOjExcHQiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpzdWhhc2lldGZAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+U3VoYXMgTmFuZGFrdW1hcjwvYT48L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJp Zjtmb250LXNpemU6MTFwdDtmb250LXdlaWdodDpib2xkIiBjbGFzcz0iIj5TZW50Og0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEx cHQiIGNsYXNzPSIiPuKAjjE0L+KAjjA3L+KAjjIwMTYgMTg6NDM8L3NwYW4+PGJyIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6 MTFwdDtmb250LXdlaWdodDpib2xkIiBjbGFzcz0iIj5UbzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0IiBjbGFzcz0iIj48 YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+Q2hyaXN0ZXIgSG9sbWJlcmc8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEx cHQ7Zm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+Q2M6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTFwdCIgY2xhc3M9IiI+PGEg aHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5Jw7Fh a2kgQmF6IENhc3RpbGxvPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20i IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5Kb25hdGhhbiBMZW5ub3g8L2E+Ow0KPGEgaHJlZj0i bWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm1tdXNpYzwv YT47IDxhIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij4NCklFVEYgQVZUQ29yZSBXRzwvYT48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTFwdDtmb250LXdlaWdo dDpib2xkIiBjbGFzcz0iIj5TdWJqZWN0Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHQiIGNsYXNzPSIiPlJlOiBbTU1VU0lD XSBbQVZUQ09SRV0gQlVORExFOiBhIHNpbmdsZSBzdHJlYW0gd2l0aCBtdWx0aXBsZSBNSURzPzwv c3Bhbj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIEp1bCAxNCwgMjAxNiBhdCAzOjI3IFBN LCBDaHJpc3RlciBIb2xtYmVyZyA8c3BhbiBkaXI9Imx0ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3 cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCjxiciBjbGFzcz0iIj4NCiZndDsuLi48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFz cz0iIj4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0O1RoZSBjdXJyZW50IHByb3Bvc2FsIGJyZWFrcyB0 aGF0LiBQbGVhc2UgbGV0J3MgTUlEIHRvIGJlIGEgc2luZ2xlLDxiciBjbGFzcz0iIj4NCiZndDt1 bmlxdWUgYW5kIG1hbmRhdG9yeSBhdHRyaWJ1dGUgcGVyIG0tbGluZS48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L3NwYW4+xaBhbmQgbGV0IGVhY2ggUlRQIHBh Y2tldCBiZSBhc3NvY2lhdGVkIHdpdGggb25lLCBhbmQgb25seSBvbmUsIG9mIHRob3NlPGJyIGNs YXNzPSIiPg0KTUlEcy9tLWxpbmVzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCllvdSBjYW4gdGhlbiBoYXZlIGFwcGxpY2F0aW9uIGxvZ2ljIHNheWluZyBlLmcu IMKzSWYgbm8gxZJsb3VkZXN0LXNwZWFrZXLCuTxiciBjbGFzcz0iIj4NCm1lZGlhIGlzIHJlY2Vp dmVkLCB0aGVuIGR1cGxpY2F0ZSB0aGUgxZJib3NzwrkgbWVkaWEgb24gdGhlIHNjcmVlbjxiciBj bGFzcz0iIj4NCmFzc29jaWF0ZWQgd2l0aCB0aGUgbG91ZGVzdCBzcGVha2VywrIuIEl0wrlzIG11 Y2ggbW9yZSBmbGV4aWJsZSwgYW5kIHdpdGhvdXQ8YnIgY2xhc3M9IiI+DQphbnkgb2YgdGhlIGNv bnN0cmFpbnRzIG1lbnRpb25lZCBlYXJsaWVyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkkgYWdyZWUgaXQgYnJpbmdzIGluIGZsZXhpYmlsaXR5IGFuZCBpdCBzY2FyZXMg bWUgYSBiaXQgYXMgd2VsbCAuLiBFYWNoIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGRlZmluZSB0aGVp ciBvd24gbG9naWMgb3IgbmVlZCBhIGNvbW1vbiBsb2dpYyBhY3Jvc3MgYWxsIGFwcGxpY2F0aW9u cyAuLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Jm5ic3A7PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxiciBjbGFzcz0iIj4NClJlZ2FyZHMsPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2hyaXN0ZXI8YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ bW11c2ljQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWM8L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsZWFyPSJhbGwiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfc2lnbmF0dXJlIiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxf c2lnbmF0dXJlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPk1pZ3VlbCBQYXLDrXMgRMOtYXo8 YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpDb21wdXRlci9Tb2Z0 d2FyZSBlbmdpbmVlci48YnIgY2xhc3M9IiI+DQpSZXNlYXJjaGVyIGFuZCBhcmNoaXRlY3QgaW4g PGEgaHJlZj0iaHR0cDovL3d3dy5rdXJlbnRvLm9yZy8iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij4NCmh0dHA6Ly93d3cua3VyZW50by5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0 cDovL3R3aXR0ZXIuY29tL21wYXJpc2RpYXoiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRw Oi8vdHdpdHRlci5jb20vbXBhcmlzZGlhejwvYT48YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9245E2F8C683438FBD160BEA27D813EEvidyocom_-- From nobody Wed Jul 20 19:34:54 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAFA12D920 for ; Wed, 20 Jul 2016 19:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 N20AK_0DhWkN for ; Wed, 20 Jul 2016 19:34:49 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5270112D9C5 for ; Wed, 20 Jul 2016 19:34:49 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id j185so98578206oih.0 for ; Wed, 20 Jul 2016 19:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cxA008+FeW974qMac8yFiEUssWy23YYxmHOVCXG8rRo=; b=gJTYqpzQjGuauzW2sDAhNQPcaISxErCxykTvfc4ZFUEsdFPCwO4Hyg7rYILgDoedv9 CBS01zQDUfpCIRDGZSsOacb4jrxXPJ1CDhgI6kQCjyC/uCXvbnqvMtkTgS/y9qIFqDOg Jv/njQRnHCy4ABQmN0v7SGw/J3VL+S4aVjeBnQ7fIWYlloez3yZOT0/yxWo7KfVJKYRT ztXonIwXjjrvxrKsimeNymfzWo2RQAqyG0TjtE2twyCScsoLpdGpDUtNymckbN2HgRcc K13Ysv7eDyPyLHAyC6VSxb4X1LiwPlGvYiwgv9bBXlEz7z+FdALKr2yvnxUjSeiQL1zP gzfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cxA008+FeW974qMac8yFiEUssWy23YYxmHOVCXG8rRo=; b=PK/U9cazOx9eisDRaDjO629fjxKpNtN79g985KsXieq6WIUTka848rdFj+ye20rjNB 85rctRyZe3CV0R1p+9G+q9IEBFuVF3Wp6Hu/49qF6Tp/ijZSBoy7klV7wDUlTl5zx5e8 jjB9CEPIvBfHA+38j4yREqkBRUSjYs51iz9K468qdxAr84BiR8fX2JN/EDRhHzGgP4/J Xs0iQDzpjGJJ08z7XDFXIWeRUtPO1GWUoKK8R97Iji6nDbGBGvv0wnRMgSNNbl0gMubb E8PVuFnX8C2b0iI6XoVE9b7kXWU7QUjIOKave6odhEqbgVhKOxFgfYbwOCdg3qjGgZvJ Nx9g== X-Gm-Message-State: ALyK8tJthKltIURCeoLD8hTQ9sv2pTJcTw2YzssitY1zFVnbO9f5zMjUuyo1Aw74RPFLzNYMNHuNrNCHkEdKwA== X-Received: by 10.202.50.139 with SMTP id y133mr23775438oiy.46.1469068488670; Wed, 20 Jul 2016 19:34:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.182.86 with HTTP; Wed, 20 Jul 2016 19:34:48 -0700 (PDT) In-Reply-To: References: <5611A155.1050303@omnitor.se> From: "Ali C. Begen" Date: Thu, 21 Jul 2016 05:34:48 +0300 Message-ID: To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= Content-Type: multipart/alternative; boundary=001a113cf21e6b04bd05381c2976 Archived-At: Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Clarification for multiple lang attributes in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 02:34:53 -0000 --001a113cf21e6b04bd05381c2976 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Gunnar I will be happy to make the change once the WG agrees with it. I am not in Berlin this week, but if this can be discussed in the mmusic session, that would be good. On Wed, Jul 20, 2016 at 1:11 AM, Gunnar Hellstr=C3=B6m < gunnar.hellstrom@omnitor.se> wrote: > Ali and all, > > The correspondence below is from a request to clarify language in > rfc4566bis for the 'lang' attribute. > > The proposed modification was successfully done, so, in the current > version, the description for the 'lang' attribute is as indicated in the > "proposed replacement" a bit down in the earlier mail. Thanks! > > However, we have discussed this in SLIM and found that there may still be > room for different interpretations. One would still be that indication of > multiple 'lang' attributes would mean a desire to use them all during the > session, and another interpretation that a list of 'lang' attributes mean= a > list for selection what to use during the session, and usually only one > language will be selected and used. > > We have recommended to have the discussions here in mmusic, where the > question belongs. > > In slim, it is in draft-ietf-slim-negotiating-human-language-01 that we > have a section 5 discussing this topic. The discussion is supposed to be > drastically reduced in next version. There is also more about the > background below. > > So, again, a wording proposal for section 6.12 of rfc4566bis: > > ------------------------------Current wording of > 6.12---------------------------------------------- > > Multiple lang attributes can be provided either at session or media > level if the session or media has capabilities to use multiple > languages, > in which case > the order of the attributes indicates the order of preference of the > various languages in the session or media, from most preferred to > least preferred. > > As a session-level attribute, lang specifies a language capability for > the session being described. As a media-level attribute, it > specifies a language capability for that media, overriding any > session-level language(s) specified. > > The "lang" attribute value must be a single [RFC5646] language tag in > US-ASCII. A "lang" attribute SHOULD be specified when a session is > of sufficient scope to cross geographic boundaries where the language > of recipients cannot be assumed, or where the session has capabilities > in > languages different from the locally assumed norm. > > Events during the session may influence which language(s) are used, an= d > the participants are not strictly bound to only use the declared > languages. > > -------------------------------------------------------------------------= --- > -----------------------Proposed wording------------------------------- > Multiple lang attributes can be provided either at session or media > level if the session or media has capabilities in more than one > language, > in which case > the order of the attributes indicates the order of preference of the > various languages in the session or media, from most preferred to > least preferred. > > As a session-level attribute, lang specifies a language capability for > the session being described. As a media-level attribute, it > specifies a language capability for that media, overriding any > session-level language(s) specified. > > The "lang" attribute value must be a single [RFC5646] language tag in > US-ASCII. A "lang" attribute SHOULD be specified when a session is > of sufficient scope to cross geographic boundaries where the language > of participants cannot be assumed, or where the session has > capabilities in > languages different from the locally assumed norm. > > The 'lang' attribute is supposed to be used for settling the initial > language(s) used in the session. > Events during the session may influence which language(s) are used, an= d > the > participants are not strictly bound to only use the declared languages= . > > Most real-time use cases start with just one language used, while other > cases involve a range of languages, e.g. an interpreted or subtitled > session. When more than one 'lang' attribute is specified, the 'lang' > attribute itself does not provide any information about if multiple > languages are intended to be used during the session, or if the intention > is to only select one language. Other attributes or the semantics in whic= h > the 'lang' attributes are used may indicate such conditions. Without such > indications of usage intent, it should be assumed that for a negotiated > session one of the declared languages should be selected and used. > > --------------------------End of wording > proposal-------------------------------- > > I realize that the last paragraph is fuzzy, and would appreciate a > discussion on the best way to handle this, and also the best way to ease > the use of the 'lang' attribute already when current RFC4566 is used. > > Regards > Gunnar > > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > > > > > > > Den 2015-10-05 kl. 12:04, skrev Ali C. Begen: > >> Hi Gunnar >> >> Thanks for bringing this up. I am not against your wording and I dont >> think this change causes issues with recorded material, which could >> support a single or multiple languages and in that case, you can use >> this attribute in the declarative mode. >> >> if there are no objections, I can implement this change in the next cycl= e. >> >> -acbegen >> >> On Mon, Oct 5, 2015 at 12:59 AM, Gunnar Hellstr=C3=B6m >> wrote: >> >>> There is some uncertainty about interpretation of multiple lang >>> attributes >>> in RFC 4566 that would need to be sorted out in rfc4566bis. >>> The uncertainty has caused stox to select another mechanism and now als= o >>> slim is hesitating. (see slim and its real-time draft for a deeper >>> discussion) >>> >>> The current text in section 6.12 of rfc4566bis is: >>> >>> -----------------------------current text from >>> 6.12-------------------------------- >>> >>> Multiple lang attributes can be provided either at session or media >>> level if the session or media use multiple languages, in which case >>> the order of the attributes indicates the order of importance of th= e >>> various languages in the session or media, from most important to >>> least important. >>> >>> As a session-level attribute, it specifies the default language for >>> the session being described. As a media-level attribute, it >>> specifies the language for that media, overriding any session-level >>> languages specified. >>> >>> The "lang" attribute value must be a single [RFC5646] language tag = in >>> US-ASCII. A "lang" attribute SHOULD be specified when a session is >>> of sufficient scope to cross geographic boundaries where the langua= ge >>> of recipients cannot be assumed, or where the session is in a >>> different language from the locally assumed norm. >>> >>> >>> -----------------------------------------------------------------------= ------------------------ >>> >>> The uncertainty has been around what the wording "use multiple language= s" >>> means. >>> It can mean that all are provided simultaneously, but it can also mean >>> that >>> it is a list of capabilities and >>> that events during the session can decide which languages will really b= e >>> used. There is also uncertainty >>> about if a negotiation can take place to agree on one or a set of commo= n >>> languages to select from as default language(s). >>> >>> In order to bring some clarity, I suggest to change to the following: >>> >>> -----------------------------proposed replacement text for >>> 6.12-------------------------------- >>> >>> Multiple lang attributes can be provided either at session or media >>> level if the session or media has capabilities to use multiple >>> languages, >>> in which case >>> the order of the attributes indicates the order of preference of th= e >>> various languages in the session or media, from most preferred to >>> least preferred. >>> >>> As a session-level attribute, lang specifies a language capability >>> for >>> the session being described. As a media-level attribute, it >>> specifies a language capability for that media, overriding any >>> session-level >>> language(s) specified. >>> >>> The "lang" attribute value must be a single [RFC5646] language tag = in >>> US-ASCII. A "lang" attribute SHOULD be specified when a session is >>> of sufficient scope to cross geographic boundaries where the langua= ge >>> of recipients cannot be assumed, or where the session has >>> capabilities in >>> languages different from the locally assumed norm. >>> >>> Events during the session may influence which language(s) are used, >>> and >>> the >>> participants are not strictly bound to only use the declared >>> languages. >>> >>> >>> >>> >>> -----------------------------------------------------------------------= ------------------------ >>> >>> My conclusion from looking at the background of the wording for lang in >>> RFC >>> 4566 is that we can safely assume that for real-time sessions, the >>> meaning >>> of multiple lang specifications is a range of capabilities, and not a >>> requirement to use all languages. >>> By that interpretation, we can also assume that an offer/answer exchang= e >>> can >>> negotiate the language(s) to be suitable for use in a session to be a >>> subset >>> of what the offer contained. >>> >>> I traced the introduction of the wording from an announcement in mmusic >>> on >>> 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 o= n >>> 1997-12-23. There was no further discussion and the wording has stayed >>> like >>> that with merely a swap of the paragraphs in rfc4566bis. >>> >>> In the mail announcing the introduction it was said that the intention >>> was >>> to fulfill requirements from a draft that then became RFC 2277. >>> >>> A relevant section in RFC 2277 is: >>> " >>> >>> 4.4. Considerations for language negotiation >>> >>> Protocols where users have text presented to them in response to us= er >>> actions MUST provide for support of multiple languages. >>> >>> How this is done will vary between protocols; for instance, in some >>> cases, a negotiation where the client proposes a set of languages a= nd >>> the server replies with one is appropriate; in other cases, a serve= r >>> may choose to send multiple variants of a text and let the client >>> pick which one to display. >>> >>> Negotiation is useful in the case where one side of the protocol >>> exchange is able to present text in multiple languages to the other >>> side, and the other side has a preference for one of these; the mos= t >>> common example is the text part of error responses, or Web pages th= at >>> are available in multiple languages. >>> >>> Negotiating a language should be regarded as a permanent requiremen= t >>> of the protocol that will not go away at any time in the future. >>> >>> In many cases, it should be possible to include it as part of the >>> connection establishment, together with authentication and other >>> preferences negotiation. " >>> >>> So it is apparent that the intention for real-time conversational cases >>> is a >>> negotiation with >>> an offer and a selection, either in an answer or by human agreement i= n >>> the >>> session. >>> >>> The central word creating the hesitation in interpretation is that all >>> languages must be used is "use" in this phrase: >>> "if the session description or media use multiple languages". >>> >>> It is hard to believe that it was the intention that all must be used. >>> The >>> proposed wording is made to make the >>> interpretation clear that it is a set of capabilities.. >>> >>> There are multiple reasons for that interpretation: >>> >>> 1. It aligns with the requirement for language negotiation in RFC 2277 >>> that >>> was said to be >>> the requirement behind the wording. >>> 2. It is usually unrealistic to use multiple languages at the same time >>> in a >>> medium. >>> It is more in line at least with real-time conversation that events >>> during the conversation causes decision to use >>> just one language. >>> 3. The discussion in the original wording of importance of languages lo= se >>> its meaning if all must be used. "the >>> order of the attributes indicates the order of importance of the variou= s >>> languages in the session or media". >>> There is no use of knowing how important a language is if they all must >>> be >>> presented. It is more likely that >>> this relates to a possibility to select languages and that the >>> "importance" >>> is a grading of preference. >>> >>> This would mean that we can safely assume that the use of multiple lang >>> attributes in SDP were and are intended as >>> a selection and that negotiation through offer/answer is possible. >>> >>> >>> I realize that the language about capabilities in my proposal does not >>> match >>> an sdp that belongs to a >>> static session with recorded material equally well as it does for a >>> real-time session between human participants, >>> but I want anyway propose the wording. >>> >>> /Gunnar Hellstr=C3=B6m >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > -- > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > --001a113cf21e6b04bd05381c2976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Gunnar

I will be happy to make the c= hange once the WG agrees with it. I am not in Berlin this week, but if this= can be discussed in the mmusic session, that would be good.

On Wed, Jul 20, 2016= at 1:11 AM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se<= /a>> wrote:
Ali and all,

The correspondence below is from a request to clarify language in rfc4566bi= s for the 'lang' attribute.

The proposed modification was successfully done, so, in the current version= , the description for the 'lang' attribute is as indicated in the &= quot;proposed replacement" a bit down in the earlier mail. Thanks!

However, we have discussed this in SLIM and found that there may still be r= oom for different interpretations. One would still be that indication of mu= ltiple 'lang' attributes would mean a desire to use them all during= the session, and another interpretation that a list of 'lang' attr= ibutes mean a list for selection what to use during the session, and usuall= y only one language will be selected and used.

We have recommended to have the discussions here in mmusic, where the quest= ion belongs.

In slim, it is in draft-ietf-slim-negotiating-human-language-01 that we hav= e a section 5 discussing this topic. The discussion is supposed to be drast= ically reduced in next version. There is also more about the background bel= ow.

So, again, a wording proposal for section 6.12 of rfc4566bis:

------------------------------Current wording of 6.12----------------------= ------------------------

=C2=A0 =C2=A0Multiple lang attributes can be provided either at session or = media
=C2=A0 =C2=A0level if the session or media has capabilities to use multiple= languages,
in which case
=C2=A0 =C2=A0the order of the attributes indicates the order of preference = of the
=C2=A0 =C2=A0various languages in the session or media, from most preferred= to
=C2=A0 =C2=A0least preferred.

=C2=A0 =C2=A0As a session-level attribute, lang specifies a language capabi= lity for
=C2=A0 =C2=A0the session being described.=C2=A0 As a media-level attribute,= it
=C2=A0 =C2=A0specifies a language capability for that media, overriding any=
=C2=A0 =C2=A0session-level language(s) specified.

=C2=A0 =C2=A0The "lang" attribute value must be a single [RFC5646= ] language tag in
=C2=A0 =C2=A0US-ASCII.=C2=A0 A "lang" attribute SHOULD be specifi= ed when a session is
=C2=A0 =C2=A0of sufficient scope to cross geographic boundaries where the l= anguage
=C2=A0 =C2=A0of recipients cannot be assumed, or where the session has capa= bilities in
=C2=A0 =C2=A0languages different from the locally assumed norm.

=C2=A0 =C2=A0Events during the session may influence which language(s) are = used, and
=C2=A0 =C2=A0the participants are not strictly bound to only use the declar= ed languages.
---------------------------------------------------------------------------= -
 -----------------------Proposed wording-------------------------------
=C2=A0 =C2=A0Multiple lang attributes can be provided either at session or = media
=C2=A0 =C2=A0level if the session or media has capabilities in more than on= e language,
in which case
=C2=A0 =C2=A0the order of the attributes indicates the order of preference = of the
=C2=A0 =C2=A0various languages in the session or media, from most preferred= to
=C2=A0 =C2=A0least preferred.

=C2=A0 =C2=A0As a session-level attribute, lang specifies a language capabi= lity for
=C2=A0 =C2=A0the session being described.=C2=A0 As a media-level attribute,= it
=C2=A0 =C2=A0specifies a language capability for that media, overriding any=
=C2=A0 =C2=A0session-level language(s) specified.

=C2=A0 =C2=A0The "lang" attribute value must be a single [RFC5646= ] language tag in
=C2=A0 =C2=A0US-ASCII.=C2=A0 A "lang" attribute SHOULD be specifi= ed when a session is
=C2=A0 =C2=A0of sufficient scope to cross geographic boundaries where the l= anguage
 =C2=A0 =C2=A0of participants cannot be assumed, or where the session has ca= pabilities in
=C2=A0 =C2=A0languages different from the locally assumed norm.

 =C2=A0The 'lang' attribute is supposed to be used for settling the = initial
=C2=A0language(s) used in the session.
=C2=A0 =C2=A0Events during the session may influence which language(s) are = used, and the
=C2=A0 =C2=A0participants are not strictly bound to only use the declared l= anguages.

 Most real-time use cases start with just one language used, while other cas= es involve a range of languages, e.g. an interpreted or subtitled session. = When more than one 'lang' attribute is specified, the 'lang'= ; attribute itself does not provide any information about if multiple langu= ages are intended to be used during the session, or if the intention is to = only select one language. Other attributes or the semantics in which the &#= 39;lang' attributes are used may indicate such conditions. Without such= indications of usage intent, it should be assumed that for a negotiated se= ssion one of the declared languages should be selected and used.

--------------------------End of wording proposal--------------------------= ------

I realize that the last paragraph is fuzzy, and would appreciate a discussi= on on the best way to handle this, and also the best way to ease the use of= the 'lang' attribute already when current RFC4566 is used.

Regards
Gunnar

-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hel= lstrom@omnitor.se




=C2=A0

Den 2015-10-05 kl. 12:04, skrev Ali C. Begen:
Hi Gunnar

Thanks for bringing this up. I am not against your wording and I dont
think this change causes issues with recorded material, which could
support a single or multiple languages and in that case, you can use
this attribute in the declarative mode.

if there are no objections, I can implement this change in the next cycle.<= br>
-acbegen

On Mon, Oct 5, 2015 at 12:59 AM, Gunnar Hellstr=C3=B6m
<gunnar= .hellstrom@omnitor.se> wrote:
There is some uncertainty about interpretation of multiple lang attributes<= br> in RFC 4566 that would need to be sorted out in rfc4566bis.
The uncertainty has caused stox to select another mechanism and now also slim is hesitating. (see slim and its real-time draft for a deeper
discussion)

The current text in section 6.12 of rfc4566bis is:

-----------------------------current text from
6.12--------------------------------

Multiple lang attributes can be provided either at session or media
=C2=A0 =C2=A0 level if the session or media use multiple languages, in whic= h case
=C2=A0 =C2=A0 the order of the attributes indicates the order of importance= of the
=C2=A0 =C2=A0 various languages in the session or media, from most importan= t to
=C2=A0 =C2=A0 least important.

=C2=A0 =C2=A0 As a session-level attribute, it specifies the default langua= ge for
=C2=A0 =C2=A0 the session being described.=C2=A0 As a media-level attribute= , it
=C2=A0 =C2=A0 specifies the language for that media, overriding any session= -level
=C2=A0 =C2=A0 languages specified.

=C2=A0 =C2=A0 The "lang" attribute value must be a single [RFC564= 6] language tag in
=C2=A0 =C2=A0 US-ASCII.=C2=A0 A "lang" attribute SHOULD be specif= ied when a session is
=C2=A0 =C2=A0 of sufficient scope to cross geographic boundaries where the = language
=C2=A0 =C2=A0 of recipients cannot be assumed, or where the session is in a=
=C2=A0 =C2=A0 different language from the locally assumed norm.

---------------------------------------------------------------------------= --------------------

The uncertainty has been around what the wording "use multiple languag= es"
means.
It can mean that all are provided simultaneously, but it can also mean that=
it is a list of capabilities and
that events during the session can decide which languages will really be used. There is also uncertainty
about if a negotiation can take place to agree on one or a set of common languages to select from as default language(s).

In order to bring some clarity, I suggest to change to the following:

-----------------------------proposed replacement text for
6.12--------------------------------

=C2=A0 =C2=A0 Multiple lang attributes can be provided either at session or= media
=C2=A0 =C2=A0 level if the session or media has capabilities to use multipl= e languages,
in which case
=C2=A0 =C2=A0 the order of the attributes indicates the order of preference= of the
=C2=A0 =C2=A0 various languages in the session or media, from most preferre= d to
=C2=A0 =C2=A0 least preferred.

=C2=A0 =C2=A0 As a session-level attribute, lang specifies a language capab= ility for
=C2=A0 =C2=A0 the session being described.=C2=A0 As a media-level attribute= , it
=C2=A0 =C2=A0 specifies a language capability for that media, overriding an= y
session-level
=C2=A0 =C2=A0 language(s) specified.

=C2=A0 =C2=A0 The "lang" attribute value must be a single [RFC564= 6] language tag in
=C2=A0 =C2=A0 US-ASCII.=C2=A0 A "lang" attribute SHOULD be specif= ied when a session is
=C2=A0 =C2=A0 of sufficient scope to cross geographic boundaries where the = language
=C2=A0 =C2=A0 of recipients cannot be assumed, or where the session has cap= abilities in
=C2=A0 =C2=A0 languages different from the locally assumed norm.

=C2=A0 =C2=A0 Events during the session may influence which language(s) are= used, and
the
=C2=A0 =C2=A0 participants are not strictly bound to only use the declared = languages.



---------------------------------------------------------------------------= --------------------

My conclusion from looking at the background of the wording for lang in RFC=
4566 is that we can safely assume that for real-time sessions, the meaning<= br> of multiple lang specifications is a range of capabilities, and not a
requirement to use all languages.
By that interpretation, we can also assume that an offer/answer exchange ca= n
negotiate the language(s) to be suitable for use in a session to be a subse= t
of what the offer contained.

I traced the introduction of the wording from an announcement in mmusic on<= br> 1997-11-23, and then the wording appeared in draft-ietf-mmusic-sdp-05 on 1997-12-23. There was no further discussion and the wording has stayed like=
that with merely a swap of the paragraphs in rfc4566bis.

In the mail announcing the introduction it was said that the intention was<= br> to fulfill requirements from a draft that then became RFC 2277.

A relevant section in RFC 2277 is:
"

4.4.=C2=A0 Considerations for language negotiation

=C2=A0 =C2=A0 Protocols where users have text presented to them in response= to user
=C2=A0 =C2=A0 actions MUST provide for support of multiple languages.

=C2=A0 =C2=A0 How this is done will vary between protocols; for instance, i= n some
=C2=A0 =C2=A0 cases, a negotiation where the client proposes a set of langu= ages and
=C2=A0 =C2=A0 the server replies with one is appropriate; in other cases, a= server
=C2=A0 =C2=A0 may choose to send multiple variants of a text and let the cl= ient
=C2=A0 =C2=A0 pick which one to display.

=C2=A0 =C2=A0 Negotiation is useful in the case where one side of the proto= col
=C2=A0 =C2=A0 exchange is able to present text in multiple languages to the= other
=C2=A0 =C2=A0 side, and the other side has a preference for one of these; t= he most
=C2=A0 =C2=A0 common example is the text part of error responses, or Web pa= ges that
=C2=A0 =C2=A0 are available in multiple languages.

=C2=A0 =C2=A0 Negotiating a language should be regarded as a permanent requ= irement
=C2=A0 =C2=A0 of the protocol that will not go away at any time in the futu= re.

=C2=A0 =C2=A0 In many cases, it should be possible to include it as part of= the
=C2=A0 =C2=A0 connection establishment, together with authentication and ot= her
=C2=A0 =C2=A0 preferences negotiation. "

So it is apparent that the intention for real-time conversational cases is = a
negotiation with
=C2=A0 an offer and a selection, either in an answer or by human agreement = in the
session.

The central word creating the hesitation in interpretation is that all
languages must be used is "use" in this phrase:
"if the session description or media use multiple languages".

It is hard to believe that it was the intention that all must be used. The<= br> proposed wording is made to make the
interpretation clear that it is a set of capabilities..

There are multiple reasons for that interpretation:

1. It aligns with the requirement for language negotiation in RFC 2277 that=
was said to be
=C2=A0 =C2=A0 the requirement behind the wording.
2. It is usually unrealistic to use multiple languages at the same time in = a
medium.
=C2=A0 =C2=A0 It is more in line at least with real-time conversation that = events
during the conversation causes decision to use
=C2=A0 =C2=A0 just one language.
3. The discussion in the original wording of importance of languages lose its meaning if all must be used. "the
order of the attributes indicates the order of importance of the various languages in the session or media".
There is no use of knowing how important a language is if they all must be<= br> presented. It is more likely that
this relates to a possibility to select languages and that the "import= ance"
is a grading of preference.

This would mean that we can safely assume that the use of multiple lang
attributes in SDP were and are intended as
a selection and that negotiation through offer/answer is possible.


I realize that the language about capabilities in my proposal does not matc= h
an sdp that belongs to a
static session with recorded material equally well as it does for a
real-time session between human participants,
but I want anyway propose the wording.

/Gunnar Hellstr=C3=B6m


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

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

--
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hel= lstrom@omnitor.se
+46 708 204 288


--001a113cf21e6b04bd05381c2976-- From nobody Fri Jul 22 00:05:36 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41EF12D93E; Fri, 22 Jul 2016 00:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TjaYqOFX9SaX; Fri, 22 Jul 2016 00:05:32 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C840B12D6A5; Fri, 22 Jul 2016 00:05:31 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f65so45221522wmi.0; Fri, 22 Jul 2016 00:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vSgK4IuQtUARUJqwcNrHSAevvPESqM3EcYr2JaJycFI=; b=Uo7inc3O120jlZFBmCBirtPmM8ux6D7bl+/Ig7cSI1YMhrctkAbOiiQO9iUHcFAhMh MJNmNn50vbesjbyg8lpihWEetArfmmLyxIl6DrrAEexFP+fv83uwRFc0lUovgndfvQ9s 8HcmUleOzDy+wI38rxSeuz7rqp88dmcTshyQx5p517E+NhT4LpTkqbm/IXo6/81C9O7w 2SkIqqcx6RjLAj/jQDJ3i5KS5s5GJ8h4cYHShdRRqighEeh5ta6InxH4e69ZBw7J2ZNK LQAjWi37hvOQcoBsSnqvbbAQsTpF/Y9c32E5Hi23pawbRDJ2puOv7ZB0YlXXw552CGDg 73mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vSgK4IuQtUARUJqwcNrHSAevvPESqM3EcYr2JaJycFI=; b=KmJyv+rR2w48PJiqVEvBvQ+UWUT9G5FvD8uT9Lu7Rh4NVR9SD5OGJW+GE69rVKaZH/ BgdK6VNO/1aUA2d++2WuQ+Fl6EyaZT2ie/jMzGaGTUFTjS505r8bQWzPE8ufTnpev6Vm oEnpsGupCnNrF4iNfK0xfClfSmmeEuAxRFcD3nN6CUx0r73jJJBgmkxWyYU7428+k1LR 72wfYMSfB84yVH5vnscxVY2XiSN8Lyly/i0opots4SD1w0ruVvtV2DPxMx93TQ80jVcQ bbs6Fil2yahkFpRewuHJI705W8OvPhq+kLO/0h9TubNpm5x7an37TWhl37JyZgDUKSDt PK9w== X-Gm-Message-State: AEkoouvY9GL953SCxn4+03B6728W20vcJfZ1O+L32EInXHkbkfKYzpOTIGmYgH+X91Xhwbo/7IA9J38F1Ghvmw== X-Received: by 10.28.18.11 with SMTP id 11mr3243606wms.11.1469171130310; Fri, 22 Jul 2016 00:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.117.67 with HTTP; Fri, 22 Jul 2016 00:05:29 -0700 (PDT) In-Reply-To: <9245E2F8-C683-438F-BD16-0BEA27D813EE@vidyo.com> References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> <7594FB04B1934943A5C02806D1A2204B476AA914@ESESSMB208.ericsson.se> <9245E2F8-C683-438F-BD16-0BEA27D813EE@vidyo.com> From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Fri, 22 Jul 2016 09:05:29 +0200 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a114697225624710538340fed Archived-At: Cc: mmusic , IETF AVTCore WG , Christer Holmberg Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 07:05:35 -0000 --001a114697225624710538340fed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Jonathan, Do you mean to add MID SDES Item [1] using SDES header extensions [2] and also extends that to provide the "version"? If we use this approach, RTP MID Header Extension [3] would be useless, wouldn't it? Anyway, could you expand your idea to show how would you solve the race condition problem? Best!! Refs [1] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-31#sec= tion-14.2 [2] https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-07 [3] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-31#sec= tion-14.3 2016-07-20 17:46 GMT+02:00 Jonathan Lennox : > draft-ietf-avtext-sdes-hdr-ext discusses ways to notice reordering of > packets carrying SDES header extensions (of which MID is an instance). I= s > that text sufficient? > > On Jul 20, 2016, at 1:36 PM, Miguel Par=C3=ADs D=C3=ADaz > wrote: > > Hello, > thinking a bit about that idea, if we support that different RTP streams > have the same MID, we should provide a kind of version to deal with race > conditions. > > Taking the example of =E2=80=9Cthe current loudest speaker=E2=80=9D (LS) = , if the middle > box switches many times Alice <-> Bob streams the endpoint receiving the > RTP streams may show the incorrect loudest-speaker due to processing an R= TP > stream before the other one (network, race condition into the endpoint, > etc.) > > Imagine that case: > MidleBox side: Alice LS -> Bob LS -> Alice LS > Endpoint side: Process Alice as LS -> Process Alice LS -> Process Bob LS > > At the end the endpoint would render Bob as LS, but it is wrong. > > To fix this race condition problem I propose adding a version: > MidleBox side: Alice LS-0 -> Bob LS-1 -> Alice LS-2 > Endpoint side: Process Alice as LS-0 -> Process Alice LS-2 -> Process Bob > LS-1 (discarded because 1<2) > > What do you think about that? > > Best regards!! > > > 2016-07-14 17:49 GMT+02:00 Christer Holmberg < > christer.holmberg@ericsson.com>: > >> Hi, >> >> You don't need a common logic. You can define an application layer >> protocol (e.g. CLUE) to define/configure/negotiate these kind of things. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------ >> From: Suhas Nandakumar >> Sent: =E2=80=8E14/=E2=80=8E07/=E2=80=8E2016 18:43 >> To: Christer Holmberg >> Cc: I=C3=B1aki Baz Castillo ; Jonathan Lennox >> ; mmusic ; IETF AVTCore WG >> >> Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple >> MIDs? >> >> >> >> On Thu, Jul 14, 2016 at 3:27 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> >>> >... >>> > >>> >The current proposal breaks that. Please let's MID to be a single, >>> >unique and mandatory attribute per m-line. >>> >>> >>> =C5=A0and let each RTP packet be associated with one, and only one, of = those >>> MIDs/m-lines. >>> >>> >>> You can then have application logic saying e.g. =C2=B3If no =C5=92loude= st-speaker=C2=B9 >>> media is received, then duplicate the =C5=92boss=C2=B9 media on the scr= een >>> associated with the loudest speaker=C2=B2. It=C2=B9s much more flexible= , and >>> without >>> any of the constraints mentioned earlier. >>> >>> >> I agree it brings in flexibility and it scares me a bit as well .. Each >> application needs to define their own logic or need a common logic acros= s >> all applications .. >> >> >> >>> >>> Regards, >>> >>> Christer >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > > > -- > Miguel Par=C3=ADs D=C3=ADaz > ------------------------------------------------------------------------ > Computer/Software engineer. > Researcher and architect in http://www.kurento.org > http://twitter.com/mparisdiaz > ------------------------------------------------------------------------ > > > --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --001a114697225624710538340fed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Jonathan,
Do you mean to add MID SDES Item [= 1] using SDES header extensions [2] and also extends that to provide the &q= uot;version"?
If we use this approach, RTP MID Header Ex= tension [3] would be useless, wouldn't it?

Anyway, co= uld you expand your idea to show how would you solve the race condition pro= blem?

Best!!

Refs
[1] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bund= le-negotiation-31#section-14.2
[2] https://tools.ie= tf.org/html/draft-ietf-avtext-sdes-hdr-ext-07
[3] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bun= dle-negotiation-31#section-14.3


2016-07-20 17:46 GMT+02:00 Jonathan Lennox = <jonathan@vidyo.com>:
draft-ietf-avtext-sdes-hdr-ext discusses ways to notice reordering of = packets carrying SDES header extensions (of which MID is an instance).=C2= =A0 Is that text sufficient?

On Jul 20, 2016, at 1:36 PM, Miguel Par=C3=ADs D=C3=ADaz <mparisdiaz@gmail.com= > wrote:

Hello,
thinking a bit about that idea, if we support that different RTP streams ha= ve the same MID, we should provide a kind of version to deal with race cond= itions.

Taking the example of =E2=80=9Cthe current loudest speaker=E2=80=9D (LS) , = if the middle box switches many times Alice <-> Bob streams the endpo= int receiving the RTP streams may show the incorrect loudest-speaker due to= processing an RTP stream before the other one (network, race condition into the endpoint, etc.)

Imagine that case:
MidleBox side: Alice LS -> Bob LS -> Alice LS
Endpoint side: Process Alice as LS -> Process Alice LS -> Process Bob= LS

At the end the endpoint would render Bob as LS, but it is wrong.

To fix this race condition problem I propose adding a version:
MidleBox side: Alice LS-0 -> Bob LS-1 -> Alice LS-2
Endpoint side: Process Alice as LS-0 -> Process Alice LS-2 -> Process= Bob LS-1 (discarded because 1<2)

What do you think about that?

Best regards!!


2016-07-14 17:49 GMT+02:00 Christer Holmberg <chr= ister.holmberg@ericsson.com>:
Hi,

You don't need a common logic. You can define an application layer prot= ocol (e.g. CLUE) to define/configure/negotiate these kind of things.

Regards,

Christer

Sent from my Windows Phone
From: Suhas Nandakumar
Sent: =E2=80= =8E14/=E2=80=8E07/=E2=80=8E2016 18:43
To: Christer Holm= berg
Cc: I=C3=B1aki Baz Castillo; Jonathan Lennox= ; mmusic; IETF AVTCore WG
Subject: Re: [M= MUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs?



On Thu, Jul 14, 2016 at 3:27 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

>...
>
>The current proposal breaks that. Please let's MID to be a single,<= br> >unique and mandatory attribute per m-line.


=C5=A0and let each RTP packet be associated with one, and only one, = of those
MIDs/m-lines.


You can then have application logic saying e.g. =C2=B3If no =C5=92loudest-s= peaker=C2=B9
media is received, then duplicate the =C5=92boss=C2=B9 media on the screen<= br> associated with the loudest speaker=C2=B2. It=C2=B9s much more flexible, an= d without
any of the constraints mentioned earlier.


I agree it brings in flexibility and it scares me a bit as well .. Eac= h application needs to define their own logic or need a common logic across= all applications ..

=C2=A0

Regards,

Christer

_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic<= br>


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




--
Miguel Par=C3=ADs D=C3=ADaz
------------------------------------------------------------------------ Computer/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.= com/mparisdiaz
------------------------------------------------------------------------




--
Miguel Par=C3= =ADs D=C3=ADaz
---------------------------------------------------------= ---------------
Computer/Software engineer.
Researcher and architect = in http://www.kurento.= org
http= ://twitter.com/mparisdiaz
------------------------------------------= ------------------------------
--001a114697225624710538340fed-- From nobody Fri Jul 22 00:51:28 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C58712DA5B; Fri, 22 Jul 2016 00:51:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160722075124.12236.99411.idtracker@ietfa.amsl.com> Date: Fri, 22 Jul 2016 00:51:24 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 07:51:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP) Authors : Marc Petit-Huguenin Ari Keranen Suhas Nandakumar Filename : draft-ietf-mmusic-ice-sip-sdp-10.txt Pages : 42 Date : 2016-07-22 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 22 00:58:00 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFDF12D5EB for ; Fri, 22 Jul 2016 00:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RjEu32JJiJDu for ; Fri, 22 Jul 2016 00:57:57 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B3612D5D0 for ; Fri, 22 Jul 2016 00:57:57 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id u134so96179517ywg.3 for ; Fri, 22 Jul 2016 00:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gKpPU4FtJEIffGineU2S/am0S4cojAWgLGjqP5drhfU=; b=sP3peKGCxZYUIsMd2hiYj3+k8XjUBw73Bjj+0NaJuP23JpdmsC5Wq0Zwx6ExXgvwWB Zu6AHKg+vKOYGGiqtRpIoDLaOLIYe6ao3dNmOcKFzA8uVO9PJ7hPo1wO99nuc7DTcLfj YO2q3mKoGNwSE24u+wjdpEDhaEba351cq5yW9+sacCmqfgrd2IQUzccPiKCX1HeAHXnI bDpqe6NIfJwzVKwDPInRc9JF3Tp+xX9255QqjfqdS4Zu/hpZ/O0LNP4HkbtRv8LPB6O1 3exYSlJu8BNmxy4mMA/rabwnoYJByA/5lNv4/RLIo+FGEvcLZV0fndCC5LJNlt4k5HeT hjwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gKpPU4FtJEIffGineU2S/am0S4cojAWgLGjqP5drhfU=; b=cj0UAXYoIm/g3wq6B2qldVt/F9wnt99m2WT1cMzlZ4LaH4c2NsFvArQjG5a5UeAiXW Omm8lgg6F4YNkMFD6cLVgXn4pchlUy31sJn3i95uvMUYtYx3T14HuXQo1bHWFcYHtPKn HC9DeEnZL80ORWeAuFPVNPYmBKmCcu/mCJ4Lbv4HIuajQKBK/t/edb0acWqKlZ9KCHBq /2kCEiW7/y5ZHROCH8cFDOUGF29mg0E/98UOxnfSgrD2XBs07F6ylDdzf83K6NrJU/V3 W7P3TyhmbrmwBx7qv7Vz1CxsRyg769h7XwOdNeaUab9Jny4BNfnx/AFslZIVuF8YVzBI TkCQ== X-Gm-Message-State: AEkoouupnyXodkMrbNZR4D5x8EsUbXO1nSwpOlDkEOIwu4Ggp2tFQqSk/+95kkfocDym0ZQhPAgJyV7Mx89N2Q== X-Received: by 10.37.201.131 with SMTP id z125mr1717350ybf.183.1469174275752; Fri, 22 Jul 2016 00:57:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Fri, 22 Jul 2016 00:57:55 -0700 (PDT) In-Reply-To: <20160722075124.12236.99411.idtracker@ietfa.amsl.com> References: <20160722075124.12236.99411.idtracker@ietfa.amsl.com> From: Suhas Nandakumar Date: Fri, 22 Jul 2016 13:27:55 +0530 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=001a114d87a4d1c9c8053834caeb Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 07:57:59 -0000 --001a114d87a4d1c9c8053834caeb Content-Type: text/plain; charset=UTF-8 Hello All The -10 version adds text for ice2 ice-options in Offer/Answer terminology, removes ICE_BIS text duplication wherever possible and fixes ICE-BIS section cross references. Thanks Christer for passing on review comments on -09 Please let us know your review feedback Thanks Suhas On Fri, Jul 22, 2016 at 1:21 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session Control of > the IETF. > > Title : Using Interactive Connectivity Establishment > (ICE) with Session Description Protocol (SDP) offer/answer and Session > Initiation Protocol (SIP) > Authors : Marc Petit-Huguenin > Ari Keranen > Suhas Nandakumar > Filename : draft-ietf-mmusic-ice-sip-sdp-10.txt > Pages : 42 > Date : 2016-07-22 > > Abstract: > This document describes how Interactive Connectivity Establishment > (ICE) is used with Session Description Protocol (SDP) offer/answer > and Session Initiation Protocol (SIP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-10 > > > 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/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a114d87a4d1c9c8053834caeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Hello All

=C2=A0The -10 version adds text for ice2 ice-options in Offer/Answer termi= nology, removes ICE_BIS text duplication wherever possible and fixes ICE-BI= S section cross references.

Thanks Christer for pa= ssing on review comments on -09

Please let us know= your review feedback

Thanks
Suhas
=

On Fri, Jul= 22, 2016 at 1:21 PM, <internet-drafts@ietf.org> wro= te:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Multiparty Multimedia Session Control of t= he IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Using Interactive Connectivity Establishment (ICE) with Session Descriptio= n Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Marc= Petit-Huguenin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ari Keranen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-ice-sip-sdp-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 42
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-07-22

Abstract:
=C2=A0 =C2=A0This document describes how Interactive Connectivity Establish= ment
=C2=A0 =C2=A0(ICE) is used with Session Description Protocol (SDP) offer/an= swer
=C2=A0 =C2=A0and Session Initiation Protocol (SIP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-mmusic-ice-sip-sdp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-m= music-ice-sip-sdp-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-mmusic-ice-sip-sdp-10


Please note that it may take a couple of minutes from the time of submissio= n
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/

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

--001a114d87a4d1c9c8053834caeb-- From nobody Fri Jul 22 01:02:15 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C02A12D5D0 for ; Fri, 22 Jul 2016 01:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 13nMWByBFI7M for ; Fri, 22 Jul 2016 01:02:11 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C35B12D63F for ; Fri, 22 Jul 2016 01:02:11 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id j12so89790601ywb.2 for ; Fri, 22 Jul 2016 01:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6WyV0qhMXoTWsr9Awf1Y+a3aVYTUeWgaB+ksUBLGiEM=; b=kgvQ53HrrPzNQ9xLYYQZmTNGXXsKO/L+XLo9knLcyfZF1a4dqJtsqPolQKck2tKDMR MvsCpMvLc9e+4mH8QroAE1XRE1oHgvKQaCKaxoP1yWpI+72w1oQtVns6i74hcZ67/aIe yy3dRtRp0UBdTlXEVXD7akwDUqV948J3cYKlwKYll555sXYK4bVYcWQFJZa8nDjrwu+I LXPEiKFOPEHNJVbo9FNyuVVqE5la/QcfPLDuvm68I2RUOLUwPORE82xT73GDub26xhKh XoGprXA8kIeG0S2u1Zv51Aut5jGM41AyYj+X7QMujfXUNYnZJjcn0gPLqdFKDnqDVQI8 ZwRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6WyV0qhMXoTWsr9Awf1Y+a3aVYTUeWgaB+ksUBLGiEM=; b=J8+hMBYJELuAZbkISKEJ+hNjEowqWcBZ3Tw1cnHvgNJRMqtzGKdICUa+Jz2tXvmolz ugFnMOr/D5SXhPdHA+7I3cbB4Z+M8oGSjuvxRvOnx3tEFE8uyilLZQ7gGsovM36afVd4 ry/YdS+RZviPXXPkzyNPBU8k62U9AXrRjvYGQY9SrTI86Mu8MOHcnKTP9lXQfxjNNfI6 bdMCLCYGNqZLVN4K2GIOvGaYKg+fsuoBwYCd5Iqzmy4A6VM105QHAHdCctVB5a6lm1J4 Q6TzX6HMV+3kyizmwEXGfrmQjJAs/wYMj+vl5lTP+NcCXzqF1m1T4qedrFkziyzILVlc UGzQ== X-Gm-Message-State: AEkoouv8PP9g4TanF94xxAmqS3RLBK5tns8GHnBpV3kyew52XmK13GOkbI6O39VTgpfOz5NyzxLu8Jjd0W2JYg== X-Received: by 10.129.156.72 with SMTP id t69mr2083967ywg.295.1469174530473; Fri, 22 Jul 2016 01:02:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Fri, 22 Jul 2016 01:02:10 -0700 (PDT) In-Reply-To: References: From: Suhas Nandakumar Date: Fri, 22 Jul 2016 13:32:10 +0530 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c0b77c4008ac1053834da49 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:02:13 -0000 --94eb2c0b77c4008ac1053834da49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Christer I have submitted -10 version to address the above feedback. Please let me know your thoughts Thanks Suhas On Thu, Jul 14, 2016 at 6:44 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > The draft currently says the following on Offer/Answer usage for the > ice2 option > > > >" The ICE option, 'ice2' is used with the SDP session level "a=3Dice- > > > options" attribute in an SDP offer to indicate that the initiator of > > the ICE exchange is compliant to procedures from [ICE-BIS ] (via > > "a=3Dice-options: ice2"). The Responding Peer includes this same > > attribute at the session level in the SDP answer if it is also an > > [ICE-BIS ] compliant ICE Agent." > > > > > > > > > Are you looking for something more specific than this ? > > > Since chapter 4 describes how offers and answers are created, I assumed i= t > should be mentioned there. The text you have is a general description. > > Regards, > > Christer > > > > On Thu, Jul 14, 2016 at 5:58 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> I see that you have added the definition of the ice2 ice-option. However= , >> you have not defined usage of it in the offer/answer procedures, and it= =E2=80=99s >> not included in the SDP examples. >> >> Regards, >> >> Christer >> >> From: mmusic on behalf of Suhas Nandakumar < >> suhasietf@gmail.com> >> Date: Friday 8 July 2016 at 15:58 >> To: "mmusic@ietf.org" >> Subject: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted >> >> Hello All >> >> We submitted -09 version of the ice-sip-sdp draft with the following >> changes >> >> 1. Added Section 5 for dealing with ice2 >> 2. updated an example in Appendix A to be IPv6 based end-point >> 3. Updated Section 13.2 to say about the aggregation rules for ice2 >> ice-option >> 4. Restructured Offer/Answer sections into a single place as can be >> seen in Section 4 >> >> Thanks to Christer for feedback on the restructuring the offer/answer >> sections. >> >> >> We hope that this version incorporates all the outstanding issues. Pleas= e >> let us know if we are missing anything. >> >> Cheers >> Suhas >> > > --94eb2c0b77c4008ac1053834da49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Christer

=C2=A0 I have submitted = -10 version to address the above feedback. Please let me know your thoughts=


Thanks
Suhas
=

On Thu, Jul 14, 2= 016 at 6:44 PM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
Hi,

> The draft currently says the following on Offer/Answer usage for = the ice2 option
>
>" The IC= E option, 'ice2' is used with the SDP session level "a=3Dice-<= /span>
>   options" attribute in an SDP offer to indicate that t=
he initiator of
>   the ICE exchange is compliant to procedures from [ICE-BIS] (via
>   "a=3Dice-options: ice2").  The Responding Peer includes th=
is same
>   attribute at the session level in the SDP answer if it is also an
>   [ICE-BIS] compliant ICE Agent.&qu=
ot;
>
>
> Are you looking for something more specific than this ?

Since chapter 4 describes how offers and answers are created, I= assumed it should be mentioned there. The text you have is a general descr= iption.

Regards,

Christer



On Thu, Jul 14, 2016 at 5:58 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

I see that you have added the definition of the ice2 ice-option. Howev= er, you have not defined usage of it in the offer/answer procedures, and it= =E2=80=99s not included in the SDP examples.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Friday 8 July 2016 at 15:58 To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic= -ice-sip-sdp-09 Submitted

Hello All

=C2=A0 We submitted -09 version of the ice-sip-sdp draft with the foll= owing changes

=C2=A0=C2=A0=C2=A01. Added Section 5 for dealing with ice2
=C2=A0 =C2=A02. updated an example in Appen= dix A to be IPv6 based end-point
=C2=A0 =C2=A03. Updated Section 13.2 to say= about the aggregation rules for ice2 ice-option
=C2=A0 =C2=A04. Restructured Offer/Answer s= ections into a single place as can be seen in Section 4
=C2=A0=C2=A0
Thanks to Christer for feedback on the rest= ructuring the offer/answer sections.


We hope that this version incorporates all = the outstanding issues. Please let us know if we are missing anything.

Cheers
Suhas

--94eb2c0b77c4008ac1053834da49-- From nobody Fri Jul 22 01:02:59 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED1B12D672 for ; Fri, 22 Jul 2016 01:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9lO9Il99YN_d for ; Fri, 22 Jul 2016 01:02:55 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F1412D64F for ; Fri, 22 Jul 2016 01:02:55 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id j12so89803311ywb.2 for ; Fri, 22 Jul 2016 01:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xY/Gr+CM6DSyTUnzjmOVMpuhhUlJoU20id05vhFQ0ZI=; b=GR6pNx6CN5HS1hbMvDflsVqhOZWhoFlVGaOB6ouNifB46ECpH6M+pNL4idoemOZcYM 9CF9U6bArDZiwr6jToKJ+SeNonfCCJaJniysMKEih/r0PqoIo04bUA9/G1OFzhe2Se1c QxjFeMj/e1stTA7wwEpOcS9AZseIkUjdDeIpql2VACwqsZO5iRswPKRKXf/LEHw4WUNf F9DxOz1SS1t1k90i8ZtjoNc67/Il7E4WlPQrFmjEFNYksemv/IEeLg4gvODmS/qbelh3 OqHe+5bH0RPdEKYHtNClY35hk0xCNDvI3xPHZ7JeB8YWyD0auDkxgIeFcypXke1aBkm4 OSYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xY/Gr+CM6DSyTUnzjmOVMpuhhUlJoU20id05vhFQ0ZI=; b=cMSI/dmCIzc8iQRKbXKX9L3VwcsQK66zmqEA8caw9ZzpdM7U/j6x1E+mP9apOGovBG gV9SkXHeYSlA32QXx+GoYASeQpx/6lVTs9zxR0nz7An8t/mHYoj3f8tqoU1IHxlMZTcY ajpriqmzl6wmw9GlWD9slu4rr1yvoRHpDQF5uA4GhfoNWmCdgZPSz1l5qf8xxPNv9HUQ YI3HaF0pJK8FWRQz1A1pzixMWWTJglWia8X+EyowKS2KSnZ7jnJmHXY9Jg+wpjWUS6t4 CELZplhwg9wxjTx1tFdeGE/Yl2z7H9Po523ejeXWDdMY6rrDo2x9fHjh1fVGml20h6pQ SKhw== X-Gm-Message-State: AEkoouu4+3Rgfoqzvx+MKDtRVyJKA0obTbhQiYECcfHlaPCAVEJbUBReOfEUpPHyTG2cpRHSLTo8lrkV37QTtw== X-Received: by 10.37.219.12 with SMTP id g12mr1872193ybf.180.1469174575027; Fri, 22 Jul 2016 01:02:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.121.3 with HTTP; Fri, 22 Jul 2016 01:02:54 -0700 (PDT) In-Reply-To: References: From: Suhas Nandakumar Date: Fri, 22 Jul 2016 13:32:54 +0530 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c18729ea86326053834dc58 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted - generic ICE text X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:02:58 -0000 --94eb2c18729ea86326053834dc58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Christer The -10 version removes the duplication and refers to ICE-BIS for the original text. Please let me know Thanks Suhas On Thu, Jul 14, 2016 at 6:58 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > The draft contains text which seems to be generic ICE text, copy/pasted > from draft-ice-5245bis. > > For example, in section 4.2.1.1.1. (ICE Restart), do we need to repeat > what an ICE restart is, when it can be performed etc? Shouldn=E2=80=99t w= e simply > describe the SDP aspects of the restart? > > So, in section 4.2.1.1.1. I think we would only need the 3 last > paragraphs. > > Regards, > > Christer > > > > From: mmusic on behalf of Suhas Nandakumar < > suhasietf@gmail.com> > Date: Friday 8 July 2016 at 15:58 > To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted > > Hello All > > We submitted -09 version of the ice-sip-sdp draft with the following > changes > > 1. Added Section 5 for dealing with ice2 > 2. updated an example in Appendix A to be IPv6 based end-point > 3. Updated Section 13.2 to say about the aggregation rules for ice2 > ice-option > 4. Restructured Offer/Answer sections into a single place as can be > seen in Section 4 > > Thanks to Christer for feedback on the restructuring the offer/answer > sections. > > > We hope that this version incorporates all the outstanding issues. Please > let us know if we are missing anything. > > Cheers > Suhas > --94eb2c18729ea86326053834dc58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Christer

=C2=A0The -10 version re= moves the duplication and refers to ICE-BIS for the original text. Please l= et me know

Thanks
Suhas

On Thu, Jul 14, 2016 a= t 6:58 PM, Christer Holmberg <christer.holmberg@ericsson.com<= /a>> wrote:

Hi,

The draft contains text which seems to be generic ICE text, copy/pasted fro= m draft-ice-5245bis.

For example, in section=C2=A0= 4.2.1.1.1. (ICE Restart), do we need to repeat what an ICE restart is, wh= en it can be performed etc? Shouldn=E2=80=99t we simply describe the SDP aspe= cts of the restart?

So, in section=C2=A04.2.1.1.1. I = think we would only need the 3 last paragraphs.

Regards,

Christer



From: mmusic <mmusic-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Friday 8 July 2016 at 15:58 To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic= -ice-sip-sdp-09 Submitted

Hello All

=C2=A0 We submitted -09 version of the ice-sip-sdp draft with the foll= owing changes

=C2=A0=C2=A0=C2=A01. Added Section 5 for dealing with ice2
=C2=A0 =C2=A02. updated an example in Appen= dix A to be IPv6 based end-point
=C2=A0 =C2=A03. Updated Section 13.2 to say= about the aggregation rules for ice2 ice-option
=C2=A0 =C2=A04. Restructured Offer/Answer s= ections into a single place as can be seen in Section 4
=C2=A0=C2=A0
Thanks to Christer for feedback on the rest= ructuring the offer/answer sections.


We hope that this version incorporates all = the outstanding issues. Please let us know if we are missing anything.

Cheers
Suhas

--94eb2c18729ea86326053834dc58-- From nobody Fri Jul 22 01:44:30 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA4A12D9F9 for ; Fri, 22 Jul 2016 01:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcH5v3Qxaypw for ; Fri, 22 Jul 2016 01:44:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BF812DA35 for ; Fri, 22 Jul 2016 01:44:25 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-ce-5791dce75e2c Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.AB.27088.7ECD1975; Fri, 22 Jul 2016 10:44:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.208]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0294.000; Fri, 22 Jul 2016 10:44:23 +0200 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted Thread-Index: AQHR2Rh/n/TctJ0bc0Gs9BWHxfSwVKAX9i8A///YJYCAADS3AIAMB+4AgAAoyEA= Date: Fri, 22 Jul 2016 08:44:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476E114F@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B476E114FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7h+6LOxPDDfo3slhMXf6YxWLn3A5m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj5bsdzAVbfjBWvP3exNTA+OEjYxcjJ4eE gInExzsLmSBsMYkL99azdTFycQgJHGGUuDRlOTOEs4RR4vnJiyxdjBwcbAIWEt3/tEEaRAS0 JFYvngvWzCwgL3FhyRowW1jAQeLj3mnsEDWOEj2zzrNA2H4Sf/vbmEFsFgFVif8nJoAdwSvg K3Fk7ScWiF0HmCR+dV9jBUlwCgRKfGq5AdbACHTd91NroJaJS9x6Mh/qagGJJXvOM0PYohIv H/9jhbCVJBqXPGGFqM+X+NJ2lRVimaDEyZlPWCYwis5CMmoWkrJZSMpmAb3MLKApsX6XPkSJ osSU7ofsELaGROucuezI4gsY2VcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbcwS2/DXYw vnzueIhRgINRiYd3Ae/EcCHWxLLiytxDjBIczEoivNeuA4V4UxIrq1KL8uOLSnNSiw8xSnOw KInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUwxixULmX6+O+3Q/QO5jrz8zUvY3R5mFj1eLVV lM8fWNwT+SOBJezwVaX7RgYrJC8Y6/9hKmHavUNO9VlNaNnH/3opp1eKtzHOkX70VarO7vy1 hwnn7oQ+2HtCUDPo1VK7LV2hDPZTXbdLqjjdX8Gup98juW1B8sIX9eFCUgcbggvPvhM4Lzpb iaU4I9FQi7moOBEA64ExcbUCAAA= Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] draft-ietf-mmusic-ice-sip-sdp-09 Submitted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:44:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B476E114FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KQSBjb3VwbGUgb2YgY29tbWVudHMuDQoNClExOg0KDQpUaGUgZHJhZnQgZGVmaW5l cyB0aGUg4oCcaWNlLXBhY2luZ+KAnSBhdHRyaWJ1dGUsIHVzZWQgdG8gbmVnb3RpYXRlIHRoZSBU YSB2YWx1ZSwgYW5kIHRoZW4gcmVmZXJlbmNlcyBJQ0UtQklTIGZvciB1c2FnZS4NCg0KSG93ZXZl ciwgSUNFLUJJUyBkb2VzIG5vdCBkZXNjcmliZSBob3cgaXQgaXMgdXNlZCBpbiBpbml0aWFsIG9m ZmVycywgYW5zd2Vycywgc3Vic2VxdWVudCBvZmZlcnMgZXRjLiBJIHRoaW5rIHdlIG5lZWQgdG8g aGF2ZSBzb21lIHRleHQgaW4gc2VjdGlvbiA0IChhbmQgc3Vic2VjdGlvbnMpIGhvdy9pZi93aGVu IHRoZSBhdHRyaWJ1dGUgaXMgdXNlZCBpbiBpbml0aWFsL3N1YnNlcXVlbnQgb2ZmZXJzL2Fuc3dl cnMgZXRjLg0KDQpUaGlzIG9mIGNvdXJzZSBhcHBsaWVzIHRvIGFsbCBTRFAgYXR0cmlidXRlcywg YnV0IGl0IHNlZW1zIGxpa2Ugc29tZS9hbGwgb2YgdGhlbSBhcmUgYWxyZWFkeSBjb3ZlcmVkLg0K DQoNClEyOg0KDQpSZWxhdGVkIHRvIFExLCB0aGVyZSBuZWVkcyB0byBiZSB0ZXh0IGRlc2NyaWJp bmcgd2hhdCB0byBkbyBpZiBhbiBvZmZlciAob3IgYW5zd2VyKSBkb2VzIG5vdCBjb250YWluIHRo ZSDigJxpY2UtcGFjaW5n4oCdIGF0dHJpYnV0ZSwgb3IgYW55IG90aGVyIGF0dHJpYnV0ZSB0aGF0 IHdpbGwgbm90IGJlIHByZXNlbnQgaWYgdGhlIHJlbW90ZSBwZWVyIGlzIFJGQyBjb21wbGlhbnQu IEl0IHdhcyBhZ3JlZWQgeWVzdGVyZGF5IGR1cmluZyB0aGUgSUNFIHNlc3Npb24gdGhhdCB0aGlz IHNob3VsZCBiZSBpbiB0aGUgaWNlLXNpcC1zZHAgZHJhZnQsIGJlY2F1c2UgYSBSRkMgY29tcGxp YW50IElDRSBhZ2VudCBhbHdheXMgdXNlcyBTSVAvU0RQLg0KDQpBbmQsIHRoZSBwcm9jZWR1cmUg aXMgdGhlIGZvbGxvd2luZzogaWYgdGhlIOKAnGljZS1wYWNpbmfigJ0gYXR0cmlidXRlIGlzIG5v dCBwcmVzZW50LCBvbmUgc2hvdWxkIGFzc3VtZSB0aGUgZGVmYXVsdCB2YWx1ZSBkZWZpbmVkIGlu IFJGQyA1MjQ1IChub3QgdGhlIGRlZmF1bHQgdmFsdWUgaW4gSUNFLUJJUykuDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCg0KRnJvbTogU3VoYXMgTmFuZGFrdW1hciBbbWFpbHRvOnN1aGFzaWV0 ZkBnbWFpbC5jb21dDQpTZW50OiAyMiBKdWx5IDIwMTYgMTE6MDINClRvOiBDaHJpc3RlciBIb2xt YmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IG1tdXNpYyBXRyA8bW11 c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIGRyYWZ0LWlldGYtbW11c2ljLWlj ZS1zaXAtc2RwLTA5IFN1Ym1pdHRlZA0KDQpIZWxsbyBDaHJpc3Rlcg0KDQogIEkgaGF2ZSBzdWJt aXR0ZWQgLTEwIHZlcnNpb24gdG8gYWRkcmVzcyB0aGUgYWJvdmUgZmVlZGJhY2suIFBsZWFzZSBs ZXQgbWUga25vdyB5b3VyIHRob3VnaHRzDQoNCg0KVGhhbmtzDQpTdWhhcw0KDQpPbiBUaHUsIEp1 bCAxNCwgMjAxNiBhdCA2OjQ0IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3 cm90ZToNCkhpLA0KDQo+IFRoZSBkcmFmdCBjdXJyZW50bHkgc2F5cyB0aGUgZm9sbG93aW5nIG9u IE9mZmVyL0Fuc3dlciB1c2FnZSBmb3IgdGhlIGljZTIgb3B0aW9uDQo+DQo+IiBUaGUgSUNFIG9w dGlvbiwgJ2ljZTInIGlzIHVzZWQgd2l0aCB0aGUgU0RQIHNlc3Npb24gbGV2ZWwgImE9aWNlLQ0K DQo+ICAgb3B0aW9ucyIgYXR0cmlidXRlIGluIGFuIFNEUCBvZmZlciB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBpbml0aWF0b3Igb2YNCg0KPiAgIHRoZSBJQ0UgZXhjaGFuZ2UgaXMgY29tcGxpYW50IHRv IHByb2NlZHVyZXMgZnJvbSBbSUNFLUJJUzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHAtMDkjcmVmLUlDRS1CSVM+XSAodmlhDQoNCj4gICAi YT1pY2Utb3B0aW9uczogaWNlMiIpLiAgVGhlIFJlc3BvbmRpbmcgUGVlciBpbmNsdWRlcyB0aGlz IHNhbWUNCg0KPiAgIGF0dHJpYnV0ZSBhdCB0aGUgc2Vzc2lvbiBsZXZlbCBpbiB0aGUgU0RQIGFu c3dlciBpZiBpdCBpcyBhbHNvIGFuDQoNCj4gICBbSUNFLUJJUzxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHAtMDkjcmVmLUlDRS1CSVM+XSBj b21wbGlhbnQgSUNFIEFnZW50LiINCg0KPg0KDQo+DQoNCj4gQXJlIHlvdSBsb29raW5nIGZvciBz b21ldGhpbmcgbW9yZSBzcGVjaWZpYyB0aGFuIHRoaXMgPw0KDQpTaW5jZSBjaGFwdGVyIDQgZGVz Y3JpYmVzIGhvdyBvZmZlcnMgYW5kIGFuc3dlcnMgYXJlIGNyZWF0ZWQsIEkgYXNzdW1lZCBpdCBz aG91bGQgYmUgbWVudGlvbmVkIHRoZXJlLiBUaGUgdGV4dCB5b3UgaGF2ZSBpcyBhIGdlbmVyYWwg ZGVzY3JpcHRpb24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCk9uIFRodSwgSnVs IDE0LCAyMDE2IGF0IDU6NTggUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdy b3RlOg0KSGksDQoNCkkgc2VlIHRoYXQgeW91IGhhdmUgYWRkZWQgdGhlIGRlZmluaXRpb24gb2Yg dGhlIGljZTIgaWNlLW9wdGlvbi4gSG93ZXZlciwgeW91IGhhdmUgbm90IGRlZmluZWQgdXNhZ2Ug b2YgaXQgaW4gdGhlIG9mZmVyL2Fuc3dlciBwcm9jZWR1cmVzLCBhbmQgaXTigJlzIG5vdCBpbmNs dWRlZCBpbiB0aGUgU0RQIGV4YW1wbGVzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9t OiBtbXVzaWMgPG1tdXNpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBTdWhhcyBOYW5kYWt1bWFyIDxzdWhhc2lldGZAZ21haWwu Y29tPG1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tPj4NCkRhdGU6IEZyaWRheSA4IEp1bHkgMjAx NiBhdCAxNTo1OA0KVG86ICJtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4i IDxtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbTU1V U0lDXSBkcmFmdC1pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcC0wOSBTdWJtaXR0ZWQNCg0KSGVsbG8g QWxsDQoNCiAgV2Ugc3VibWl0dGVkIC0wOSB2ZXJzaW9uIG9mIHRoZSBpY2Utc2lwLXNkcCBkcmFm dCB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhbmdlcw0KDQogICAxLiBBZGRlZCBTZWN0aW9uIDUgZm9y IGRlYWxpbmcgd2l0aCBpY2UyDQogICAyLiB1cGRhdGVkIGFuIGV4YW1wbGUgaW4gQXBwZW5kaXgg QSB0byBiZSBJUHY2IGJhc2VkIGVuZC1wb2ludA0KICAgMy4gVXBkYXRlZCBTZWN0aW9uIDEzLjIg dG8gc2F5IGFib3V0IHRoZSBhZ2dyZWdhdGlvbiBydWxlcyBmb3IgaWNlMiBpY2Utb3B0aW9uDQog ICA0LiBSZXN0cnVjdHVyZWQgT2ZmZXIvQW5zd2VyIHNlY3Rpb25zIGludG8gYSBzaW5nbGUgcGxh Y2UgYXMgY2FuIGJlIHNlZW4gaW4gU2VjdGlvbiA0DQoNClRoYW5rcyB0byBDaHJpc3RlciBmb3Ig ZmVlZGJhY2sgb24gdGhlIHJlc3RydWN0dXJpbmcgdGhlIG9mZmVyL2Fuc3dlciBzZWN0aW9ucy4N Cg0KDQpXZSBob3BlIHRoYXQgdGhpcyB2ZXJzaW9uIGluY29ycG9yYXRlcyBhbGwgdGhlIG91dHN0 YW5kaW5nIGlzc3Vlcy4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHdlIGFyZSBtaXNzaW5nIGFueXRo aW5nLg0KDQpDaGVlcnMNClN1aGFzDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B476E114FESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BIGNvdXBsZSBvZiBj b21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlExOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGRyYWZ0IGRlZmluZXMgdGhl IOKAnGljZS1wYWNpbmfigJ0gYXR0cmlidXRlLCB1c2VkIHRvIG5lZ290aWF0ZSB0aGUgVGEgdmFs dWUsIGFuZCB0aGVuIHJlZmVyZW5jZXMgSUNFLUJJUyBmb3IgdXNhZ2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Ib3dldmVyLCBJQ0UtQklTIGRvZXMgbm90IGRlc2Ny aWJlIGhvdyBpdCBpcyB1c2VkIGluIGluaXRpYWwgb2ZmZXJzLCBhbnN3ZXJzLCBzdWJzZXF1ZW50 IG9mZmVycyBldGMuIEkgdGhpbmsgd2UgbmVlZCB0byBoYXZlIHNvbWUgdGV4dA0KIGluIHNlY3Rp b24gNCAoYW5kIHN1YnNlY3Rpb25zKSBob3cvaWYvd2hlbiB0aGUgYXR0cmlidXRlIGlzIHVzZWQg aW4gaW5pdGlhbC9zdWJzZXF1ZW50IG9mZmVycy9hbnN3ZXJzIGV0Yy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoaXMgb2YgY291cnNlIGFwcGxpZXMgdG8gYWxsIFNE UCBhdHRyaWJ1dGVzLCBidXQgaXQgc2VlbXMgbGlrZSBzb21lL2FsbCBvZiB0aGVtIGFyZSBhbHJl YWR5IGNvdmVyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5h bWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+UTI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5SZWxhdGVkIHRvIFExLCB0aGVyZSBuZWVkcyB0byBiZSB0ZXh0IGRlc2NyaWJpbmcg d2hhdCB0byBkbyBpZiBhbiBvZmZlciAob3IgYW5zd2VyKSBkb2VzIG5vdCBjb250YWluIHRoZSDi gJxpY2UtcGFjaW5n4oCdIGF0dHJpYnV0ZSwgb3INCiBhbnkgb3RoZXIgYXR0cmlidXRlIHRoYXQg d2lsbCBub3QgYmUgcHJlc2VudCBpZiB0aGUgcmVtb3RlIHBlZXIgaXMgUkZDIGNvbXBsaWFudC4g SXQgd2FzIGFncmVlZCB5ZXN0ZXJkYXkgZHVyaW5nIHRoZSBJQ0Ugc2Vzc2lvbiB0aGF0IHRoaXMg c2hvdWxkIGJlIGluIHRoZSBpY2Utc2lwLXNkcCBkcmFmdCwgYmVjYXVzZSBhIFJGQyBjb21wbGlh bnQgSUNFIGFnZW50IGFsd2F5cyB1c2VzIFNJUC9TRFAuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5BbmQsIHRoZSBwcm9jZWR1cmUgaXMgdGhlIGZvbGxvd2luZzogaWYg dGhlIOKAnGljZS1wYWNpbmfigJ0gYXR0cmlidXRlIGlzIG5vdCBwcmVzZW50LCBvbmUgc2hvdWxk IGFzc3VtZSB0aGUgZGVmYXVsdCB2YWx1ZSBkZWZpbmVkIGluIFJGQw0KIDUyNDUgKG5vdCB0aGUg ZGVmYXVsdCB2YWx1ZSBpbiBJQ0UtQklTKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBTdWhhcyBOYW5kYWt1bWFyIFttYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiAyMiBKdWx5IDIwMTYgMTE6MDI8YnI+DQo8Yj5Ubzo8L2I+IENo cmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBtbXVzaWMgV0cgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIGRyYWZ0LWlldGYtbW11c2ljLWljZS1zaXAtc2RwLTA5 IFN1Ym1pdHRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIENo cmlzdGVyPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgSSBoYXZlIHN1Ym1pdHRlZCAtMTAgdmVyc2lvbiB0byBhZGRyZXNzIHRoZSBhYm92ZSBmZWVk YmFjay4gUGxlYXNlIGxldCBtZSBrbm93IHlvdXIgdGhvdWdodHM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1aGFzPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDE0 LCAyMDE2IGF0IDY6NDQgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 IFRoZSBkcmFmdCBjdXJyZW50bHkgc2F5cyB0aGUgZm9sbG93aW5nIG9uIE9mZmVyL0Fuc3dlciB1 c2FnZSBmb3IgdGhlIGljZTIgb3B0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7JnF1b3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IFRoZSBJQ0Ugb3B0aW9uLCAnaWNlMicgaXMg dXNlZCB3aXRoIHRoZSBTRFAgc2Vzc2lvbiBsZXZlbCAmcXVvdDthPWljZS08L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7IG9wdGlvbnMmcXVv dDsgYXR0cmlidXRlIGluIGFuIFNEUCBvZmZlciB0byBpbmRpY2F0ZSB0aGF0IHRoZSBpbml0aWF0 b3Igb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7IHRoZSBJQ0UgZXhjaGFuZ2UgaXMgY29tcGxpYW50IHRvIHBy b2NlZHVyZXMgZnJvbSBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbW11c2ljLWljZS1zaXAtc2RwLTA5I3JlZi1JQ0UtQklTIiB0YXJnZXQ9Il9ibGFuayIg dGl0bGU9IiZxdW90O0ludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50IChJQ0Up OiBBIFByb3RvY29sIGZvciBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRvciAoTkFUKSBUcmF2ZXJz YWwgZm9yIE9mZmVyL0Fuc3dlciBQcm90b2NvbHMmcXVvdDsiPklDRS1CSVM8L2E+XSAodmlhPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0 OyZuYnNwOyZuYnNwOyAmcXVvdDthPWljZS1vcHRpb25zOiBpY2UyJnF1b3Q7KS4mbmJzcDsgVGhl IFJlc3BvbmRpbmcgUGVlciBpbmNsdWRlcyB0aGlzIHNhbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7Jm5ic3A7IGF0dHJp YnV0ZSBhdCB0aGUgc2Vzc2lvbiBsZXZlbCBpbiB0aGUgU0RQIGFuc3dlciBpZiBpdCBpcyBhbHNv IGFuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jmd0OyZuYnNwOyZuYnNwOyBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbW11c2ljLWljZS1zaXAtc2RwLTA5I3JlZi1JQ0UtQklTIiB0YXJnZXQ9Il9i bGFuayIgdGl0bGU9IiZxdW90O0ludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50 IChJQ0UpOiBBIFByb3RvY29sIGZvciBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRvciAoTkFUKSBU cmF2ZXJzYWwgZm9yIE9mZmVyL0Fuc3dlciBQcm90b2NvbHMmcXVvdDsiPklDRS1CSVM8L2E+XSBj b21wbGlhbnQgSUNFIEFnZW50LiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyBBcmUgeW91 IGxvb2tpbmcgZm9yIHNvbWV0aGluZyBtb3JlIHNwZWNpZmljIHRoYW4gdGhpcyA/PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPlNpbmNlIGNoYXB0ZXIgNCBkZXNjcmliZXMgaG93IG9mZmVy cyBhbmQgYW5zd2VycyBhcmUgY3JlYXRlZCwgSSBhc3N1bWVkIGl0IHNob3VsZCBiZSBtZW50aW9u ZWQgdGhlcmUuIFRoZSB0ZXh0IHlvdSBoYXZlIGlzIGEgZ2VuZXJhbCBkZXNjcmlwdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5PbiBUaHUsIEp1bCAxNCwgMjAxNiBhdCA1OjU4IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkg c2VlIHRoYXQgeW91IGhhdmUgYWRkZWQgdGhlIGRlZmluaXRpb24gb2YgdGhlIGljZTIgaWNlLW9w dGlvbi4gSG93ZXZlciwgeW91IGhhdmUgbm90IGRlZmluZWQgdXNhZ2Ugb2YgaXQgaW4gdGhlIG9m ZmVyL2Fuc3dlciBwcm9jZWR1cmVzLCBhbmQgaXTigJlzIG5vdCBpbmNsdWRlZA0KIGluIHRoZSBT RFAgZXhhbXBsZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNocmlzdGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5tbXVzaWMgJmx0OzxhIGhyZWY9Im1haWx0bzptbXVzaWMt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpYy1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDsgb24gYmVoYWxmIG9mIFN1aGFzIE5hbmRha3VtYXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpzdWhhc2lldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3VoYXNpZXRmQGdtYWlsLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSA4IEp1bHkgMjAxNiBhdCAxNTo1ODxi cj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bTU1VU0lDXSBkcmFmdC1pZXRmLW1tdXNpYy1pY2Utc2lw LXNkcC0wOSBTdWJtaXR0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkhlbGxvIEFsbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgV2Ugc3VibWl0dGVkIC0wOSB2ZXJzaW9uIG9mIHRoZSBp Y2Utc2lwLXNkcCBkcmFmdCB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhbmdlczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzEuIEFk ZGVkIFNlY3Rpb24gNSBmb3IgZGVhbGluZyB3aXRoIGljZTI8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNw OzIuIHVwZGF0ZWQgYW4gZXhhbXBsZSBpbiBBcHBlbmRpeCBBIHRvIGJlIElQdjYgYmFzZWQgZW5k LXBvaW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDszLiBVcGRh dGVkIFNlY3Rpb24gMTMuMiB0byBzYXkgYWJvdXQgdGhlIGFnZ3JlZ2F0aW9uIHJ1bGVzIGZvciBp Y2UyIGljZS1vcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNw OzQuIFJlc3RydWN0dXJlZCBPZmZlci9BbnN3ZXIgc2VjdGlvbnMgaW50byBhIHNpbmdsZSBwbGFj ZSBhcyBjYW4gYmUgc2VlbiBpbiBTZWN0aW9uIDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoYW5rcyB0byBD aHJpc3RlciBmb3IgZmVlZGJhY2sgb24gdGhlIHJlc3RydWN0dXJpbmcgdGhlIG9mZmVyL2Fuc3dl ciBzZWN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5XZSBob3BlIHRoYXQgdGhpcyB2ZXJzaW9uIGluY29ycG9yYXRlcyBhbGwgdGhlIG91dHN0YW5k aW5nIGlzc3Vlcy4gUGxlYXNlIGxldCB1cyBrbm93IGlmIHdlIGFyZSBtaXNzaW5nIGFueXRoaW5n LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlN1aGFzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B476E114FESESSMB209erics_-- From nobody Sun Jul 24 12:30:09 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F2712D60D for ; Sun, 24 Jul 2016 12:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1siFumgJ6YKu for ; Sun, 24 Jul 2016 12:29:59 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D10912D606 for ; Sun, 24 Jul 2016 12:29:59 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f65so112220433wmi.0; Sun, 24 Jul 2016 12:29:59 -0700 (PDT) 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-transfer-encoding:thread-index :content-language; bh=m7XWi6L1R/PqqbRhcCjeYW3t3yn7LbxOvCkHEPGcM0A=; b=p7CYFWAlIdu0QBcTDfLWook3f+lc8hu5BZA6OHZog4Py4B8SQ31q+J+aehOemJhPMN dd/NwsYwFQj7NvpU2FX08tmz267rSQy70Dv1/ek+HqbIas/iZzUTZuow3ye1zTUnXYbR 7FHN9S04ZANmIHmfHNR86v+B+ADCqyDP+PwNJZqYW+zdg3+zPJWY+XO94w6B7KMrlHhH 9WmwfvPBSx7N9qiH4eEec7hdFtRlEsD57trwreB5ujxEAjEN+cIc9jMiEmTwfBvSA9MW EoNYDToa7w9ciJku0vTN2UP61EPugKYncPS4TMN63b57A6MtKkaxLLo1QAxP+x5Dc+1g 71Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=m7XWi6L1R/PqqbRhcCjeYW3t3yn7LbxOvCkHEPGcM0A=; b=dtLBc9F1IUzJoKVGtwkGli1SqM+FUJ24z8teIIluwktx6vuw4BniT+xgESXwV12KzA XFyNYC2KEYpuECXsJ2B0PZs4g7TIbB4wlYwszXuwOSs6+OFemPmaAsj4CbiuPXysf+wz 7VRuTb3M67vPTucljr0izQL0ufNVcEan4apeKEzYvGRxnLrsPZX7gelyMp4RPc8Nuxk/ vRWTDZL7VHajLDQKTBa/9bN2KzIu6+ke89gqsdInttnmF9/5bHLdyGE8jZRHCYrcz4E6 NZf0TvD/IQYjLZ+7gke5f22MGtA/4RBxlN4c6LmlTIJrw1FldsRAe14Hy/PLraE74h4d 8hsg== X-Gm-Message-State: ALyK8tIV0eUZowfdyF919lyKP3ENWGaf5xaD3OBJsfdtSZKPiwS5I1lQ//Mrtuw6u35k1g== X-Received: by 10.28.63.8 with SMTP id m8mr38156605wma.88.1469388597950; Sun, 24 Jul 2016 12:29:57 -0700 (PDT) Received: from RoniPC (bzq-79-180-189-228.red.bezeqint.net. [79.180.189.228]) by smtp.gmail.com with ESMTPSA id r127sm23578854wmf.23.2016.07.24.12.29.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 24 Jul 2016 12:29:56 -0700 (PDT) From: "Roni Even" To: "'Flemming Andreasen'" , "'mmusic'" References: <5ff3d1d2-1d3f-738c-ce16-11dc26508516@cisco.com> In-Reply-To: <5ff3d1d2-1d3f-738c-ce16-11dc26508516@cisco.com> Date: Sun, 24 Jul 2016 22:29:54 +0300 Message-ID: <00e501d1e5e1$c254e180$46fea480$@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: AQF13/AyHtteVqxJdPz5Tuk1mpYerKDgAd2w Content-Language: he Archived-At: Cc: draft-ietf-mmusic-sdp-simulcast-05@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 19:30:08 -0000 Hi, This solution is partial since it does not support all simulcast use cases.The document in section 6.4 talk about declarative usage and point to section 8 about limitation of supporting this case. In section 8 the document says that the solution does not support multiple multicast groups and as such claiming support for declarative usage is very limited or does not exist. The question is why does the document support the simulcast attribute only on the media level and does not define usage for the session level to allow multiple multicast groups each as a separate RTP session. Roni Even > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming > Andreasen > Sent: Thursday, July 07, 2016 5:42 PM > To: mmusic > Cc: draft-ietf-mmusic-sdp-simulcast-05@ietf.org > Subject: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-05 > > Greetings MMUSIC > > This is to announce a 3 week WGLC on the draft: > > https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-05.txt > > as Proposed Standard. Please review and provide any comments you may > have on the document by Thursday, July 28, 2016. Comments should be sent > to the document authors and the MMUSIC WG list. If you review the > document but do not have any comments, please send a note to that effect > as well. > > Thanks > > -- Flemming (MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Jul 25 03:19:16 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7516712D5CC; Mon, 25 Jul 2016 03:19:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160725101912.11449.77398.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2016 03:19:12 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 10:19:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju (Raju) Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Filename : draft-ietf-mmusic-data-channel-sdpneg-09.txt Pages : 39 Date : 2016-07-25 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 25 03:22:46 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB212D5CC; Mon, 25 Jul 2016 03:22:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160725102244.11477.21108.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2016 03:22:44 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-05.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 10:22:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : MSRP over Data Channels Authors : Keith Drage Maridi R. Makaraju (Raju) Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Filename : draft-ietf-mmusic-msrp-usage-data-channel-05.txt Pages : 17 Date : 2016-07-25 Abstract: This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based generic data channel negotiation framework. Two network configurations are documented: a WebRTC end- to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 25 03:35:42 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C9A12D78C for ; Mon, 25 Jul 2016 03:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH5BoTMF0tB0 for ; Mon, 25 Jul 2016 03:35:38 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BB112D787 for ; Mon, 25 Jul 2016 03:35:38 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 7439E77B39B08 for ; Mon, 25 Jul 2016 10:35:30 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6PAZWdt008919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 25 Jul 2016 10:35:32 GMT 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 u6PAZWHT012358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Jul 2016 12:35:32 +0200 Received: from [135.224.211.217] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 25 Jul 2016 12:35:32 +0200 From: Juergen Stoetzer-Bradler To: "mmusic@ietf.org" Message-ID: <7ac71e12-b84f-6999-6109-6223495f6185@alcatel-lucent.com> Date: Mon, 25 Jul 2016 12:35:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------ABB504C2BAACD77E6C7F4749" X-Originating-IP: [135.239.27.39] Archived-At: Subject: [MMUSIC] New versions data-channel-sdpneg-09 and msrp-usage-data-channel-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 10:35:40 -0000 --------------ABB504C2BAACD77E6C7F4749 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello, I've submitted new versions of the data channel-sdpneg and msrp-usage-data-channel drafts. Major changes are: * draft-ietf-mmusic-data-channel-sdpneg-09 o New definition of "data channel subprotocol" in Section 3 as proposed on the MMUSIC list, https://www.ietf.org/mail-archive/web/mmusic/current/msg15827.html. o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative references. o Updates of the tables in Section 8.2.1 and Section 8.2.2 as per section 8.2.4 of [I-D.ietf-mmusic-rfc4566bis]. o New Section 8.3 regarding the new usage level. * draft-ietf-mmusic-msrp-usage-data-channel-05 o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative references. o Addition of Section 8.2 as per section 8.2.4 of [I-D.ietf-mmusic-rfc4566bis]. Thanks, Juergen --------------ABB504C2BAACD77E6C7F4749 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hello,

I've submitted new versions of the data channel-sdpneg and msrp-usage-data-channel drafts.
Major changes are:

  * draft-ietf-mmusic-data-channel-sdpneg-09
      o New definition of "data channel subprotocol" in Section 3 as proposed on the MMUSIC list,
        https://www.ietf.org/mail-archive/web/mmusic/current/msg15827.html.
      o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative references.
      o Updates of the tables in Section 8.2.1 and Section 8.2.2 as per section 8.2.4 of [I-D.ietf-mmusic-rfc4566bis].
      o New Section 8.3 regarding the new usage level.

  * draft-ietf-mmusic-msrp-usage-data-channel-05
      o Addition of [I-D.ietf-mmusic-rfc4566bis] to list of normative references.
      o Addition of Section 8.2 as per section 8.2.4 of [I-D.ietf-mmusic-rfc4566bis].


Thanks,
Juergen
--------------ABB504C2BAACD77E6C7F4749-- From nobody Mon Jul 25 08:04:26 2016 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA16F12B05A; Mon, 25 Jul 2016 08:04:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160725150421.11530.97108.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2016 08:04:21 -0700 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-mux-exclusive@ietf.org, mmusic@ietf.org Subject: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-mmusic-mux-exclusive-09=3A_=28with_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 15:04:22 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mmusic-mux-exclusive-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Quick question: My initial understanding was that newer systems usually support RTP/RTCP multiplexing, while older systems that do not support RTP/RTCP multiplexing will also not be able to understand this new attribut. So I guess that's not the use case. That means the use case if for newer system that do know about RTP/RTCP multiplexing as well as the 'rtcp-mux-only' attribute but don't support it for some reason. What are these reasons? Maybe you can provide some more background about the intended usage here! Minor: Some sentences are a little hard to pharse as they are quite long, e.g. OLD: "When an offerer sends the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=" line)." MAYBE: "If the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST send the initial offer with an associated SDP 'rtcp-mux-only' attribute and the associated SDP media description ("m=" line)." From nobody Mon Jul 25 11:16:51 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC58C12D961; Mon, 25 Jul 2016 11:16:49 -0700 (PDT) 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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBJ6XdO3H5jc; Mon, 25 Jul 2016 11:16:47 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0D612D966; Mon, 25 Jul 2016 11:16:45 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u6PIGeKh022950; Mon, 25 Jul 2016 14:16:40 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 241uh6m4gq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 25 Jul 2016 14:16:40 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 25 Jul 2016 13:16:39 -0500 From: Jonathan Lennox To: =?utf-8?B?TWlndWVsIFBhcsOtcyBEw61heg==?= Thread-Topic: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? Thread-Index: AQHR3bAS2iXZNVjDUESNYXQcq89uRqAYBL8AgABgnYCAAAGkAIAJJ36AgABFx4CAApMIgIAFcoMA Date: Mon, 25 Jul 2016 18:16:39 +0000 Message-ID: References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com> <7E00EB16-72FE-4A1E-A268-66674361FB2B@vidyo.com> <3BECBA70-B73C-4E87-8A69-55AAA406A8B9@vidyo.com> <7594FB04B1934943A5C02806D1A2204B476AA914@ESESSMB208.ericsson.se> <9245E2F8-C683-438F-BD16-0BEA27D813EE@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.220.24] Content-Type: multipart/alternative; boundary="_000_B01B64DDF99D4876A545D608068ADE3Dvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-25_14:2016-07-25,2016-07-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607250210 Archived-At: Cc: mmusic , IETF AVTCore WG , Christer Holmberg Subject: Re: [MMUSIC] [AVTCORE] BUNDLE: a single stream with multiple MIDs? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 18:16:50 -0000 --_000_B01B64DDF99D4876A545D608068ADE3Dvidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgMjIsIDIwMTYsIGF0IDM6MDUgQU0sIE1pZ3VlbCBQYXLDrXMgRMOtYXogPG1wYXJp c2RpYXpAZ21haWwuY29tPG1haWx0bzptcGFyaXNkaWF6QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpI ZWxsbyBKb25hdGhhbiwNCkRvIHlvdSBtZWFuIHRvIGFkZCBNSUQgU0RFUyBJdGVtIFsxXSB1c2lu ZyBTREVTIGhlYWRlciBleHRlbnNpb25zIFsyXSBhbmQgYWxzbyBleHRlbmRzIHRoYXQgdG8gcHJv dmlkZSB0aGUgInZlcnNpb24iPw0KSWYgd2UgdXNlIHRoaXMgYXBwcm9hY2gsIFJUUCBNSUQgSGVh ZGVyIEV4dGVuc2lvbiBbM10gd291bGQgYmUgdXNlbGVzcywgd291bGRuJ3QgaXQ/DQoNClRoZSBw bGFuIGlzIHRvIHVwZGF0ZSB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgTUlEIEhlYWRlciBFeHRlbnNp b24gaW4gQlVORExFIHRvIHVzZSB0aGUgU0RFUyBoZWFkZXIgZXh0ZW5zaW9ucyBkcmFmdC4gIFRo aXMgaXNu4oCZdCBhIGNoYW5nZSB0byB0aGUgYml0cyBvbiB0aGUgd2lyZSBvciBpbiB0aGUgc2ln bmFsaW5nLCBqdXN0IGluIGhvdyBpdOKAmXMgc3BlY2lmaWVkLg0KDQpBbnl3YXksIGNvdWxkIHlv dSBleHBhbmQgeW91ciBpZGVhIHRvIHNob3cgaG93IHdvdWxkIHlvdSBzb2x2ZSB0aGUgcmFjZSBj b25kaXRpb24gcHJvYmxlbT8NCg0KU2luY2UgU0RFUyBpcyBzZW50IHBlcmlvZGljYWxseSwgZXZl biBpZiBwYWNrZXQgcmVvcmRlcmluZyBjYXVzZXMgZW5kcG9pbnQgY29uZnVzaW9uICh3aGljaCBp cyB1bmxpa2VseSwgc2luY2UgTUlEIGlzIG9ubHkgc3VwcG9zZWQgdG8gYmUgc2VudCDigJxlYXJs eeKAnSBpbiBhIHN0cmVhbSksIHRoZSBlbmRwb2ludCBzaG91bGQgcmVzeW5jaHJvbml6ZSBwcmV0 dHkgcXVpY2tseS4NCg0KDQpCZXN0ISENCg0KUmVmcw0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtYnVuZGxlLW5lZ290aWF0aW9uLTMxI3NlY3Rp b24tMTQuMg0KWzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2dGV4 dC1zZGVzLWhkci1leHQtMDcNClszXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbi0zMSNzZWN0aW9uLTE0LjMNCg0KDQoy MDE2LTA3LTIwIDE3OjQ2IEdNVCswMjowMCBKb25hdGhhbiBMZW5ub3ggPGpvbmF0aGFuQHZpZHlv LmNvbTxtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tPj46DQpkcmFmdC1pZXRmLWF2dGV4dC1zZGVz LWhkci1leHQgZGlzY3Vzc2VzIHdheXMgdG8gbm90aWNlIHJlb3JkZXJpbmcgb2YgcGFja2V0cyBj YXJyeWluZyBTREVTIGhlYWRlciBleHRlbnNpb25zIChvZiB3aGljaCBNSUQgaXMgYW4gaW5zdGFu Y2UpLiAgSXMgdGhhdCB0ZXh0IHN1ZmZpY2llbnQ/DQoNCk9uIEp1bCAyMCwgMjAxNiwgYXQgMToz NiBQTSwgTWlndWVsIFBhcsOtcyBEw61heiA8bXBhcmlzZGlhekBnbWFpbC5jb208bWFpbHRvOm1w YXJpc2RpYXpAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhlbGxvLA0KdGhpbmtpbmcgYSBiaXQgYWJv dXQgdGhhdCBpZGVhLCBpZiB3ZSBzdXBwb3J0IHRoYXQgZGlmZmVyZW50IFJUUCBzdHJlYW1zIGhh dmUgdGhlIHNhbWUgTUlELCB3ZSBzaG91bGQgcHJvdmlkZSBhIGtpbmQgb2YgdmVyc2lvbiB0byBk ZWFsIHdpdGggcmFjZSBjb25kaXRpb25zLg0KDQpUYWtpbmcgdGhlIGV4YW1wbGUgb2Yg4oCcdGhl IGN1cnJlbnQgbG91ZGVzdCBzcGVha2Vy4oCdIChMUykgLCBpZiB0aGUgbWlkZGxlIGJveCBzd2l0 Y2hlcyBtYW55IHRpbWVzIEFsaWNlIDwtPiBCb2Igc3RyZWFtcyB0aGUgZW5kcG9pbnQgcmVjZWl2 aW5nIHRoZSBSVFAgc3RyZWFtcyBtYXkgc2hvdyB0aGUgaW5jb3JyZWN0IGxvdWRlc3Qtc3BlYWtl ciBkdWUgdG8gcHJvY2Vzc2luZyBhbiBSVFAgc3RyZWFtIGJlZm9yZSB0aGUgb3RoZXIgb25lIChu ZXR3b3JrLCByYWNlIGNvbmRpdGlvbiBpbnRvIHRoZSBlbmRwb2ludCwgZXRjLikNCg0KSW1hZ2lu ZSB0aGF0IGNhc2U6DQpNaWRsZUJveCBzaWRlOiBBbGljZSBMUyAtPiBCb2IgTFMgLT4gQWxpY2Ug TFMNCkVuZHBvaW50IHNpZGU6IFByb2Nlc3MgQWxpY2UgYXMgTFMgLT4gUHJvY2VzcyBBbGljZSBM UyAtPiBQcm9jZXNzIEJvYiBMUw0KDQpBdCB0aGUgZW5kIHRoZSBlbmRwb2ludCB3b3VsZCByZW5k ZXIgQm9iIGFzIExTLCBidXQgaXQgaXMgd3JvbmcuDQoNClRvIGZpeCB0aGlzIHJhY2UgY29uZGl0 aW9uIHByb2JsZW0gSSBwcm9wb3NlIGFkZGluZyBhIHZlcnNpb246DQpNaWRsZUJveCBzaWRlOiBB bGljZSBMUy0wIC0+IEJvYiBMUy0xIC0+IEFsaWNlIExTLTINCkVuZHBvaW50IHNpZGU6IFByb2Nl c3MgQWxpY2UgYXMgTFMtMCAtPiBQcm9jZXNzIEFsaWNlIExTLTIgLT4gUHJvY2VzcyBCb2IgTFMt MSAoZGlzY2FyZGVkIGJlY2F1c2UgMTwyKQ0KDQpXaGF0IGRvIHlvdSB0aGluayBhYm91dCB0aGF0 Pw0KDQpCZXN0IHJlZ2FyZHMhIQ0KDQoNCjIwMTYtMDctMTQgMTc6NDkgR01UKzAyOjAwIENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+Og0KSGksDQoNCllvdSBkb24ndCBuZWVkIGEgY29t bW9uIGxvZ2ljLiBZb3UgY2FuIGRlZmluZSBhbiBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCAo ZS5nLiBDTFVFKSB0byBkZWZpbmUvY29uZmlndXJlL25lZ290aWF0ZSB0aGVzZSBraW5kIG9mIHRo aW5ncy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhv bmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBTdWhhcyBOYW5kYWt1 bWFyPG1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tPg0KU2VudDog4oCOMTQv4oCOMDcv4oCOMjAx NiAxODo0Mw0KVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+DQpDYzogScOxYWtpIEJheiBDYXN0aWxsbzxtYWlsdG86aWJjQGFsaWF4Lm5l dD47IEpvbmF0aGFuIExlbm5veDxtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tPjsgbW11c2ljPG1h aWx0bzptbXVzaWNAaWV0Zi5vcmc+OyBJRVRGIEFWVENvcmUgV0c8bWFpbHRvOmF2dEBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbQVZUQ09SRV0gQlVORExFOiBhIHNpbmdsZSBzdHJl YW0gd2l0aCBtdWx0aXBsZSBNSURzPw0KDQoNCg0KT24gVGh1LCBKdWwgMTQsIDIwMTYgYXQgMzoy NyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxt YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCj4uLi4NCj4N Cj5UaGUgY3VycmVudCBwcm9wb3NhbCBicmVha3MgdGhhdC4gUGxlYXNlIGxldCdzIE1JRCB0byBi ZSBhIHNpbmdsZSwNCj51bmlxdWUgYW5kIG1hbmRhdG9yeSBhdHRyaWJ1dGUgcGVyIG0tbGluZS4N Cg0KDQrFoGFuZCBsZXQgZWFjaCBSVFAgcGFja2V0IGJlIGFzc29jaWF0ZWQgd2l0aCBvbmUsIGFu ZCBvbmx5IG9uZSwgb2YgdGhvc2UNCk1JRHMvbS1saW5lcy4NCg0KDQpZb3UgY2FuIHRoZW4gaGF2 ZSBhcHBsaWNhdGlvbiBsb2dpYyBzYXlpbmcgZS5nLiDCs0lmIG5vIMWSbG91ZGVzdC1zcGVha2Vy wrkNCm1lZGlhIGlzIHJlY2VpdmVkLCB0aGVuIGR1cGxpY2F0ZSB0aGUgxZJib3NzwrkgbWVkaWEg b24gdGhlIHNjcmVlbg0KYXNzb2NpYXRlZCB3aXRoIHRoZSBsb3VkZXN0IHNwZWFrZXLCsi4gSXTC uXMgbXVjaCBtb3JlIGZsZXhpYmxlLCBhbmQgd2l0aG91dA0KYW55IG9mIHRoZSBjb25zdHJhaW50 cyBtZW50aW9uZWQgZWFybGllci4NCg0KDQpJIGFncmVlIGl0IGJyaW5ncyBpbiBmbGV4aWJpbGl0 eSBhbmQgaXQgc2NhcmVzIG1lIGEgYml0IGFzIHdlbGwgLi4gRWFjaCBhcHBsaWNhdGlvbiBuZWVk cyB0byBkZWZpbmUgdGhlaXIgb3duIGxvZ2ljIG9yIG5lZWQgYSBjb21tb24gbG9naWMgYWNyb3Nz IGFsbCBhcHBsaWNhdGlvbnMgLi4NCg0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGlu ZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1t dXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQoNCg0KLS0NCk1pZ3VlbCBQYXLDrXMgRMOt YXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tcHV0ZXIvU29mdHdhcmUgZW5naW5lZXIuDQpSZXNlYXJj aGVyIGFuZCBhcmNoaXRlY3QgaW4gaHR0cDovL3d3dy5rdXJlbnRvLm9yZzxodHRwOi8vd3d3Lmt1 cmVudG8ub3JnLz4NCmh0dHA6Ly90d2l0dGVyLmNvbS9tcGFyaXNkaWF6DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KDQoNCg0KLS0NCk1pZ3VlbCBQYXLDrXMgRMOtYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29t cHV0ZXIvU29mdHdhcmUgZW5naW5lZXIuDQpSZXNlYXJjaGVyIGFuZCBhcmNoaXRlY3QgaW4gaHR0 cDovL3d3dy5rdXJlbnRvLm9yZzxodHRwOi8vd3d3Lmt1cmVudG8ub3JnLz4NCmh0dHA6Ly90d2l0 dGVyLmNvbS9tcGFyaXNkaWF6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K --_000_B01B64DDF99D4876A545D608068ADE3Dvidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0C2CE3E9C0075C4C80783DE496FC3A4B@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwg MjIsIDIwMTYsIGF0IDM6MDUgQU0sIE1pZ3VlbCBQYXLDrXMgRMOtYXogJmx0OzxhIGhyZWY9Im1h aWx0bzptcGFyaXNkaWF6QGdtYWlsLmNvbSIgY2xhc3M9IiI+bXBhcmlzZGlhekBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPkhlbGxvIEpvbmF0aGFuLDxiciBjbGFzcz0iIj4NCkRvIHlvdSBtZWFuIHRvIGFkZCBNSUQg U0RFUyBJdGVtIFsxXSB1c2luZyBTREVTIGhlYWRlciBleHRlbnNpb25zIFsyXSBhbmQgYWxzbyBl eHRlbmRzIHRoYXQgdG8gcHJvdmlkZSB0aGUgJnF1b3Q7dmVyc2lvbiZxdW90Oz88YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgd2UgdXNlIHRoaXMgYXBwcm9hY2gsIFJUUCBN SUQgSGVhZGVyIEV4dGVuc2lvbiBbM10gd291bGQgYmUgdXNlbGVzcywgd291bGRuJ3QgaXQ/PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoZSBwbGFuIGlzIHRvIHVwZGF0ZSB0aGUgZGVmaW5pdGlv biBvZiB0aGUgTUlEIEhlYWRlciBFeHRlbnNpb24gaW4gQlVORExFIHRvIHVzZSB0aGUgU0RFUyBo ZWFkZXIgZXh0ZW5zaW9ucyBkcmFmdC4gJm5ic3A7VGhpcyBpc27igJl0IGEgY2hhbmdlIHRvIHRo ZSBiaXRzIG9uIHRoZSB3aXJlIG9yIGluIHRoZSBzaWduYWxpbmcsIGp1c3QgaW4gaG93IGl04oCZ cyBzcGVjaWZpZWQuJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkFueXdheSwgY291bGQgeW91IGV4cGFuZCB5b3VyIGlk ZWEgdG8gc2hvdyBob3cgd291bGQgeW91IHNvbHZlIHRoZSByYWNlIGNvbmRpdGlvbiBwcm9ibGVt PzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlNpbmNlIFNERVMgaXMgc2VudCBwZXJpb2Rp Y2FsbHksIGV2ZW4gaWYgcGFja2V0IHJlb3JkZXJpbmcgY2F1c2VzIGVuZHBvaW50IGNvbmZ1c2lv biAod2hpY2ggaXMgdW5saWtlbHksIHNpbmNlIE1JRCBpcyBvbmx5IHN1cHBvc2VkIHRvIGJlIHNl bnQg4oCcZWFybHnigJ0gaW4gYSBzdHJlYW0pLCB0aGUgZW5kcG9pbnQgc2hvdWxkIHJlc3luY2hy b25pemUgcHJldHR5IHF1aWNrbHkuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkJlc3QhITxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KUmVmczxiciBjbGFz cz0iIj4NClsxXSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbi0zMSNzZWN0aW9uLTE0LjIiIHRhcmdldD0i X2JsYW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW1tdXNpYy1zZHAtYnVuZGxlLW5lZ290aWF0aW9uLTMxI3NlY3Rpb24tMTQuMjwvYT48YnIgY2xh c3M9IiI+DQpbMl0gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtYXZ0ZXh0LXNkZXMtaGRyLWV4dC0wNyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LXNkZXMtaGRyLWV4dC0w NzwvYT48YnIgY2xhc3M9IiI+DQpbM10gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1idW5kbGUtbmVnb3RpYXRpb24tMzEjc2VjdGlvbi0x NC4zIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbi0zMSNzZWN0aW9uLTE0 LjM8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTYt MDctMjAgMTc6NDYgR01UJiM0MzswMjowMCBKb25hdGhhbiBMZW5ub3ggPHNwYW4gZGlyPSJsdHIi IGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20iIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0Ozwvc3Bhbj46PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPmRyYWZ0LWlldGYtYXZ0ZXh0LXNkZXMtaGRyLWV4dCBkaXNjdXNzZXMgd2F5cyB0byBub3Rp Y2UgcmVvcmRlcmluZyBvZiBwYWNrZXRzIGNhcnJ5aW5nIFNERVMgaGVhZGVyIGV4dGVuc2lvbnMg KG9mIHdoaWNoIE1JRCBpcyBhbiBpbnN0YW5jZSkuJm5ic3A7IElzIHRoYXQgdGV4dCBzdWZmaWNp ZW50PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Img1Ij48YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPk9uIEp1bCAyMCwgMjAxNiwgYXQgMTozNiBQTSwgTWlndWVsIFBhcsOtcyBEw61h eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wYXJpc2RpYXpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+bXBhcmlzZGlhekBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IZWxsbyw8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCnRo aW5raW5nIGEgYml0IGFib3V0IHRoYXQgaWRlYSwgaWYgd2Ugc3VwcG9ydCB0aGF0IGRpZmZlcmVu dCBSVFAgc3RyZWFtcyBoYXZlIHRoZSBzYW1lIE1JRCwgd2Ugc2hvdWxkIHByb3ZpZGUgYSBraW5k IG9mIHZlcnNpb24gdG8gZGVhbCB3aXRoIHJhY2UgY29uZGl0aW9ucy48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRha2luZyB0aGUgZXhhbXBsZSBvZiDigJx0aGUgY3VycmVu dCBsb3VkZXN0IHNwZWFrZXLigJ0gKExTKSAsIGlmIHRoZSBtaWRkbGUgYm94IHN3aXRjaGVzIG1h bnkgdGltZXMgQWxpY2UgJmx0Oy0mZ3Q7IEJvYiBzdHJlYW1zIHRoZSBlbmRwb2ludCByZWNlaXZp bmcgdGhlIFJUUCBzdHJlYW1zIG1heSBzaG93IHRoZSBpbmNvcnJlY3QgbG91ZGVzdC1zcGVha2Vy IGR1ZSB0byBwcm9jZXNzaW5nIGFuIFJUUCBzdHJlYW0gYmVmb3JlIHRoZSBvdGhlciBvbmUgKG5l dHdvcmssDQogcmFjZSBjb25kaXRpb24gaW50byB0aGUgZW5kcG9pbnQsIGV0Yy4pPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpJbWFnaW5lIHRoYXQgY2FzZTo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCk1pZGxlQm94IHNpZGU6IEFsaWNlIExTIC0mZ3Q7IEJvYiBMUyAtJmd0OyBB bGljZSBMUzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KRW5kcG9pbnQgc2lkZTogUHJvY2VzcyBBbGlj ZSBhcyBMUyAtJmd0OyBQcm9jZXNzIEFsaWNlIExTIC0mZ3Q7IFByb2Nlc3MgQm9iIExTPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpBdCB0aGUgZW5kIHRoZSBlbmRwb2ludCB3 b3VsZCByZW5kZXIgQm9iIGFzIExTLCBidXQgaXQgaXMgd3JvbmcuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQpUbyBmaXggdGhpcyByYWNlIGNvbmRpdGlvbiBwcm9ibGVtIEkg cHJvcG9zZSBhZGRpbmcgYSB2ZXJzaW9uOjxiciBjbGFzcz0iIj4NCk1pZGxlQm94IHNpZGU6IEFs aWNlIExTLTAgLSZndDsgQm9iIExTLTEgLSZndDsgQWxpY2UgTFMtMjxiciBjbGFzcz0iIj4NCkVu ZHBvaW50IHNpZGU6IFByb2Nlc3MgQWxpY2UgYXMgTFMtMCAtJmd0OyBQcm9jZXNzIEFsaWNlIExT LTIgLSZndDsgUHJvY2VzcyBCb2IgTFMtMSAoZGlzY2FyZGVkIGJlY2F1c2UgMSZsdDsyKTxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQg dGhhdD88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkJlc3QgcmVnYXJkcyEh PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE2LTA3LTE0IDE3OjQ5IEdNVCYjNDM7 MDI6MDAgQ2hyaXN0ZXIgSG9sbWJlcmcgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0Ozxh IGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozwvc3Bh bj46PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTFwdCIgY2xhc3M9IiI+SGksPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWW91IGRvbid0IG5lZWQgYSBjb21tb24gbG9naWMu IFlvdSBjYW4gZGVmaW5lIGFuIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sIChlLmcuIENMVUUp IHRvIGRlZmluZS9jb25maWd1cmUvbmVnb3RpYXRlIHRoZXNlIGtpbmQgb2YgdGhpbmdzLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KQ2hyaXN0ZXI8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTZW50IGZyb20gbXkg V2luZG93cyBQaG9uZTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxo ciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 Zm9udC1zaXplOjExcHQ7Zm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+RnJvbToNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0 IiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPlN1aGFzIE5hbmRha3VtYXI8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEx cHQ7Zm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0IiBjbGFzcz0iIj7i gI4xNC/igI4wNy/igI4yMDE2IDE4OjQzPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHQ7Zm9udC13ZWln aHQ6Ym9sZCIgY2xhc3M9IiI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTFwdCIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi PkNocmlzdGVyIEhvbG1iZXJnPC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0O2ZvbnQtd2VpZ2h0 OmJvbGQiIGNsYXNzPSIiPkNjOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHQiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpp YmNAYWxpYXgubmV0IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ScOxYWtpIEJheiBDYXN0aWxs bzwvYT47DQo8YSBocmVmPSJtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+Sm9uYXRoYW4gTGVubm94PC9hPjsNCjxhIGhyZWY9Im1haWx0bzptbXVzaWNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tbXVzaWM8L2E+OyA8YSBocmVmPSJt YWlsdG86YXZ0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpJRVRGIEFWVENv cmUgV0c8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHQ7Zm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9 IiI+U3ViamVjdDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZToxMXB0IiBjbGFzcz0iIj5SZTogW01NVVNJQ10gW0FWVENPUkVdIEJV TkRMRTogYSBzaW5nbGUgc3RyZWFtIHdpdGggbXVsdGlwbGUgTUlEcz88L3NwYW4+PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPk9uIFRodSwgSnVsIDE0LCAyMDE2IGF0IDM6MjcgUE0sIENocmlzdGVyIEhvbG1i ZXJnIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyIGNs YXNzPSIiPg0KJmd0Oy4uLjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPiZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7VGhlIGN1cnJlbnQgcHJvcG9zYWwgYnJlYWtzIHRoYXQuIFBsZWFzZSBsZXQn cyBNSUQgdG8gYmUgYSBzaW5nbGUsPGJyIGNsYXNzPSIiPg0KJmd0O3VuaXF1ZSBhbmQgbWFuZGF0 b3J5IGF0dHJpYnV0ZSBwZXIgbS1saW5lLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjwvc3Bhbj7FoGFuZCBsZXQgZWFjaCBSVFAgcGFja2V0IGJlIGFzc29jaWF0 ZWQgd2l0aCBvbmUsIGFuZCBvbmx5IG9uZSwgb2YgdGhvc2U8YnIgY2xhc3M9IiI+DQpNSURzL20t bGluZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KWW91IGNh biB0aGVuIGhhdmUgYXBwbGljYXRpb24gbG9naWMgc2F5aW5nIGUuZy4gwrNJZiBubyDFkmxvdWRl c3Qtc3BlYWtlcsK5PGJyIGNsYXNzPSIiPg0KbWVkaWEgaXMgcmVjZWl2ZWQsIHRoZW4gZHVwbGlj YXRlIHRoZSDFkmJvc3PCuSBtZWRpYSBvbiB0aGUgc2NyZWVuPGJyIGNsYXNzPSIiPg0KYXNzb2Np YXRlZCB3aXRoIHRoZSBsb3VkZXN0IHNwZWFrZXLCsi4gSXTCuXMgbXVjaCBtb3JlIGZsZXhpYmxl LCBhbmQgd2l0aG91dDxiciBjbGFzcz0iIj4NCmFueSBvZiB0aGUgY29uc3RyYWludHMgbWVudGlv bmVkIGVhcmxpZXIuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBhZ3Jl ZSBpdCBicmluZ3MgaW4gZmxleGliaWxpdHkgYW5kIGl0IHNjYXJlcyBtZSBhIGJpdCBhcyB3ZWxs IC4uIEVhY2ggYXBwbGljYXRpb24gbmVlZHMgdG8gZGVmaW5lIHRoZWlyIG93biBsb2dpYyBvciBu ZWVkIGEgY29tbW9uIGxvZ2ljIGFjcm9zcyBhbGwgYXBwbGljYXRpb25zIC4uPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KPGJyIGNsYXNzPSIiPg0KUmVnYXJkcyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpDaHJpc3RlcjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNz PSIiPg0KbW11c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpt bXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbW11c2ljIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48 YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNz PSIiPg0KbW11c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpt bXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsZWFyPSJhbGwiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNz PSIiPg0KPGRpdiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIiBjbGFzcz0iIj4NCjxk aXYgZGlyPSJsdHIiIGNsYXNzPSIiPk1pZ3VlbCBQYXLDrXMgRMOtYXo8YnIgY2xhc3M9IiI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpDb21wdXRlci9Tb2Z0d2FyZSBlbmdpbmVlci48 YnIgY2xhc3M9IiI+DQpSZXNlYXJjaGVyIGFuZCBhcmNoaXRlY3QgaW4gPGEgaHJlZj0iaHR0cDov L3d3dy5rdXJlbnRvLm9yZy8iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCmh0dHA6Ly93d3cu a3VyZW50by5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3R3aXR0ZXIuY29t L21wYXJpc2RpYXoiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwOi8vdHdpdHRlci5jb20v bXBhcmlzZGlhejwvYT48YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xlYXI9ImFsbCIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQotLSA8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiIGRhdGEt c21hcnRtYWlsPSJnbWFpbF9zaWduYXR1cmUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+TWln dWVsIFBhcsOtcyBEw61hejxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0i Ij4NCkNvbXB1dGVyL1NvZnR3YXJlIGVuZ2luZWVyLjxiciBjbGFzcz0iIj4NClJlc2VhcmNoZXIg YW5kIGFyY2hpdGVjdCBpbiA8YSBocmVmPSJodHRwOi8vd3d3Lmt1cmVudG8ub3JnLyIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cDovL3d3dy5rdXJlbnRvLm9yZzwvYT48YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vbXBhcmlzZGlheiIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPmh0dHA6Ly90d2l0dGVyLmNvbS9tcGFyaXNkaWF6PC9hPjxiciBjbGFzcz0i Ij4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_B01B64DDF99D4876A545D608068ADE3Dvidyocom_-- From nobody Tue Jul 26 00:22:54 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B5912D181 for ; Tue, 26 Jul 2016 00:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPqLbGgB-Yd2 for ; Tue, 26 Jul 2016 00:22:52 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CD712B014 for ; Tue, 26 Jul 2016 00:22:51 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 4D7DF4281; Tue, 26 Jul 2016 09:22:49 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2016 09:22:48 +0200 Message-Id: <01BF2AA0-A652-4D77-BC34-F51AA4179F19@edvina.net> To: mmusic@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [MMUSIC] ICEbis: Happy ICE balls X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 07:22:54 -0000 https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-10#page-19 " : is taken from RFC 4566 [RFC4566 ]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value -- the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=3Dcandidate attribute, the FQDN is looked up in the DNS first using an AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing.=E2=80=9D After realising that STUNbis may lead to happy stunballs issues, I = checked ICEbis, and see one clearly here. If there=E2=80=99s a FQDN in the candidates, doing = AAAA first and then A is against all current advice on Happy Eyeballs-like = situations. This has to be configurable and propably there needs to be two probes, one for each = address and not in serial mode. IPv4 only clients lookup A, IPv6 only agents lookup AAAA and dual stack = clients needs to look up A and AAAA - not just AAAA. /O From nobody Tue Jul 26 06:35:54 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D678A12DDC1; Tue, 26 Jul 2016 06:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8EDudbEpMHu; Tue, 26 Jul 2016 06:35:47 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BA812DCAB; Tue, 26 Jul 2016 06:18:07 -0700 (PDT) X-AuditID: c1b4fb25-703ff70000000bbb-f0-5797630d44ca Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id CA.8B.03003.D0367975; Tue, 26 Jul 2016 15:18:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.208]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0301.000; Tue, 26 Jul 2016 15:18:04 +0200 From: Christer Holmberg To: Mirja Kuehlewind , The IESG Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mmusic-mux-exclusive-09:_(with_COMMENT)?= Thread-Index: AQHR5oXUdmY3ZrAWz0ucUbQzbONunKAqrPng Date: Tue, 26 Jul 2016 13:18:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476E65EC@ESESSMB209.ericsson.se> References: <20160725150421.11530.97108.idtracker@ietfa.amsl.com> In-Reply-To: <20160725150421.11530.97108.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7hy5f8vRwg2vbuSwubz3FavH+gq7F jD8TmS1eXP/IbHF+53omi6nLH7M4sHlM+b2R1WPJkp9MHi0fF7IGMEdx2aSk5mSWpRbp2yVw Zaz928lU8EC6omP1ZsYGxhbpLkYODgkBE4nndzi6GLk4hATWM0qsPnCfGcJZwigxd/cOVpAi NgELie5/2iCmiICLxOyvnCAlzAK9TBLTJu1kB3GEBXoYJe6+f8IK4ogI9DJKnFnZx9jFyAnk GEm8e/mFCcRmEVCV+LfvG5jNK+ArMfvsHTYQW0jAUeLp75vsIDangJPE7S8drCA2o4CYxPdT a8DqmQXEJW49mQ9mSwgISCzZc54ZwhaVePn4HyuErSSx9vB2FpBLmQU0Jdbv0odoVZSY0v2Q HWKtoMTJmU9YJjCKzkIydRZCxywkHbOQdCxgZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJ ERhVB7f8Vt3BePmN4yFGAQ5GJR7eBcHTwoVYE8uKK3MPMUpwMCuJ8IYmTg8X4k1JrKxKLcqP LyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwJjGt8dFsJ1rDl/FjiW+SctU 5vam6n/X4v5366AId8p2/xMvW2J+KH8M1vvqVXf5kXzjqxAdubhLf0//WcM1L0nmIp//mQ1T V9UKPN1in7XHYtIs/ilXZUNWc3ereZZY/lgQ/4KrcIOn08XDgRaeWS4fr+V+M9macmKxi7re uTVGytNLz05V+KLEUpyRaKjFXFScCABpm4M2pgIAAA== Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-mux-exclusive@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-mmusic-mux-exclusive-09=3A_=28with_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 13:35:53 -0000 SGkgTWlyamEsDQoNClRoYW5rcyBmb3IgWW91ciBjb21tZW50cyEgUGxlYXNlIHNlZSBpbmxpbmUu DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClF1aWNrIHF1ZXN0 aW9uOiANCj4gTXkgaW5pdGlhbCB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IG5ld2VyIHN5c3RlbXMg dXN1YWxseSBzdXBwb3J0IFJUUC9SVENQIG11bHRpcGxleGluZywgd2hpbGUNCj4gb2xkZXIgc3lz dGVtcyB0aGF0IGRvIG5vdCBzdXBwb3J0IFJUUC9SVENQIG11bHRpcGxleGluZyB3aWxsIGFsc28g bm90IGJlIGFibGUgdG8gdW5kZXJzdGFuZCB0aGlzIA0KPiBuZXcgYXR0cmlidXRlLiAgU28gSSBn dWVzcyB0aGF0J3Mgbm90IHRoZSB1c2UgY2FzZS4gVGhhdCBtZWFucyB0aGUgdXNlIGNhc2UgaWYg Zm9yIG5ld2VyIHN5c3RlbSB0aGF0IA0KPiBkbyBrbm93IGFib3V0ICBSVFAvUlRDUCBtdWx0aXBs ZXhpbmcgYXMgd2VsbCBhcyB0aGUgJ3J0Y3AtbXV4LW9ubHknIGF0dHJpYnV0ZSBidXQgZG9uJ3Qg c3VwcG9ydCBpdCANCj4gZm9yIHNvbWUgcmVhc29uLiBXaGF0IGFyZSB0aGVzZSByZWFzb25zPyBN YXliZSB5b3UgY2FuIHByb3ZpZGUgc29tZSBtb3JlIGJhY2tncm91bmQgYWJvdXQgdGhlIA0KPiBp bnRlbmRlZCB1c2FnZSBoZXJlIQ0KDQpUaGVyZSBhcmUgbmV3ZXIgc3lzdGVtcyB0aGF0IE9OTFkg c3VwcG9ydCBSVFAvUlRDUCBtdWx0aXBsZXhpbmcgLSB3aXRob3V0IGJlaW5nIGFibGUgdG8gZmFs bCBiYWNrIHRvIG5vbi1tdXguIEhvd2V2ZXIsIHRoZSBleGlzdGluZyBTRFAgYXR0cmlidXRlIHRv IGluZGljYXRlIHN1cHBvcnQgb2YgUlRQL1JUQ1AgbXVsdGlwbGV4aW5nIG1hbmRhdGVzIHRoZSBz ZW5kZXIgdG8gYmUgYWJsZSB0byBmYWxsIGJhY2sgdG8gbm9uLW11eC4gVGhlIG5ldyBTRFAgYXR0 cmlidXRlIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCB5b3UgY2FuIGRvIFJUUC9SVENQIG11bHRp cGxleGluZyBPTkxZLg0KDQpPbmUgcmVhc29uIHdoeSB0aGUgcmVjZWl2ZXIgbWF5IHN1cHBvcnQg bXV4LCBidXQgcHJlZmVycyB0byBkbyBub24tbXV4IGlzIGJlY2F1c2UgaXQgaXMgY29ubmVjdGVk IHRvIGEgcmFkaW8gaW50ZXJmYWNlIGFuZCB3YW50cyB0byB1c2UgZGlmZmVyZW50IGJlYXJlcnMg KHBvc3NpYmxlIHdpdGggZGlmZmVyZW50IHF1YWxpdHkgY2hhcmFjdGVyaXN0aWNzKSBmb3IgUlRQ IGFuZCBSVENQLg0KDQpBbm90aGVyIHJlYXNvbiBpcyBpZiB0aGUgcmVjZWl2ZXIgaXMgYSBnYXRl d2F5IGNvbm5lY3RlZCB0byBhIG5ldHdvcmsgd2hlcmUgUlRQL1JUQ1AgbXVsdGlwbGV4aW5nIGlz IG5vdCB1c2VkLiBJbiBzdWNoIGNhc2UgdGhlIGdhdGV3YXkgbWF5IHByZWZlciB0byBub3QgdXNl IFJUUC9SVENQIG11eCBvbiBlaXRoZXIgInNpZGUiLiBPdGhlcndpc2UgaXQgd291bGQgaGF2ZSB0 byBwZXJmb3JtIFJUUC9SVENQIGRlbXV4aW5nIChiZXR3ZWVuIHRoZSBlbmRwb2ludCB0aGF0IHVz ZXMgbXV4IGFuZCB0aGUgZW5kcG9pbnQgdGhhdCBkb2Vzbid0KS4NCg0KQW5vdGhlciByZWFzb24g aXMgaWYgYSBkZXZpY2Ugd2lzaGVzIHRvIGhhbmRsZSBSVFAgYW5kIFJUQ1Agb24gZGlmZmVyZW50 IGludGVyZmFjZXMvZGV2aWNlcy4NCg0KDQpNaW5vcjogDQo+IFNvbWUgc2VudGVuY2VzIGFyZSBh IGxpdHRsZSBoYXJkIHRvIHBoYXJzZSBhcyB0aGV5IGFyZSBxdWl0ZSBsb25nLCBlLmcuDQo+DQo+ IE9MRDoNCj4gICAiV2hlbiBhbiBvZmZlcmVyIHNlbmRzIHRoZSBpbml0aWFsIG9mZmVyLCBpZiB0 aGUgb2ZmZXJlciB3YW50cyB0bw0KPiAgIGluZGljYXRlIGV4Y2x1c2l2ZSBSVFAvUlRDUCBtdWx0 aXBsZXhpbmcgZm9yIFJUUC1iYXNlZCBtZWRpYSwgdGhlDQo+ICAgb2ZmZXJlciBNVVNUIGFzc29j aWF0ZSBhbiBTRFAgJ3J0Y3AtbXV4LW9ubHknIGF0dHJpYnV0ZSB3aXRoIHRoZQ0KPiAgIGFzc29j aWF0ZWQgU0RQIG1lZGlhIGRlc2NyaXB0aW9uICgibT0iIGxpbmUpLiINCj4NCj4gTUFZQkU6DQo+ ICAgIklmIHRoZSBvZmZlcmVyIHdhbnRzIHRvIGluZGljYXRlIGV4Y2x1c2l2ZSBSVFAvUlRDUCBt dWx0aXBsZXhpbmcgZm9yIFJUUC1iYXNlZCBtZWRpYSwgdGhlDQo+ICAgb2ZmZXJlciBNVVNUIHNl bmQgdGhlIGluaXRpYWwgb2ZmZXIgd2l0aCBhbiBhc3NvY2lhdGVkIFNEUCAncnRjcC1tdXgtb25s eScgYXR0cmlidXRlIGFuZCB0aGUNCj4gICBhc3NvY2lhdGVkIFNEUCBtZWRpYSBkZXNjcmlwdGlv biAoIm09IiBsaW5lKS4iDQoNCkkgZG9uJ3QgaGF2ZSBhbnl0aGluZyB0aGUgc3VnZ2VzdGVkIG5l dyB0ZXh0IChJIGFzc3VtZSB5b3UgbWVhbnQgImF0dHJpYnV0ZSAqaW4qIHRoZSBhc3NvY2lhdGVk Li4uIikgYXMgc3VjaCwgYnV0IGFzIHRoZSBvcmlnaW5hbCB0ZXh0IGZvbGxvd3MgdGhlIHN0cnVj dHVyZSBJJ3ZlIGFsc28gdXNlZCBpbiBvdGhlciBkcmFmdHMgSSdkIGxpa2UgdG8ga2VlcCBpdCA6 KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Tue Jul 26 06:56:39 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803D612DD44 for ; Tue, 26 Jul 2016 06:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy-1uQtd31WM for ; Tue, 26 Jul 2016 06:56:30 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB06712DE2D for ; Tue, 26 Jul 2016 06:45:29 -0700 (PDT) Received: (qmail 22343 invoked from network); 26 Jul 2016 15:45:27 +0200 Received: from p5dec2f79.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.121) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 26 Jul 2016 15:45:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476E65EC@ESESSMB209.ericsson.se> Date: Tue, 26 Jul 2016 15:45:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FD87D38-D416-4A10-90E1-C156D4FB8E5D@kuehlewind.net> References: <20160725150421.11530.97108.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B476E65EC@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-mmusic-mux-exclusive-09=3A_=28with_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 13:56:32 -0000 Hi Christer, see below. > Am 26.07.2016 um 15:18 schrieb Christer Holmberg = : >=20 > Hi Mirja, >=20 > Thanks for Your comments! Please see inline. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Quick question:=20 >> My initial understanding was that newer systems usually support = RTP/RTCP multiplexing, while >> older systems that do not support RTP/RTCP multiplexing will also not = be able to understand this=20 >> new attribute. So I guess that's not the use case. That means the = use case if for newer system that=20 >> do know about RTP/RTCP multiplexing as well as the 'rtcp-mux-only' = attribute but don't support it=20 >> for some reason. What are these reasons? Maybe you can provide some = more background about the=20 >> intended usage here! >=20 > There are newer systems that ONLY support RTP/RTCP multiplexing - = without being able to fall back to non-mux. However, the existing SDP = attribute to indicate support of RTP/RTCP multiplexing mandates the = sender to be able to fall back to non-mux. The new SDP attribute is used = to indicate that you can do RTP/RTCP multiplexing ONLY. >=20 > One reason why the receiver may support mux, but prefers to do non-mux = is because it is connected to a radio interface and wants to use = different bearers (possible with different quality characteristics) for = RTP and RTCP. >=20 > Another reason is if the receiver is a gateway connected to a network = where RTP/RTCP multiplexing is not used. In such case the gateway may = prefer to not use RTP/RTCP mux on either "side". Otherwise it would have = to perform RTP/RTCP demuxing (between the endpoint that uses mux and the = endpoint that doesn't). >=20 > Another reason is if a device wishes to handle RTP and RTCP on = different interfaces/devices. Okay, now makes sense. Maybe add these examples to the draft? >=20 >=20 > Minor:=20 >> Some sentences are a little hard to pharse as they are quite long, = e.g. >>=20 >> OLD: >> "When an offerer sends the initial offer, if the offerer wants to >> indicate exclusive RTP/RTCP multiplexing for RTP-based media, the >> offerer MUST associate an SDP 'rtcp-mux-only' attribute with the >> associated SDP media description ("m=3D" line)." >>=20 >> MAYBE: >> "If the offerer wants to indicate exclusive RTP/RTCP multiplexing = for RTP-based media, the >> offerer MUST send the initial offer with an associated SDP = 'rtcp-mux-only' attribute and the >> associated SDP media description ("m=3D" line)." >=20 > I don't have anything the suggested new text (I assume you meant = "attribute *in* the associated...") as such, but as the original text = follows the structure I've also used in other drafts I'd like to keep it = :) Yes, I=E2=80=99ve seen this construct a couple of time in the doc and I = found it always hard to read. It=E2=80=99s on you, however, improving = readability is usually a win. Mirja >=20 > Regards, >=20 > Christer >=20 From nobody Wed Jul 27 10:43:18 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A68812D0CD; Wed, 27 Jul 2016 10:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYGfZG33F0Ay; Wed, 27 Jul 2016 10:43:15 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797C112D744; Wed, 27 Jul 2016 10:36:51 -0700 (PDT) X-AuditID: c1b4fb2d-54bff70000000eb1-a5-5798f131f33a Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 6C.17.03761.131F8975; Wed, 27 Jul 2016 19:36:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.208]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0301.000; Wed, 27 Jul 2016 19:36:48 +0200 From: Christer Holmberg To: "Mirja Kuehlewind (IETF)" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mmusic-mux-exclusive-09:_(with_COMMENT)?= Thread-Index: AQHR5oXUdmY3ZrAWz0ucUbQzbONunKAqrPng///sYQCAAfPZAA== Date: Wed, 27 Jul 2016 17:36:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476E8526@ESESSMB209.ericsson.se> References: <20160725150421.11530.97108.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B476E65EC@ESESSMB209.ericsson.se> <8FD87D38-D416-4A10-90E1-C156D4FB8E5D@kuehlewind.net> In-Reply-To: <8FD87D38-D416-4A10-90E1-C156D4FB8E5D@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7oq7hxxnhBhsWmFpc3nqK1eL9BV2L GX8mMlu8uP6R2eL8zvVMFlOXP2ZxYPOY8nsjq8eSJT+ZPFo+LmQNYI7isklJzcksSy3St0vg yri9Yzl7wTaeiqN/uxgbGHt4uhg5OSQETCSub2lhA7GFBNYzSlyaINbFyAVkL2GU+Hipl7GL kYODTcBCovufNkiNiICxxOHJ31lBapgF/jFKXJt0A8wRFuhhlLj7/gmYIyLQyyhxZmUfI0SL k0TLrGlgK1gEVCV+dbWwgti8Ar4SZ+bOZoZYt5dR4sSLbWAJTqCG/t3XWUBsRgExie+n1jCB 2MwC4hK3nsxngrhbQGLJnvPMELaoxMvH/1ghbCWJFdsvgZ3NLKApsX6XPkSrosSU7ofsEHsF JU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwMg6 uOW37g7G1a8dDzEKcDAq8fAm3J0eLsSaWFZcmXuIUYKDWUmEt+HFjHAh3pTEyqrUovz4otKc 1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjIzx3be0fyZbT+iuYrdR5nx3TPxD +ZcnhdufOM3Yn2JZyt/q39R5/OaxqaYTX1x5nfOl2NmhcfKm6+WXDf44/WzlOJD449F/nq6j OQqL23fI2lj+PV9rJPsgqOatJJNppfrEY9eq7f5OvDA7asLvVbmZcdm6CiIaMcss0y+yJTGu /lD6fVYDpxJLcUaioRZzUXEiAMhgh8eoAgAA Archived-At: Cc: "fandreas@cisco.com" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG , "draft-ietf-mmusic-mux-exclusive@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-mmusic-mux-exclusive-09=3A_=28with_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 17:43:17 -0000 SGkgTWlyamEsDQoNCi4uLg0KDQo+PiBUaGVyZSBhcmUgbmV3ZXIgc3lzdGVtcyB0aGF0IE9OTFkg c3VwcG9ydCBSVFAvUlRDUCBtdWx0aXBsZXhpbmcgLSB3aXRob3V0IGJlaW5nIA0KPj4gYWJsZSB0 byBmYWxsIGJhY2sgdG8gbm9uLW11eC4gSG93ZXZlciwgdGhlIGV4aXN0aW5nIFNEUCBhdHRyaWJ1 dGUgdG8gaW5kaWNhdGUgc3VwcG9ydCANCj4+IG9mIFJUUC9SVENQIG11bHRpcGxleGluZyBtYW5k YXRlcyB0aGUgc2VuZGVyIHRvIGJlIGFibGUgdG8gZmFsbCBiYWNrIHRvIG5vbi1tdXguIA0KPj4g VGhlIG5ldyBTRFAgYXR0cmlidXRlIGlzIHVzZWQgdG8gaW5kaWNhdGUgdGhhdCB5b3UgY2FuIGRv IFJUUC9SVENQIG11bHRpcGxleGluZyBPTkxZLg0KPj4gDQo+PiBPbmUgcmVhc29uIHdoeSB0aGUg cmVjZWl2ZXIgbWF5IHN1cHBvcnQgbXV4LCBidXQgcHJlZmVycyB0byBkbyBub24tbXV4IGlzIGJl Y2F1c2UgaXQNCj4+IGlzIGNvbm5lY3RlZCB0byBhIHJhZGlvIGludGVyZmFjZSBhbmQgd2FudHMg dG8gdXNlIGRpZmZlcmVudCBiZWFyZXJzIChwb3NzaWJsZSB3aXRoIGRpZmZlcmVudCANCj4+IHF1 YWxpdHkgY2hhcmFjdGVyaXN0aWNzKSBmb3IgUlRQIGFuZCBSVENQLg0KPj4gDQo+PiBBbm90aGVy IHJlYXNvbiBpcyBpZiB0aGUgcmVjZWl2ZXIgaXMgYSBnYXRld2F5IGNvbm5lY3RlZCB0byBhIG5l dHdvcmsgd2hlcmUgUlRQL1JUQ1AgDQo+PiBtdWx0aXBsZXhpbmcgaXMgbm90IHVzZWQuIEluIHN1 Y2ggY2FzZSB0aGUgZ2F0ZXdheSBtYXkgcHJlZmVyIHRvIG5vdCB1c2UgUlRQL1JUQ1AgbXV4IG9u DQo+PiBlaXRoZXIgInNpZGUiLiBPdGhlcndpc2UgaXQgd291bGQgaGF2ZSB0byBwZXJmb3JtIFJU UC9SVENQIGRlbXV4aW5nIChiZXR3ZWVuIHRoZSANCj4+IGVuZHBvaW50IHRoYXQgdXNlcyBtdXgg YW5kIHRoZSBlbmRwb2ludCB0aGF0IGRvZXNuJ3QpLg0KPj4gDQo+PiBBbm90aGVyIHJlYXNvbiBp cyBpZiBhIGRldmljZSB3aXNoZXMgdG8gaGFuZGxlIFJUUCBhbmQgUlRDUCBvbiBkaWZmZXJlbnQg aW50ZXJmYWNlcy9kZXZpY2VzLg0KPg0KPiBPa2F5LCBub3cgbWFrZXMgc2Vuc2UuIE1heWJlIGFk ZCB0aGVzZSBleGFtcGxlcyB0byB0aGUgZHJhZnQ/DQoNCkkgY2FuIGRvIHRoYXQuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Fri Jul 29 18:27:38 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F376812D5B7 for ; Fri, 29 Jul 2016 18:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 T3arHhI8ap9Q for ; Fri, 29 Jul 2016 18:27:26 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8993712D66A for ; Fri, 29 Jul 2016 18:27:24 -0700 (PDT) X-AuditID: c1b4fb25-6efff70000000bbb-e0-579c02792db5 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 66.82.03003.9720C975; Sat, 30 Jul 2016 03:27:22 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 30 Jul 2016 03:27:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2zfNH54JQ+mZCrrBJhoUr7SMwBPwqme9YN1+U6cIvg4=; b=Qm9vQb6p/IXvkNX3FWdOWHl2oMvDYJG6pj+zy6v/wTcX15zYZOmE0mXmmF9tSH/ItO4INXHtw4s6NKDB+poZ+RvBx9AJ/OKcoJNhJ0yEJaTzWqcqn1SD6wXQ+ABOEFAocKTJFu2/n3NxrKCddDg8HR61e/GjqISmX2T35jXhtac= Received: from AM3PR07MB1188.eurprd07.prod.outlook.com (10.163.188.26) by AM3PR07MB1187.eurprd07.prod.outlook.com (10.163.188.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sat, 30 Jul 2016 01:27:18 +0000 Received: from AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::943a:806b:3daa:440e]) by AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::943a:806b:3daa:440e%14]) with mapi id 15.01.0549.016; Sat, 30 Jul 2016 01:27:18 +0000 From: Bo Burman To: "mmusic (mmusic@ietf.org)" Thread-Topic: Minutes for MMUSIC WG session in Berlin (IETF96) Thread-Index: AdHqAU64f0vVMtNxR5qjY2bItSVvsg== Date: Sat, 30 Jul 2016 01:27:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [83.209.206.189] x-ms-office365-filtering-correlation-id: fa0880cc-c1d5-41e0-fd0f-08d3b818a582 x-microsoft-exchange-diagnostics: 1; AM3PR07MB1187; 6:JegbT2qVvW4hewo9Mf6nCvtxyigSMWSS+pZPepxaTq+p2rSwJ+wiX+L6T9TfZmP3N6+WRognD8QRZXYvOObbJ8PulG5Ly/z9cGgifnP0rG0NZx06xNUQCZGmSWDZfy4gIT87LqI/OBHWpgHA7R+Zz1eliGDxnWyereKVmJyViTiEGJVbV0IyyLmZMpgXsdi8r3mxYO/SCwoCAgxq7JfdsQtasg3tYa6M8ZIqVDjKhn2e3fi2GHNg30hWixYqAS+JC8RczmVkR+utrI2KbtpXPgaglRrGIi8IoEiHNlPyF64=; 5:y2T+h/P8a6smu0MXx7m06XKboOB4VWmUto5Ydz59kRPHSCJKL5dA/Jy1nfnu09EFd58yCgseao+rVQYb6Xr1PNqVse8YMlM3jPkLBCtdTWFu0dJ6x8dW+jOL1I8Pwi6Go06Nf2Rhng3v8htj72DMmw==; 24:I+xs6mZ5LPKkGwRE8lxRLg0Evcwnyr+NT6LvKVeEThXJnpL/4+GLfJke950F3uSxn99GM0hSELCUjXZPHPnY5FN+lj2aBWcVXqUFfsc4lds=; 7:xesb+nbk9CDo5BzuBoRfrnLisYdJO46VOHy4bwjodK9N5rgQtQespSoh3lSLJeuKyTZiNgn/zQ/lj8fAl1JioIiAiTP4NeROz7p544PrqbgijwdTfAO9gt5nF1FDMYdOk3dS2rm7okHjjjOAacE7P0KdB+6fs5/LzxM30RHx7PDfMM93utcrlCDhNHXpfNNa1LM2yQcsihrte7HgARWLqxP3RmUnABvtwsQahZGfHPIpUyqomI+DuvI6pIh5I85T x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB1187; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM3PR07MB1187; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1187; x-forefront-prvs: 001968DD50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(68736007)(6116002)(3846002)(107886002)(586003)(2900100001)(11100500001)(9686002)(5250100002)(81166006)(92566002)(105586002)(7696003)(8936002)(189998001)(558084003)(110136002)(97736004)(7846002)(19300405004)(16236675004)(8676002)(7906003)(102836003)(5002640100001)(7736002)(15975445007)(74316002)(790700001)(81156014)(33656002)(19580395003)(76576001)(450100001)(229853001)(87936001)(3280700002)(3660700001)(19625215002)(66066001)(101416001)(2906002)(19617315012)(106356001)(50986999)(54356999)(86362001)(19609705001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1187; H:AM3PR07MB1188.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB11882CD14A21C6D297EE6EF78D020AM3PR07MB1188eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2016 01:27:18.3281 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1187 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUyM2K7vW4V05xwg/XbbSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujANP1rAWtElXXFnbwtzA2CPRxcjJISFgInHk/07mLkYuDiGB 9YwSFyYsYINwTjBKzHw4ASzDItDLLNGwZAsjRGYak8SfviPsEM5jRomtt9ayggxjE9CQmL/j LiOILSJgIDF75QwwW1jAUuLsngssXYwcQHE7iUvLgiFK9CSuzVrGDmKzCKhKPD79AczmFYiR OPbmF5jNKCAm8f3UGiYQm1lAXOLWk/lMEHcLSCzZc54ZwhaVePn4HytEfaTE5Iln2SHiShJ7 /rdA2b4S1y/MBntAQuAdm8Szk7cZIRJuEs/WfWYCuU1CIFtiw0+oeiuJjonHWSHqgeHSt2Qe G0RCRqL/xAEmiMR1Vomu+xvABgkJpEosX9sK9bCUxN0rnVC2jMSLO3tZIT7Il2g5vokN4ktB iZMzn7BMYFSbheS5WUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtTi5Ny 042M9VKLMpOLi/Pz9PJSSzYxApPNwS2/VXcwXn7jeIhRgINRiYd3wczZ4UKsiWXFlbmHGCU4 mJVEeMv+AYV4UxIrq1KL8uOLSnNSiw8xSnOwKInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUw Cj45MJvFft+VaV1Z7KuXbQyek9DYyXuPU0CGJatnht52aes/F4IbnzoqKTX/+XbZ7LungpLf Ab2oindWi6+7GDYarPt/KPyL+4urpSY8uybWBZxtE9g7LSvp74r2h2ZqHYu4at6dbLXfYMnb VbZabOPunR8vSIeF8G625Vgi+CAn6GKM9kUFJZbijERDLeai4kQAzJFeeDIDAAA= Archived-At: Subject: [MMUSIC] Minutes for MMUSIC WG session in Berlin (IETF96) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 01:27:30 -0000 --_000_AM3PR07MB11882CD14A21C6D297EE6EF78D020AM3PR07MB1188eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MMUSIC, The initial version of the minutes have been uploaded. Please review and pr= ovide feedback: https://www.ietf.org/proceedings/96/minutes/minutes-96-mmusic Thanks Bo Burman MMUSIC Co-chair --_000_AM3PR07MB11882CD14A21C6D297EE6EF78D020AM3PR07MB1188eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MMUSIC,

 

The initial version of the minutes have been uplo= aded. Please review and provide feedback:

 

https://www.ietf.org/proceedings/96/minutes/minute= s-96-mmusic

 

Thanks

 

Bo Burman

MMUSIC Co-chair

 

--_000_AM3PR07MB11882CD14A21C6D297EE6EF78D020AM3PR07MB1188eurp_-- From nobody Fri Jul 29 23:19:07 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDFC12B047 for ; Fri, 29 Jul 2016 23:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyaMK9Z-48ZY for ; Fri, 29 Jul 2016 23:19:04 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD1A12B029 for ; Fri, 29 Jul 2016 23:19:03 -0700 (PDT) X-Halon-ID: 7c777fc7-561d-11e6-be7b-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.67.72.88]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 30 Jul 2016 08:18:52 +0200 (CEST) To: "mmusic (E-mail)" From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Sat, 30 Jul 2016 08:18:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5D86CD4AB385FB64196FA68F" Archived-At: Subject: [MMUSIC] Media type "image" is missing in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 06:19:06 -0000 This is a multi-part message in MIME format. --------------5D86CD4AB385FB64196FA68F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I noted a small issue in rfc4566bis: In section 5.14 of draft-ietf-mmusic-rfc4566bis-17, a paragraph defining media says: -----------------current text in 5.14------------------------------------ is the media type. Currently defined media are "audio", "video", "text", "application", and "message", although this list may be extended in the future (see Section 8). ------------------------------------------------------------------------------- The "image" media is also defined and should be included in this list. It was registered by RFC 6466. So, the paragraph should read: --------------proposed modified text for 5.14------------------------------ is the media type. Currently defined media are "audio", "video", "text", "application", "message", and "image", although this list may be extended in the future (see Section 8). -------------end of change 1------------------------------------------------------------------- It should also be considered if the fact that "image" is a defined media type should be reflected in section 8.2.1, where it is currently said: " --------------------------current text in 8.2.1------------------------------------------- This memo registers the media types "audio", "video", "text", "application", and "message". ----------------------------------------------------------- The action in section 8.2.1 depends on what the plans are for IANA register of rfc4566bis values, but somehow "image" should be mentioned also in section 8.2.1. If the registration of the other media types for sdp are still regarded as registered by RFC 4566, the sentence is proposed to read: ------------------------Proposed replacement---------------------- Registered media types at the publication of this memo are "audio", "video", "text", "application", "message", and "image". -----------------end of change 2------------------------------------------------- (while if registration of the basic set of media will be regarded to be moved to have been made by rfc4566bis, then another wording is needed.) Regards Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se --------------5D86CD4AB385FB64196FA68F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I noted a small issue in rfc4566bis:

In section 5.14 of draft-ietf-mmusic-rfc4566bis-17, a paragraph defining media says:

-----------------current text in 5.14------------------------------------

<media> is the media type. Currently defined media are "audio", "video", "text", "application", and "message", although this list may be extended in the future (see Section 8).

-------------------------------------------------------------------------------

The "image" media is also defined and should be included in this list. It was registered by RFC 6466.

So, the paragraph should read:

--------------proposed modified text for 5.14------------------------------

<media> is the media type. Currently defined media are "audio", "video", "text", "application", "message", and "image", although this list may be extended in the future (see Section 8).

-------------end of change 1-------------------------------------------------------------------

It should also be considered if the fact that "image" is a defined media type should be reflected in section 8.2.1,  where it is currently said: "

--------------------------current text in 8.2.1-------------------------------------------

   This memo registers the media types "audio", "video", "text",
   "application", and "message".
-----------------------------------------------------------

The action in section 8.2.1 depends on what the plans are for IANA register of rfc4566bis values, but somehow "image" should be mentioned also in section 8.2.1. If the registration of the other media types for sdp are still regarded as registered by RFC 4566, the sentence is proposed to read:

------------------------Proposed replacement----------------------
Registered media types at the publication of this memo are "audio", "video", "text", "application", "message", and "image".
-----------------end of change 2-------------------------------------------------

(while if registration of the basic set of media will be regarded to be moved to have been made by rfc4566bis, then another wording is needed.)

Regards
Gunnar


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
--------------5D86CD4AB385FB64196FA68F-- From nobody Fri Jul 29 23:26:29 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991FC12D50D for ; Fri, 29 Jul 2016 23:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ykRWt9Ca5sfv for ; Fri, 29 Jul 2016 23:26:27 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D06E12D1E4 for ; Fri, 29 Jul 2016 23:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2865; q=dns/txt; s=iport; t=1469859987; x=1471069587; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uNTrYxllsIEoU0cYnw7A0tO72yASLzotpKDtt0Q5nOY=; b=QGf1SknPufjCrpFJlZApRwif5mLeoj0+cNEpa95ZwHiDqcRZAP7NsPtl 7a7fzK96xZUm7RNNhzHg+viGl4XhjQ7V8wak+eFmR2f3kuPxHIYf4Xidc nta9gV2sHB0xcIhTlH65plH4O9XSRkv24B//+J0bIXavH8XKc5+pRe8gk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQALSJxX/5xdJa1dg0VWfAa5CIF9J?= =?us-ascii?q?IUvSgKBKjgUAQEBAQEBAV0nhF4BAQQBAQFsCwULAgEIGC4nCyUCBA4FiCkIDr8?= =?us-ascii?q?cAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoF4CIJNhECDLIISHQWIJJEPAY5+g?= =?us-ascii?q?WuIC4VJjDCDdgEeNoISHIFMbodAfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,443,1464652800"; d="scan'208";a="303755461" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2016 06:26:26 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6U6QQCZ024592 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 30 Jul 2016 06:26:26 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 30 Jul 2016 01:26:25 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Sat, 30 Jul 2016 01:26:25 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: =?Windows-1252?Q?Gunnar_Hellstr=F6m?= Thread-Topic: [MMUSIC] Media type "image" is missing in rfc4566bis Thread-Index: AQHR6ipMMrcdqglcS0KyRBuiR0ztRaAw1hMA Date: Sat, 30 Jul 2016 06:26:25 +0000 Message-ID: <6D6EBF16-373D-4800-8C50-2AB61CD49887@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.242.210] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] Media type "image" is missing in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 06:26:28 -0000 Hi Gunnar -=20 I also noticed this and meant to bring it up as well. I wasn=92t sure whet= her we explicitly add the =91image=92 media type to the text or simply put = a reference to RFC 6466 [or presumably both?]. Thanks, Gonzalo > On Jul 30, 2016, at 2:18 AM, Gunnar Hellstr=F6m wrote: >=20 > I noted a small issue in rfc4566bis: > In section 5.14 of draft-ietf-mmusic-rfc4566bis-17, a paragraph defining = media says: >=20 > -----------------current text in 5.14------------------------------------ > is the media type. Currently defined media are "audio", "video", = "text", "application", and "message", although this list may be extended in= the future (see Section 8). >=20 > -------------------------------------------------------------------------= ------ > The "image" media is also defined and should be included in this list. It= was registered by RFC 6466. >=20 > So, the paragraph should read: >=20 > --------------proposed modified text for 5.14----------------------------= -- > is the media type. Currently defined media are "audio", "video", = "text", "application", "message", and "image", although this list may be ex= tended in the future (see Section 8). >=20 > -------------end of change 1---------------------------------------------= ---------------------- > It should also be considered if the fact that "image" is a defined media = type should be reflected in section 8.2.1, where it is currently said: " >=20 > --------------------------current text in 8.2.1--------------------------= ----------------- > This memo registers the media types "audio", "video", "text", > "application", and "message". > ----------------------------------------------------------- >=20 > The action in section 8.2.1 depends on what the plans are for IANA regist= er of rfc4566bis values, but somehow "image" should be mentioned also in se= ction 8.2.1. If the registration of the other media types for sdp are still= regarded as registered by RFC 4566, the sentence is proposed to read: >=20 > ------------------------Proposed replacement---------------------- > Registered media types at the publication of this memo are "audio", "vide= o", "text", "application", "message", and "image". > -----------------end of change 2-----------------------------------------= -------- >=20 > (while if registration of the basic set of media will be regarded to be m= oved to have been made by rfc4566bis, then another wording is needed.) >=20 > Regards > Gunnar >=20 >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor >=20 > gunnar.hellstrom@omnitor.se > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Jul 29 23:51:23 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26FA12B028 for ; Fri, 29 Jul 2016 23:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZkCW6fEbBpx for ; Fri, 29 Jul 2016 23:51:19 -0700 (PDT) Received: from bin-vsp-out-02.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304A512B01D for ; Fri, 29 Jul 2016 23:51:19 -0700 (PDT) X-Halon-ID: 016622e2-5622-11e6-b8a7-005056917f90 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.67.72.88]) by bin-vsp-out-02.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 30 Jul 2016 08:51:13 +0200 (CEST) To: mmusic@ietf.org References: <6D6EBF16-373D-4800-8C50-2AB61CD49887@cisco.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5a8be354-7fd1-8415-caff-5d532a89928f@omnitor.se> Date: Sat, 30 Jul 2016 08:51:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6D6EBF16-373D-4800-8C50-2AB61CD49887@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] Media type "image" is missing in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2016 06:51:22 -0000 Hi Gonzalo, Den 2016-07-30 kl. 08:26, skrev Gonzalo Salgueiro (gsalguei): > Hi Gunnar - > > I also noticed this and meant to bring it up as well. I wasn’t sure whether we explicitly add the ‘image’ media type to the text or simply put a reference to RFC 6466 [or presumably both?]. GH: The reference to RFC 6466 should be evident in the IANA registry, so I think it is sufficient to mention the 'image' media type among what is registered for use. /Gunnar > > Thanks, > > Gonzalo > > >> On Jul 30, 2016, at 2:18 AM, Gunnar Hellström wrote: >> >> I noted a small issue in rfc4566bis: >> In section 5.14 of draft-ietf-mmusic-rfc4566bis-17, a paragraph defining media says: >> >> -----------------current text in 5.14------------------------------------ >> is the media type. Currently defined media are "audio", "video", "text", "application", and "message", although this list may be extended in the future (see Section 8). >> >> ------------------------------------------------------------------------------- >> The "image" media is also defined and should be included in this list. It was registered by RFC 6466. >> >> So, the paragraph should read: >> >> --------------proposed modified text for 5.14------------------------------ >> is the media type. Currently defined media are "audio", "video", "text", "application", "message", and "image", although this list may be extended in the future (see Section 8). >> >> -------------end of change 1------------------------------------------------------------------- >> It should also be considered if the fact that "image" is a defined media type should be reflected in section 8.2.1, where it is currently said: " >> >> --------------------------current text in 8.2.1------------------------------------------- >> This memo registers the media types "audio", "video", "text", >> "application", and "message". >> ----------------------------------------------------------- >> >> The action in section 8.2.1 depends on what the plans are for IANA register of rfc4566bis values, but somehow "image" should be mentioned also in section 8.2.1. If the registration of the other media types for sdp are still regarded as registered by RFC 4566, the sentence is proposed to read: >> >> ------------------------Proposed replacement---------------------- >> Registered media types at the publication of this memo are "audio", "video", "text", "application", "message", and "image". >> -----------------end of change 2------------------------------------------------- >> >> (while if registration of the basic set of media will be regarded to be moved to have been made by rfc4566bis, then another wording is needed.) >> >> Regards >> Gunnar >> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> >> gunnar.hellstrom@omnitor.se >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Sat Jul 30 23:52:49 2016 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E1C12D567 for ; Sat, 30 Jul 2016 23:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTRj7k6nhPmZ for ; Sat, 30 Jul 2016 23:52:45 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75C012B00C for ; Sat, 30 Jul 2016 23:52:44 -0700 (PDT) X-Halon-ID: 5b164b7e-56eb-11e6-be7b-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [2.64.229.68]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sun, 31 Jul 2016 08:52:32 +0200 (CEST) To: mmusic@ietf.org References: <6D6EBF16-373D-4800-8C50-2AB61CD49887@cisco.com> <5a8be354-7fd1-8415-caff-5d532a89928f@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Sun, 31 Jul 2016 08:52:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5a8be354-7fd1-8415-caff-5d532a89928f@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] Media type "image" is missing in rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 06:52:47 -0000 Den 2016-07-30 kl. 08:51, skrev Gunnar Hellström: > Hi Gonzalo, > Den 2016-07-30 kl. 08:26, skrev Gonzalo Salgueiro (gsalguei): >> Hi Gunnar - >> >> I also noticed this and meant to bring it up as well. I wasn’t sure >> whether we explicitly add the ‘image’ media type to the text or >> simply put a reference to RFC 6466 [or presumably both?]. > GH: The reference to RFC 6466 should be evident in the IANA registry, > so I think it is sufficient to mention the 'image' media type among > what is registered for use. > > /Gunnar >> >> Thanks, >> >> Gonzalo >> >> >>> On Jul 30, 2016, at 2:18 AM, Gunnar Hellström >>> wrote: >>> >>> I noted a small issue in rfc4566bis: >>> In section 5.14 of draft-ietf-mmusic-rfc4566bis-17, a paragraph >>> defining media says: >>> >>> -----------------current text in >>> 5.14------------------------------------ >>> is the media type. Currently defined media are "audio", >>> "video", "text", "application", and "message", although this list >>> may be extended in the future (see Section 8). >>> >>> ------------------------------------------------------------------------------- >>> >>> The "image" media is also defined and should be included in this >>> list. It was registered by RFC 6466. >>> >>> So, the paragraph should read: >>> >>> --------------proposed modified text for >>> 5.14------------------------------ >>> is the media type. Currently defined media are "audio", >>> "video", "text", "application", "message", and "image", although >>> this list may be extended in the future (see Section 8). >>> >>> -------------end of change >>> 1------------------------------------------------------------------- >>> It should also be considered if the fact that "image" is a defined >>> media type should be reflected in section 8.2.1, where it is >>> currently said: " >>> >>> --------------------------current text in >>> 8.2.1------------------------------------------- >>> This memo registers the media types "audio", "video", "text", >>> "application", and "message". >>> ----------------------------------------------------------- >>> >>> The action in section 8.2.1 depends on what the plans are for IANA >>> register of rfc4566bis values, but somehow "image" should be >>> mentioned also in section 8.2.1. If the registration of the other >>> media types for sdp are still regarded as registered by RFC 4566, >>> the sentence is proposed to read: >>> >>> ------------------------Proposed replacement---------------------- >>> Registered media types at the publication of this memo are "audio", >>> "video", "text", "application", "message", and "image". >>> -----------------end of change >>> 2------------------------------------------------- >>> >>> (while if registration of the basic set of media will be regarded to >>> be moved to have been made by rfc4566bis, then another wording is >>> needed.) GH: Also the definition of media in the syntax chapter 9 would preferably be extended to include the complete set of media currently registered, even if it says "typically" ..... >>> >>> Regards >>> Gunnar >>> >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> >>> gunnar.hellstrom@omnitor.se >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se