From nobody Sat Dec 1 04:04:25 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5827E12F1A5 for ; Sat, 1 Dec 2018 04:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 F_0eIuIZ9RBL for ; Sat, 1 Dec 2018 04:04:20 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 3324F12D4F2 for ; Sat, 1 Dec 2018 04:04:20 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id v10so4931412vsv.12 for ; Sat, 01 Dec 2018 04:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=1KHJJelN1KTfrot6EVxBAYJ22i/DRu3mViTCvIIdoWc=; b=0GljII3JhV9jQ55//idF7LeGxkRW1UnE9zIEFcyK/buHoHz07Q8ZwDnK1JjkVNoJeQ KiwcBRrld6M4qRyxYJCew6AQLskXF11ycMVuhB18Y2L38jwoWpXMnzxxHfIRnn4CbL/N KsOci4jMUy3J8Ia5v2CrV81RwkMvCduhABm5kjCqj4xf8+leziAT4Rhj7eNmNc+269pL XLxmcRXgCBiSeOOu+iBCcr3mrykvM5u0/TSnnDcyGf7YsAizZ63sedOPFPjTtl3YO97w 4wRUWYFsuvvFm8Om93k0oYVXiOeVddY7y98HAw/vXYu8XqCTLw6mxTeMxBgsHsQe7l1p qSLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=1KHJJelN1KTfrot6EVxBAYJ22i/DRu3mViTCvIIdoWc=; b=uYzpkS60c5oGlKgd5jXBQrU4O7m9rz0KVPUSgyV1PgZLpbpSAcIVehrPFzI1dkurjG PrlC6mEtmGJsgPmful8FUHCvFzmITwZhOyfinmZP/nKorVXRfFdehx2T/bWBl1tMUrvj XDv9gWHB1I3FSQzRCChvRm3ne+dFIrSYNSYfYrdYqh12LrhDjEsRDaIQpxGkqZPwSi39 vpNrBjh7ZT70EDN+Uypyj5lkpSSK9YXW8aiZM4fm5om8ymfB3l4GdW/OVK/jBdWULeGm ohoJIRajrZYUZ4a+WxvcQD8ll9Q30DKME2y1is+lCmSsdm7BD1C1VTSSBnAbY1B2rZpa AorA== X-Gm-Message-State: AA+aEWatsg0/i0Wu91QoE7Pl8L0Uz5/7qzUA0bt+DxX/rfJlkQUfIi4i jiArRIAohPQmYa5UirW9kQCtVjv+v0L+BAoVgZKFBYPvFCc= X-Google-Smtp-Source: AFSGD/Vz3jd72gaPRyCWp8w4lyG4H9IFuqQROwJg7W9Sra9q04qXYvM3q6JICs4o8lKiiy8HnNIkUrTVvlAJhjrC7M0= X-Received: by 2002:a67:6204:: with SMTP id w4mr4153708vsb.68.1543665858336; Sat, 01 Dec 2018 04:04:18 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 1 Dec 2018 13:04:06 +0100 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2018 12:04:23 -0000 Hi, We are almost in 2019 and, personally, I don't know yet which the proper/standard way for simulcast + RTX is. Clearly, RID must be used to send simulcast so, instead of signaling a=3Dssrc lines in the offer, the offerer signals a=3Drid values for all the simulcast streams. The remote learns the associated SSRC upon receipt of the first RTP packet by matching its RTP RID extension value. This is clearly specified in https://tools.ietf.org/html/draft-ietf-avtext-rid-09 and Firefox does properly implement it. Now, the issue is when adding RTX to simulcast streams. Theoretically (if I'm not wrong) the sender should signal both the a=3Drid of media streams and the a=3Drrid of their associated RTX streams, and then send RTP RID in media RTP packets and RTP RepairedRtpStreamId in RTX RTP packets. NOTE: Not sure about a=3Drrid, I can't find it in any draft. So: Q1: Is there any spec defining the SDP syntax to indicate RepairedRtpStreamId values in the SDP? Q2: Is THIS (RID + RepairedRtpStreamId) the proper way to go for simulcast + RTX? Also, when it comes to receive media with RTX it's clear that WebRTC does not define how to receive simulcast streams for WebRTC clients (browsers), so browsers must receive a single stream plus an optional RTX stream. In this case, as far as a=3Dmid plus RTP MID extension is used (or a=3Dssrc) signaled, there is zero need for RID. However, how is RTX supposed to be signaled in this case? Chrome expects ""a=3Dssrc-group: FID MEDIA_SSRC RTX_SSRC" in the remote SDP to be able to receive an additional RTX stream. Q3: Is this the way to go for receiving a single stream with RTX? --=20 I=C3=B1aki Baz Castillo From nobody Sun Dec 2 07:25:49 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4F9130EC8 for ; Sun, 2 Dec 2018 07:25:47 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9csCBsXRESdP for ; Sun, 2 Dec 2018 07:25:45 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 EB7B212F1AB for ; Sun, 2 Dec 2018 07:25:44 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id x10so9599154wrs.8 for ; Sun, 02 Dec 2018 07:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=W9XTs24D5O7jq61mNgJ4imCi/ydPt8KYPyRSqvvFYPc=; b=pWOE3sxeRGk7yDXfLbm1mgPpSu+K5cJ44sWGqR1etMKZt8ZSPYTO0BUzRH0MO6eT1Q xz9TrzNkNx7qVEArcMISVaKIVZmYig93Lc1AnVZz0ZL7izzooZiJuK866vmxr5IO9SHO iMrzV4TOjrRHATFw8iqujRShjBFFX6vcAstKMugsaMHBvHF/N8SIWKnmee34YLUUcRj9 BddJLSEcDZ0t2AzpjCejdz+rpPwQ7DhPNcgxsXunzKIblPndQi/cqAIujVEEBm/AebrK OlVs5iQVDHMUEOPF8yXhghRexCvHN+yVaSowpSSUQ9jm8yPBehzrbUd78Ee/+6KFiB+I aO3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=W9XTs24D5O7jq61mNgJ4imCi/ydPt8KYPyRSqvvFYPc=; b=XM8uSPw66gH9z+KznREpZPYCUZkx49emv70z5A9qmH5aW5H8gGJCL4B3hEJR3ae12l pOW9cooiqpavHmg6Q6J1Rlz/ONjLcaaxqG6C4iGZkZehuPcyn3r1q1EubhHK6ISSrH/S lSjcfaPfmCYRxcXRM9T8X+T2CQQO/30rsWw+n32kvGgSdNEB2l51ZV8J1lnOkSSw7z6t WBtWS1guxMwGGatoRywO7+B5G1Yp5g4mSJZKU7b4cfj31YdILbLKjMkKgZvsGoUrQINF y6aUk08CeLuKDiGuVUAd2JwYO3j09lpNXpH9dL9OSTDrUwYfIupcQ923KB/6HG2U0QNr K8Dw== X-Gm-Message-State: AA+aEWbWyjjXkpOjwGZ8dm2503mNMC0i5UsYM5zXop3dF1jptWkOHJAM UXPCqF1TAfY7zurAMYEfEAu+sdYo X-Google-Smtp-Source: AFSGD/Uy3TNO8lPbfj9SfEoOa1Uo+XaWaoNQXzYnkm11A2+bnVWFBxDhOzKeHPsyMtoruYKg7ybX0A== X-Received: by 2002:a5d:5111:: with SMTP id s17mr10831290wrt.43.1543764343242; Sun, 02 Dec 2018 07:25:43 -0800 (PST) Received: from [192.168.0.11] (89.141.9.215.dyn.user.ono.com. [89.141.9.215]) by smtp.googlemail.com with ESMTPSA id g201sm3687877wme.43.2018.12.02.07.25.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Dec 2018 07:25:42 -0800 (PST) To: rtcweb@ietf.org References: From: Sergio Garcia Murillo Message-ID: Date: Sun, 2 Dec 2018 16:29:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2018 15:25:47 -0000 The value for the RepairedRtpStreamId is the same as the RtpStreamId which is negotiated in the a=rid value, so there is no further need for an a=rrid negotiation. However, I have the doubt about the usage of the RepairedRtpStreamId as I have heard some opinions that the rtx could use also the RtpStreamId header and demultiplex media and rtx ssrcs via payload type. This would make sense as the rtx rfc states that the rtx packet should contain the same extensions as the original packet, so the RtpStreamId is copied by default by firefox in the rtx packet. So I would like to get a clarification about what is the preferred way of implementing. Also, when rid is not used I assume that the mid header extension should also be included in the rtx packet to be able to avoid ssrc negotiation. Should also mid have to be included when using simulcast (my assumption is that it is needed in order to differentiate between same rids in different mids). Best regards Sergio On 01/12/2018 13:04, Iñaki Baz Castillo wrote: > Hi, > > We are almost in 2019 and, personally, I don't know yet which the > proper/standard way for simulcast + RTX is. > > Clearly, RID must be used to send simulcast so, instead of signaling > a=ssrc lines in the offer, the offerer signals a=rid values for all > the simulcast streams. The remote learns the associated SSRC upon > receipt of the first RTP packet by matching its RTP RID extension > value. This is clearly specified in > https://tools.ietf.org/html/draft-ietf-avtext-rid-09 and Firefox does > properly implement it. > > Now, the issue is when adding RTX to simulcast streams. Theoretically > (if I'm not wrong) the sender should signal both the a=rid of media > streams and the a=rrid of their associated RTX streams, and then send > RTP RID in media RTP packets and RTP RepairedRtpStreamId in RTX RTP > packets. > > NOTE: Not sure about a=rrid, I can't find it in any draft. So: > > Q1: Is there any spec defining the SDP syntax to indicate > RepairedRtpStreamId values in the SDP? > > Q2: Is THIS (RID + RepairedRtpStreamId) the proper way to go for > simulcast + RTX? > > > Also, when it comes to receive media with RTX it's clear that WebRTC > does not define how to receive simulcast streams for WebRTC clients > (browsers), so browsers must receive a single stream plus an optional > RTX stream. > > In this case, as far as a=mid plus RTP MID extension is used (or > a=ssrc) signaled, there is zero need for RID. However, how is RTX > supposed to be signaled in this case? Chrome expects ""a=ssrc-group: > FID MEDIA_SSRC RTX_SSRC" in the remote SDP to be able to receive an > additional RTX stream. > > Q3: Is this the way to go for receiving a single stream with RTX? > > From nobody Mon Dec 3 02:02:26 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EDC130E00 for ; Mon, 3 Dec 2018 02:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=KKa8LT/k; dkim=pass (1024-bit key) header.d=ericsson.com header.b=GU3cL8d7 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 fZLIk6wMzkV9 for ; Mon, 3 Dec 2018 02:02:22 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 515EC128CF2 for ; Mon, 3 Dec 2018 02:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1543831326; x=1546423326; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dlLtc1YJ6JqAj4f8OpgYz4zHc6uHoOEzcLoVKARFXM4=; b=KKa8LT/kLmp84BzwO+QKpkKHs8E1W3f94yv+lEinkiD+f6t88YrQ8RvPGmTLfGGE AxTxoUn3eAR4bXn08vApFDiThW9zBpzNMlFBHrfAyE+C/OUrU3Et9JgtX/KJ5d+x ceVC+GelosQsYXT7kB4KfKzBw6Hk+y8qkBD7LdnYB7Y=; X-AuditID: c1b4fb30-f15ff700000043c4-60-5c04ff1e1c2c Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B5.CD.17348.E1FF40C5; Mon, 3 Dec 2018 11:02:06 +0100 (CET) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 3 Dec 2018 11:02:06 +0100 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 3 Dec 2018 11:02:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OwmX+kYTldjwvt7kEiQjiENZujNSCtXhOmmyCpKjR54=; b=GU3cL8d7CI45RXPsD8MXxRTjYIZ/+u1GlWiVIZDeIt56S1Lh99jPO1xlOUjwhbhMmnQ1VzlqfhSyADihuYl0yDqt5Tszq4GVYvSZ55nRiqO4yts9rwkfQ4rS0THRl3901XtkIw1Nn5Pqb6dbmUfq0GylH1j7jzFFP68I2yExBYQ= Received: from AM0PR07MB4979.eurprd07.prod.outlook.com (20.178.19.28) by AM0PR07MB5522.eurprd07.prod.outlook.com (20.178.23.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.9; Mon, 3 Dec 2018 10:02:05 +0000 Received: from AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405]) by AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405%3]) with mapi id 15.20.1404.016; Mon, 3 Dec 2018 10:02:05 +0000 From: Magnus Westerlund To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId Thread-Index: AQHUiW4P7j7OLNWOUEuBI+fFoBaelA== Date: Mon, 3 Dec 2018 10:02:05 +0000 Message-ID: References: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.95] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB5522; 6:JbEIg0v9o/GTTerFcO3KoIqqAFBPfwP+3qtlfhSRI7kJBAAyi7+0tEGMtsWq3DksjtngdYYSg3NstE1VJrK1nW0SjmlULlMg8Z0zfakSiPywq2VqD3eubU1uxumMsFJ/nfx5xtllznhMSCKCGs3rjVGRho+6hRnpexRmvVKDG1qB6mcu+afjfLNXGdxvgffGoC6+rnlFZ9D/IGl7x54HA9uxDJmBcIoJmW3jg2KyHy1xb4KgUyte9aq2YgF0djnTxbw7uMlAkSkvIkO2C0PCL0Pdi6GJad1y4MH1QiOKl7JBVTThOCirM03JI1kTMIUlSu3cBaTzLnnrIBPPis499b48hS/DqrXXRc9S85sp7GUuIa4g87Y+6+g5Sdj6dXa1VP8H6FSrk96u6HoNZcAfklBN9mWJfNJgh6drrFnMy2+mrnj4GwX7z+3KH4Wr2LFIBQ//txwdtvktldmpFE135g==; 5:iMRjC9XS+M27ogVvba10CFaMSf0GzStBTFQPbT3B6nGbWugPuUOVGcqQJtbXyH9xWd+yvS3KYsZccynjr1kIgaWEH6st0dAQksOvH/jxax3lq6HHd2kpNQg3vyUD8nekuzR1qvcJO+UeXBZVpt9zNkkOK35FzkVSURQn+spc460=; 7:ev/vf7KMWQ8ezHTUcfBLu4b4ndbmy6oJ7xO2ewnuszQKKJWfiQlT/JBIxAAS3quRO9l5HLgyeH10zK2zd4OzqlzzQHeo6ODyczIG5Le1xFalIWbBeGf28G4rf9wap/dyNmd1es1+HlCdZUJkVxn0vw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 97d82eee-98fc-4af9-d0d9-08d65906616f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB5522; x-ms-traffictypediagnostic: AM0PR07MB5522: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231455)(999002)(944501493)(52105112)(93006095)(93001095)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB5522; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB5522; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(136003)(39860400002)(396003)(189003)(199004)(5660300001)(186003)(26005)(478600001)(68736007)(256004)(14444005)(7696005)(6436002)(6506007)(71200400001)(53546011)(66574009)(446003)(74316002)(2501003)(66066001)(71190400001)(86362001)(55016002)(486006)(6246003)(7736002)(305945005)(476003)(76176011)(44832011)(9686003)(97736004)(25786009)(229853002)(106356001)(2906002)(3846002)(81156014)(6116002)(81166006)(102836004)(53936002)(14454004)(99286004)(316002)(8676002)(8936002)(105586002)(33656002)(110136005)(156123004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5522; H:AM0PR07MB4979.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: UV6i/Gh1Wz5uWeuBsnafpI2PeRzF++P8MeR38lr/fOT6waN6fAOUuaHIU8U0qwmmLlu6LKjbOGYebyZulmhL7ZRlh/cqiyvwIdMnCfGAg0wG6pOfLHYUaNYUqk8WV+eyfY0iqk+NE/aXmoR/y5h7U3QZj4UHg8eBxpgQXDPPG4qJwtyeSuQE4LbZpSbD/Mc7JuUb5jg9O2IHVUlxbzx3S7/1JjoFCeTbfUkqosStvfIenDnDQPIsdb9ew3i0s94iu4oSbtFunbGoHgiJOr/5Fqdk/W/vL3bfLfblHMsDYMdfBsMFRCAKnlUhldedcF/paKmqXKQjR7NUFv6dMM/x46ITgkMZJjz83n8kDRNYJFY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 97d82eee-98fc-4af9-d0d9-08d65906616f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 10:02:05.7756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5522 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42KZGbG9TFfuP0uMQVezhcX0fTYWa/+1szsw eZxreM/usWTJT6YApigum5TUnMyy1CJ9uwSujBW/3rMWzJOoWD7rBUsD42fhLkZODgkBE4m1 N9aydjFycQgJHGGU+HHmKjOE85VRYvKO51CZxUwSX5++ZwFxWAQmMEu8P/0SKtPPJLHj5GOo noeMEpMWXWUDmcwmYCFx80cjmC0ikCCx+cEUoHYODmGBIIkNhxghwsESDfPuQZXoSUxvaQez WQRUJG5fPcoMYvMKxEjs3PqOBcQWEgiQ+PH6JVicUUBW4v73e2BxZgFxiVtP5jNBPCQgsWTP eWYIW1Ti5eN/rBC2gkTngTdQNbISl+Z3M4LcLCFwjU3iT+cpdoiErsSHqVOhmn0lvr9pYoUo usAosXj1NBaIhJbEz2MrWCGuSJS40fgUamq2xM5HLVDb5CRW9T5kgWg+zyzRsfo11AYZiftf bkNNvcIq8XPiQtYJjHqzkLwBYetJ3Jg6hQ3C1pZYtvA18yxwcAhKnJz5hGUBI8sqRtHi1OKk 3HQjI73Uoszk4uL8PL281JJNjMDkcXDLb4MdjC+fOx5iFOBgVOLhXfyNJUaINbGsuDL3EKME B7OSCG9BIVCINyWxsiq1KD++qDQntfgQozQHi5I4r4Xf5ighgfTEktTs1NSC1CKYLBMHp1QD Y6ZtsG3P96/vjqeUxPFoin+JUcl4uT3n8/yQ9IgF9ruZFB5IqP4Jj3wTyJDP6N55gWO2+mPR 2y953q8tD7Jc6x1SyTrx359aaa1bvlflFbeIztYwLU68Etj69xFvpVbBud1dDZeufMup4Tiy a/nk42w+NitnN/67x+PfYftGJIj9aLzKSvXjSizFGYmGWsxFxYkAw2G14RoDAAA= Archived-At: Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 10:02:25 -0000 Hi,=0A= =0A= I think what should really be done is to update RFC 4588 to recommend=0A= that one uses RepairedStreamID to indicate the retransmission stream's=0A= relation to the source stream for the same RTP session multiplexing=0A= case. I also think there is a point to discuss the separate RTP session=0A= multiplexing case and its SSRC usage. This will however require one to=0A= have a legacy discussion section for both these cases.=0A= =0A= =0A= =0A= =0A= On 2018-12-01 13:04, I=F1aki Baz Castillo wrote:=0A= > Q1: Is there any spec defining the SDP syntax to indicate=0A= > RepairedRtpStreamId values in the SDP?=0A= =0A= =0A= As Sergio stated, no needed for that as the ID value referenced are the=0A= RID ID for the source stream.=0A= =0A= >=0A= > Q2: Is THIS (RID + RepairedRtpStreamId) the proper way to go for=0A= > simulcast + RTX?=0A= =0A= Yes, if you would use the RFC 4588 format.=0A= =0A= However, for FLEXFEC one doesn't need that at all as the repair packets=0A= are self-describing. I have raised an question in PAYLOAD WG if flexfec=0A= should be explicit about its non usage of RepairedStreamId. =0A= =0A= =0A= >=0A= > Also, when it comes to receive media with RTX it's clear that WebRTC=0A= > does not define how to receive simulcast streams for WebRTC clients=0A= > (browsers), so browsers must receive a single stream plus an optional=0A= > RTX stream.=0A= >=0A= > In this case, as far as a=3Dmid plus RTP MID extension is used (or=0A= > a=3Dssrc) signaled, there is zero need for RID. However, how is RTX=0A= > supposed to be signaled in this case? Chrome expects ""a=3Dssrc-group:=0A= > FID MEDIA_SSRC RTX_SSRC" in the remote SDP to be able to receive an=0A= > additional RTX stream.=0A= >=0A= > Q3: Is this the way to go for receiving a single stream with RTX?=0A= >=0A= To attempt to restate your question. For RTP sessions, where there are a=0A= single source media stream per Media Description in SDP (m=3D block) and=0A= where there is explicit MID signalling and SSRC signalling, then one=0A= will not need RepairedStreamId and can instead rely on explicit MID=0A= signalling for the RTX stream?=0A= =0A= I think no. I think using RepairedStreamId independent if there is=0A= multiple source RTP streams or not per media description provides a more=0A= consistent experience.=0A= =0A= However, as noted at the start. The use of RepairedStreamId for RFC4588=0A= RTX format is not well defined and how to handle and detect legacy. So,=0A= I think an update should be done.=0A= =0A= Cheers=0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Mon Dec 3 02:08:18 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE722130E4A for ; Mon, 3 Dec 2018 02:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 fRZEp7585Ttm for ; Mon, 3 Dec 2018 02:08:16 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 14C48130E19 for ; Mon, 3 Dec 2018 02:08:16 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id j10so11449065wru.4 for ; Mon, 03 Dec 2018 02:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=K62Zi1U00ldTiwupK2jliwt1cbCzAJJlxwrw3u4Rxuw=; b=QcOK/HqUUSeafpVzKi2/Iyg2qvBuY8JqFHlgTfl77OtUqQTfC/K3VwJH8GowiPcpc5 FWWntZM3bhr22jyarIutIjda0EcUbhIhtzwhPGjeyYz39haXCUQONZO9csub+P4428EA VAbinUUVU7bzMq0Emrx7xTfGIH5mYNK01s0AJ5SdODx1dKqAI4c5+lWdUpaI2v4TNVyJ vqO0PERGAIfgmsjL8cqtYgkfs709iDapP0dlKyHsA+U2fHxVJjo4apEXO0wJxE44Y4Rb +8j1LExjggWS6TC7Cz/U+eippECuxOQNtSspbDoSi+NO3dCfDVtHri885HRgvf3OKJYW ilWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=K62Zi1U00ldTiwupK2jliwt1cbCzAJJlxwrw3u4Rxuw=; b=DFQsvumXO00qsoWLXahcUSbbXRXP+HQx+wE4toTBOiP7wqUCrLKK+pbpwkJbKYGYA7 y/3SfyJXJwW+T2HhyZ0hU7nEfq8GZUBf+BAk8nSTvt+9LqyfqSIoXRc97M8WqJ0hcW+a n2cmycOHNIwH34Cu2thRg5kmvPrjxfxq4Swydkg9A5bH+4gF6ud15GGTlJgjI4u92IdP M0YdWRVr7FIVO+MvIQJSXO9PHQU5CpYp22ihodlW4ItRxtGH9FK5rDGbmdljZp4/HiL7 EZoeL+7AbsxdmR9DHWidqtvl5/5OEPSgetyH+ZoZYzkF6abVAKCiBfqeQEWSqAqATEoM vuJw== X-Gm-Message-State: AA+aEWZ1I+W1faGorCFHC32/nmGrCNaXLreQ1gX+xS9v9qfjXjAl0AV+ oK3aLAjyUjlS9I5wyhXNqknF+tcX X-Google-Smtp-Source: AFSGD/WIHAWoBAb4pXJW4bCCHgboqGjQDBbjMahizwWE/GiOcpGjXljApk3SsyXr4oXExR2JHfVqgg== X-Received: by 2002:adf:9246:: with SMTP id 64mr14277288wrj.130.1543831694148; Mon, 03 Dec 2018 02:08:14 -0800 (PST) Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id v1sm14725320wrw.90.2018.12.03.02.08.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Dec 2018 02:08:13 -0800 (PST) To: rtcweb@ietf.org References: From: Sergio Garcia Murillo Message-ID: <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com> Date: Mon, 3 Dec 2018 11:11:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 10:08:18 -0000 On 03/12/2018 11:02, Magnus Westerlund wrote: > To attempt to restate your question. For RTP sessions, where there are a > single source media stream per Media Description in SDP (m= block) and > where there is explicit MID signalling and SSRC signalling, then one > will not need RepairedStreamId and can instead rely on explicit MID > signalling for the RTX stream? > > I think no. I think using RepairedStreamId independent if there is > multiple source RTP streams or not per media description provides a more > consistent experience How would that work, if we are not using simulcast, no rid will negotiated in the SDP (AFAIK) so we can't use RepairedStreamId and we will have to rely on mid header extension and pt multiplexing, right? Best regards Sergio From nobody Mon Dec 3 04:44:57 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8AA130FBD for ; Mon, 3 Dec 2018 04:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=GJefGsb+; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lsyDUUgv 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 pax1DI16OZGm for ; Mon, 3 Dec 2018 04:44:43 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 B2135130FA0 for ; Mon, 3 Dec 2018 04:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1543841080; x=1546433080; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vLPaXkysRXBqeM4uEKKPTbTRol6IIwm7bWbRryDomuw=; b=GJefGsb+DK1H/PatW9pM8s9dxJpk3rKZ7SRlUE6XJ0/rKS5NUHiz4BH4ZkYwlULl rrmglw4CVlPm9F3/CI4xntwkbqs6K1S6RiA6d6eGAJUzj5gabufrfaG46FEe9d5L a+VL2T3NjNI7drgld4Enz/JZl7RsleLnKNg2MPVyf4k=; X-AuditID: c1b4fb3a-477ff70000002747-bd-5c0525381e68 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A4.75.10055.835250C5; Mon, 3 Dec 2018 13:44:40 +0100 (CET) Received: from ESESSMR506.ericsson.se (153.88.183.128) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 3 Dec 2018 13:44:39 +0100 Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMR506.ericsson.se (153.88.183.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 3 Dec 2018 13:44:39 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 3 Dec 2018 13:44:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oPq4D1mjdxqBaamd2yDMGxzGGi26YJDDXMxJFiQyV90=; b=lsyDUUgvHdwr9ST9azBnskUdey7kflugBPoOaN+NeFwbC1V07OUEQBIzrDW5zn63yDB0VxSBCKR59VSugK2iVw1W8smUfxE46nmfmcX3DUSU9Y9oLrix/+hiLQpp0RpntNkMx7haljSyfDSC/NwKQ+eDXJuvcGK0CfaLYXbgUEA= Received: from AM0PR07MB4979.eurprd07.prod.outlook.com (20.178.19.28) by AM0PR07MB6051.eurprd07.prod.outlook.com (20.178.115.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.11; Mon, 3 Dec 2018 12:44:38 +0000 Received: from AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405]) by AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405%3]) with mapi id 15.20.1404.016; Mon, 3 Dec 2018 12:44:38 +0000 From: Magnus Westerlund To: Sergio Garcia Murillo , "rtcweb@ietf.org" Thread-Topic: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId Thread-Index: AQHUiW4P7j7OLNWOUEuBI+fFoBaelA== Date: Mon, 3 Dec 2018 12:44:38 +0000 Message-ID: References: <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.83] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB6051; 6:9vs6yvZmLU3quUotYM474gtYcSlAQyuH2GGyPf5M72heT7gPMUAIvlVlJJAaL7VlcwC+HXptjcO18++h6d/cDmaXu8/6F8mvlouydpc0g7ZVdi32P5IhtyNuEsk1IaLFdad4ih93qizWbDFwGvv5+bAjcIrbEvciDyeHettSCuDyKwHBDgE2h3Fow8YC9LKKow8rFnz22HYyLoiV/WF5gTVwUdqphwNHj/RipVjBxdnrtOh371RDDS07oLJp0Ghhi0kQqCxHsGO2hDCYRNVShz/FVppZpmUAeUWfPlNgmJzF2GeioGB4KXsyv/f+y31e2Ybg6hw3+WBUKK/6XfPrgHnOFFTfoMz96zijq6pPyZVVyc2jLdi1y79ioJ0RW4mUQKrABQUrWvhp6Fwnu5PsDPg11FVGg7auELFqWwqtRviBIdmUNjvrpJ0tBayK8jQOZvhm1Pbu4nX2pVU0cmxfoA==; 5:q5K4CRMRsEeu/SxYey4KWd8/NzCvsqFVoS/CCoIVMPsrVfcirUfxJ55oS3C9fMKemAB09RRaHY4/aCZPlSTXc+g2+xJZwng8HHVN606w+FTdj7mAIiPQ4hOBrbnb53ix+RY9bVR8500A4W9zjXMbCldjsXKG2/6djAHk8FJhASQ=; 7:paXao+Mida/fo7yyyyfI2ZQIeXS7/0nW+riLSZHxslBmdVXyirPtD/rrQmgCCsK2TRMGRyxJNh2n5ACP8VCBWIE1fbWH7XF0dsd/yTVYVEhlD24lTah55wzmOrJiRrSHKWa4XMmRV4XMcCzpJsTIVA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0e94c3de-dbe2-4f6c-588e-08d6591d16a4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB6051; x-ms-traffictypediagnostic: AM0PR07MB6051: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231455)(999002)(944501493)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB6051; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB6051; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(376002)(346002)(39860400002)(189003)(199004)(186003)(71200400001)(55016002)(86362001)(5660300001)(2906002)(478600001)(26005)(66066001)(39060400002)(71190400001)(316002)(446003)(110136005)(476003)(44832011)(256004)(486006)(8676002)(14454004)(76176011)(7696005)(106356001)(102836004)(8936002)(68736007)(53546011)(6506007)(99286004)(229853002)(81156014)(105586002)(81166006)(6436002)(53936002)(7736002)(236005)(74316002)(9686003)(54896002)(33656002)(3846002)(25786009)(97736004)(2501003)(6246003)(6116002)(156123004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6051; H:AM0PR07MB4979.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: D/6PUdpUSZNlZAvOj68fAJIA3230Nx6REdY86FXhlBtwbb1+0Cnpplg2u3d4y9qnClwX8TLYfo7VYyPOUwiwxsRkQsyZOpbyrZZHYyc3J7GrhFnMxCFDGKckhqIFFgzjdkqXxgmCRdv4GDeIrQ7y/m5mTUQZjcC9YnzVLT88Q33Sw8sWEIjcKwTCbyL+DwS0hsmOfkuIHARjYusUTbzSken0RU/HYuDxIO6zUI/oNtw3XyaOon3Pp8rREMpDV+p0t4w61E1EJaTZZXAACcF+r7/5CdwAuzTLBumpv8N6bTKmKipDoCVT06QF7rB10Xdi0l/6DbP17Bb0ldHr1H9S9P45sScUu5tb7o+lRBDLTKs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM0PR07MB4979571D1B2933258A18544A95AE0AM0PR07MB4979eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0e94c3de-dbe2-4f6c-588e-08d6591d16a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 12:44:38.7095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6051 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec9lOy4Xp+XlQZ3k0ArDVZKwIqSC0C+Cn0xkokuPurxMd8xS IjQUdRaYuJozNM0Eh4aZMk1nbGhmhpqEecnMGxFimpmakqR7V/jt93+e/3N7eRlS0kh7MOq0 TE6bpkqRCURURaSZD1D40cpTFV+QommnUKhY2DGTF4jQDuOUMLSu7jcRTkSJzsdzKeosTnsy OFaU1Go0EOk9vjdHNlaFuWjSW4ecGGDPwPpYAaFDIkbC9iBoXH6EsPiF4Me4hfgvhjs/CrF4 QsBSfpVdUGwpCVOVLTTOlBHQ0lDpqJlB8LTMQu2NEbAKGN/ME+yxC3sVOgen6D0+zEbA/QeL JI5fgaG2BhqzHB7mF9r9FOsL3a+r7H3ErBK+/7lL4QGjCBZ65+zFiJXC9MZnu4lk3WFivprA 97FQ1zVEYnaFb3M7NParYCxvweE5Ap/0TULMUhipLrE/AbCjApiZLHYUB8CKXu/gMHhh3hZg 0zCCDy9bHJ38oddUjjAng+XnrACzN5juzVCYh0jot2owe8H02iRdiuTGfYsbEbPLGng2wBnt Rx+C/op5ClvkMKYvF2A+AfU1iyTmADDs2Kj98cdIaEKuPMfzqYmBgXJOq47jeU2aPI3LbEG7 f8jaun2uHVm/XrQhlkEyZ3G0D62U0KosPjvVhoAhZS7i9AxKKRHHq7JzOK0mRns9heNtyJOh ZO7iSwmKKAmbqMrkkjkundP+yxKMk0cuIk1Fz9966F1v6yyGabcb0rWahPS6oI7uyE2528Fm /+RAWUiVy+UYw/oE+a5gtKta2pEqar5T338rKLxN3L7lWjvYNyBdMTsvz4asqtQ1E30R2ceP tfYwXkVLGdoIP4P7m/cuR2PjLNcOFEdvqV+16c56huVYlcE6n5LBzsRaJxnFJ6lO+5NaXvUX HoFHhz8DAAA= Archived-At: Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 12:44:56 -0000 --_000_AM0PR07MB4979571D1B2933258A18544A95AE0AM0PR07MB4979eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 2018-12-03 11:11, Sergio Garcia Murillo wrote: On 03/12/2018 11:02, Magnus Westerlund wrote: To attempt to restate your question. For RTP sessions, where there are a single source media stream per Media Description in SDP (m=3D block) and where there is explicit MID signalling and SSRC signalling, then one will not need RepairedStreamId and can instead rely on explicit MID signalling for the RTX stream? I think no. I think using RepairedStreamId independent if there is multiple source RTP streams or not per media description provides a more consistent experience How would that work, if we are not using simulcast, no rid will negotiated = in the SDP (AFAIK) so we can't use RepairedStreamId and we will have to rel= y on mid header extension and pt multiplexing, right? That is my point, that we should define that when using RFC 4588 RTX one sh= ould include RID and use the RepairedStreamID for dynamic bindings of the S= SRCs even if one doesn't use Simulcast. That would be a stable and commonly= operational solution. The solution that I=F1aki suggested still only works in a sub-set of condit= ions and you will still need to implement the dynamic late binding solution= that is described in RFC4588. That will be the ultimate fallback. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_AM0PR07MB4979571D1B2933258A18544A95AE0AM0PR07MB4979eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


On 2018-12-03 11:11, Sergio Garcia Murillo w= rote:
On 03/12/2018 11:02, Magnus Westerlund wrote:
To attempt to restate y= our question. For RTP sessions, where there are a
single source media stream per Media Description in SDP (m=3D block) and where there is explicit MID signalling and SSRC signalling, then one
will not need RepairedStreamId and can instead rely on explicit MID
signalling for the RTX stream?

I think no. I think using RepairedStreamId independent if there is
multiple source RTP streams or not per media description provides a more consistent experience

How would that work, if we are not using simulcast, no rid will negotiated = in the SDP (AFAIK) so we can't use RepairedStreamId and we will have to rel= y on mid header extension and pt multiplexing, right?


That is my point, that we should define that when using RFC 4588 RTX one= should include RID and use the RepairedStreamID for dynamic bindings of th= e SSRCs even if one doesn't use Simulcast. That would be a stable and commo= nly operational solution.

The solution that I=F1aki suggested still only works in a sub-set of con= ditions and you will still need to implement the dynamic late binding solut= ion that is described in RFC4588. That will be the ultimate fallback. 

Cheers =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_AM0PR07MB4979571D1B2933258A18544A95AE0AM0PR07MB4979eurp_--


From nobody Mon Dec  3 05:32:56 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B7F130E44 for ; Mon,  3 Dec 2018 05:32:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 02A9T2OgpcYo for ; Mon,  3 Dec 2018 05:32:53 -0800 (PST)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 7F98312D4E8 for ; Mon,  3 Dec 2018 05:32:53 -0800 (PST)
Received: by mail-wm1-x32e.google.com with SMTP id a18so5711753wmj.1 for ; Mon, 03 Dec 2018 05:32:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=nRbUFylODDcpHxOIqemXhjasCB1TeGgGK/a+YkW4gbc=; b=iBQY0dZFh7+N1ev+GTzxWkLF6Xfq9LyzqfS49Wl5pMVs8Zs7GGuUbCAjjrLwNne7Vz 7KNol60BPlykjj4YgqRBHLGZj38YE3VEDl/rK6042kSOuIPYqc7VRPhbJpdKK12m+AD5 EJhLDDKyxOACTg1gmc9/09TCvYwoTOi2QAkBrZ4seXaZcwXQV+MDyaE5V0QjeHQXJNwo 9DQsjA98dJCZ7xVI+9dcIDPzkbhqgMxwM1x0eElMKvzWqjrucvTqg0OOtIbCCFI54jIq VwvffWLNuvbraoXDcSlLQgNr7fBsy7/zG7tV+cA0GefAwy5RNPtrNbs2+p3c1jVl29vb qCcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=nRbUFylODDcpHxOIqemXhjasCB1TeGgGK/a+YkW4gbc=; b=E1Ie6kxWxUOEU6A21ZWp37Tx60V5UtzDcvEmfRY6JABPhXwyO9Y+qYcuu7JY4YwmBX +sg6ukHMcfTVfHknbLP+YZ336yhTXtso22RfJOELnVIVzrtkfmv1gHSEg2Xx9NjoabbP C8GPd1lv6JCKzpaM7dZSKCllEWdAzggC5NqQgKVCveyMospgGe/UyuuwYP0zYW7Vz7K8 iDQg+UlGfoB2zjtvnQsIE4oJhh+bZH6v5UfpGjN3NgWUdQf5I2mgg8t796tdcDMGI51c dxCEunf7u87/CCo5KUT12GtvlesNR5/hGjGvl/jTAL9ah2KIe5F351HAgiXo/htUrFxG Md7w==
X-Gm-Message-State: AA+aEWaP0MAEhYyQ4hLdqjuTbPbTlupOJyzOQ/ne1QMLAL5etnHC8pqS sDbqpgk7KaQ9IRLSXyPA7gjI0v3A
X-Google-Smtp-Source: AFSGD/XpMbMha5p/vaQnZnksik14gg40QCBpxt0SaSptwOWVRLL12JiWJ5rNU7wpJFhkJbG7JFYvhw==
X-Received: by 2002:a1c:27c6:: with SMTP id n189mr8197044wmn.108.1543843971708;  Mon, 03 Dec 2018 05:32:51 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id o15sm15393540wrp.12.2018.12.03.05.32.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Dec 2018 05:32:50 -0800 (PST)
To: Magnus Westerlund , "rtcweb@ietf.org" 
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>
Date: Mon, 3 Dec 2018 14:36:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2018 13:32:55 -0000

On 03/12/2018 13:44, Magnus Westerlund wrote:
>>
>> How would that work, if we are not using simulcast, no rid will 
>> negotiated in the SDP (AFAIK) so we can't use RepairedStreamId and we 
>> will have to rely on mid header extension and pt multiplexing, right?
>
>
> That is my point, that we should define that when using RFC 4588 RTX 
> one should include RID and use the RepairedStreamID for dynamic 
> bindings of the SSRCs even if one doesn't use Simulcast. That would be 
> a stable and commonly operational solution.
>
>
Given than rid is not globally unique but unique per mid, the rtx packet 
would need to include the mid anyway, wouldn't rid be redundant for 
non-simulcast use case?

Best regards

Sergio


From nobody Mon Dec  3 12:58:21 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0723012D4E8 for ; Mon,  3 Dec 2018 12:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.75
X-Spam-Level: 
X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=P4FudI4I; dkim=pass (1024-bit key) header.d=ericsson.com header.b=K7GcWa4Y
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 KByV3HjnSZD3 for ; Mon,  3 Dec 2018 12:58:15 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3C6C81200B3 for ; Mon,  3 Dec 2018 12:58:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543870693; x=1546462693; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8gvNl+CzXa7XPLQuemxsoTYV9dZatVaEvwOvNA7yis4=; b=P4FudI4I+q7W5Sc+NS5G/UItoOXJdlAiNj2XRJLuPdunbEsL2hLN3WFbw+wQNQ9C Dv5USFRVGjBpVmvjt31Pi0OxcK0Z5gjCXAuaVENjWC+BHN5SgaG6KvyhQjrY9h6F Y3gGRXYlCurs7GsI6fSPupYT2JFUC75Poc5YvOWVKCY=;
X-AuditID: c1b4fb3a-45fff70000002747-62-5c0598e53984
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.93.10055.5E8950C5; Mon,  3 Dec 2018 21:58:13 +0100 (CET)
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 3 Dec 2018 21:58:13 +0100
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 3 Dec 2018 21:58:12 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8gvNl+CzXa7XPLQuemxsoTYV9dZatVaEvwOvNA7yis4=; b=K7GcWa4Y3lVeo15Bd/EeWz6xBdbi0HsYk/khDRJpSm8JxPvZAjExmOONpaa9ZY9G0dFoUrjyvoh8XJPIB65R1aGMJYfieIYvMfDTl5sJ2STfkxZQhPa5IO0vFOCJByIqUvbssJFzw7DOk12USvf6S34jjJXCJCBjqJqjUPN7iUk=
Received: from AM6PR07MB5621.eurprd07.prod.outlook.com (20.178.91.14) by AM6PR07MB5798.eurprd07.prod.outlook.com (20.178.93.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.8; Mon, 3 Dec 2018 20:58:12 +0000
Received: from AM6PR07MB5621.eurprd07.prod.outlook.com ([fe80::a5dd:4302:feec:e113]) by AM6PR07MB5621.eurprd07.prod.outlook.com ([fe80::a5dd:4302:feec:e113%3]) with mapi id 15.20.1382.020; Mon, 3 Dec 2018 20:58:11 +0000
From: Christer Holmberg 
To: Roman Shpount , Adam Roach - SIPCORE Chair 
CC: RTCWeb IETF , mmusic WG 
Thread-Topic: [rtcweb] [MMUSIC] Default proto transport in JSEP
Thread-Index: AQHUhquP7oWmB9W6S0+oK/sz+g4vAaVlZEyAgAAFLoCAABfmgIAABUCAgAf/CNw=
Date: Mon, 3 Dec 2018 20:58:11 +0000
Message-ID: 
References:   <9B9B741B-622F-4565-899B-700636408F6C@iii.ca>  <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com>  <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca>  <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com>, 
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=christer.holmberg@ericsson.com; 
x-originating-ip: [37.136.29.129]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM6PR07MB5798; 6:NlrR46XkfJ/df4mYoSJGCfezoZO3DNB2fKW3coKGBL+6gYumikxR0darrrBCiZ2JAU5kFRMCIwnkf2z0cDb9BTJsJZCFUcaRIpaFpTGw1HslARXCIsKAw4l017P/MMWaBRHnm64dRDdL7JguwrenZ961KTdjC9vCZrkYGJNnCplGPPjxSW81ybkhOnrVBkSjqUd4FgJGNiSMXeJrnVoF+6fW4M+Yd2xDEmqSvgNWhSQXEa/pJyOCwERYcwnjZ5w/HSxfVX+mTKhLGE9BzWo7Lq2YDS6WoKvVc8gFo0R5UxWHVvaJUtRwwl5zSQo1mEMg+AJlNgS0NqV8IH7CidFCaATKIJaxuYaxq1vUn45OTI8fXH3EGM1srgqbZ7BNcAKbmsjCsk5gvC9vx+FzvMrFkKaUR67LiknsAep/JECjtfHKFPLLA+lkxO3ob0Xz/GfHJ6+lwOE4NxgQPfbBHz4B6Q==; 5:830cZdyVbqYIcmpKUIDYV640Sqcz+1whBtKwH+SCLYHKg+/oIeWRmz6iq1pxCqYN17ZzJ7NI4Io1pG2FYVZBhZsX39fVxMT78gOaDFkTJxMbZpqQ1LrJdMKC1hyDUKL/jhCjDC71+3N8omnjAxYH0Z3/DieR0NN3MHIcK34JACE=; 7:LCGA1EGN8j2CF1NRWN2P74SKFCprKTbbhdz6hii5m1Li0PLXWCAuEsZxSU16Y/VNrvNOjcO1RZ5nvM3DGkM6ox/T2huR1GMoWIoym16GBi0YdBCeQn1o8EEgO8kiWfdIRpg0CArV+4PT7/Fqha8h6A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 4da75bc1-4f4e-41fb-d39f-08d659620976
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB5798; 
x-ms-traffictypediagnostic: AM6PR07MB5798:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231455)(999002)(944501493)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB5798; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB5798; 
x-forefront-prvs: 08756AC3C8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(366004)(396003)(39860400002)(199004)(189003)(110136005)(256004)(6606003)(7736002)(5070765005)(54906003)(8676002)(4326008)(3846002)(966005)(53936002)(8936002)(229853002)(11346002)(316002)(76176011)(2906002)(54896002)(9686003)(236005)(186003)(6306002)(55016002)(44832011)(6116002)(14444005)(19627405001)(53546011)(1015004)(33656002)(6506007)(606006)(6246003)(486006)(7696005)(74316002)(102836004)(5660300001)(68736007)(97736004)(86362001)(93886005)(81156014)(446003)(6436002)(81166006)(26005)(478600001)(14454004)(25786009)(71200400001)(71190400001)(106356001)(105586002)(476003)(99286004)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5798; H:AM6PR07MB5621.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ogOIvPdtMJJbM0WWDZHE8uGD2Dwhn8tRf4EAN+CchPLcpIRmtxu2nOx1DlnpLdJ8nHrN/0cS8sURX+ioQ88Mt1tNaudYRNsuu6DzU71dp+oswb9A6mP2/rQW3BlKv3Mx0KzrnKjbvV0EsDqPfw3W8OK7g4dLrp3zGIROwCgkZ+9YJsM1cLPw3FA+oGB9i/+idCTSEwC+ncYBB9zAqavPRxdiMHP9EzKmSQLsn1eDsO2rDBR4ugxXb2ZdGlR66v5mNmmg+pIpKAKLcAkeBttwpgLW0tKglpWVPPtOiFRlcdzhwkRTIEAMCCdMotV5eZRT6hKnLQCh5xlQxEmsSQbsAVS5UR3jDvqpWPnitWjDhhs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM6PR07MB5621291E0EA9E72A8065380A93AE0AM6PR07MB5621eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4da75bc1-4f4e-41fb-d39f-08d659620976
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 20:58:11.9192 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5798
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfebcfR4LS8PKhZjerDzGnihxFqFxFMMCy7mIxs5EnNTdeO ifrJIlIUU7PlBWuay0pS7OYtRbcclWiuAstR4i3ExLxNYqxWHs8Cv/2e5/n/n//zwksSkk6+ L5memU3rMlVqqUCEaxI7coO+V/OVISVjAYqeP/eFCv3DaayotuoJRYurUHgIxxiNDl5MbdcM jrHd1sYTSaLwFFqdnkPrgiPPi9L6fy4ItIYalLvYWoULkOM6KkYkCVQYPH/kV4xEpIQaQDDh +sbjijUED3pniWLksV408mB5NocdYKqcgDLzb8ypyniwMlQn4IpJBI2FBUJ2r4BSQIkrkHV7 UqehzbmMWCaoSLBUf+axvG2d734qwpzmIJj01/gcH4ObVbUCljG1G1pKBze8YkoJpuk5d7AD Q9PYDQGb5UEdB6slidUgyht+DT7hcVk+YJsxbDBQFBh7RgiOvWBu2sXn9Croa55w93fBYLFd yPF2+GgoQWwWUKMCsHx1Ym4QBEt6vdsQBzWWXrfBisDeepRjGZiWRxDHGbBi/eH2BkBz6STm lo4QMGQsE5aj4NpNx3KcBRUv3xK1G4/eCu9qZjDXD4HF9waC40Boaph3czA8tQ+jzf16JGxG XgzNMJrU0FA5rUu/wDBZmfJMOvsZWv9PphfOA53INHvYjCgSSbeIu8v4SglflcPkacwISELq KdZexkqJOEWVl0/rspJ1V9Q0Y0Z+JJb6iI9cVCRJqFRVNp1B01pa93/KIz18C1AoMenvL49a 6iq5pDCF/X1VaZNFk2cHFoLundDEzSc0rfl4nzlZUd/up6hU9+2rzF/de2vKY9wc3rZj9NwH wZ2rfXvymPHwuniN1vlF3tPKuOasNn3EcJF1jtqZ2B97SthdJzPlxyS3R9iNDdGkZdXhfNyB oxJ4r2NDDFFTb6SYSVPtlxE6RvUPhIcTv0sDAAA=
Archived-At: 
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2018 20:58:19 -0000

--_000_AM6PR07MB5621291E0EA9E72A8065380A93AE0AM6PR07MB5621eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Hi,

I am jumping late into the circle, but I share Roman's concern regarding th=
e suggested change to 5.2.2. I think the WHOLE m=3D line (including the pro=
tocol) shall match the currently used properties. You may also end up havin=
g SDP attributes that are not defined the for the indicated protocol (since=
 you are using another protocol). That is asking for interoperability probl=
ems, in my opinion.

I've probably missed it, but what is the "catastrophic flaw" (to use Adam's=
 words) that would require this change, and misalign the JSEP ICE procedure=
s from all the documents Roman listed?

Regards,

Christer

________________________________
From: rtcweb  on behalf of Roman Shpount 
Sent: Wednesday, November 28, 2018 8:41 PM
To: Adam Roach - SIPCORE Chair
Cc: RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP


Hi Adam,

On Wed, Nov 28, 2018 at 1:22 PM Adam Roach > wrote:

On 11/28/18 10:57 AM, Roman Shpount wrote:
On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings > wrote:
On Nov 27, 2018, at 4:46 PM, Roman Shpount > wrote:

 I suggest to update JSEP section 5.1.2 to match the rest of the documents =
to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When=
 ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto MUST be used if =
default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto M=
UST be used if default (only) candidate is TCP candidate.

I don=92t see any real befits to implementations to this change and I don=
=92t think the rtcweb consensus was around the currently solution. Do you s=
ee some advantage to implementations to this?

This is what every other document related to ICE, including JSEP section 5.=
2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB ne=
ed a really good reason why it needs to be different.

It would probably help clarify things if you quoted the parts of the docume=
nt that you think are in conflict. I can't find any explicit  field =
handling in 5.2.2.

 I have mentioned this already in the previous message, but I guess this go=
t lost in the traffic.

JSEP-25 in section 5.2.2 says (https://tools.ietf.org/html/draft-ietf-rtcwe=
b-jsep-25#section-5.2.2):

Each "m=3D" and c=3D" line MUST be filled in with the port, protocol, and a=
ddress of the default candidate for the m=3D section, as described in [I-D.=
ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.

At the same time section 5.1.2 says (https://tools..ietf.org/html/draft-iet=
f-rtcweb-jsep-25#section-5.1.2):

For media m=3D sections, JSEP implementations MUST support the "UDP/TLS/RTP=
/SAVPF" profile specified in [RFC5764], and MUST indicate this profile for =
each media m=3D line they produce in an offer. For data m=3D sections, impl=
ementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this=
 profile for each data m=3D line they produce in an offer.

So, section 5.2.2 says m=3D line should be filled with currently used proto=
col, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP" if default candidat=
e is TCP based, but section 5.1.2 says it must be "UDP/TLS/RTP/SAVPF" or "U=
DP/DTLS/SCTP", even if default candidate is TCP based. I thought that secti=
on 5.2.2, since it is more specific, overwrites 5.1.2, which I assumed only=
 applies to ICE restart. Authors disagree and want to update the document.

In terms of changing technical aspects of JSEP: the only reason the documen=
t is out of the RFC Editor's queue right now is to address issues arising f=
rom rationalizing the reference to RFC 8445 within Cluster 238. This is not=
 an opportunity to re-litigate previously settled consensus decisions. Tech=
nical issues such as the one at hand should have been raised during WG deve=
lopment, WG last call, or -- in extremis, since you're a regular RTCWEB par=
ticipant -- during IETF last call. It's up to the chairs what to allow, but=
 I wouldn't expect anything other than catastrophic flaws to be open for ch=
ange at this time.

I am not the one who opened this can of worms. I am fine if the current dra=
ft version is not changed. This is why I did not comment during the WG last=
 call. Draft authors are introducing the new change in https://github.com/r=
tcweb-wg/jsep/pull/857, which makes JSEP incompatible with ice-sip-sdp. I o=
ppose this change. If the group considers that a change to clarify things i=
s necessary, I would suggest that section 5.1.2 should be changed instead t=
o that it only applies during ICE restart, so that JSEP is compatible with =
ice-sip-sdp.

Regards,
______________
Roman Shpount

--_000_AM6PR07MB5621291E0EA9E72A8065380A93AE0AM6PR07MB5621eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
















Hi,









I am jumping late into the circle, but I share Roman's concern regarding th=
e suggested change to 5.2.2. I think the WHOLE m=3D line (including the pro=
tocol) shall match the currently used properties. You may also end up havin=
g SDP attributes that are not defined
 the for the indicated protocol (since you are using another protocol). Tha=
t is asking for interoperability problems, in my opinion.









I've probably missed it, but what is the "catastrophic
 flaw" (to use Adam's words) that would require this change, and misal=
ign the JSEP ICE procedures from all the documents Roman listed?








Regards,









Christer








From: rtcweb <rtcweb-bou=
nces@ietf.org> on behalf of Roman Shpount <roman@telurix.com>

Sent: Wednesday, November 28, 2018 8:41 PM

To: Adam Roach - SIPCORE Chair

Cc: RTCWeb IETF; mmusic WG

Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

 















Hi Adam,








On Wed, Nov 28, 2018 at 1:22 PM Adam Roach <adam@nostrum.com> wrote:













On 11/28/18 10:=
57 AM, Roman Shpount wrote:










On =
Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <fluffy@iii.ca> wrote:
















On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> wrote:




 I
 suggest to update JSEP section 5.1.2 to match the rest of the documents to=
 say that "UDP/TLS/RTP/SA=
VPF"
 proto MUST be used during ICE restart. When ICE restart is not in progress=
, "UDP/TLS/RTP/SAVPF"=
; proto
 MUST be used if default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto
 MUST be used if default (only) candidate is TCP candidate.








I don=92t see any real befits to implementations to this change and I =
don=92t think the rtcweb consensus was around the currently solution. Do yo=
u see some advantage to implementations to this?











This is what every other document related to ICE, including JSEP secti=
on 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCW=
EB need a really good reason why it needs to be different.








It would probably help clarify things if you quoted the parts of the doc=
ument that you think are in conflict. I can't find any explicit <proto&g=
t; field handling in 5.2.2.








 I have mentioned this already in the previous message, but I gue=
ss this got lost in the traffic.











Each "m=3D" and c=3D" line MUST=
 be filled in with the port,
protocol, and address of the default candidate for the m=3D section,=
 as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.



















For media m=3D sections, JSEP impleme=
ntations MUST support the "UDP/TLS/RTP/SAVPF" profile specified i=
n [RFC5764], and MUST indicate this profile for each media m=3D line they p=
roduce in an offer. For data m=3D sections,
 implementations MUST support the "UDP/DTLS/SCTP" profile and MUS=
T indicate this profile for each data m=3D line they produce in an offer.











So, section 5.2.2 says m=3D line should be filled with currently used proto=
col, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP"=
 if default candidate is TCP based, but section 5.1.2 says it must be =
"UDP/TLS/RTP/SAVPF" or "UDP/DTLS/SCTP",
 even if default candidate is TCP based. I thought that section 5.2.2, sinc=
e it is more specific, overwrites 5.1.2, which I assumed only applies to IC=
E restart. Authors disagree and want to update the document.












In terms of changing technical aspects of JSEP: the only reason the docu=
ment is out of the RFC Editor's queue right now is to address issues arisin=
g from rationalizing the reference to RFC 8445 within Cluster 238. This is =
not an opportunity to re-litigate
 previously settled consensus decisions. Technical issues such as the one a=
t hand should have been raised during WG development, WG last call, or -- i=
n extremis, since you're a regular RTCWEB participant -- during IETF last c=
all. It's up to the chairs what
 to allow, but I wouldn't expect anything other than catastrophic flaws to =
be open for change at this time.






I am not the one who opened this can of worms. I am fine if the curren=
t draft version is not changed. This is why I did not comment during the WG=
 last call. Draft authors are introducing the new change in https://github.com/rtcweb-wg/jsep/pull=
/857,
 which makes JSEP incompatible with ice-sip-sdp. I oppose this change. =
;If the group considers that a change to clarify things is necessary, I wou=
ld suggest that section 5.1.2 should be changed instead to that it only app=
lies during ICE restart, so that JSEP
 is compatible with ice-sip-sdp.







Regards,


______________


Roman Shpount




















--_000_AM6PR07MB5621291E0EA9E72A8065380A93AE0AM6PR07MB5621eurp_--


From nobody Mon Dec  3 13:01:42 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC9C12D4E8 for ; Mon,  3 Dec 2018 13:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.748
X-Spam-Level: 
X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=eT2Ccvnc; dkim=pass (1024-bit key) header.d=ericsson.com header.b=QGbagpeE
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 y6kbk1ZGGpgo for ; Mon,  3 Dec 2018 13:01:37 -0800 (PST)
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 A64241200B3 for ; Mon,  3 Dec 2018 13:01:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543870894; x=1546462894; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EKw/QLGCbgLxmUXvVU3VwlZVGnvla7kVfg8JkuMpAdY=; b=eT2CcvncwLvFNs15pUbi3NK8nza+dsKNH7cqWl2zh1kuF4nzHPRbuV+RwK3KFtqC MoemIVF3B98cw7cgz6DIfRecBsjLsNdib1vCdsPGexko6LoMiPW6g1qEUrdRnKzp 3ePDAk7qPNUJRiAmSQxPTECL/h+tVvpjNYZyOZtoUfg=;
X-AuditID: c1b4fb25-5e9ff7000000191f-62-5c0599ae476a
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5B.DC.06431.EA9950C5; Mon,  3 Dec 2018 22:01:34 +0100 (CET)
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 3 Dec 2018 22:01:34 +0100
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 3 Dec 2018 22:01:34 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EKw/QLGCbgLxmUXvVU3VwlZVGnvla7kVfg8JkuMpAdY=; b=QGbagpeEv8bZ9agK4DVHFvS3+cOB/SmlzNC/dQV4zX4MfIY1OCp8qa1vc68TQE3dUfz5W8XLHs4g1vLgZZ6QrijB4cMpEyEbS8vC5ly53RIJYd0HF8y9iBswz9++kAsstKqX3CStv2BcoRI4939s/fGo087qdIIDkle5I961PJE=
Received: from AM6PR07MB5621.eurprd07.prod.outlook.com (20.178.91.14) by AM6PR07MB5415.eurprd07.prod.outlook.com (20.178.88.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.7; Mon, 3 Dec 2018 21:01:33 +0000
Received: from AM6PR07MB5621.eurprd07.prod.outlook.com ([fe80::a5dd:4302:feec:e113]) by AM6PR07MB5621.eurprd07.prod.outlook.com ([fe80::a5dd:4302:feec:e113%3]) with mapi id 15.20.1382.020; Mon, 3 Dec 2018 21:01:33 +0000
From: Christer Holmberg 
To: Roman Shpount , Adam Roach - SIPCORE Chair 
CC: RTCWeb IETF , mmusic WG 
Thread-Topic: [rtcweb] [MMUSIC] Default proto transport in JSEP
Thread-Index: AQHUhquP7oWmB9W6S0+oK/sz+g4vAaVlZEyAgAAFLoCAABfmgIAABUCAgAf/CNyAAAM1xA==
Date: Mon, 3 Dec 2018 21:01:33 +0000
Message-ID: 
References:   <9B9B741B-622F-4565-899B-700636408F6C@iii.ca>  <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com>  <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca>  <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com>, , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [37.136.29.129]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM6PR07MB5415; 6:I/Ng3/6IlQEkTYbjWQdsShBTGXJpopugLvEdUk0z6x2R4o3VDb8twS23sEYSHIbA2yCVaxMLaPAlbPofoOlR/OjwVgANwgAYwUppd8YTAAkMvpi8xn0q60FbWeAicckpS9sg2aWHbzvpyDurKJr8w8CLNi+nhMqQvA3nPDng2lZVaETZTjc6cQKQS0tTNVWzhTkjMHwXN9MGoO9czHH19Ay6Mzjh48vd77TCUkQm2Z8QKcrcx9VH0I4DViB/DAyvkrgOBxTErgb9P7/n575jjdHNsaJ71sIsz4RtpiEE1N47/1sO5dohOklj/cLGHuz2Ov5gutT8OwAyjfAAFklFc6xKs01/CGSDkpAezV/ilqtN/44sdpP6JZg0oBb9gKqqCWez8jDY2h5B/KZmwVqqv6a0YIyO0dgnxZ7GUONeuFY5QWBtVNpPyowwA1vU/AwdzjXViZYFkLib84YrLSmqUQ==; 5:PIO5A5zkJhRa9cqjmxUecyrBhGkM7bbgbWVIOQ4RXNAyuHIPGlxNft8hb8dWIdg9Dwct3pyWwQ97EDyc7fY2PUHvs7Av4czt7I6w29t/GbRbr4uV2K8O3gRTebChifuKe+geCYO2URAd3PshlJLOaz6xOGP+yPtSUhWpstBwxNU=; 7:9xqGznCy/a6zzdis/DKJeXeVzCDvfjtubQiLdrROwvW874dG4ITcFuakta7UGmHreV6MBbJjv2gajiFyAbdFgrFp+qPWl3DUDBhOdBEmLmLTO1zDuUc8gX47Wqu54zL4ufZRXlO1fow6WFOAUOU0BQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 02f1e7b7-c5aa-44fc-11dd-08d6596281ab
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB5415; 
x-ms-traffictypediagnostic: AM6PR07MB5415:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231455)(999002)(944501493)(52105112)(10201501046)(148016)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB5415; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB5415; 
x-forefront-prvs: 08756AC3C8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(136003)(346002)(376002)(199004)(189003)(2940100002)(6606003)(54896002)(93886005)(97736004)(54906003)(9686003)(6246003)(55016002)(66066001)(14454004)(53936002)(6116002)(4326008)(5070765005)(236005)(110136005)(6436002)(6506007)(76176011)(476003)(478600001)(53546011)(486006)(7696005)(93156006)(44832011)(966005)(3846002)(6306002)(5660300001)(186003)(26005)(99286004)(229853002)(68736007)(8676002)(71190400001)(86362001)(106356001)(74316002)(446003)(81166006)(2906002)(7736002)(71200400001)(102836004)(33656002)(316002)(8936002)(14444005)(256004)(11346002)(105586002)(19627405001)(81156014)(606006)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5415; H:AM6PR07MB5621.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: wsnJItF5ogj3GFPA6xmVR85x+WRMP3pnF89m4yR106EX5RmGFr8+LjnD/sMVCAZrO/8JaSW4PUI/uUSLJ+aqkt3oPPZs3ASyenvZ8t1npEXyxelM2wRtUkBYrJZZwCOKVtPqTocw6+5gKyTeRou5CNGtdFsTfKHBqgc9IPmqBLl0nCOHdzyM2QVDH+AgHBe1ruP0NoP/L/xyI1gtu1IKDgIICMukyj4YXho0ALgC5hix1TFxUDBbC5B9tkqVlAgxepr2p+28jfAHMI6m6hn9TzjICV5d1/NXZyF8HhhexXbqNu+WYgElWZW3C8JUHpJSO3TfYLP2vD3akZpWO0UiQAa9YGqc95R8JRQrF+jhROg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM6PR07MB562184CD3351856DBC45A71B93AE0AM6PR07MB5621eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 02f1e7b7-c5aa-44fc-11dd-08d6596281ab
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 21:01:33.6172 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5415
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHe97L9moO3paXk1LQyj4oc2pCI0zLL9kHrU8hOsuVLyrqnNs0 TQVRIpuINlzeKs1mXihpJjbNyE2LWrPZ7GJCobjScpWRJuUt3TvBb79zzv/P/5yHh8L5/aQv lSZTMQqZNEPAcSfq4h5eEHbWkZLg50Nicf9KM1esbZ0ixLUjWlx8b/Uy9ygRrdP9xaLre+1E 9Hi1/BQe7x6ezGSk5TIKUUSSe2qX8SNXrm9Dee3frFgxMmqQGrlRQIeB2TGIqZE7xaeHEEyX feewxQKCNdsMwRa3Mei0mJ0ygq7CwdJ3xSWrxODf8hjJFpMIvtQsrE8oikOLoXw1cCPEkz4N 95d+OQNxOgKe1r7HNnjnOt8YLSNYTSQYtSXkpr6p14FvMEHvh0/qCqeGR0ug3nbVtdIwCdaB l06DG50Ib0pbnAGI9oZF812MDfOBcXsjxl5Kg67firPsBV+nVkmW94JZPc9leTfYGsvRRgDQ 7zhQOzhBsAMhzGm1LnMM9NSoCVY0gmDuWoVLFACPFx5h7BZSeNIx4TKkw7PPl1zvvQc6KiZd ZisO5rezqAqJ6rdsy3IW9Br0TubRO+BFnZ1g+8Hw81UjznIg3Lk162IR6OeH0dZ+E+J2IC8l ozyXmRJ6MIhRpJ1XKrNkQTJG1YXW/5Sxe8nfgEYdx0yIppDAgxdVSUr4pDRXmZ9pQkDhAk+e PJuQ8HnJ0vyLjCLrrCIng1GakB9FCHx4k4cexPPpFKmKSWcYOaPYnGKUm28xyhZ+aN/up4gr ij1RKNMUHLb1lFaFnTzTPBSu9xB6dP92E415W48Xh+sb7KM+OZmOluoj6UVtVtKv9cdAzNq+ kriEOv6BysjrJl2StqswJG869OacZckQ1eeZEFu9vBZUb9G8tspLhLH5STPWhgKVv2ZlG2+e gxar6T+JcYZdAkKZKg0JwBVK6X9lnzDkTwMAAA==
Archived-At: 
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2018 21:01:40 -0000

--_000_AM6PR07MB562184CD3351856DBC45A71B93AE0AM6PR07MB5621eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,


In addition, even from a pure WebRTC perspective, there is no guarantee tha=
t both endpoints are implementing JSEP, so any WebRTC-specific ICE modifica=
tion would probably have to be done in a separate document.


Regards,


Christer


________________________________
From: rtcweb  on behalf of Christer Holmberg 
Sent: Monday, December 3, 2018 10:58 PM
To: Roman Shpount; Adam Roach - SIPCORE Chair
Cc: RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP



Hi,

I am jumping late into the circle, but I share Roman's concern regarding th=
e suggested change to 5.2.2. I think the WHOLE m=3D line (including the pro=
tocol) shall match the currently used properties. You may also end up havin=
g SDP attributes that are not defined the for the indicated protocol (since=
 you are using another protocol). That is asking for interoperability probl=
ems, in my opinion.

I've probably missed it, but what is the "catastrophic flaw" (to use Adam's=
 words) that would require this change, and misalign the JSEP ICE procedure=
s from all the documents Roman listed?

Regards,

Christer

________________________________
From: rtcweb  on behalf of Roman Shpount 
Sent: Wednesday, November 28, 2018 8:41 PM
To: Adam Roach - SIPCORE Chair
Cc: RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP


Hi Adam,

On Wed, Nov 28, 2018 at 1:22 PM Adam Roach > wrote:

On 11/28/18 10:57 AM, Roman Shpount wrote:
On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings > wrote:
On Nov 27, 2018, at 4:46 PM, Roman Shpount > wrote:

 I suggest to update JSEP section 5.1.2 to match the rest of the documents =
to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When=
 ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto MUST be used if =
default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto M=
UST be used if default (only) candidate is TCP candidate.

I don=92t see any real befits to implementations to this change and I don=
=92t think the rtcweb consensus was around the currently solution. Do you s=
ee some advantage to implementations to this?

This is what every other document related to ICE, including JSEP section 5.=
2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB ne=
ed a really good reason why it needs to be different.

It would probably help clarify things if you quoted the parts of the docume=
nt that you think are in conflict. I can't find any explicit  field =
handling in 5.2.2.

 I have mentioned this already in the previous message, but I guess this go=
t lost in the traffic.

JSEP-25 in section 5.2.2 says (https://tools.ietf.org/html/draft-ietf-rtcwe=
b-jsep-25#section-5.2.2):

Each "m=3D" and c=3D" line MUST be filled in with the port, protocol, and a=
ddress of the default candidate for the m=3D section, as described in [I-D.=
ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.

At the same time section 5.1.2 says (https://tools..ietf.org/html/draft-iet=
f-rtcweb-jsep-25#section-5.1.2):

For media m=3D sections, JSEP implementations MUST support the "UDP/TLS/RTP=
/SAVPF" profile specified in [RFC5764], and MUST indicate this profile for =
each media m=3D line they produce in an offer. For data m=3D sections, impl=
ementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this=
 profile for each data m=3D line they produce in an offer.

So, section 5.2.2 says m=3D line should be filled with currently used proto=
col, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP" if default candidat=
e is TCP based, but section 5.1.2 says it must be "UDP/TLS/RTP/SAVPF" or "U=
DP/DTLS/SCTP", even if default candidate is TCP based. I thought that secti=
on 5.2.2, since it is more specific, overwrites 5.1.2, which I assumed only=
 applies to ICE restart. Authors disagree and want to update the document.

In terms of changing technical aspects of JSEP: the only reason the documen=
t is out of the RFC Editor's queue right now is to address issues arising f=
rom rationalizing the reference to RFC 8445 within Cluster 238. This is not=
 an opportunity to re-litigate previously settled consensus decisions. Tech=
nical issues such as the one at hand should have been raised during WG deve=
lopment, WG last call, or -- in extremis, since you're a regular RTCWEB par=
ticipant -- during IETF last call. It's up to the chairs what to allow, but=
 I wouldn't expect anything other than catastrophic flaws to be open for ch=
ange at this time.

I am not the one who opened this can of worms. I am fine if the current dra=
ft version is not changed. This is why I did not comment during the WG last=
 call. Draft authors are introducing the new change in https://github.com/r=
tcweb-wg/jsep/pull/857, which makes JSEP incompatible with ice-sip-sdp. I o=
ppose this change. If the group considers that a change to clarify things i=
s necessary, I would suggest that section 5.1.2 should be changed instead t=
o that it only applies during ICE restart, so that JSEP is compatible with =
ice-sip-sdp.

Regards,
______________
Roman Shpount

--_000_AM6PR07MB562184CD3351856DBC45A71B93AE0AM6PR07MB5621eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable










Hi,







In addition, even from a pure Web=
RTC perspective, there is no guarantee that both endpoints are implementing=
 JSEP, so any WebRTC-specific ICE modification would probably have to be do=
ne in a separate document.







Regards,







Christer










From: rtcweb <rtcweb-bou=
nces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@eric=
sson.com>

Sent: Monday, December 3, 2018 10:58 PM

To: Roman Shpount; Adam Roach - SIPCORE Chair

Cc: RTCWeb IETF; mmusic WG

Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

 














Hi,









I am jumping late into the circle, but I share Roman's concern regarding th=
e suggested change to 5.2.2. I think the WHOLE m=3D line (including the pro=
tocol) shall match the currently used properties. You may also end up havin=
g SDP attributes that are not defined
 the for the indicated protocol (since you are using another protocol). Tha=
t is asking for interoperability problems, in my opinion.









I've probably missed it, but what is the "catastrophic
 flaw" (to use Adam's words) that would require this change, and misal=
ign the JSEP ICE procedures from all the documents Roman listed?








Regards,









Christer








From: rtcweb <rtcweb-b=
ounces@ietf.org> on behalf of Roman Shpount <roman@telurix.com>
Sent: Wednesday, November 28, 2018 8:41 PM

To: Adam Roach - SIPCORE Chair

Cc: RTCWeb IETF; mmusic WG

Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

 















Hi Adam,








On Wed, Nov 28, 2018 at 1:22 PM Adam Roach <adam@nostrum.com> wrote:













On 11/28/18 1=
0:57 AM, Roman Shpount wrote:










O=
n Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <fluffy@iii.ca> wrote:
















On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> wrote:




 I
 suggest to update JSEP section 5.1.2 to match the rest of the documents to=
 say that "UDP/TLS/RTP/SA=
VPF"
 proto MUST be used during ICE restart. When ICE restart is not in progress=
, "UDP/TLS/RTP/SAVPF"=
; proto
 MUST be used if default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto
 MUST be used if default (only) candidate is TCP candidate.








I don=92t see any real befits to implementations to this change and I =
don=92t think the rtcweb consensus was around the currently solution. Do yo=
u see some advantage to implementations to this?











This is what every other document related to ICE, including JSEP secti=
on 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCW=
EB need a really good reason why it needs to be different.








It would probably help clarify things if you quoted the parts of the doc=
ument that you think are in conflict. I can't find any explicit <proto&g=
t; field handling in 5.2.2.








 I have mentioned this already in the previous message, but I gue=
ss this got lost in the traffic.











Each "m=3D" and c=3D" line MU=
ST be filled in with the port,
protocol, and address of the default candidate for the m=3D section,=
 as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.



















For media m=3D sections, JSEP impleme=
ntations MUST support the "UDP/TLS/RTP/SAVPF" profile specified i=
n [RFC5764], and MUST indicate this profile for each media m=3D line they p=
roduce in an offer. For data m=3D sections,
 implementations MUST support the "UDP/DTLS/SCTP" profile and MUS=
T indicate this profile for each data m=3D line they produce in an offer.











So, section 5.2.2 says m=3D line should be filled with currently used proto=
col, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP"=
 if default candidate is TCP based, but section 5.1.2 says it must be =
"UDP/TLS/RTP/SAVPF" or "UDP/DTLS/SCTP",
 even if default candidate is TCP based. I thought that section 5.2.2, sinc=
e it is more specific, overwrites 5.1.2, which I assumed only applies to IC=
E restart. Authors disagree and want to update the document.












In terms of changing technical aspects of JSEP: the only reason the docu=
ment is out of the RFC Editor's queue right now is to address issues arisin=
g from rationalizing the reference to RFC 8445 within Cluster 238. This is =
not an opportunity to re-litigate
 previously settled consensus decisions. Technical issues such as the one a=
t hand should have been raised during WG development, WG last call, or -- i=
n extremis, since you're a regular RTCWEB participant -- during IETF last c=
all. It's up to the chairs what
 to allow, but I wouldn't expect anything other than catastrophic flaws to =
be open for change at this time.






I am not the one who opened this can of worms. I am fine if the curren=
t draft version is not changed. This is why I did not comment during the WG=
 last call. Draft authors are introducing the new change in https://github.com/rtcweb-wg/jsep/pu=
ll/857,
 which makes JSEP incompatible with ice-sip-sdp. I oppose this change. =
;If the group considers that a change to clarify things is necessary, I wou=
ld suggest that section 5.1.2 should be changed instead to that it only app=
lies during ICE restart, so that JSEP
 is compatible with ice-sip-sdp.







Regards,


______________


Roman Shpount


























--_000_AM6PR07MB562184CD3351856DBC45A71B93AE0AM6PR07MB5621eurp_--


From nobody Mon Dec  3 13:05:44 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6B11294D0 for ; Mon,  3 Dec 2018 13:05:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level: 
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 2L8vUVk57q-m for ; Mon,  3 Dec 2018 13:05:40 -0800 (PST)
Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 D029A1200B3 for ; Mon,  3 Dec 2018 13:05:39 -0800 (PST)
Received: by mail-vk1-xa2f.google.com with SMTP id h128so3257674vkg.11 for ; Mon, 03 Dec 2018 13:05:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+kmndj1NgXPDHTbA6TRtchzpxjhq0S85XlPUSonY9UM=; b=m/A1dkQTyJ7pllntRXTpJc6ia/WAJ/DKgLpE5D0GjQeEFINMtirtkY7TFMt4OBAFIP xB1o3QIUhdZpo7yzj90vyylqrAymCcNj9e0i7lD1S1k+dBZRAyCPz+X7fYF1LPSJC6r+ Lz1mgPjqO4IxZBOcvCVo2H75+r2V05rpgXqGzi82kHQRShJWI+WWHRRu6TqKaOZLSPnj ueGid7flCfrBPYImTOaqulce72xMDMQTCuF0PyMv/0APv29c/sqJxYZtSWICxGfhsXRm H1T3Nl1ERipS9CITSxebevE8YAh/mmAksk/czgBgSrNdL0RgKCGc8WXTArPm0GQ2leNB 7prQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+kmndj1NgXPDHTbA6TRtchzpxjhq0S85XlPUSonY9UM=; b=qNIPoCjTLyli7W08AfVye5yCqQgBx9IgecLj4X1CT2fqJajM4MUcJkmGxuDt6m/51S LaRPt9A49T92k1CMMxZHypBfBn+Ax9Gfhsq4bWHS7zkq9jOCzG52vrZq2zEopK9qRaYb QS+PGozi6lzTt6ba8F8OifPLgVb8iH5kTe62ccNfUnH+JhZE4f06WAvshfgTtLXo6EJi 8N8yBdo7HcDzEAwlagIDtBIE4aekBsEzGzoUa0JB5OMM9TfSN7kZdXns3guuLt5N2XCn oG/0o3WRdYZwMR1wnFOtwoDhgd6JRPAM210lLbawB/EaU1YVm6kXiyKLJRz1prOk0U+d i+aA==
X-Gm-Message-State: AA+aEWYJoymASuhSGrRQZVVkTnEI8tA0x5mvPo3kjsBPtFZ5oulnYo+q 662kb7/xwHVGVfI4rOtyBKcJiQN0iVAMmrDANMVD+g==
X-Google-Smtp-Source: AFSGD/WZIGMrfP63ygbWFAVIzkPyFP5S1A7Ti1FiWE0JAbE1kO7sVh9SJtFjVBhNNeZ97v7/akgTApGUqvwcd4G1q5s=
X-Received: by 2002:a1f:8b48:: with SMTP id n69mr7566183vkd.12.1543871138506;  Mon, 03 Dec 2018 13:05:38 -0800 (PST)
MIME-Version: 1.0
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>
In-Reply-To: <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 3 Dec 2018 22:05:27 +0100
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Magnus Westerlund , rtcweb@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2018 21:05:42 -0000

On Mon, 3 Dec 2018 at 14:32, Sergio Garcia Murillo
 wrote:
> Given than rid is not globally unique but unique per mid, the rtx packet
> would need to include the mid anyway, wouldn't rid be redundant for
> non-simulcast use case?

All the streams (ssrcs) belonging to the same "source" and
"transceiver" should have the same MID.
MID should be used as the first demux mechanism to identify the
"source" or "transceiver".
Then inspect RID, ssrc and PT to match the exact media/RTX/FLEXFEC stream.


--=20
I=C3=B1aki Baz Castillo



From nobody Mon Dec  3 13:22:45 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ACF12D4ED for ; Mon,  3 Dec 2018 13:22:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 YAz-rHk_W_jE for ; Mon,  3 Dec 2018 13:22:43 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 9D60512E043 for ; Mon,  3 Dec 2018 13:22:42 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id z18so7434884wmc.4 for ; Mon, 03 Dec 2018 13:22:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Th3u7jvTqn4lFvFr+eVtX4Kh6KkR0qIVhhLR0qUK1IA=; b=bAQCd40B/AgQSjnW+1XaWl8SPIUK+YtZ0iHN7O0zO4/ELSeEcO91C/WuVcDiHP2cn5 Q2bbYoxuX1P2cckfh2eC4P1t6icRBgGAHxXMnZuoUz54KSXVc7ck02aYpRZ9zKt0aPEl oF5CDs8KncM/B9IO02RnE9NsEUy8vvzH442nNkKCS0q1ax/Io2mYxxHs+xwbJoYWATHd rwnYaGu8SD3ejqZmFWwqys+wDJMVFzT0LDIFpXUxf5RE/iyjs1gDTeY8vU8URZc0CUor x0EaOjavRb0SyU5Eao1Cz+nG3yGr8OR2FTIGTqCs0x7HlF9FYtcB0dZzjGohQFWhHUV/ itkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Th3u7jvTqn4lFvFr+eVtX4Kh6KkR0qIVhhLR0qUK1IA=; b=NWHgrKTZjOn4dLUwzM+y382nj4wVIsIG2MECtNx/k5mCROSBulfNkpwnqWcNkprV+m bINe8vhmjV7UbUxddqbogill1QzfZA7e+shajQvYap3oz/2GH/FSiXkvgGN/FNl+b1vR Q0A3Kxq3VHaq1/NgQeT7C5zh5dS7NcImE1v0bu+pp6ZnlRT+eiuvayWzyUbZaYhA2Q0t Sig/FcJG8PDNELH6ShPt26g5fQbnVhZgXmoonqJH6Nz/sApbdiZOfiGhGGFxXvhsRGw6 ICeE7kG+zoF57nymGGq/eiA2TmVsIsNYowgxRR//JymMUhjbIMAvyf4+RAC/Q6a0JPiy exJA==
X-Gm-Message-State: AA+aEWa/MC0EdIAZRhrgjs2qhCqPY4bsajqBjVFhVoUa3Fjb+RuvUiU5 n4EjW8S+ey5QH1BsadS5MnBBQ1fI
X-Google-Smtp-Source: AFSGD/UgZVmMvSGctg2SGukuBt0BaKKswpgbaZnb9XozFvz9rU7lNgAFdeRjvFIr8LGOXvt+GPv8eg==
X-Received: by 2002:a1c:f116:: with SMTP id p22mr9953090wmh.0.1543872160813; Mon, 03 Dec 2018 13:22:40 -0800 (PST)
Received: from [192.168.0.11] (89.141.9.215.dyn.user.ono.com. [89.141.9.215]) by smtp.googlemail.com with ESMTPSA id j33sm28313552wre.91.2018.12.03.13.22.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Dec 2018 13:22:40 -0800 (PST)
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: Magnus Westerlund , rtcweb@ietf.org
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>
Date: Mon, 3 Dec 2018 22:26:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2018 21:22:44 -0000

On 03/12/2018 22:05, Iñaki Baz Castillo wrote:
> On Mon, 3 Dec 2018 at 14:32, Sergio Garcia Murillo
>  wrote:
>> Given than rid is not globally unique but unique per mid, the rtx packet
>> would need to include the mid anyway, wouldn't rid be redundant for
>> non-simulcast use case?
> All the streams (ssrcs) belonging to the same "source" and
> "transceiver" should have the same MID.
> MID should be used as the first demux mechanism to identify the
> "source" or "transceiver".
> Then inspect RID, ssrc and PT to match the exact media/RTX/FLEXFEC stream.
>
My point is that there is a single source in the transceiver/MID why 
should we add default RID and waste 2 more bytes in each media and rtx 
packet?


Best regards

Sergio


From nobody Mon Dec  3 13:26:33 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4468C129BBF for ; Mon,  3 Dec 2018 13:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level: 
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 vb7aNheTqWgI for ; Mon,  3 Dec 2018 13:26:29 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 B027012D4ED for ; Mon,  3 Dec 2018 13:26:29 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id b74so8470064vsd.9 for ; Mon, 03 Dec 2018 13:26:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ObYiMzF2Kny3EEUTs1i8LA3YOJV4Mm72trqgRV2AkLI=; b=LFKQE2/dcRjSitjdUWqXk7+/utcFi5LILZuJdPWDOVlWFdkZ89GzcgdZhz1NN6lpfm v8noY7ISZAIC5yNJxXm5XLBKXt+c6S+qiybowf9awhM5e9tlRRYorHM1Z5p+ZOY53rH6 +QczktLIquhINsS+1rhVVRqkpRGsrOtFPJx0Blk1utAn/azWEV9P7WOPCTs68zxQtlhq 3bboZ7Z3NmIqSk0lMyGfDAWlFXgpaIzL+dln2jAeSRYGFVxlhFQ2/5ZQxTJDqFQz+V+d StmTSvewvfChHNeVrKqzmBZuCDYz7esiy8EisklULd/MWFBBaZA5VRDp2YIYcHwKuUaO aEqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ObYiMzF2Kny3EEUTs1i8LA3YOJV4Mm72trqgRV2AkLI=; b=QnrWJvk9Sg0VrPBaNwQoCERcxNcm/pEsJa6C3QwvSS8Bapgd/WSnGsnJ57LD+FbTTp FllJvSKCtIs2++Illx0YMaaXOjnUjwPcIpT/0JEeKTLKNBIzlmRXgCeGAhgN8nErNPCe 4Jq/2KxIqgQhli+iHJ7QRkdH6uSjeP/wE4FVknfzWUAeIJMAD/o41UCBaWu0WXRdFQEn mcrsXLjDfx384ktrN4vT2N4SQ0hQz931CGbupQx9fXX9Vvw0tacDBtHhSJl6YxYG699o 1XH64evq8f8AVwPYJ2U0Dj0rVEQ87Hx7+9qHgQrRJYvJfkkR2cmTWIBrQ3ReglDhNJuC XbWw==
X-Gm-Message-State: AA+aEWY/LuQgBteEn3t22o3OKyPlkRyxh5HbFfNZ/rGGhr32gHZzwuFP ozMq6+YfYBJNVNoRRcvcHng2QHBchM2pJDzbcqienA==
X-Google-Smtp-Source: AFSGD/WGayP6lWS5fi6McyUUgKegKX8px4f8aEW79P1OXwEDzqXLUbYcYqk3aV/uQjvBrQORl6Ar+NWSiuSOFiu8DaQ=
X-Received: by 2002:a67:6346:: with SMTP id x67mr7389357vsb.114.1543872388768;  Mon, 03 Dec 2018 13:26:28 -0800 (PST)
MIME-Version: 1.0
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>  <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>
In-Reply-To: <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 3 Dec 2018 22:26:17 +0100
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Magnus Westerlund , rtcweb@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2018 21:26:32 -0000

On Mon, 3 Dec 2018 at 22:22, Sergio Garcia Murillo
 wrote:
> My point is that there is a single source in the transceiver/MID why
> should we add default RID and waste 2 more bytes in each media and rtx
> packet?

Regardless what browsers do today, both MID and RID headers should be
just included in the first packets. The receiver is supposed to update
its ssrc table for faster matching.

NOTE: The sender should also resend MID and RID if the SSRC changed
because some RFCs state that SSRCs may conflict and things that
absolutely never happen.

--=20
I=C3=B1aki Baz Castillo



From nobody Mon Dec  3 13:30:49 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFDE12D4ED for ; Mon,  3 Dec 2018 13:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level: 
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 kYbzIvxu-NYM for ; Mon,  3 Dec 2018 13:30:46 -0800 (PST)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 C0BB4129BBF for ; Mon,  3 Dec 2018 13:30:45 -0800 (PST)
Received: by mail-ua1-x931.google.com with SMTP id d19so4988340uaq.11 for ; Mon, 03 Dec 2018 13:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zGPzTTFylWPwAsvUFrJuHG0/inqtFXMTtrgiVTh8gsk=; b=N1g3vJafr6bWCdnd3gIvxrSEWuQoiED4+6tm732/Ro0G+AqtMMq6+Qd3JcaZNh0bCD 7LXmKH09v6SMWDxXO6Le1zZj3kWPXcBA3mSl8LrdOXYDmYMoFtHiqx/TrVx5FlGc6dv4 wVZETd0untz7crmZeSKkSznHJMCK6sn8yC2+1FjzO8WCqU+7yoq0/gkEiWW1RYAUI7Ai BX4se3N4PAOHLbm1DVMpEWf8tGcHXIEuiY7Q14RgLBus2BLjKGEYkhP1vAySQCRKol7P RyvAKaZwq7qLpkW7JMAdmt53yJ6pqKCrh9pUoH9PEogaRio6JqYQlpUU/BwT6C0PoC+z oHoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zGPzTTFylWPwAsvUFrJuHG0/inqtFXMTtrgiVTh8gsk=; b=UOmQqzqRt2IixfteunPn/70RDuslAcTWuo8ovs9Rq8bBYwy9Y4ki21LPAu5Ez/j8Ou dVB/bO/yYWjKRnDMomLuaqOWGqYU5N+lg/YO4ff91+jzLff3Yx6Ob8w8dG7u+mWPBftv BDYC3zxEJvl614A7b4EnNKwZLG+0gs3TG+ORoXQajtDlaEMd/nIsLdUpGDI0exO0o6OJ JzC4jSUTof6MrmpLNh/R3/o8quSP58lwbOCQ6QYFIOn9UQbmMlY0ysAZgcDGXeZhn6ok ECb7mCQzNvGH6qSqCd5f3iW5I3Eo15S5U5td+l4w5tgkJfNuQHdrz08qbdrWy0A0tlH8 VuMg==
X-Gm-Message-State: AA+aEWZw8sKkeyG7K4bN/kxMsU29bisISpTKKqaeb0ehVWrJJK47Fjb/ y7su4b0eo/RWJWuhwE8zchiLlmMK+sne4TmGeYMvOQ==
X-Google-Smtp-Source: AFSGD/XttfrEDfazXF7wKNRQmcEcwupZR3eyweyfQSohueffUbknNorbyROBNuA53d/Iaz7AAS5EEKJbPcbv5kLg0uE=
X-Received: by 2002:ab0:7048:: with SMTP id v8mr7566022ual.84.1543872644696; Mon, 03 Dec 2018 13:30:44 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 3 Dec 2018 22:30:33 +0100
Message-ID: 
To: Magnus Westerlund 
Cc: rtcweb@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2018 21:30:47 -0000

On Mon, 3 Dec 2018 at 11:02, Magnus Westerlund
 wrote:

> To attempt to restate your question. For RTP sessions, where there are a
> single source media stream per Media Description in SDP (m=3D block) and
> where there is explicit MID signalling and SSRC signalling, then one
> will not need RepairedStreamId and can instead rely on explicit MID
> signalling for the RTX stream?
>
> I think no. I think using RepairedStreamId independent if there is
> multiple source RTP streams or not per media description provides a more
> consistent experience.

So, you say that the receiver would receive both media and RTX streams
with same RID values, and then the receiver would decide whether it's
a media or a rtx packet based on PT, right?


> However, as noted at the start. The use of RepairedStreamId for RFC4588
> RTX format is not well defined and how to handle and detect legacy. So,
> I think an update should be done.

Is that issue related to the fact that RTX packets are supposed to
also carry original packet header extensions?

Why is there any problem with 4588? This is just about the browser
adding RID to RTX packets. That breaks nothing in RFC 4588 (IMHO).


--=20
I=C3=B1aki Baz Castillo



From nobody Mon Dec  3 14:27:32 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D78130DF5 for ; Mon,  3 Dec 2018 14:27:31 -0800 (PST)
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 93zS55i6EtlA for ; Mon,  3 Dec 2018 14:27:30 -0800 (PST)
Received: from smtp73.iad3b.emailsrvr.com (smtp73.iad3b.emailsrvr.com [146.20.161.73]) (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 171C8130DF2 for ; Mon,  3 Dec 2018 14:27:30 -0800 (PST)
Received: from smtp10.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp10.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id 495DCE0326; Mon,  3 Dec 2018 17:27:29 -0500 (EST)
X-Auth-ID: fluffy@iii.ca
Received: by smtp10.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 3F038E025A;  Mon,  3 Dec 2018 17:27:27 -0500 (EST)
X-Sender-Id: fluffy@iii.ca
Received: from [10.66.246.3] ([UNAVAILABLE]. [64.104.248.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.12); Mon, 03 Dec 2018 17:27:29 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings 
In-Reply-To: <0293CF6D-9B4F-4680-BBB9-833C33D03013@sn3rd.com>
Date: Mon, 3 Dec 2018 15:27:25 -0700
Cc: RTCWeb IETF 
Content-Transfer-Encoding: quoted-printable
Message-Id: <00FB4C71-EBD9-4EF6-A3B1-D0C06EA61A53@iii.ca>
References: <0293CF6D-9B4F-4680-BBB9-833C33D03013@sn3rd.com>
To: Sean Turner 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [rtcweb] status: draft-ietf-rtcweb-security-arch
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2018 22:27:32 -0000

Why would we want to prohibit false start? I has assumed we could use it =
for early media. Is there an issue we should be aware of ?



> On Nov 21, 2018, at 10:54 AM, Sean Turner  wrote:
>=20
> Hi!
>=20
> We are getting to the point where we be able to move =
draft-ietf-rtcweb-security-arch
> (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/) to =
our AD for IETF LC.
> ekr has noted in PR that follows that false start should be =
prohibited:
>=20
> https://github.com/rtcweb-wg/security-arch/issues/82
>=20
> If there is any concerns with merging addressing this issue please =
speak up.
>=20
> Cheers,
>=20
> stp
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


From nobody Mon Dec  3 23:05:13 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09E130DF7 for ; Mon,  3 Dec 2018 23:05:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.747
X-Spam-Level: 
X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=HDgGj0zU; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Ii3DFAwC
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 jqagvt4mL7zy for ; Mon,  3 Dec 2018 23:05:03 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 6C1AF130DFB for ; Mon,  3 Dec 2018 23:05:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543907093; x=1546499093; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kW30SeQVV0iLRu6mGsms3kYeKNWnTNixXxfKqw55OEw=; b=HDgGj0zUIGXSx/qmDgDDIWX+8fDOGMf5X/6Mv3dcWHL8E+CUnTeTg5/uhEUzj5QA EnNHfT/bQa/+Qw9Jl/DyZMqDGh7Je+VWACdSqzlh8cOP0ZjnOAJR7tEotgyxeJ3n JZXrJbQfxYDEEdcWGIUtP2fWx0WOPNnV0LA4jfsaurI=;
X-AuditID: c1b4fb30-39c4e9e0000043c4-0c-5c0627152985
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 08.99.17348.517260C5; Tue,  4 Dec 2018 08:04:53 +0100 (CET)
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Dec 2018 08:04:50 +0100
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 4 Dec 2018 08:04:50 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kW30SeQVV0iLRu6mGsms3kYeKNWnTNixXxfKqw55OEw=; b=Ii3DFAwCSZzj4amanwpEmIRJX/HzyIYd08fsCySCVSxBMS6wqqjxzhdhh03b0LlLFol6s+WF5pOckzji0xwutKiU0ywW+pB4lzeWMMboUUF8s7r8bfFsuPc+VZGivobhPLpFBbh+nabfOcs1EMEXT13cmbfZMSOpZG7xMpcFetk=
Received: from AM6PR07MB5621.eurprd07.prod.outlook.com (20.178.91.14) by AM6PR07MB4486.eurprd07.prod.outlook.com (20.177.38.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.7; Tue, 4 Dec 2018 07:04:50 +0000
Received: from AM6PR07MB5621.eurprd07.prod.outlook.com ([fe80::a5dd:4302:feec:e113]) by AM6PR07MB5621.eurprd07.prod.outlook.com ([fe80::a5dd:4302:feec:e113%3]) with mapi id 15.20.1382.023; Tue, 4 Dec 2018 07:04:50 +0000
From: Christer Holmberg 
To: Roman Shpount , Adam Roach - SIPCORE Chair 
CC: RTCWeb IETF , mmusic WG 
Thread-Topic: [rtcweb] [MMUSIC] Default proto transport in JSEP
Thread-Index: AQHUhquP7oWmB9W6S0+oK/sz+g4vAaVlZEyAgAAFLoCAABfmgIAABUCAgAf/CNyAAAM1xIAAqHN9
Date: Tue, 4 Dec 2018 07:04:49 +0000
Message-ID: 
References:   <9B9B741B-622F-4565-899B-700636408F6C@iii.ca>  <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com>  <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca>  <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com>, , , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:14bb:44:c7e:7d15:40e6:4a11:7e26]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM6PR07MB4486; 6:KPt9W5fxsCQgsRg9NtFvKMXC6gpoDEmS+jgwZoQfVhXOygqToys5hkK2H6qDz4WaqzD/dsiroSuTpApedgxGKLZOiP5rDH3NboUj0+t+W1Y/hfYnue6LwUiA/tHoapgWQq6g6pGebnU+eE1fhyjajocXbVSSYoM+S4/UrVNJgjovbxDJ0MJVpMji0paGZF3uySFOys/f2ojYbeDyEu+V6tcpYFGKZysEe/J3xxOma5Xn/zGuA7Tn/ShGfZr4PbqGmjWVSTNncz5A74E3PkYFaPxbMdmNWkB5lnmuB0NClr0JECO6BWVEdxJCSnKnb1vO8QE9/hMbg58IJVRuBt3Fic4QqaHJ0cOeEIky3pSjtUqtfaRtN+riw9OZVU3+hPWwo1TFsQDgYo/avDlLl7FFGRBaNbxd8hLRYUu/C3ceovClmF28qQN9yLXj/zmIjOdj3pjkgCWhYdfgo8XodrpbdQ==; 5:+DM+pXm09zh3RrCgIxSR+d51K0WyfWXsYETfwRLqWlD2pPqdMU4rKHtjf0GsUyqbdA+6AY7fMkg2iVCSGiTumnxqY4ZlsnPv+W2r6YQNhkVT32ETKsvklZnvuBov2Qxx5t1C33EkSwVPRg/Ahq92ldM7+4pds8C5XuZNubw2JWU=; 7:QrwgzF2bwFScmFFQ7nfY52/oA0ILjMN8Q/cQVOMJE9AD/WsXe8BjdcRcoFE61PnRHjC19wtWTyXXN3CGQ6izVu0PJOjGar0GtIhtHWyr0PNtGiEnavmgjH6t8ZDVyJxX6sW9vVOw845VShNC8SB56w==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 930080dd-f0b8-448c-39aa-08d659b6c86c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB4486; 
x-ms-traffictypediagnostic: AM6PR07MB4486:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231455)(999002)(944501493)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB4486; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB4486; 
x-forefront-prvs: 0876988AF0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(396003)(39860400002)(366004)(199004)(189003)(54896002)(486006)(6306002)(110136005)(4326008)(55016002)(446003)(11346002)(5660300001)(476003)(44832011)(9686003)(71200400001)(71190400001)(6436002)(6606003)(81166006)(966005)(68736007)(236005)(81156014)(316002)(97736004)(54906003)(606006)(8676002)(5070765005)(33656002)(86362001)(256004)(14444005)(53936002)(6116002)(99286004)(6246003)(74316002)(25786009)(186003)(8936002)(46003)(7696005)(7736002)(106356001)(105586002)(93886005)(19627405001)(478600001)(76176011)(53546011)(6506007)(14454004)(102836004)(2906002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4486; H:AM6PR07MB5621.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 4XyFwMa7JiudQ2cEhOiYKiKw17QZkShuksXbX1fwGvbKWsYG77P0uYzZkVBRrsXcBdFspvd1RhzbBgj3l2sHiX9Lp8/W/AQ7ouOaD9opjWf6+rQCIpVBj5n63tqJIkT1rahaDW0/xn5KQtOpjYu8Oj++tRnUwTbdC1KhbaKwmLc3GWub3ZgXRQblsgoyJdQftsXFSwXEDnWCE1aEvMpuYwS5Yl3dEMMaMGzlqBvjrLsc/ATgr7B7hCRMFvBApSDnmnVSu/1kCg1hGRSFm0YThaGMH6ZkV9wVNXTaXsKAQ1kMIpAsoODWnHZEkEICvF9nazSmuE61J8qBGVGBvOs0/JCr9TLv+V96OjuDn/X2DxU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM6PR07MB5621629CDF15C89D5AE048E893AF0AM6PR07MB5621eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 930080dd-f0b8-448c-39aa-08d659b6c86c
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2018 07:04:49.9698 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4486
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA03Se0hTYRQA8L7du+26nNzmzIORxAoWvhWlS4UlQdgfiRU9GItceX3gnOte s+wv0bLa8pE0muIjc2mYiqmlomSK/pFhWmHGEJlMEDXznaU1c34L/O93vnO+c84HH0XI2oU+ VLIuneV0Gq1CJCGLL7XeDPRSitQh5fn+TOffZ2LGVGMnGfOQiWDqHffEx8loi+W3ILqkfYKM tj7WxxIqydF4VpucwXLBkXGSpOW8N4S+vhXd6jYWEFnoUQUyIDcK6HCY7OgTOy2jexH0NnoY kGTTKwiyFuZEOKgSgMGQI3YGJF1IQHNHqRhnCgSQa1glcTCO4O67UoEBUZSIZsDo8Hf2ldMX oHF9YWseQUdCn3lE4LTnpsu+3CdxzTHoNmULsVUw09RIOE3SB6ClroZwtpTSavhgO4hHVYrA fMeyVe9GX4Zek23LiN4Nq/11AjzLG6wTFQL8ThosnYMEthdM2R1CbAYGcm1i7L3wucKInAOA /ioCe/WiCCcCYd5kcl0+DV25xUJcNITAkd3i6uQHJdZ+Md5CA121NteFFPjTVuayL9TmjZPY gwRsrCUUouCSbctip0H9RumWpfQueF88QeLzEJj7WEFg+0N15YzLwfBqeQBtP3+KxLXIi2f5 q6mJYWFBLJd8jefTdEE6Nr0JbX6o7pb1kDY0NRnVg2gKKdylM7+EaplQk8FnpvYgoAiFXKq/ Tqpl0nhN5m2WS7vC3dCyfA/aQ5EKbykT06yS0YmadDaFZfUs9z8roNx8shC3eHawINaTieic 3hEzrPQkD0ny15hTLze0ad9OKqeT2lamRC/Kx0aGHxZdXPcea9nfgPZV9k2nn4krKRpTLr3N CucCgqJWf+QFUFVhliOS2VEPFfP6sHx+OdS6EtRw3pzTNfNTovWJefAp9Nzs8xOj+icJEaRR 7st5LH3faXdXkHySJtSP4HjNP/PFuFZMAwAA
Archived-At: 
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 07:05:06 -0000

--_000_AM6PR07MB5621629CDF15C89D5AE048E893AF0AM6PR07MB5621eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Hi,

Also, as far as I understand, JSEP only defines an API, not a network proto=
col, so if you want to be standards compliant on the wire the JS app would =
have to modify the SDP before sending it to the network, and I do not think=
 we want that.

Regards,

Christer

________________________________
From: rtcweb  on behalf of Christer Holmberg 
Sent: Monday, December 3, 2018 11:01 PM
To: Roman Shpount; Adam Roach - SIPCORE Chair
Cc: RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP


Hi,


In addition, even from a pure WebRTC perspective, there is no guarantee tha=
t both endpoints are implementing JSEP, so any WebRTC-specific ICE modifica=
tion would probably have to be done in a separate document.


Regards,


Christer


________________________________
From: rtcweb  on behalf of Christer Holmberg 
Sent: Monday, December 3, 2018 10:58 PM
To: Roman Shpount; Adam Roach - SIPCORE Chair
Cc: RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP



Hi,

I am jumping late into the circle, but I share Roman's concern regarding th=
e suggested change to 5.2.2. I think the WHOLE m=3D line (including the pro=
tocol) shall match the currently used properties. You may also end up havin=
g SDP attributes that are not defined the for the indicated protocol (since=
 you are using another protocol). That is asking for interoperability probl=
ems, in my opinion.

I've probably missed it, but what is the "catastrophic flaw" (to use Adam's=
 words) that would require this change, and misalign the JSEP ICE procedure=
s from all the documents Roman listed?

Regards,

Christer

________________________________
From: rtcweb  on behalf of Roman Shpount 
Sent: Wednesday, November 28, 2018 8:41 PM
To: Adam Roach - SIPCORE Chair
Cc: RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP


Hi Adam,

On Wed, Nov 28, 2018 at 1:22 PM Adam Roach > wrote:

On 11/28/18 10:57 AM, Roman Shpount wrote:
On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings > wrote:
On Nov 27, 2018, at 4:46 PM, Roman Shpount > wrote:

 I suggest to update JSEP section 5.1.2 to match the rest of the documents =
to say that "UDP/TLS/RTP/SAVPF" proto MUST be used during ICE restart. When=
 ICE restart is not in progress, "UDP/TLS/RTP/SAVPF" proto MUST be used if =
default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto M=
UST be used if default (only) candidate is TCP candidate.

I don=92t see any real befits to implementations to this change and I don=
=92t think the rtcweb consensus was around the currently solution. Do you s=
ee some advantage to implementations to this?

This is what every other document related to ICE, including JSEP section 5.=
2.2 currently specifies. It was also consensus in MMUSIC. I think RTCWEB ne=
ed a really good reason why it needs to be different.

It would probably help clarify things if you quoted the parts of the docume=
nt that you think are in conflict. I can't find any explicit  field =
handling in 5.2.2.

 I have mentioned this already in the previous message, but I guess this go=
t lost in the traffic.

JSEP-25 in section 5.2.2 says (https://tools.ietf.org/html/draft-ietf-rtcwe=
b-jsep-25#section-5.2.2):

Each "m=3D" and c=3D" line MUST be filled in with the port, protocol, and a=
ddress of the default candidate for the m=3D section, as described in [I-D.=
ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.

At the same time section 5.1.2 says (https://tools..ietf.org/html/draft-iet=
f-rtcweb-jsep-25#section-5.1.2):

For media m=3D sections, JSEP implementations MUST support the "UDP/TLS/RTP=
/SAVPF" profile specified in [RFC5764], and MUST indicate this profile for =
each media m=3D line they produce in an offer. For data m=3D sections, impl=
ementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this=
 profile for each data m=3D line they produce in an offer.

So, section 5.2.2 says m=3D line should be filled with currently used proto=
col, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP" if default candidat=
e is TCP based, but section 5.1.2 says it must be "UDP/TLS/RTP/SAVPF" or "U=
DP/DTLS/SCTP", even if default candidate is TCP based. I thought that secti=
on 5.2.2, since it is more specific, overwrites 5.1.2, which I assumed only=
 applies to ICE restart. Authors disagree and want to update the document.

In terms of changing technical aspects of JSEP: the only reason the documen=
t is out of the RFC Editor's queue right now is to address issues arising f=
rom rationalizing the reference to RFC 8445 within Cluster 238. This is not=
 an opportunity to re-litigate previously settled consensus decisions. Tech=
nical issues such as the one at hand should have been raised during WG deve=
lopment, WG last call, or -- in extremis, since you're a regular RTCWEB par=
ticipant -- during IETF last call. It's up to the chairs what to allow, but=
 I wouldn't expect anything other than catastrophic flaws to be open for ch=
ange at this time.

I am not the one who opened this can of worms. I am fine if the current dra=
ft version is not changed. This is why I did not comment during the WG last=
 call. Draft authors are introducing the new change in https://github.com/r=
tcweb-wg/jsep/pull/857, which makes JSEP incompatible with ice-sip-sdp. I o=
ppose this change. If the group considers that a change to clarify things i=
s necessary, I would suggest that section 5.1.2 should be changed instead t=
o that it only applies during ICE restart, so that JSEP is compatible with =
ice-sip-sdp.

Regards,
______________
Roman Shpount

--_000_AM6PR07MB5621629CDF15C89D5AE048E893AF0AM6PR07MB5621eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable















Hi,







Also, as far as I understand, JSEP only defines an API, not a network =
protocol, so if you want to be standards compliant on the wire the JS app w=
ould have to modify the SDP before sending it to the network, and I do not =
think we want that.







Regards,







Christer








From: rtcweb <rtcweb-bou=
nces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@eric=
sson.com>

Sent: Monday, December 3, 2018 11:01 PM

To: Roman Shpount; Adam Roach - SIPCORE Chair

Cc: RTCWeb IETF; mmusic WG

Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

 








Hi,







In addition, even from a pure We=
bRTC perspective, there is no guarantee that both endpoints are implementin=
g JSEP, so any WebRTC-specific ICE modification would probably have to be d=
one in a separate document.







Regards,







Christer










From: rtcweb <rtcweb-b=
ounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@er=
icsson.com>

Sent: Monday, December 3, 2018 10:58 PM

To: Roman Shpount; Adam Roach - SIPCORE Chair

Cc: RTCWeb IETF; mmusic WG

Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

 














Hi,









I am jumping late into the circle, but I share Roman's concern regarding th=
e suggested change to 5.2.2. I think the WHOLE m=3D line (including the pro=
tocol) shall match the currently used properties. You may also end up havin=
g SDP attributes that are not defined
 the for the indicated protocol (since you are using another protocol). Tha=
t is asking for interoperability problems, in my opinion.









I've probably missed it, but what is the "catastrophic
 flaw" (to use Adam's words) that would require this change, and misal=
ign the JSEP ICE procedures from all the documents Roman listed?








Regards,









Christer








From: rtcweb <rtcweb=
-bounces@ietf.org> on behalf of Roman Shpount <roman@telurix.com><=
br>
Sent: Wednesday, November 28, 2018 8:41 PM

To: Adam Roach - SIPCORE Chair

Cc: RTCWeb IETF; mmusic WG

Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP

 















Hi Adam,








On Wed, Nov 28, 2018 at 1:22 PM Adam Roach <adam@nostrum.com> wrote:













On 11/28/18=
 10:57 AM, Roman Shpount wrote:










On Wed, Nov 28, 2018 at 11:38 AM Cullen Jennings <fluffy@iii.ca> wrote:
















On Nov 27, 2018, at 4:46 PM, Roman Shpount <roman@telurix.com> wrote:




 I
 suggest to update JSEP section 5.1.2 to match the rest of the documents to=
 say that "UDP/TLS/RTP/SA=
VPF"
 proto MUST be used during ICE restart. When ICE restart is not in progress=
, "UDP/TLS/RTP/SAVPF"=
; prot=
o
 MUST be used if default (only) candidate is a UDP candidate and "TCP/TLS/RTP/SAVPF" proto
 MUST be used if default (only) candidate is TCP candidate.








I don=92t see any real befits to implementations to this change and I =
don=92t think the rtcweb consensus was around the currently solution. Do yo=
u see some advantage to implementations to this?











This is what every other document related to ICE, including JSEP secti=
on 5.2.2 currently specifies. It was also consensus in MMUSIC. I think RTCW=
EB need a really good reason why it needs to be different.








It would probably help clarify things if you quoted the parts of the doc=
ument that you think are in conflict. I can't find any explicit <proto&g=
t; field handling in 5.2.2.








 I have mentioned this already in the previous message, but I gue=
ss this got lost in the traffic.











Each "m=3D" and c=3D" line =
MUST be filled in with the port,
protocol, and address of the default candidate for the m=3D section,=
 as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2.



















For media m=3D sections, JSEP impleme=
ntations MUST support the "UDP/TLS/RTP/SAVPF" profile specified i=
n [RFC5764], and MUST indicate this profile for each media m=3D line they p=
roduce in an offer. For data m=3D sections,
 implementations MUST support the "UDP/DTLS/SCTP" profile and MUS=
T indicate this profile for each data m=3D line they produce in an offer.











So, section 5.2.2 says m=3D line should be filled with currently used proto=
col, which means "TCP/TLS/RTP/SAVPF" or "TCP/DTLS/SCTP"=
 if default candidate is TCP based, but section 5.1.2 says it must be =
"UDP/TLS/RTP/SAVPF" or "UDP/DTLS/SCTP",
 even if default candidate is TCP based. I thought that section 5.2.2, sinc=
e it is more specific, overwrites 5.1.2, which I assumed only applies to IC=
E restart. Authors disagree and want to update the document.












In terms of changing technical aspects of JSEP: the only reason the docu=
ment is out of the RFC Editor's queue right now is to address issues arisin=
g from rationalizing the reference to RFC 8445 within Cluster 238. This is =
not an opportunity to re-litigate
 previously settled consensus decisions. Technical issues such as the one a=
t hand should have been raised during WG development, WG last call, or -- i=
n extremis, since you're a regular RTCWEB participant -- during IETF last c=
all. It's up to the chairs what
 to allow, but I wouldn't expect anything other than catastrophic flaws to =
be open for change at this time.






I am not the one who opened this can of worms. I am fine if the curren=
t draft version is not changed. This is why I did not comment during the WG=
 last call. Draft authors are introducing the new change in https://github.com/rtcweb-wg/jsep/=
pull/857,
 which makes JSEP incompatible with ice-sip-sdp. I oppose this change. =
;If the group considers that a change to clarify things is necessary, I wou=
ld suggest that section 5.1.2 should be changed instead to that it only app=
lies during ICE restart, so that JSEP
 is compatible with ice-sip-sdp.







Regards,


______________


Roman Shpount
































--_000_AM6PR07MB5621629CDF15C89D5AE048E893AF0AM6PR07MB5621eurp_--


From nobody Tue Dec  4 01:04:36 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC188130E4F for ; Tue,  4 Dec 2018 01:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.76
X-Spam-Level: 
X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Ez54Lmi9; dkim=pass (1024-bit key) header.d=ericsson.com header.b=LXJHCRT2
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 PETG3Cln_8-F for ; Tue,  4 Dec 2018 01:04:29 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 43DBB124BF6 for ; Tue,  4 Dec 2018 01:04:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543914267; x=1546506267; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IE3LRqtrUCqau8Cb+I1ykMvFl0CuYnoA+keEez+tZVA=; b=Ez54Lmi9PCSOD6/TLoDPFl2Fr4Bn59a/t6DsWtklzM9wywpWJKtg25jLklkG+MMl h1vmBTVkqs4Ci0rF4Lm2W1ks0dE43HG4aMy6OzFOFvic7T/ueHhgy938ThvdmdLB cQp7AqBWQp/l6ZM3vVEwIaGDPe/1f5a1IT3fA9x+pAQ=;
X-AuditID: c1b4fb3a-8d8849e000002747-20-5c06431b2936
Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0B.8A.10055.B13460C5; Tue,  4 Dec 2018 10:04:27 +0100 (CET)
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Dec 2018 10:04:18 +0100
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 4 Dec 2018 10:04:19 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1IYe2M1DbyBBYriC3BZ5Dn5CqgCbJBegcm+RTz1caHU=; b=LXJHCRT2heI9iTxMn/UFyEgEHyjsJNVhe0S4J+x/jN2kxNRrcWn2InGLjNa01D1FAPNzvr8vYWiybGL2YemCzv9CpFmj/ySfd+NLLKLMZvVSc3rPahnklMhaf2EhsnaQMUMstPB3N9YJyjhfbp0aFSnzevz4FHkHPRA06xKbgn4=
Received: from AM0PR07MB4979.eurprd07.prod.outlook.com (20.178.19.28) by AM0PR07MB4547.eurprd07.prod.outlook.com (52.135.151.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.14; Tue, 4 Dec 2018 09:04:18 +0000
Received: from AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405]) by AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405%3]) with mapi id 15.20.1404.016; Tue, 4 Dec 2018 09:04:18 +0000
From: Magnus Westerlund 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
Thread-Index: AQHUiW4P7j7OLNWOUEuBI+fFoBaelA==
Date: Tue, 4 Dec 2018 09:04:18 +0000
Message-ID: 
References:   
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4547; 6:ftTbYASthwF1t/o+rsXGEl5J7vRFPyyyEkrSbLOGxEGCJXbrzVM5+C7mgYo+SlzfNeki8c5OYbFqP8DIl9WL4+41TA9uYvmig8sTCf7CCJJm8yLqkVWvQb4TOsU6qO+h+MRB4lFc2v2KTNyzQ4BTGfuK6GQWR+TFSCJMKcItKRhyLtnwmDjkhcqdlNTKdlwOWKIVfegdrqiD3RRm54ihB1sKzWvAGbIxut/cu8M6O3Rx475QGvAEg3nJ1MfUiXPgjkbmvjczy1+opB+Uk0eDopBJHUoSrsSfYoJ5yy208k30vVd+Y/EPQyqP0/+yGaw9pUWBHuH2ErdXlw2WAREDgh9byrZyjFuJRGTpCzSoe+Vt+jwe0mhSgRuiICth/SQf+yHsEvH4YOW69hhOfrROe7qUZ++gPQy/QzdwqKc6O2sbJLVt7do6Pfwi63eHyycUl3opHnsbZmr64y5RiIyvZw==; 5:bQfpOX0X+eFvtnCdefpGnq3l6iPWSb7oACfe1tTUhktJcAU2C/3q1rfnoXy44UW3O+njWW7AM+jkJLV0xdBHXGxua7bFobgHgyrbFm5glOVVirPN6fv/SprnScIBYhPrEpSRvqslxn0bBa2NeMDJfbXamIaFs9C9RqENq6nW7SM=; 7:G253WivRp1gaebhk87AkBt0e5HpC0Yfh123lbNOjfWSiUWEOWjygP05pb0jf7WzXnRDxb5HKA4yF6WF1K42lDG7NGeaglv5OYm16ZZ4VY8I5RSo0asYLZkCnov2Ib555nZ+95CI9gbY1dXVZV/gvpQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 0acdfe59-e726-40e2-f479-08d659c77903
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB4547; 
x-ms-traffictypediagnostic: AM0PR07MB4547:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231455)(999002)(944501505)(52105112)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB4547; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4547; 
x-forefront-prvs: 0876988AF0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(136003)(376002)(396003)(189003)(199004)(186003)(6916009)(33656002)(102836004)(53546011)(26005)(5660300001)(74316002)(446003)(305945005)(7736002)(3846002)(2906002)(6116002)(76176011)(14454004)(105586002)(229853002)(478600001)(106356001)(7696005)(6506007)(68736007)(6436002)(4326008)(99286004)(256004)(55016002)(8936002)(5024004)(14444005)(486006)(8676002)(9686003)(53936002)(86362001)(66574009)(66066001)(25786009)(81156014)(97736004)(81166006)(71200400001)(316002)(71190400001)(44832011)(476003)(6246003)(156123004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4547; H:AM0PR07MB4979.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: TyRfEOZ8JckMuhSDGMSrDZ1R4+LElj18eGfkOyL2Wt02K8xWMzinptmtSX0SorXKDUdL2dQYlcUgCX5lizQKlTY7Cr8uJrYGavISXMV12gPOL3xwJmaGQjG+6DAo/6GMo0VesBURUM5Hap3fjfTM/BkQwiW+5xbxZWtAMfoghm9JvtceOzf2KkZwDIqwY97UEwvsH6qwozKKJZmKia6j8HbF5ZHtp3Hux5Cx6V2bIguBI0IdvPdYwuupe+tli9G399StD0RiIYc9NKG6qxiwWUM71U/pbsGdJ44jlM1tRH5wmJH8H8KTwwdZIrDp0HaNxHITsvtCtVM39vKFkfMk1mHsZ05tFKtkapk/4vthUNY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0acdfe59-e726-40e2-f479-08d659c77903
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2018 09:04:18.2249 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4547
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42KZGbG9UlfamS3G4OlfYYvp+2ws1v5rZ3dg 8jjX8J7dY8mSn0wBTFFcNimpOZllqUX6dglcGR19z9kLFilUtJyUb2A8IdXFyMkhIWAicffp VRYQW0jgCKPE8j11XYxcQPZXRomtf9+yQjiLmSQ65txgA3FYBCYwS/Qsms4MkZnIJPF630Eo 5yGjRPvxg2DD2AQsJG7+aGQDsUUELCVuzL3JDGIzC6hL3Fl8jr2LkYNDWCBIYsMhRoiSYImG efegyvUkpre0g9ksAioSSy48AWvlFYiRONv+jQmkVUjgFaNEAxNImFFAVuL+93ssENPFJW49 mc8E8ZqAxJI955khbFGJl4//sULYChJ3pq5lh7BlJS7N72aEsK+xSSw97wJh60p8mDoVqtdX 4ux/SEhICFxglPh68BxUs5ZE/7FNjBBHJErcaHwKtThb4vq9b1DNchKreh+yQDSfZ5Z4evEf 1DYZiUM/7zNPYNSfheRwCFtP4sbUKWwQtrbEsoWvmWeB/S8ocXLmE5YFjCyrGEWLU4uLc9ON jPRSizKTi4vz8/TyUks2MQJTxsEtv612MB587niIUYCDUYmHN/Qna4wQa2JZcWXuIUYJDmYl Ed47amwxQrwpiZVVqUX58UWlOanFhxilOViUxHmd0iyihATSE0tSs1NTC1KLYLJMHJxSDYzs cSId7/1Om1r93RLd7P/oy4YXPyflKHG6TP+XlC3a89ovVPiU9rf9/VId51l9rrfbtK9s60mK FN80b5fvdM3qb9fVbgZssqg5liCVdvyD+Io/GgvKvbYvjd9qp8wjtjLVJf9yQBC73hSJt0XP 2ic2dXZtl8x6ubBlnfydqG/mLEc/b9vVvE6JpTgj0VCLuag4EQAtV/MVFQMAAA==
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 09:04:35 -0000

On 2018-12-03 22:31, I=F1aki Baz Castillo wrote:=0A=
> On Mon, 3 Dec 2018 at 11:02, Magnus Westerlund=0A=
>  wrote:=0A=
>=0A=
>> To attempt to restate your question. For RTP sessions, where there are a=
=0A=
>> single source media stream per Media Description in SDP (m=3D block) and=
=0A=
>> where there is explicit MID signalling and SSRC signalling, then one=0A=
>> will not need RepairedStreamId and can instead rely on explicit MID=0A=
>> signalling for the RTX stream?=0A=
>>=0A=
>> I think no. I think using RepairedStreamId independent if there is=0A=
>> multiple source RTP streams or not per media description provides a more=
=0A=
>> consistent experience.=0A=
> So, you say that the receiver would receive both media and RTX streams=0A=
> with same RID values, and then the receiver would decide whether it's=0A=
> a media or a rtx packet based on PT, right?=0A=
=0A=
Yes, but for the Repair stream I think the right thing would be to=0A=
replace the RtpStreamID with a RepairedStreamId SDES Item and header=0A=
extension as appropriate but with the same RID ID.=0A=
=0A=
=0A=
>=0A=
>=0A=
>> However, as noted at the start. The use of RepairedStreamId for RFC4588=
=0A=
>> RTX format is not well defined and how to handle and detect legacy. So,=
=0A=
>> I think an update should be done.=0A=
> Is that issue related to the fact that RTX packets are supposed to=0A=
> also carry original packet header extensions?=0A=
=0A=
That implications I actually hadn't thought about. But you are right=0A=
there is an issue here. =0A=
=0A=
So RFC 4588 says this:=0A=
=0A=
=0A=
   If the original RTP header carried an RTP header extension, the=0A=
   retransmission packet SHOULD carry the same header extension.  This=0A=
   header extension MUST be placed right after the fixed RTP header, as=0A=
   specified in RTP [3].  In this case, the retransmission payload=0A=
   header MUST be placed after the header extension.=0A=
=0A=
=0A=
So following that an implementation SHOULD include the RtpStreamID=0A=
header extension and the RFC is silent about adding additional ones. So=0A=
the reconstructed original packet needs to have the RtpStreamId header=0A=
extensio. However, some text on the use of RepairedRtpStreamId appears=0A=
required. Like that it should be added at certain cases, like first=0A=
sendings of an repair RTP stream (until know it be delivered) as well as=0A=
when endpoints join the session. The receiver also needs to know to=0A=
strip this particular header and not include it in those that are=0A=
attached to the reconstructed packet.=0A=
=0A=
>=0A=
> Why is there any problem with 4588? This is just about the browser=0A=
> adding RID to RTX packets. That breaks nothing in RFC 4588 (IMHO).=0A=
=0A=
With the exception for the issue with the header extension related to=0A=
RepairedRTPStreamID above I agree nothing breaks. However, the late=0A=
binding mechanism in RFC4588 is actually problematic in some cases.=0A=
Where the RepairedRTPStreamId pointing to the relevant RID actually=0A=
supports dynamic in session rebinding and have no issues with multiple=0A=
outstanding NACK requests prior to learnt the binding. So this is a=0A=
superior mechanism that should be recommended for usage with RFC4588 RTX=0A=
in all new applications and possibly some old ones.=0A=
=0A=
The legacy fallback story appears reasonably clear as there are several=0A=
signalling attributes one can key on that wouldn't be there unless one=0A=
supports this mechanism.=0A=
=0A=
=0A=
Cheers=0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Tue Dec  4 01:26:44 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0F130E67 for ; Tue,  4 Dec 2018 01:26:43 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OMklC5bkGsAb for ; Tue,  4 Dec 2018 01:26:42 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 A7790130E66 for ; Tue,  4 Dec 2018 01:26:41 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id u3so15089870wrs.3 for ; Tue, 04 Dec 2018 01:26:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=fgay/puvXqH9L8IYE95eL/xQ63k0v5NN6RwwvIIrRBw=; b=pJJGyaOBf4YaPyymI9EvjF5noZ4IeG1bnW8HvD+v0/irqKlt+qajx8l5YYqZS5O8Kh H+3gp4XRFp0qPoUHiJ5Q2h8JSQpXnLesmrFfRAAOgjpzBiiGx/EwH7pSXw3kocVLIq8P VwxcJSAoMZD5RBgUl1tXXgNtj7O3KB4zEWf4eZ0fJslKTIW0vNQX5icy8v1ExIoX+RwZ tibwZV2xVA4sLfQYE83SkTY8+2g3601cuRJmGDljhPhiwyClJzWea7kBrF3K6k/wrV83 lRfUE1VE1c0Ga5zdjkaz+pl0uXnSZRYYL+y0N5cIgq9nw0HOIU6nZXj8dzjTgFaBZ518 sUVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=fgay/puvXqH9L8IYE95eL/xQ63k0v5NN6RwwvIIrRBw=; b=NaY7MdLpSQzvQO6yR0OAT0Zo8Xr0AXznCcTYKBNYiMovshhXCO9/PSxcmfvPKr1kUZ ZlIZ2bG1RXsQu3zqR3+H59qDqThZu7cAeXLxyMVv9zOKK7ACbfTaEei9ZD3hQDCWLHOd 2HfPJQyMy0eRg8pNBbYVamInxb3C7ELXJ8IyjE2NyaTfBB9thKQR06DRWmSnfsZQVkCU kcFkCW/v9q4huFN9ZCOawY5hiP7qpK+WPBtm6Z5/bsIxiaXL0ra2y4in2HR5rIQkkTuM dzq1I19gxsxt+Wmrmo+GAmuCrxqmnl6AJQYBeUZAQARPounzol8I/g1CDLEav5P52NyZ sn4A==
X-Gm-Message-State: AA+aEWaUf+/RDTVosYfxpdP2QWT1c7Y+kJc9wUzLAQWAru2tcuvzbLLS IbQCMLr1wgYkQ8HjZHbO1l1Yw0er
X-Google-Smtp-Source: AFSGD/WjaFW0YvkshtvucDGsjIfNT2iwEXBTnLdtpHHAaoHgijpnI+xj9AbT5kp9NTBTijru2OZb4g==
X-Received: by 2002:a5d:6907:: with SMTP id t7mr16900198wru.226.1543915599739;  Tue, 04 Dec 2018 01:26:39 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id 80sm11568516wmv.6.2018.12.04.01.26.38 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 01:26:38 -0800 (PST)
To: rtcweb@ietf.org
References:    
From: Sergio Garcia Murillo 
Message-ID: <80824dca-9914-934d-7922-a5b100a2fa0f@gmail.com>
Date: Tue, 4 Dec 2018 10:30:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 09:26:43 -0000

On 04/12/2018 10:04, Magnus Westerlund wrote:
> On 2018-12-03 22:31, Iñaki Baz Castillo wrote:
>> On Mon, 3 Dec 2018 at 11:02, Magnus Westerlund
>>  wrote:
>>
>>> However, as noted at the start. The use of RepairedStreamId for RFC4588
>>> RTX format is not well defined and how to handle and detect legacy. So,
>>> I think an update should be done.
>> Is that issue related to the fact that RTX packets are supposed to
>> also carry original packet header extensions?
> That implications I actually hadn't thought about. But you are right
> there is an issue here.
>
> So RFC 4588 says this:
>
>
>     If the original RTP header carried an RTP header extension, the
>     retransmission packet SHOULD carry the same header extension.  This
>     header extension MUST be placed right after the fixed RTP header, as
>     specified in RTP [3].  In this case, the retransmission payload
>     header MUST be placed after the header extension.
>
>
> So following that an implementation SHOULD include the RtpStreamID
> header extension and the RFC is silent about adding additional ones. So
> the reconstructed original packet needs to have the RtpStreamId header
> extensio. However, some text on the use of RepairedRtpStreamId appears
> required. Like that it should be added at certain cases, like first
> sendings of an repair RTP stream (until know it be delivered) as well as
> when endpoints join the session. The receiver also needs to know to
> strip this particular header and not include it in those that are
> attached to the reconstructed packet.


Given that RFC 4588 already covers the inclusion of the original 
RTPStreamID header into the RTX packet and that FlexFEC will not use 
RapairedStreamId mechanism (as a single flex fec stream will be used for 
all protected media), I see no use at all for the RepairedStreamId 
header extension and related mechanisms at all.


Best regards

Sergio



From nobody Tue Dec  4 01:35:32 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1B1130E78 for ; Tue,  4 Dec 2018 01:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 eiiupX2D-6IR for ; Tue,  4 Dec 2018 01:35:24 -0800 (PST)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 2E75D130E79 for ; Tue,  4 Dec 2018 01:35:24 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id z18so8797437wmc.4 for ; Tue, 04 Dec 2018 01:35:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=L4D6BJ/f2ner4Dp1pDmcUVeEvSvNHeCUq+eCUOWFgDg=; b=Tk6gzdNeTumKEuQsxQxw6p2DwJW1rGRj/eoZAqSzWuAC3mi6sq2qhPdfCjUS742t/t 0gRm4oAAlDyIVICkk7VIIdq3KOtb+P9RbLCtXd1EQnT5hyyToRSSWlMblLCgUDzwkJFh a4s77gFPK2gARoN+f/xt78EMS47p2xXtA+g8og4F+jxj7o0HYLMb90pvHdCAZ0NfgjrZ NLAoldAsxx7LAmDCJ54yrlWhSedk/JWkHvhGBYwt1W9G9ca4BHBnTydYtuvLbThZXYEV 5vQPrkiLBdtgk71ReYCgMbY+9Y2w7vAn3hpsbADy+vYi6xqfwnDXhjRn8jy+3UPxwvqD l6ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=L4D6BJ/f2ner4Dp1pDmcUVeEvSvNHeCUq+eCUOWFgDg=; b=QZmlvPi6avuOdOOV/FsWnWmCFP1gmMRewMrhSXh9tELXTuYZxexyRXGJmkkG0sXq8D SR7pGswES89XhWKfMKnZzn9gjEo/OcSUnP+HKh3pY5uJB0gY8kmL10g/JrNIl35bEF6j buQaLeRLPkN2GGHQnUfvjm6G/GCnvpd5PpYtRzFfhKaCFLEdhr8ARo84/TWxLcyvg2Qg Kk7E02UfdznAU7V6eEYGc7OXOL682BdS6k25Vp3t9F+1sbFbJat8jAXMhLmlkyBk9UBF EZxWGJxn/8ZbPWrUx24mbnFvd3EsIG8l9k3DkczZE3DHRqsh1KH+RKfyczoo4gwyi2/Q fV/g==
X-Gm-Message-State: AA+aEWYi5nr3TOHXBCvdg65NJBGKgcpbN5e3P+yL3NLBzgjqD/cES/tX RN0HG4sPbuKzLbd1CFuIk+me+0H8
X-Google-Smtp-Source: AFSGD/UmiG3AG9Xvshpf2MxkGm9csLdjXWM0NRR8Obx3EJYVrDqqIHFxNDAEpggkDOFlgrrbTZaJZw==
X-Received: by 2002:a1c:c303:: with SMTP id t3mr10940824wmf.94.1543916122346;  Tue, 04 Dec 2018 01:35:22 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id e19sm38811044wrc.25.2018.12.04.01.35.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 01:35:21 -0800 (PST)
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: Magnus Westerlund , rtcweb@ietf.org
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>  <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com>
Date: Tue, 4 Dec 2018 10:39:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 09:35:31 -0000

On 03/12/2018 22:26, Iñaki Baz Castillo wrote:
> On Mon, 3 Dec 2018 at 22:22, Sergio Garcia Murillo
>  wrote:
>> My point is that there is a single source in the transceiver/MID why
>> should we add default RID and waste 2 more bytes in each media and rtx
>> packet?
> Regardless what browsers do today, both MID and RID headers should be
> just included in the first packets. The receiver is supposed to update
> its ssrc table for faster matching.
>
> NOTE: The sender should also resend MID and RID if the SSRC changed
> because some RFCs state that SSRCs may conflict and things that
> absolutely never happen.
>
Kind of agree, but from a theoretical point of view remember that we 
introduced MIDs/RIDs to cover rtp proxing/switching scenarios in which 
ssrc conflicts may happen, so in order to cover those scenarios the 
MIDs/RIDs values must be included in every packet. If we ignore that, 
then could just go back to ssrc signaling and avoid mids/rids 
completely, which I would be in favor of.

Best regards

Sergio



From nobody Tue Dec  4 01:58:27 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5981A130E27 for ; Tue,  4 Dec 2018 01:58:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.758
X-Spam-Level: 
X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=E/jKi4vh; dkim=pass (1024-bit key) header.d=ericsson.com header.b=CpFxpjgy
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 q3T7BeSrP1L6 for ; Tue,  4 Dec 2018 01:58:24 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 5602112785F for ; Tue,  4 Dec 2018 01:58:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543917502; x=1546509502; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yCx9DyhQxwGW78khZjWxJNq11VU4EGE9BQmx/+ovfIk=; b=E/jKi4vhF+bkhnaO2Wjb24tz+LWAu/t2E908yJgT8IVSLMaVTHbaQEt6x4q8alDH Lm/dLYRNxbDOVPkoCZ/TO4sWR98uQwKGzWRUakbwF0nPFse9uNkE6F6dviYEAcNj 4vZ5n/Ffj2ntVPpfp3ELCQRU31RO7Br50WhqnIUBGT0=;
X-AuditID: c1b4fb30-39c4e9e0000043c4-1d-5c064fbe58e4
Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5B.61.17348.EBF460C5; Tue,  4 Dec 2018 10:58:22 +0100 (CET)
Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Dec 2018 10:57:51 +0100
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Dec 2018 10:57:51 +0100
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 4 Dec 2018 10:57:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nr0YdrE1G/R/RC88rfjOT71/MklVI05/j1HFNkNZBXA=; b=CpFxpjgyT9DEYjJVcsH89wG+qKYvOiKhXn4X9Eu+linDlAlUKrq/jmcSlM3zTy8O7+t9DXqkfsK4rEjupH54ROiOJOq737YYpFSzVTEu5xs/msvipdcE1cf6ZF3hHKyyvQy0fgTiKJ2iIXnjR5S1VR5zZuM40GiSKSO/oe/+ryM=
Received: from AM0PR07MB4979.eurprd07.prod.outlook.com (20.178.19.28) by AM0PR07MB3876.eurprd07.prod.outlook.com (52.134.82.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.11; Tue, 4 Dec 2018 09:57:50 +0000
Received: from AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405]) by AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405%3]) with mapi id 15.20.1404.016; Tue, 4 Dec 2018 09:57:50 +0000
From: Magnus Westerlund 
To: Sergio Garcia Murillo , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
Thread-Index: AQHUiw/JPEl6adMtxEO6Fn3OSoL1jw==
Date: Tue, 4 Dec 2018 09:57:50 +0000
Message-ID: 
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>  <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>  <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB3876; 6:gUKBvBf4FA30LgnBeq+K3fsPol3gQ3zdeqBFaZi1q6n07olRqsvE7xZndo5tCwWJLfgMYDQQiOPzQlO44zL5A2FBlC9ujCA7Qbl6lRzHyYRS1/D/DPyfgFP0HalMzV0IMSzSRskT4CW41x83VzufFjuWLuMKuetqSIUoq/9mFGRc5b9rYi9xnAmm/GYW0l/+hsh8tQIpVv4V518kGBlxpC7ktjtfGM4IySQwoDZ4ZIJQDZdm4aHNIl/exye7Q/UCWot8xXcCxKcNPxuIhE5gZ4FEyWWRnkpK73c+PfO0FwO0XqzaeXWIrdIRMMti1yauKh4XNCnwznB5rCzPGT1TkAycRkR5v6Hy7sfB5NBwM265ukpBNM3oSgBHF7qsyhBLBWzSSyhuPEdbmSiCQkjhY19FCa4Vr4KHq1DFOUSa8sj/kbHD/UqeaVjJnniQ32eoACxfJDKZC++zVSWiGCnDpA==; 5:WxomRtLHIOBWSlVhhaA+EAB4bRUsbSJ4R6p9YK4b3Pw4epzSTqb4Sb1l/0yCDnlmzKLFl5e9mlm/ChzdHe4leCI0ojDJy9jvVW5TI412O0m6O5MxPCkZkxchpWmmIlriB4Tkua7r3S2A7qs3D+38xjgtcwIjfOJpwrsm5VekrOs=; 7:tRPQL0m6hXVSLr3B7WiG1viH9NMUtQsNdMHImv2NUXQSufr375A0dbREnbTVKcUfqvnSvJq7rDaf23P6JZVWXFToWfwio81P4TqqG6d7+ABohHu4eGAbL8ymXqR26RdrXlfycCl268Hgx9yqEAYJBQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 2a408ac4-d415-4dfa-f2e1-08d659cef3ba
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB3876; 
x-ms-traffictypediagnostic: AM0PR07MB3876:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231455)(999002)(944501505)(52105112)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB3876; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB3876; 
x-forefront-prvs: 0876988AF0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(346002)(39860400002)(136003)(189003)(199004)(6246003)(9686003)(53936002)(68736007)(305945005)(4326008)(7736002)(74316002)(66066001)(105586002)(229853002)(316002)(5660300001)(99286004)(446003)(110136005)(476003)(7696005)(102836004)(44832011)(97736004)(6506007)(76176011)(53546011)(14444005)(86362001)(256004)(3846002)(39060400002)(6116002)(486006)(55016002)(8936002)(2906002)(26005)(186003)(93886005)(478600001)(25786009)(8676002)(81156014)(81166006)(14454004)(33656002)(71200400001)(71190400001)(66574009)(106356001)(6436002)(156123004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB3876; H:AM0PR07MB4979.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: GAvhoUVbRW5l7xTic/92mmaFtqIuHQVuOQi0yomr3p5C418nQ6zFqHuQQF6zgRXoU8O/91jEIN98GjjhfM+d/ff3IBSXPTnTttWrf1CtKrvUqa/kDkU2quCyXks1icoTXWePEL4SjY3vKzQl7K9od/meOui4U5+t2okr7J1j+qWLwNx84wOxlXRb4pSUPfLZ1xlinXp6jnUT6k2OukViXHX+HZe2+1Tva9kbFXBfLnsZC1XDUreB9E4La78f02M4NT/MvcmxrIe9nu/UyYPImUsvKBDPEk+Oh2wuEASj0VnOfOZfQpNHDar9ADKD3XhnXyohGwrt/twRCTDhe7bbttlfVt+AME6ERWByZCFqj+U=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a408ac4-d415-4dfa-f2e1-08d659cef3ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2018 09:57:50.5903 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3876
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SXUxSYRjH93IOcCRpR9J8wtGKMjdLItcFlbqs1lgrK+uiHKWUJyUVHYdc 2pa4tj5wTrZiTTK1JC9MxNKmNjPDvNAhkh/NinCmiMZFdVHZSgw4tHX3e/b/eJ53ewlMUMMW Eiq1ltKolYViDg+vPdVVntR3lKOQttaJZHf7UmQW/w2uzOPvwvZicofuC1feY/rIlZvNv1jH sCxeSi5VqCqlNNvTcnj5Va3jeElb1OVes5OrQ49X61EEAeROaP80xQmygHyNwGrcpEe8AH9H UNN4ncsIgWFy+SQjNLFgoNvEDQ44acCg09KMMYqBBR+WF1jMMINg5NscK5jnkDJ4t1QZWhJN auHeCzs7yBiZAK4mR6CKINaQmdBuQ4zlBOjq3WG7BAbHpkN2nNwMk233sSDzSQV4LC/ZzC4n DpaejlAYkSKY/unGmf5YeD/XwGIeSoK5dxRjOAYWZ/1shjeAy2jhMiyCsYYqFCwF8i0HbnWP 44yQBF+NxnD4COhHZjmMyYnAOHMtnE4ES1U7i7lCCVOVnvDmAnjUUR/m9dBSPRMuHcVgXKcy IKnpv2MZlsCU8Q6H4a3Q/MCHmUKvjoKh2jm8EeEtKIam6HNFecnJEkqjOk/TxWqJmtI+RYFv 8qrzt7QbLXrTbYgkkDiS71tiKwRsZSldVmRDQGDiaL5rC0ch4Ocqy8opTXG25lIhRdtQHIGL Y/myjI4sAZmn1FIFFFVCaf6pLCJCqEPSN/seWsfshs8NkU3W+V2AnXEJsxOHPVx/XPGFAxlX VxZy9t+WTUQOYhPD6Yr4NIImhQPeyf4fu7uS8u0r9udrnWdbMweG+MnPqq+kxR9+MuzWnZbb fN51Nx1/xKkpe7xGPGGju6TikPagQzR/cZW1d1v/8exUg0hXBxU+vRin85U7EjENrfwLmFmX JSIDAAA=
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 09:58:26 -0000

On 2018-12-04 10:35, Sergio Garcia Murillo wrote:=0A=
> On 03/12/2018 22:26, I=F1aki Baz Castillo wrote:=0A=
>> On Mon, 3 Dec 2018 at 22:22, Sergio Garcia Murillo=0A=
>>  wrote:=0A=
>>> My point is that there is a single source in the transceiver/MID why=0A=
>>> should we add default RID and waste 2 more bytes in each media and rtx=
=0A=
>>> packet?=0A=
>> Regardless what browsers do today, both MID and RID headers should be=0A=
>> just included in the first packets. The receiver is supposed to update=
=0A=
>> its ssrc table for faster matching.=0A=
>>=0A=
>> NOTE: The sender should also resend MID and RID if the SSRC changed=0A=
>> because some RFCs state that SSRCs may conflict and things that=0A=
>> absolutely never happen.=0A=
>>=0A=
> Kind of agree, but from a theoretical point of view remember that we =0A=
> introduced MIDs/RIDs to cover rtp proxing/switching scenarios in which =
=0A=
> ssrc conflicts may happen, so in order to cover those scenarios the =0A=
> MIDs/RIDs values must be included in every packet. If we ignore that, =0A=
> then could just go back to ssrc signaling and avoid mids/rids =0A=
> completely, which I would be in favor of.=0A=
>=0A=
However, an RTP middlebox has the freedom to introduce those header=0A=
extensions when switching. They do not need to be sent end-to-end all=0A=
the time. So after the initial establishment of them, I see it as the=0A=
central middlebox responsibility to ensure that they are included in the=0A=
down stream legs towards the conference participants. Also at least for=0A=
video introducing them only on reception of a FIR also makes sense.=0A=
=0A=
Cheers =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Tue Dec  4 02:01:28 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E915A12785F for ; Tue,  4 Dec 2018 02:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 MuQZ-BDTrV_v for ; Tue,  4 Dec 2018 02:01:20 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 1CA08130E39 for ; Tue,  4 Dec 2018 02:01:20 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id u3so15214182wrs.3 for ; Tue, 04 Dec 2018 02:01:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=7ynMUa6E+44udiuja8qv71vNUFXcc8n4GZyDAogixaA=; b=TmTZGSpoRdnhhAm4LPi7HZqg03VabeuGnlGM6pcrBC44YvIgjS7WIMwRni2Pc9cNzr pHvfkImOxW5UG4L5ZIiOuWVP11Qdd+hNSg7CPh+G0e9kv0vYC2rCUshy6DT2f2P3G87V 2AXl+I0gKu7cA06D61RU4Bd+GBHSJvEymJuG4jRTYdaVV+ptLDmwO7yl+QGaIw/VG50C 4IN1Q5GAf+7gsiAX7z0oWcm1IT7OOIjx7R732KFPG/CAapDfHRFGOW3e5J0Dl+dwTv0p RcNOJvhZbaJwLyBvMBDMvDWOWCogLHxVjWi6Ckf5iki91n29my9ranrUQFR0nuoW9jMe f5yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=7ynMUa6E+44udiuja8qv71vNUFXcc8n4GZyDAogixaA=; b=gNx6+JEUHFdLsJMu8pFoj5NHP+RSoIiuE1RF8KSp7jlzFuMT6SD7Cay3WokulDKSOZ VqQQxoVg5ifFjA1DSrizQbzmIaWPVcUnS2ghHh3N8y5Kx11SXUWBoTpgWYbuXjUeNknT y/jpFzlDBXFumJVnLzcuuF3TKClPwiVQWay6A2pbDWLWopOZNWdm0UYJY2qNHkMsjpIh 8admWredjnvWfbkqyjhWEJxKqhn0djuqcHe8CYMjlJPkMszbDaGZkGbGMt8lfdOizgxD ych8yZkLrrzcK0owaB++ncbfwgesE8ufZ/56ZtBgxo/mNXWetWCYRu/qi+iVkkmpDC0R 0g7w==
X-Gm-Message-State: AA+aEWY4FpgLi2pP1pdABRe1OXL2Kh19o6RnleoMpogpVYJUo/dvE4xT KeXD7GuCNqUUjGikO2lEdPPnS3ii
X-Google-Smtp-Source: AFSGD/UuLtwi9bJXKBaorX+fi31h6/gIUV6SGh6x1Wj9do0pr6Kch0DFRvUlCBsnvs6qgLUFkLYpkg==
X-Received: by 2002:a5d:684b:: with SMTP id o11mr16559257wrw.316.1543917678474;  Tue, 04 Dec 2018 02:01:18 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id j6sm15899452wrw.30.2018.12.04.02.01.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 02:01:17 -0800 (PST)
To: Magnus Westerlund , =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: "rtcweb@ietf.org" 
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>  <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>  <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <2d9ca83e-4b81-23e2-ccbb-3c3e4423d291@gmail.com>
Date: Tue, 4 Dec 2018 11:05:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 10:01:27 -0000

> However, an RTP middlebox has the freedom to introduce those header
> extensions when switching. They do not need to be sent end-to-end all
> the time. So after the initial establishment of them, I see it as the
> central middlebox responsibility to ensure that they are included in the
> down stream legs towards the conference participants. Also at least for
> video introducing them only on reception of a FIR also makes sense.

Same could be said about changing the ssrc to avoid collisions and we 
would have avoided our selves to introduced all this new ids.

Best regards

Sergio



From nobody Tue Dec  4 02:52:13 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4765130E33 for ; Tue,  4 Dec 2018 02:52:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.76
X-Spam-Level: 
X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=GLMjgFE0; dkim=pass (1024-bit key) header.d=ericsson.com header.b=NHlj9nXf
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 bTOLH9imiWy6 for ; Tue,  4 Dec 2018 02:52:10 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 E5C2D12785F for ; Tue,  4 Dec 2018 02:52:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543920727; x=1546512727; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=isJuuvfUrlDYZq3+8mw/uEbfIVetRg4lPNrj3jDTia0=; b=GLMjgFE0tNKmzHu2ywt6Pkjm/Imw8I/7D5cTAfxwWAkeZytn3aBO+XqRduPpXf6G ZA7HturW5oOgxmebDYGcynWuWFOq2v7bXt8z2infRV59ljtSANMeCGBNCEBpMfHv pOjuOhvceK+OVNUrTLqmTwhD3bA9wAhKZ3QZb699Zj0=;
X-AuditID: c1b4fb3a-477ff70000002747-1c-5c065c57e068
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.8A.10055.75C560C5; Tue,  4 Dec 2018 11:52:07 +0100 (CET)
Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Dec 2018 11:51:58 +0100
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Dec 2018 11:51:57 +0100
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 4 Dec 2018 11:51:57 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=33qRaOcoHGDppDqDQDk7uVW/lM4lce9nhTDYaCcLGic=; b=NHlj9nXfVvXKvwRkc0bgBJnocbQ/hibIYmfhsoheq7EHOC99wYS3WmDv5fSc+p/QbMF7oEwzBvc2EOWwSUHpzYJjFN0B4xMUTWaoqHqrr6iuSk4V2RFWqOXHX1CtZBuYsScXw48xn1tgsrdaauG+Ev2qo/S7J/0Iv4ww8NaJG/k=
Received: from AM0PR07MB4979.eurprd07.prod.outlook.com (20.178.19.28) by AM0PR07MB5972.eurprd07.prod.outlook.com (20.178.112.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.11; Tue, 4 Dec 2018 10:51:56 +0000
Received: from AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405]) by AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::edb0:806b:dd18:8405%3]) with mapi id 15.20.1404.016; Tue, 4 Dec 2018 10:51:56 +0000
From: Magnus Westerlund 
To: Sergio Garcia Murillo , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
Thread-Index: AQHUiw/JPEl6adMtxEO6Fn3OSoL1jw==
Date: Tue, 4 Dec 2018 10:51:56 +0000
Message-ID: 
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>  <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>  <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com>  <2d9ca83e-4b81-23e2-ccbb-3c3e4423d291@gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB5972; 6:2bBfn2Gq8R43cAgVybB5btcCdCzskogMzFBZt4vyujvyKllSMk7XDQGZGn0wvJdJ7Mk6Kc0IFG7eREmzZEYKtRWv/Hto9KOstNzDl1n6AXjyKMy1Mee/PqXquawpirH1YzlnDlhYqazGdEJepzK6ZsdxdvbcBM1DU42/rsOxRr0QkN6ep0Q6gPcgqeclZRlXefvHKyWy/fsDcPYTv7akFIdYF4BsdC5d6uuq4y5WhK11129Ls8RykEuexSU+/WHUzqdePXRpzCbLCV07PYoDari9yo3hYQ4Y0IKYBHHISTJQupcHgRKsVoxzMF/Y5INyOYJ7FR5Bu8RRLJwH8ya7gRdgCBzvBY7XhWViBtkZr0T2oJQ0tYCHKBzpig/2ld8zrg5NYR+3g44q3xhBaJdyPItXC5n5CXEF1JEP9h107uOU7B/I3aRw2JBEIe6Qx52bU4I9K+/NkkMsE3kopysURQ==; 5:ISOpXE8XeohWD+qzEr/vNw9tm5tXYJpVljUnFwBD8EvkTzNqvQ5TEEGDdd5Tkw00gYbPMfTxC2bwcMCrSUSdhZccnWIQuYA+OlE/uew5iIHdy4LxFGS6N7cJtDIvkz2prIo9ZvB56nAh5NCt5ldblUsG5nGO4afCezQxYhDDjjs=; 7:rkTO1ELCzXswgZY3Kaate++VAHskfwNL7izKzY1oPEjLidpvZBxOFViSzJpcsl0bOwsk3DOfQLWVhBIj6nSW4P2okwa2ttgFoKCCkWXzyQeM4UbJopl/gEL+eQCIxLbUyDKfzv1k7COSqDDgRnmbrQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 091491bd-93c5-46c3-b7dd-08d659d68276
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB5972; 
x-ms-traffictypediagnostic: AM0PR07MB5972:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231455)(999002)(944501493)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB5972; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB5972; 
x-forefront-prvs: 0876988AF0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(39860400002)(396003)(346002)(199004)(189003)(6436002)(102836004)(26005)(7696005)(186003)(81166006)(8676002)(14454004)(99286004)(2906002)(476003)(33656002)(44832011)(68736007)(71200400001)(229853002)(8936002)(81156014)(3846002)(6116002)(256004)(76176011)(53546011)(6506007)(86362001)(71190400001)(446003)(486006)(93886005)(74316002)(97736004)(7736002)(106356001)(305945005)(105586002)(316002)(110136005)(4326008)(478600001)(25786009)(53936002)(66066001)(5660300001)(55016002)(9686003)(39060400002)(6246003)(156123004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5972; H:AM0PR07MB4979.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: meyWQnVj+xUIPjeUYHWXENyJ1JOEL6CShltvPLvqW0bxBs3DLcCDuu+Lot/7KNT82KnF1hbq/hBrv2gKp0WMkK5m03njTvqVBGWUi6MOzKcYkTtor19xZecllF5UJIYtv1HIBiMhOpBn7NogK1JAPF5qhBv5YyvcSvyC5cjmwJmF5hoz7hi/qmYCHRaUyJwFwvUYfldz23RLpnAoMvrf4YuWDk5b1D5oKetqfmYpVs9G4NycmesWLOb9vHTt1rV40H0XcdjsjLzxg3h25FBYTQBrGd1Vh9qycRdnqaCAI+qM9t2/3JR69eGD5tQLz3vL+mMiv57lGTa3eXR5Sgs6wErVrDuCXZk3lTiqExkZdiU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 091491bd-93c5-46c3-b7dd-08d659d68276
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2018 10:51:56.5144 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5972
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sf0hTURTHvXs/9jSH16l4UFYxI8HyRyoxQsKCQpBiFFHYMIc+f05d701R kZjQWEzCRY6YUpaKqaWVBDPUTLNCERUh0fzV0KlTKwkkf+Co+Vb03+d7z+ecew9chpCaqRAm p0DHcgVqjZz2Ia3XbCWRV1W0KmaoJU7x4G2Cos1lFCscLhuRSCSN6H+Ik97UzIqTGhu3RUoi xSchg9XkFLNc9Ok0n+yOvUpS2+RXMrLyjdCjaV8T8mYAx8P3XQNhQj6MFA8gcO59ooSwiWBv ZZ34F7qG25EQGkRgtz6k3YHEZgKqF56L3MOk+J4IqlpCBcuO4F37LOUu0FgBU1sVtJsDsQ5q e4b3zwkcDjMNI2ITYpgAfAle9iNBuQz6R3MePQo+jM9TboXER2BwROs+lmAVfN1ppIWrJihY W/2434uwDOZ/zZHC+GD4slgnEhbF0Ng9SggcBM4FFyX4apiscHicwzBjaRMLLIPxusr9jQFP 0DB/57ZHioQNi8Uz6ALYXq2KBWkMgXnrs6cQAVZXDylwHpgcBiTwQWi9ayeFhlEC2gYMIjOK qfnvtQJHwaSlmhb4GDQ9WSNq9tf2h0HrIvkYka0oiGd5Pj8rNjaK5XLSeb6wIKqA1XWgP/+k 7/XuqU7Ut3ymH2EGyX0lV7YplZRSF/Ol+f0IGEIeKJk5Squkkgx1aRnLFd7gijQs349CGVIe LDmbqUiR4iy1js1jWS3L/a2KGO8QPdI6OVtuZ+k5a/0c5kafxcmaZfqen8ljNzXiQ7vvvbyz Nnain6ZIFX6ZhUXlvKlLUT/k3Wo/v5wbcGvRSKfh683GixPKzuIDVbO1fqmJXtPdx1/UK9eb TxpSufuGuKVZx1Jv3078ZrkzXWksm0rOlIWF9+o1kXXKsKJpjX+lnOSz1SciCI5X/waKY7Ym IwMAAA==
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 10:52:12 -0000

On 2018-12-04 11:01, Sergio Garcia Murillo wrote:=0A=
>> However, an RTP middlebox has the freedom to introduce those header=0A=
>> extensions when switching. They do not need to be sent end-to-end all=0A=
>> the time. So after the initial establishment of them, I see it as the=0A=
>> central middlebox responsibility to ensure that they are included in the=
=0A=
>> down stream legs towards the conference participants. Also at least for=
=0A=
>> video introducing them only on reception of a FIR also makes sense.=0A=
> Same could be said about changing the ssrc to avoid collisions and we =0A=
> would have avoided our selves to introduced all this new ids.=0A=
=0A=
I think you are significantly misrepresenting the reasons why RID's are=0A=
needed. The fact that we have multiple models for how RTP middleboxes=0A=
works is a significant contributing factor. The next is in RTP ancestry=0A=
as a non-centralized multi-party protocol, i.e. intended to work over=0A=
any source multicast. And as simulcast do implies a selection by the=0A=
middlebox that aspect do needs to be handled. A clean-slate approach=0A=
could possibly select another set of constraints and maybe be somewhat=0A=
simpler but not a lot.=0A=
=0A=
I do note that also the MIDs and RIDs only have per signalling context=0A=
and may require translation between the various legs of the conference=0A=
in a multi-party one.=0A=
=0A=
Cheers =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Tue Dec  4 03:22:49 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9FC130EC2 for ; Tue,  4 Dec 2018 03:22:47 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BtO2NKRee6Rv for ; Tue,  4 Dec 2018 03:22:45 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 A70C3130EC1 for ; Tue,  4 Dec 2018 03:22:44 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id m22so8940084wml.3 for ; Tue, 04 Dec 2018 03:22:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=P5PxbEZMY2dAW6B73RsuStFgPD/Uruth81xCiyHsSsA=; b=iqMziFJHfGtcGDqL3P7Tjk7kq5PR4G/jnUx2/SiyoXLgX7cUFWSXGQe+nw1UaAo6+0 g2NT2O+8DF4wAJnyec/LFSwll1xIKJARCnmTTpXJM/0rZmY+Sn7H3gHdks0WYbCvZnb2 JojRykHxSCNfs1cO6HxYdflTgs1svckaUauKL6Bf6j6CG3D/ec81pr1QawcSPcVyo4MI OoBef4NjQL9fgrjtjr7W76Mg4wvz6zZHr8k+mRffTVdOtdmi19Jth9ZPmNL9q2MTqaa9 +GYdtMD4ybrn6rqX6F4Gmu6UAIzWc0dNEK88xDs4ZZAXsxxBMQFgDwJ1G1tHQF4fZs22 0zng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=P5PxbEZMY2dAW6B73RsuStFgPD/Uruth81xCiyHsSsA=; b=T5kimxrJ5s9CRnBsJVjcT6R7iNGspeKF55/MTW4yJUsO/Sh2DFonr/8LaSFCn8J9dT 6YJlWxDh1RIlvLPGM0w8yQdMAr4w/IPG01n3vnZ2qVhf7HRMPTXgACPtv0/cAq6lVflc u8usOhLGrgOR/xJXd0rZJx3tDtJ+3QItpEC7DZNeCqk+WuBde6RA/liOjjmoLbaQB/IJ xBzp4ZCkOtvjuWlMRUaVNOtaqo3UeLT5xfjKUlZmHCYVFsNrFdE1Q4vxtLF7PljVpFfS jCnqNxGe3GDcS8nkmE9PajCs4bBQJgCf2xplRbi/Mu9zIa5eaobbkU5lllLKjKi6SOq8 29Hw==
X-Gm-Message-State: AA+aEWaf6PBlPij/Fp+GSavVWXB0gQ2AzPCSZEgrLu2pxJqU2Ew0Zt6S TJqb3UQ5u3xNeuBP5kr6J5X7+ACQ
X-Google-Smtp-Source: AFSGD/XYX271KNro1jFjtTM1SZE9tpv5r7PM3vrnAbS/fAsHFDNELMHNLNI2AwPdCfRQ5D6ftXTZyw==
X-Received: by 2002:a1c:44d6:: with SMTP id r205mr12346246wma.50.1543922562718;  Tue, 04 Dec 2018 03:22:42 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id v19sm23534970wrd.46.2018.12.04.03.22.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 03:22:41 -0800 (PST)
To: Magnus Westerlund , =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: "rtcweb@ietf.org" 
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>  <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>  <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com>  <2d9ca83e-4b81-23e2-ccbb-3c3e4423d291@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: <8571e2cb-85fb-9638-097a-831a5949a69a@gmail.com>
Date: Tue, 4 Dec 2018 12:26:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D8735F7748E7564157EB0D58"
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 11:22:48 -0000

This is a multi-part message in MIME format.
--------------D8735F7748E7564157EB0D58
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 04/12/2018 11:51, Magnus Westerlund wrote:
> On 2018-12-04 11:01, Sergio Garcia Murillo wrote:
>>> However, an RTP middlebox has the freedom to introduce those header
>>> extensions when switching. They do not need to be sent end-to-end all
>>> the time. So after the initial establishment of them, I see it as the
>>> central middlebox responsibility to ensure that they are included in the
>>> down stream legs towards the conference participants. Also at least for
>>> video introducing them only on reception of a FIR also makes sense.
>> Same could be said about changing the ssrc to avoid collisions and we
>> would have avoided our selves to introduced all this new ids.
> I think you are significantly misrepresenting the reasons why RID's are
> needed. The fact that we have multiple models for how RTP middleboxes
> works is a significant contributing factor. The next is in RTP ancestry
> as a non-centralized multi-party protocol, i.e. intended to work over
> any source multicast. And as simulcast do implies a selection by the
> middlebox that aspect do needs to be handled. A clean-slate approach
> could possibly select another set of constraints and maybe be somewhat
> simpler but not a lot.
>
> I do note that also the MIDs and RIDs only have per signalling context
> and may require translation between the various legs of the conference
> in a multi-party one.


I disagree with several of those statements, but my intention was not to 
start a new discussion about the need of mids/rids, but the usage in RTX 
which I have not yet got a good answer.

Trying to get back to the discussion:

  * What headers should contain a RTX packet from a track added via
    addTrack or addTransceiver without encodings
  * What headers should contain an RTX packet from a track added via
    addTransceiver with several encoding+rids

Best regards

Sergio


--------------D8735F7748E7564157EB0D58
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 04/12/2018 11:51, Magnus Westerlund
      wrote:

    

    

      
On 2018-12-04 11:01, Sergio Garcia Murillo wrote:


      

        

          
However, an RTP middlebox has the freedom to introduce those header
extensions when switching. They do not need to be sent end-to-end all
the time. So after the initial establishment of them, I see it as the
central middlebox responsibility to ensure that they are included in the
down stream legs towards the conference participants. Also at least for
video introducing them only on reception of a FIR also makes sense.


        

        
Same could be said about changing the ssrc to avoid collisions and we 
would have avoided our selves to introduced all this new ids.


      

      
I think you are significantly misrepresenting the reasons why RID's are
needed. The fact that we have multiple models for how RTP middleboxes
works is a significant contributing factor. The next is in RTP ancestry
as a non-centralized multi-party protocol, i.e. intended to work over
any source multicast. And as simulcast do implies a selection by the
middlebox that aspect do needs to be handled. A clean-slate approach
could possibly select another set of constraints and maybe be somewhat
simpler but not a lot.

I do note that also the MIDs and RIDs only have per signalling context
and may require translation between the various legs of the conference
in a multi-party one.


    

    


    

    
I disagree with several of those statements, but my intention was
      not to start a new discussion about the need of mids/rids, but the
      usage in RTX which I have not yet got a good answer.

    
Trying to get back to the discussion:

    
    
      
  • What headers should contain a RTX packet from a track added
        via addTrack or addTransceiver without encodings
    
      
    • 
      
  • What headers should contain an RTX packet from a track added
        via addTransceiver with several encoding+rids
    
      
    • 
    

    
Best regards

    
Sergio

    

  


--------------D8735F7748E7564157EB0D58--


From nobody Tue Dec  4 03:34:32 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E70A126C7E for ; Tue,  4 Dec 2018 03:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 7AFrnlQ-GwAd for ; Tue,  4 Dec 2018 03:34:28 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 023B812875B for ; Tue,  4 Dec 2018 03:34:27 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id y27so9594600vsi.1 for ; Tue, 04 Dec 2018 03:34:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=M06p9UDL9v/TtzDhzWrkdDkAWjlywOUiMJKl7zGbYlU=; b=OP0EFMD82/8TeLC42ZvoJATpg5WQDzGvHen2OKaRibN9+bC9RRp3fZPrVus+ltirxF Tf46XiogL2HOALN+vyHRJxxISQmo7ZGqcthmyxJXgIOKnKRSn+Y5TiSbejMvJzlihsU5 iaubJtWmKoHW0Xuhhh1vh9yGpt8HQdm7JuOHoC45fQ2RYo/qd5C2V70jvdVMQAWq7ghq MyXIPp0L2yKh1ezd3j+0gOQxw07CjLXuKtL6X9BEud7LIYaskcUX2rQtbG2aunGRYxjJ ibCswA+WJAaQjXZIxnGcxyStQwZJ9k2UHCYwLYw6R3sgsfANm2q8Fk8ndB6NLRB+iw5y YJwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=M06p9UDL9v/TtzDhzWrkdDkAWjlywOUiMJKl7zGbYlU=; b=aCIXYPy11/TJgeaAltOl74NB3A9byJOwDRGc5HGhWv5K9Uf0iQ+yOB3JRpN0YDGzHi EQyJoD8u4ZGGTwn6BphoCTFj6jXxeLBqXf//4tAovGOgNyC4YqpOzMuAla5jPng/v8GN 0oDfnYcjpObOPt3xJ8DIJLVwE0+C+kth8jnhuhvuWOnyMnIlszLqT5/cY/G5agBNX+uO aP0LRkgtBOCnapA0OOM0YZz6FaqAzx4TA44GftBgHPK8plB39XTxc8jpPqUDdz88h4ew 90pUfjpKLqQ2gfOvATsodwHyBUknyA3VIXTzTdFwHpCibpY6yR6QtCQSKfqNv+7nWFd3 +LEQ==
X-Gm-Message-State: AA+aEWZAO7gCC1VoEgqpr5liDBm2cEO8t5oAz8Pq+CMlpHxIUTJalJ6u K1GOR8aP+UgL025YGx+rqN9aDqxGv+cHPmXOCk9yfA==
X-Google-Smtp-Source: AFSGD/XYKEFNvky2jctQ+f3Nuz7QnBbuZEeGaNOK0C7Nwq+FQ5Ctd8vubZk0J8kHesn/tNhwBU9cGIx7NUMgzYw7z6o=
X-Received: by 2002:a67:3edc:: with SMTP id a89mr8591894vsi.136.1543923266816;  Tue, 04 Dec 2018 03:34:26 -0800 (PST)
MIME-Version: 1.0
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>  <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>  <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com>
In-Reply-To: <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 4 Dec 2018 12:34:15 +0100
Message-ID: 
To: Sergio Garcia Murillo 
Cc: Magnus Westerlund , rtcweb@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 11:34:31 -0000

On Tue, 4 Dec 2018 at 10:35, Sergio Garcia Murillo
 wrote:
>
> On 03/12/2018 22:26, I=C3=B1aki Baz Castillo wrote:
> > On Mon, 3 Dec 2018 at 22:22, Sergio Garcia Murillo
> >  wrote:
> >> My point is that there is a single source in the transceiver/MID why
> >> should we add default RID and waste 2 more bytes in each media and rtx
> >> packet?
> > Regardless what browsers do today, both MID and RID headers should be
> > just included in the first packets. The receiver is supposed to update
> > its ssrc table for faster matching.
> >
> > NOTE: The sender should also resend MID and RID if the SSRC changed
> > because some RFCs state that SSRCs may conflict and things that
> > absolutely never happen.
> >
> Kind of agree, but from a theoretical point of view remember that we
> introduced MIDs/RIDs to cover rtp proxing/switching scenarios in which
> ssrc conflicts may happen, so in order to cover those scenarios the
> MIDs/RIDs values must be included in every packet.

I don't think that rationale is correct. No need for MID/RID in
*every* packet, but just in the first ones (despite what browsers do).
Once magic SSRC conflict happens (AM I READY TALKING ABOUT SSRC
CONFLICT??) the sender should just choose a new SSRC and add MID/RID
in the next packets.

> If we ignore that,
> then could just go back to ssrc signaling and avoid mids/rids
> completely, which I would be in favor of.

Definitely signaling ssrcs instead of MID/RID is *much* easier for
anyone who has implemented this stuff. I'm still waiting for any good
reason to not signal ssrcs (NOTE: I do not believe in SSRC conflicts
and will not believe in it no matter which "RTP middlebox stuff"
rationale is given to me).

Said that, if we go that way (signal MID and RID instead of ssrcs)
it's ok as far as we can also properly signal simulcast + RTX, which
is not clear given the length of this thread.

--=20
I=C3=B1aki Baz Castillo



From nobody Tue Dec  4 03:45:21 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90299128CF3 for ; Tue,  4 Dec 2018 03:45:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 E8a9M0IsYMin for ; Tue,  4 Dec 2018 03:45:17 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 99225126CB6 for ; Tue,  4 Dec 2018 03:45:17 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id j2so15618904wrw.1 for ; Tue, 04 Dec 2018 03:45:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ocF0AC3jlEbQDJ6nsbsWQAytzUvM5FGT33hEu2ZFZdE=; b=B1bDWz6VGcLEVw1K0kTmze2ZD3yR3yq2qy3NLiEvHb5mspxxhmKYJxA5taZ+UjgjyU mPdPFyIUf524n8GkR0oIQ2kjRBeOeJa9QO5vYETjvjJKo/nZLbdWifiAJBIfGnUkosqO vTfk2o69hRiUjXPk5Eypg3rtE0jhywX7jW7GdwebxBSmv/+t+CyHnJw1RjS8GeWyPMz0 WPkKeZnfJsOhczo2OLpKHPjRZwgziPFywYmtb1iYBPkK5DTR2Cn75lTq2aSqPzqYrrQb qgsZRJ+Oo8HvFXvG9css3arrYMayUptf6T9dp+BsrASOT96H35XPcMcgHcMZgm9Hh7W2 u2GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ocF0AC3jlEbQDJ6nsbsWQAytzUvM5FGT33hEu2ZFZdE=; b=h5IbdQV5slgOIU8HD0cBwxC2E9NffMQyGJEzGb0Av9W7eCiF3mYvvry6La3h+PXADt gJafPg4RGA5NT+GOzDKYBgLcOmEQOo2ihHd3tMMZrv7gc4Dlkp77P1VByTrEj7BKLVbS OyVpPXbEm+3ibteQHYJMEbzdV+QkfovEjx7g6iShydedpFtOQosDd62WN6juCM1z8KBA s/eEqrZMZZAukdMa/AJxMO/ZVTtaSynB1qv+Y9ltV8O1SKSMKkKLH8OsMnI65OfAyPQ4 nwsMLn25wEIj3bKbB8gd4OQxaqFCzCcD1QEl15xX3oxt8FxtC05L+p67JMQ6OG36HCg4 Qd7Q==
X-Gm-Message-State: AA+aEWb2F7zfcJPwbMaWwoLIYBUVCx4M4RqTJeckvoTR/XTA2d8G00jV SlgGyslPaDl2USNvzdBZ1UYjQAYb
X-Google-Smtp-Source: AFSGD/Wo6l/0B0xbfTdAJWkXYq/mxs0JWLf7VP7QJ4NTcA+I825OfDp4Murf0Gc7bn5wKdzwaAun0g==
X-Received: by 2002:adf:ec50:: with SMTP id w16mr18176782wrn.171.1543923915740;  Tue, 04 Dec 2018 03:45:15 -0800 (PST)
Received: from [192.168.0.111] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id v5sm21779086wrn.71.2018.12.04.03.45.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 03:45:14 -0800 (PST)
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: Magnus Westerlund , rtcweb@ietf.org
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>  <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>  <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com> 
From: Sergio Garcia Murillo 
Message-ID: 
Date: Tue, 4 Dec 2018 12:48:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 11:45:19 -0000

On 04/12/2018 12:34, Iñaki Baz Castillo wrote:
> On Tue, 4 Dec 2018 at 10:35, Sergio Garcia Murillo
>  wrote:
>> On 03/12/2018 22:26, Iñaki Baz Castillo wrote:
>>> On Mon, 3 Dec 2018 at 22:22, Sergio Garcia Murillo
>>>  wrote:
>>>> My point is that there is a single source in the transceiver/MID why
>>>> should we add default RID and waste 2 more bytes in each media and rtx
>>>> packet?
>>> Regardless what browsers do today, both MID and RID headers should be
>>> just included in the first packets. The receiver is supposed to update
>>> its ssrc table for faster matching.
>>>
>>> NOTE: The sender should also resend MID and RID if the SSRC changed
>>> because some RFCs state that SSRCs may conflict and things that
>>> absolutely never happen.
>>>
>> Kind of agree, but from a theoretical point of view remember that we
>> introduced MIDs/RIDs to cover rtp proxing/switching scenarios in which
>> ssrc conflicts may happen, so in order to cover those scenarios the
>> MIDs/RIDs values must be included in every packet.
> I don't think that rationale is correct. No need for MID/RID in
> *every* packet, but just in the first ones (despite what browsers do).
> Once magic SSRC conflict happens (AM I READY TALKING ABOUT SSRC
> CONFLICT??) the sender should just choose a new SSRC and add MID/RID
> in the next packets.

Yes, they could be sent in all packets until the first received RTCP RR 
for that ssrc (to ensure binding on the received side) and then only on 
first packet of an intra frame for video.


>> If we ignore that,
>> then could just go back to ssrc signaling and avoid mids/rids
>> completely, which I would be in favor of.
> Definitely signaling ssrcs instead of MID/RID is *much* easier for
> anyone who has implemented this stuff. I'm still waiting for any good
> reason to not signal ssrcs (NOTE: I do not believe in SSRC conflicts
> and will not believe in it no matter which "RTP middlebox stuff"
> rationale is given to me).


+1

btw, I use an alternative approach for signaling back rids/ssrc 
association for chrome sdp mangling in order to havea single processing 
algo on the SFU (note the ssrc attribute on the rid which is completely 
valid accoding to the rid ABNF ;)

a=ssrc-group:FID 3267388881 2718767991
a=ssrc:3267388881 cname:jwLMsXS4a6eBfofC
a=ssrc:3267388881 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:3267388881 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:3267388881 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:2718767991 cname:jwLMsXS4a6eBfofC
a=ssrc:2718767991 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:2718767991 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:2718767991 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc-group:FID 100 101
a=ssrc:100 cname:jwLMsXS4a6eBfofC
a=ssrc:100 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:100 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:100 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:101 cname:jwLMsXS4a6eBfofC
a=ssrc:101 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:101 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:101 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc-group:FID 102 103
a=ssrc:102 cname:jwLMsXS4a6eBfofC
a=ssrc:102 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:102 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:102 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:103 cname:jwLMsXS4a6eBfofC
a=ssrc:103 msid:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3 
21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc:103 mslabel:GSRze2SaLY9enVp5h3LslsdM0kD7cydbdFk3
a=ssrc:103 label:21715433-7804-4c4d-a269-dfc6a06470cd
a=ssrc-group:SIM 3267388881 100 102
a=simulcast:send a;b;c
a=rid:a send ssrc=102
a=rid:b send ssrc=100
a=rid:c send ssrc=3267388881

> Said that, if we go that way (signal MID and RID instead of ssrcs)
> it's ok as far as we can also properly signal simulcast + RTX, which
> is not clear given the length of this thread.

Neither for non-simulcast scenarios


Best regards

Sergio


From nobody Tue Dec  4 03:45:27 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8AF126CB6 for ; Tue,  4 Dec 2018 03:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 p_-4OVZHFcog for ; Tue,  4 Dec 2018 03:45:18 -0800 (PST)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 BB1BE128A6E for ; Tue,  4 Dec 2018 03:45:17 -0800 (PST)
Received: by mail-vs1-xe2a.google.com with SMTP id y27so9611263vsi.1 for ; Tue, 04 Dec 2018 03:45:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SMaLAJJKNwbQR/R/y7jzyw0/OF93lPONtUr7IAGDBRQ=; b=CjmZXTyx4OYXVHGI9oAwBP6ZT5TLIaeTt8cGvNi2OqLPljAheR8yB/C3X4EuKnQWoV /NEUWpkIXgrKFBcJIhnuEt8Dz3QQ4S3hXnn8CCFWdjU8lo9dA7pMq1g8C87iFgqfOE2y eg55qD2XRwjn18xETN5N0k32sCGK7vkQ/sQvSOuqSxJNrwEnA5t2uvQHgtYD3nBg8Tz3 0OKyAiYYDEqZfyeQQhvqtWzY5tZinLNrLAHMhaBSA34SA+av4kphYlRGbc5gwavJIYsS CmvWF0tQZyFKOWZ6rMQOs/m7TXT8ReeDY4nsr2h1Gtks9BfaPdOcWKrzhR5f83aS96le K92w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SMaLAJJKNwbQR/R/y7jzyw0/OF93lPONtUr7IAGDBRQ=; b=G4d1bcXLP+iXCkvbaWO+oeB34LszdJg6VFlyycp0KpSmYcR6lX6XiRJeA5oqVPvEy7 WuFQLzdAHM+1nv3eVYrxxpTUPnVcNqtiui5pmZ3ATupwTTQPVowKBS3KCB/Dy9fxaBai mfQSMKF2DJ74B2Vx7NiaTq8YEFz/aSIuPfa54YVnXRkdlJ1m2sfAlxmyHnBrEN0qJ6md jTJISWGMeHZ4ql1gdME0YcgVx6Kung0VtvT8mrL4X9WM5aDG9bJuwO7nAm3SCO2e7Rsl dtsEqdtu3FqIAzykogkiEzENYtxVvFHupzE0WcMkajW2srV/MUyixvDBHsykG2r7kCjy u/og==
X-Gm-Message-State: AA+aEWZKMGWppnuI6RMNk4z5qiJWyGQwfZiPmJX4b7ql1ZSstdq9hQp3 bijZ3cTGzamUE/6EE0EFvldrVN1XTlPcGHAbS48vig==
X-Google-Smtp-Source: AFSGD/UE12DnBQp7Uy8jUqYpfw2+uEvzKfZtV/KgpUrUvVe1sV/ViHfW6LU6oMypKh9O+ETX5zblw/TfZ7bCDV8FNx0=
X-Received: by 2002:a67:6204:: with SMTP id w4mr8802705vsb.68.1543923916698; Tue, 04 Dec 2018 03:45:16 -0800 (PST)
MIME-Version: 1.0
References:   <45beb8d6-6578-dc98-4ff7-1be7a55c0687@gmail.com>  <13ff90af-d62e-2f47-3ccc-16ca4e9e3cac@gmail.com>  <2613a4ff-0855-4f78-d3f0-9f9aaaf9ecdb@gmail.com>  <1af3105f-5e66-548d-cb31-6aaf9f2cd0b4@gmail.com> 
In-Reply-To: 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 4 Dec 2018 12:45:05 +0100
Message-ID: 
To: Magnus Westerlund 
Cc: Sergio Garcia Murillo , rtcweb@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Clarification on simulcast and RID and RepairedRtpStreamId
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 11:45:20 -0000

On Tue, 4 Dec 2018 at 10:58, Magnus Westerlund
 wrote:
> However, an RTP middlebox has the freedom to introduce those header
> extensions when switching. They do not need to be sent end-to-end all
> the time. So after the initial establishment of them, I see it as the
> central middlebox responsibility to ensure that they are included in the
> down stream legs towards the conference participants. Also at least for
> video introducing them only on reception of a FIR also makes sense.

The problem here is well known and happens often in this WG: the lack
of proper layer separation in SDP / RTP. The thing is:

1) MID/RID is valid within the context of a transport, nothing else.
And a transport is hop by hop. The receiver (an endpoint, a SFU, a
MCU, whatever) checks packet MID and then packet RID/RRID to figure
out the corresponding "transceiver" or m section and the corresponding
stream (media, simulcast, RTX).

2) If the receiver is a SFU which is gonna multiplex such a "track"
with many others to send them to a receiver over a single transport
(Bundle) then MID/RID does not make any sense because MID is typically
"0" or "1" etc. So the SFU would need to rewrite MID for each receiver
or just not announce MID support at all in the other leg.

3) In the case of RTX this is much more easier: RTX is just hop by
hop. If there is a SFU in the middle, you don't send a RTX packet
directly to the endpoint. You send it to the SFU (assuming the SFU
sent you a NACK). The SFU "decodes" and stores it. If the receiver in
the other leg sends a NACK, the SFU encapsulates such a stored packet
into a new RTX packet and sends it to the receiver. So RTX is hop by
hop, and hence it does not make any sense to talk about reusing
MID/RID headers for same reasons given in 2).

--=20
I=C3=B1aki Baz Castillo



From nobody Tue Dec  4 06:00:59 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1905D130DD5 for ; Tue,  4 Dec 2018 06:00:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 LPu7ba3HgU8S for ; Tue,  4 Dec 2018 06:00:53 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 CC0DA126DBF for ; Tue,  4 Dec 2018 06:00:52 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id q70so9631897qkh.6 for ; Tue, 04 Dec 2018 06:00:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/8FMgKWDovOj1jcAXnO4uUmuISBuIdiqTRGzSjbaZmE=; b=S3T6hTCiUMp6uaDLcbIMn5iqy96ihpQjZazQF9BbwjTQuIftPlINASf0wt/1AqoC8V M6KhaC9XKYyrb28G/XbEeWD/OuXq4dK9O2MU8/M5P8jsqWuo+MgJ8k2PqZVYGq7Ec6rz D5udJInice9L/qJu4Ewm9BXHp8NO2eyZ9CdzE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/8FMgKWDovOj1jcAXnO4uUmuISBuIdiqTRGzSjbaZmE=; b=sDXwC88Kj1FpzBGWS8WNWvTR00osqSoqiEPssmGCQu93xynASIQ/2gv3jE5kR0VvRX X2+h0VqMX75DARtzBfJsNIQ7tHd61Z1/rDtwCBjjuLoLEy0DztOP0fMlSkSMt2oBhes8 hGZbkDGe+fiF0+cdtingdsxpFjmjYm9A6HOekTcQ+uJGt6t9rYt2DnJe4oteWx0DS0yO Q/XMILAJhkh6Owk/sjjaaC2MnNQzEX73wDZZeKr3kuwVFUBWjL57eP3NPfGywBkHHlP1 GbKcnId94GEVn1BBfaYvq9jXPSMfu/XrxGeG+BfoptpXZurInRS8585/dZhWxo9Zs2Lo AY7g==
X-Gm-Message-State: AA+aEWYvJpvG8pxQNh6hN3v5ew+9eLxTR0/64gNblQaSKYT9iXC2LLsc 2kmduYbPpu9jZB+afA7ruIT6rQ==
X-Google-Smtp-Source: AFSGD/WCRUF7g2ksJepSWmOtyR4WyRMKOub+njW1KgXqvPfjRWEd/FH0lY4TLfvbDnbDHE2OF6NWRg==
X-Received: by 2002:a37:611:: with SMTP id 17mr18785585qkg.123.1543932051931;  Tue, 04 Dec 2018 06:00:51 -0800 (PST)
Received: from [172.16.0.18] ([96.231.221.42]) by smtp.gmail.com with ESMTPSA id 195sm9407607qki.76.2018.12.04.06.00.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 06:00:51 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Sean Turner 
In-Reply-To: <00FB4C71-EBD9-4EF6-A3B1-D0C06EA61A53@iii.ca>
Date: Tue, 4 Dec 2018 09:00:50 -0500
Cc: RTCWeb IETF 
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A355EC4-A687-44EE-B8F4-CED1D25F1EDA@sn3rd.com>
References: <0293CF6D-9B4F-4680-BBB9-833C33D03013@sn3rd.com> <00FB4C71-EBD9-4EF6-A3B1-D0C06EA61A53@iii.ca>
To: Cullen Jennings , Eric Rescorla 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [rtcweb] status: draft-ietf-rtcweb-security-arch
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 14:00:58 -0000

I will have to defer to ekr as I was just throwing in a PR to address =
this issue:
https://github.com/rtcweb-wg/security-arch/issues/82

spt

> On Dec 3, 2018, at 17:27, Cullen Jennings  wrote:
>=20
>=20
> Why would we want to prohibit false start? I has assumed we could use =
it for early media. Is there an issue we should be aware of ?
>=20
>=20
>=20
>> On Nov 21, 2018, at 10:54 AM, Sean Turner  wrote:
>>=20
>> Hi!
>>=20
>> We are getting to the point where we be able to move =
draft-ietf-rtcweb-security-arch
>> (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/) =
to our AD for IETF LC.
>> ekr has noted in PR that follows that false start should be =
prohibited:
>>=20
>> https://github.com/rtcweb-wg/security-arch/issues/82
>>=20
>> If there is any concerns with merging addressing this issue please =
speak up.
>>=20
>> Cheers,
>>=20
>> stp
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>=20


From nobody Tue Dec  4 13:21:54 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E77130E6E for ; Tue,  4 Dec 2018 13:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.347
X-Spam-Level: 
X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hSK4-6f7T11z for ; Tue,  4 Dec 2018 13:21:45 -0800 (PST)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 A955A130EE4 for ; Tue,  4 Dec 2018 13:21:44 -0800 (PST)
Received: by mail-pf1-x429.google.com with SMTP id q1so8849526pfi.5 for ; Tue, 04 Dec 2018 13:21:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s6WjL3qP1z+ZBHj4CCN+zPtY0njDoHz3rgQDmDQAqz8=; b=MQLjyxEC6OJQjZAe8buDDdg/HW7epOXMSITXh8PhlbfZEan5MKrtugEmiQiFlSi69T oujKO/BCeA+uuDcuPLSTehcM3UzvHoGoGgDHjg2MKA/rVlSmqpjMoOuwGaMsYiB+ltuM GNkPE3w+bFrVOHbr0TOaSaM2a0+Q5rm0h0dp/WV0s2t6Hs1088T6TUFYuEW4l0RMA0cq fbqGzj4EuvMg2qZZUsnZ13xw91QoKrTzwxvYjtyj3q3wHebvBJpp4rVAvRT3bANl770v R3PWBRIhLgFoTZkj9bzZzr0QQvpLzfqJS1PlxQYmwPDNb2yXB11kePKtL0WXAsAEZDJl c8Rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s6WjL3qP1z+ZBHj4CCN+zPtY0njDoHz3rgQDmDQAqz8=; b=P14HXQhlfcF+71FT9NTmL5wTFeAqth0SpKdikq3F3KXyk60Wt8t1huEgyCLh6j+TOv vmfQ1p8DrK/Fw/E08+OD/3cmu15+ExVvl2dMCzAYSHPD+/3sy8dUwWzO51Gsp8YVD19V JLS2pvZNwwH2AqD/ZpvSL99Q0njE7lMbH7aPyw01YH1NHc9npXx5PiYW6lC0dKt+qfWH uNKGRu4cdORzd2ZHZfUHhK8VwkP+/oFMAYCkV+1Z3x1fl66q6sG0tJCay1/7wXkqBgPN 1B/8xf9AMJR7UPKQV37QEhbNM69CPtbG8DJdXAUW4zv+LDWwRiaIQYqD5t1l3pdb2RpN xBDw==
X-Gm-Message-State: AA+aEWYw474MKz/yRTRPjgLRzd7OtH2oyzEBkehoXA2YjF8Ks2NQnBA5 LpS7CB9YXhRzwp6fA17KKP023rPWfug=
X-Google-Smtp-Source: AFSGD/WLVSPXvmB1m8LaUAp6xMrJbWfYmSNtjpCVh8/OeT6a7nsoD4VUJaOcAhr7wSJgF6pSA49ewg==
X-Received: by 2002:a62:b15:: with SMTP id t21mr22524169pfi.136.1543958504065;  Tue, 04 Dec 2018 13:21:44 -0800 (PST)
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com. [209.85.214.176]) by smtp.gmail.com with ESMTPSA id g28sm33714715pfd.100.2018.12.04.13.21.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 13:21:43 -0800 (PST)
Received: by mail-pl1-f176.google.com with SMTP id y1so4109998plp.9; Tue, 04 Dec 2018 13:21:42 -0800 (PST)
X-Received: by 2002:a17:902:2f03:: with SMTP id s3mr21092354plb.277.1543958502575;  Tue, 04 Dec 2018 13:21:42 -0800 (PST)
MIME-Version: 1.0
References:   <9B9B741B-622F-4565-899B-700636408F6C@iii.ca>  <54ebb208-e7b3-a0f1-6a5c-4745d3a56447@cisco.com>  <1346FE48-5D61-48B7-BF37-3D7BAA930DB0@iii.ca>  <110dc822-b3be-7bc2-dcc5-9e6c8277e0d1@nostrum.com>    
In-Reply-To: 
From: Roman Shpount 
Date: Tue, 4 Dec 2018 16:21:31 -0500
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Adam Roach - SIPCORE Chair , RTCWeb IETF , mmusic WG 
Content-Type: multipart/alternative; boundary="0000000000001814a4057c38da11"
Archived-At: 
Subject: Re: [rtcweb] [MMUSIC] Default proto transport in JSEP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2018 21:21:47 -0000

--0000000000001814a4057c38da11
Content-Type: text/plain; charset="UTF-8"

Hi,

On Tue, Dec 4, 2018 at 2:04 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Also, as far as I understand, JSEP only defines an API, not a network
> protocol, so if you want to be standards compliant on the wire the JS app
> would have to modify the SDP before sending it to the network, and I do not
> think we want that.
>
>
I generally agree. JSEP is API specification and a signaling profile which
specifies in more detail offer/answer procedures which are used by JSEP
compliant end points. So far, JSEP was compliant with existing procedures,
but it made some things more strict. In that sense, using UDP based
protocols during ICE restart is totally within JSEP scope. Changing RFC
5245 and other related ICE documents, including ice-sip-sdp, in
non-backwards-compatible manner by changing procedures during subsequent
offer/answer exchanges which do not change ICE settings should not be
within this document scope. Furthermore,  it seems to be totally
unnecessary except for procedural and editorial reasons.

Regards,
_____________
Roman Shpount

--0000000000001814a4057c38da11
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Hi,

<=
div dir=3D"ltr">On Tue, Dec 4, 2018 at 2:04 AM Christer Holmberg <christer.holmberg@ericsson.com<=
/a>> wrote:










Al=
so, as far as I understand, JSEP only defines an API, not a network protoco=
l, so if you want to be standards compliant on the wire the JS app would ha=
ve to modify the SDP before sending it to the network, and I do not think w=
e want that.






=
=C2=A0


--0000000000001814a4057c38da11--


From nobody Sun Dec 16 06:41:44 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24537126BED for ; Sun, 16 Dec 2018 06:41:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 v28KrXmH0R9N for ; Sun, 16 Dec 2018 06:41:40 -0800 (PST)
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 1510B124D68 for ; Sun, 16 Dec 2018 06:41:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 32F797C5A79 for ; Sun, 16 Dec 2018 15:41:38 +0100 (CET)
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 WUwc6D-A2-Vn for ; Sun, 16 Dec 2018 15:41:30 +0100 (CET)
Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 747D27C5A12 for ; Sun, 16 Dec 2018 15:41:30 +0100 (CET)
References: <154469279635.2745.5414294686765340732.idtracker@ietfa.amsl.com>
To: "rtcweb@ietf.org" 
From: Harald Alvestrand 
Openpgp: preference=signencrypt
Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk=
X-Forwarded-Message-Id: <154469279635.2745.5414294686765340732.idtracker@ietfa.amsl.com>
Message-ID: <78cb0682-c683-c469-a4d2-ec3d0eeebb71@alvestrand.no>
Date: Sun, 16 Dec 2018 15:41:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <154469279635.2745.5414294686765340732.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-mmusic-msid-17.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 16 Dec 2018 14:41:43 -0000

I believe this discharges the obligation I took on at the Bangkok IETF
meeting to update MSID according to the new consensus that track may be
omitted.

Harald


-------- Videresendt melding --------
Emne: New Version Notification for draft-ietf-mmusic-msid-17.txt
Dato: Thu, 13 Dec 2018 01:19:56 -0800
Fra: internet-drafts@ietf.org
Til: Harald Alvestrand 


A new version of I-D, draft-ietf-mmusic-msid-17.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Name:		draft-ietf-mmusic-msid
Revision:	17
Title:		WebRTC MediaStream Identification in the Session Description
Protocol
Document date:	2018-12-13
Group:		mmusic
Pages:		19
URL:
https://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-17.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-msid-17
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msid
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-17

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.





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.

The IETF Secretariat


From nobody Fri Dec 21 15:13:07 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34567130EB8 for ; Fri, 21 Dec 2018 15:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level: 
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 mvSiDM5dUICj for ; Fri, 21 Dec 2018 15:13:05 -0800 (PST)
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 1DB1A130EB3 for ; Fri, 21 Dec 2018 15:13:05 -0800 (PST)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wBLND1WQ057973 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 21 Dec 2018 17:13:03 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1545433984; bh=Sv1oYAX9ofW+kYQ0CUV5BBh6DcPcR8t0jUukZeuQzwE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=eA9raU6xQUhpcVfCWH92uWzlcSk4c45vUMrEL6suf7iChmUgKbo3Erx2OOHmocEAS ARSq5kNbcT2lTwZ6wTB1aR3eB7yDgPps20GZ5CAj9msRA9oLAQlTky/dSp0SIirf18 CysjGKP8dtJkltoBrGfC8c1rVG1cEs38fFnfyJU0=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Sean Turner , Cullen Jennings , Eric Rescorla 
Cc: RTCWeb IETF 
References: <0293CF6D-9B4F-4680-BBB9-833C33D03013@sn3rd.com> <00FB4C71-EBD9-4EF6-A3B1-D0C06EA61A53@iii.ca> <9A355EC4-A687-44EE-B8F4-CED1D25F1EDA@sn3rd.com>
From: Adam Roach 
Message-ID: 
Date: Fri, 21 Dec 2018 17:12:56 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <9A355EC4-A687-44EE-B8F4-CED1D25F1EDA@sn3rd.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] status: draft-ietf-rtcweb-security-arch
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2018 23:13:06 -0000

EKR / Fluffy -- can we come to closure on this?

/a

On 12/4/18 8:00 AM, Sean Turner wrote:
> I will have to defer to ekr as I was just throwing in a PR to address this issue:
> https://github.com/rtcweb-wg/security-arch/issues/82
>
> spt
>
>> On Dec 3, 2018, at 17:27, Cullen Jennings  wrote:
>>
>>
>> Why would we want to prohibit false start? I has assumed we could use it for early media. Is there an issue we should be aware of ?
>>
>>
>>
>>> On Nov 21, 2018, at 10:54 AM, Sean Turner  wrote:
>>>
>>> Hi!
>>>
>>> We are getting to the point where we be able to move draft-ietf-rtcweb-security-arch
>>> (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/) to our AD for IETF LC.
>>> ekr has noted in PR that follows that false start should be prohibited:
>>>
>>> https://github.com/rtcweb-wg/security-arch/issues/82
>>>
>>> If there is any concerns with merging addressing this issue please speak up.
>>>
>>> Cheers,
>>>
>>> stp
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



From nobody Thu Dec 27 22:53:33 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40E912958B for ; Thu, 27 Dec 2018 22:53:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MsFPbHgLBpEy for ; Thu, 27 Dec 2018 22:53:27 -0800 (PST)
Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 EE1CE12894E for ; Thu, 27 Dec 2018 22:53:26 -0800 (PST)
Received: by mail-lf1-x142.google.com with SMTP id p86so13984241lfg.5 for ; Thu, 27 Dec 2018 22:53:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=w1vMSflOjbbYQgh53H4tlERHVxAMBy/IVxwRUIDeBXA=; b=vGsWzBPGqhyRMdrVJwfgwMN4YTDQlKqxSpKegmiQbFtVnZ+hQUkql+oxdHyGgZ57Ys Slj6kCANRFQNKbs+nckGcaQKfqn1JV5LYAIgM2OHpZnGieXzx5OZKWkDjfvw7yEJHCgL Xb3Gq/8IALSR4pN9STKiOcNbwjL5q4hOoH1IEj1om2Q08ZhkLdBEVJfCY4UCvsBg1d/c 1xdysHthUepg00BTOBtPtVMQlq+WshRNq4G2F8tkit+M7uSzeNlsRpZrdav2E6boC4Yr M9LzDedCAI6KMdCahazjhnryMJynUGjYQJwr/wVIc5HwdmNs47AX7u0zJtZ8o6DRqTi8 6D4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=w1vMSflOjbbYQgh53H4tlERHVxAMBy/IVxwRUIDeBXA=; b=j36pt/xYw2ynA0thUyl9I7u2hztm/mALiYPlXGAgN+Iv6AQh+D4VZ9mfNrkH6i+JxR 0dZgYxMrAAPrbY21ArEQBh7ImQLj7HHHvT5k2jBxFMzVUOvQMHIgU285KTr9Phz8g4F5 7mKGMJGKgGencgboPhsnqdha98m66QmyuMT3g7ufry9AVYZ7NLS0dfMQmiwwJr41ugpS aFBeneUu56qAWTP4PYFEEpznFO5NXtmtcjrWCij2HrmagSm0MS3Y9+sHTcNFLsUaPhOI EwFi9fk1ROvecM3eixNF8Hrn1tLzDKPoQ8CtliCOlFLANKeUMMAdpNET4MqiqhMPFIc6 VT9Q==
X-Gm-Message-State: AA+aEWYKwwgIjhEaBcNVz0LkT9ScYeXo+TJYEsaVbwwpgQM2oCaMWoU5 V/AB+ViJm6ZuWauN+aO4fX2iW+Mj+H5G+baijdAl50X3S7w=
X-Google-Smtp-Source: AFSGD/V9moI1xNQJordAO/tI7U6EOG/kQxoNLy8fjutmFMnvL5OhG3BbDuk5DVVeR5xz8I3ZOa/Yu8EAUhyE+L//+ns=
X-Received: by 2002:a19:c014:: with SMTP id q20mr12374381lff.16.1545980004630;  Thu, 27 Dec 2018 22:53:24 -0800 (PST)
MIME-Version: 1.0
From: Frelyn SDIWC 
Date: Fri, 28 Dec 2018 14:53:15 +0800
Message-ID: 
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000182e6057e0f8519"
Archived-At: 
Subject: [rtcweb] The Fourth International Conference on Electrical, Electronics, Computer Engineering and their Applications (EECEA2019)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2018 06:53:31 -0000

--0000000000000182e6057e0f8519
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You are invited to participate in *The Fourth International Conference on
Electrical, Electronics, Computer Engineering and their Applications
(EECEA2019)* that will be held at *University of Perpetual Help System
DALTA, Las Pi=C3=B1as, Manila, Philippines* on *February 20-22, 2019*. The =
event
will be held over three days, with presentations delivered by researchers
from the international community, including presentations from keynote
speakers and state-of-the-art lectures.


The conference welcomes papers on the following (but not limited to)
research topics:
*-----Electronics Engineering-----*
3D Semiconductor Device Technology
Adaptive Signal Processing
Advanced Electromagnetics
Artificial Intelligence
Component Technology of MEMS
Compound Semiconductor
Physics and Devices
Computer Engineering
Device Electronics for I.C
Electronics System-Level Based Design
Electronics & Nano Electronics
Electronics-Medical Electronics
Epitaxy and Light-emitting Diodes
Fiber Optics and Fiber Devices
Giant Area Microelectronics
Intelligent Transportation Systems
Integrated Optics
Medicine and Biology Applications
Micro/Nano Systems and Networks
Mixed Signal Circuits
Mobile Computing
Mobile Robotics
Multimedia Services and Technologies
Networks Design, Protocols and Management
Optical Electronic Devices & Photonics
Radio-Frequency Integrated Circuits
Signal & Image Processing
VLSI Testing and Design for Testability

*-----Electrical Engineering-----*
Software Specification
Software Assurance
Analysis of Power
Quality and System Stability
Assembly and Packaging
Analog Circuits and Digital Circuits
Antenna and Propagation
Battery Management System
Circuits and Electronics
Computer Relaying
Electric Energy Processing
Electromagnetic and Photonics
Electro-optical Phenomena of Semiconductors
Integrated Optics and Electro-optics Devices
Microwave Theory and Techniques
Microwave and millimeter circuit and Antenna
Modulation, Coding, and Channel Analysis
Power Electronics
Power IC
Remote control and techniques of GPS
Remote Control and Techniques of GPS
Robotics and Atomization Engineering
Signal Integrity Design for High-Speed Digital Systems
Signal Processing
Simulation of Propagation
Smart Grid
Solar Power Generation
Techniques of Laser and Applications Of Electro-optics
Wind Power Generation

*-----Computer Engineering-----*
Algorithms
Artificial Intelligence
Automated Software Engineering
Bioinformatics and Scientific Computing
Computer-aided Design
Computer Animation
Computer Architecture
Computing Ethics
Computer Modeling
Computer Networks
Computer Security
Computer Simulation
Database and Data Mining
Data Compression
Data Encryption
Data Mining
Digital Signal and Image Processing
Digital System and Logic Design
Expert Systems
Image Processing
Information Systems
Internet and Web Applications
Mobile Computing
Network Security and Cryptography
Multimedia Applications
Multimedia Networking
Mobile Wireless Networks
Programming Languages
Wireless Communication
Wireless Sensor Network


Important Dates
Submission Date        *Jan. 20, 2019*
Notification of Acceptance         *Feb. 3, 2019*
Camera Ready Submission *Feb. 10, 2019*
Registration Deadline         *Feb. 10, 2019*
Conference Dates                 *Feb. 20-22, 2019*


For more inquiries, just visit*
http://sdiwc.net/conferences/4th-international-conference-electrical-electr=
onics-computer-engineering-applications/
*
or email us at *eecea19@sdiwc.net *

--0000000000000182e6057e0f8519
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


You are invited to participate in=C2=A0The Fourth International Conference on Electrical, =
Electronics, Computer Engineering and their Applications (EECEA2019)=C2=A0that will be held at=C2=A0University o=
f Perpetual Help System DALTA, Las Pi=C3=B1as, Manila, Philippines=C2=A0on=C2=A0February 20-22, 2019.=
 The event will be held over three days, with presentations delivered by re=
searchers from the international community, including presentations from ke=
ynote speakers and state-of-the-art lectures.


=

The conference welcomes papers on the following (but not limited=
 to) research topics:
-----Electronics=
 Engineering-----
3D Semiconductor Device Technology	
Adaptive Signal Proce=
ssing
Advanced Electromagnetics	
Artificial Intelligence
Component Technolog=
y of MEMS	
Compound S=
emiconductor=C2=A0
Physics and Devices
Computer Enginee=
ring	
Device Electron=
ics for I.C
Electronics System-Level Based Design	
Electronics & Nano Electronics<=
/div>
Electronics-Medical Electronics	
Epitaxy and Light-emitting Diodes
Fiber Opt=
ics and Fiber Devices	
Giant Area Microelectronics
Intelligent Transportation Systems<=
span style=3D"white-space:pre-wrap">	
Integrated Optics
Medicine and Biology Applications	
Micro/Nano Systems and Networks
Mixed Signa=
l Circuits	
Mobile Co=
mputing
Mobile Robotics	
Multimedia Services and Technologies
Networks Desig=
n, Protocols and Management	
Optical Electronic Devices & Photonics
Radio-Frequenc=
y Integrated Circuits	
Signal & Image Processing
VLSI Testing and Design for Testa=
bility	

-----Electric=
al Engineering-----
Software Specification	
Software Assurance
A=
nalysis of Power=C2=A0
Quality and System Stability	
Assembly and Packaging
=
Analog Circuits and Digital Circuits	<=
/span>
Antenna and Propagation
Battery Management Syste=
m	
Circuits and Elect=
ronics
Computer Relaying	
Electric Energy Processing
Electromagnetic and Pho=
tonics	
Electro-optic=
al Phenomena of Semiconductors
Integrated Optics and Electro-opti=
cs Devices	
Microwave=
 Theory and Techniques
Microwave and millimeter circuit and Anten=
na	
Modulation, Codin=
g, and Channel Analysis
Power Electronics	
Power IC
Remote control and techn=
iques of GPS	
Remote =
Control and Techniques of GPS
Robotics and Atomization Engineerin=
g	
Signal Integrity D=
esign for High-Speed Digital Systems
Signal Processing	
Simulation of Propagation
Smart Grid	
Sol=
ar Power Generation
Techniques of Laser and Applications Of Elect=
ro-optics	
Wind Power=
 Generation

-----Comput=
er Engineering-----
Algorithms	
Artificial Intelligence
Automated=
 Software Engineering	
Bioinformatics and Scientific Computing
Computer-aided Design	
Computer Animation
Computer Architecture	<=
/div>
Computing Ethics
Computer Modeling	
Computer Networks
Computer Sec=
urity	
Computer Simul=
ation
Database and Data Mining	
Data Compression
Data Encryption	
Data Mining
Digital =
Signal and Image Processing	
Digital System and Logic Design
Expert Systems	
Image Processing
Inf=
ormation Systems	
Int=
ernet and Web Applications
Mobile Computing	
Network Security and Cryptography
Multimedia Applications	
Multimedia Networking
Mobile Wireless Networks	
Programming Languages
Wireless Communication	
=

Wireless Sensor Network


Import=
ant Dates
Submission Date			=
=C2=A0 =C2=A0 =C2=A0 =C2=A0Jan. 20, 2019
Notificati=
on of Acceptance	=C2=A0 =C2=A0 =
=C2=A0 =C2=A0=C2=A0Feb. 3, 2019
Camera Ready Submission		Feb. 10, 2019
R=
egistration Deadline		=C2=A0 =
=C2=A0 =C2=A0 =C2=A0=C2=A0Feb. 10, 2019
Conference Dates		=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Feb. 20-22, 2019

<=
div>
or ema=
il us at=C2=A0eecea19@sdiwc.net



--0000000000000182e6057e0f8519--