From nobody Fri Aug 1 01:16:24 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9431A036F for ; Fri, 1 Aug 2014 01:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf34eUIDzmP8 for ; Fri, 1 Aug 2014 01:16:14 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBA21A0377 for ; Fri, 1 Aug 2014 01:16:14 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q107so5341747qgd.40 for ; Fri, 01 Aug 2014 01:16:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=GlXvarv4U9Em77z8RjLZy9gcyaYosRmYSfIO2NRct3E=; b=XseGVo9g1WfNf6QvvlukQxKfX04iySDPAojvBwGFOQIAcicHOZz+d+1TMyudT4NZno rlCOU2zc2h6T6yQCuC4XoNQd5WtrW/TICkP0F53CG/zGNo1nPS7W+AyGESYLgB3M7sVd +tLem3PRmJOC1cbjHVJS5YGwDzhQlp7mf8DVmU/6ZVhWJ2AjiSbCfSzwtOYlMuhXUn3w s4gKPNhNExpWqRaBzee8CVP5YyUtDSSvzh/VBJ7vK+A8+6kvBykyduq3qyOrs4FJnFez GPpnMbjgJoO8lh1XtjlVFV63lmzD3odIZ/Vj4uRgW7qrSiiUBZyHdW2Bg3+5Axth445E 2rrw== X-Gm-Message-State: ALoCoQl82dijwzZBiPenhBzk4/Of5MFdJ9/SqpJBKsVWIXCRwNNAdahF6fQyxo3hBy5o6aKik/68 X-Received: by 10.224.120.195 with SMTP id e3mr6263128qar.5.1406880973397; Fri, 01 Aug 2014 01:16:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.161 with HTTP; Fri, 1 Aug 2014 01:15:53 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 1 Aug 2014 10:15:53 +0200 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/osr-OtmpzM97_oE1gxHkv5eJiXQ Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 08:16:20 -0000 2014-08-01 3:06 GMT+02:00 Justin Uberti : > On Thu, Jul 31, 2014 at 5:34 PM, Martin Thomson > wrote: >> >> On 31 July 2014 15:40, I=C3=B1aki Baz Castillo wrote: >> > - For DTLS it means complexity in the sense that a separate DTLS >> > session/context is required for each "transport". >> >> Not really. DTLS "says" that, but it doesn't functionally rely on a >> stable 5-tuple in any real fashion. >> >> Other protocols that rely on UDP are likely to be similar. Reliance >> in name only. > > > Think of ICE as a virtual socket. I assume you mean "DTLS" rather than "ICE". > At higher layers, you don't know the > address of the remote endpoint or exactly how it will be contacted, but y= ou > know if you send something on the virtual socket it will make it to the > remote endpoint. That's all DTLS needs to know. Sure. But for that, in case of UDP, you need a *separate* DTLS "virtual socket" for each different UDP remote address from which you receive DTLS packets (you don't want to pass two different ClientHello to the same DTLS virtual socket, assuming that each DTLS virtual socket handles a single DTLS session/context, right?). Well, I will try to explain my concern better: - Let's assume that peerA is a full ICE agent and announces two host candidates (due to two interfaces eth0 and eth1 connected to Internet). - peerB is also full ICE agent which announces a single host candidate. - To simplify, both agree on rtcp-mux and so on. - peerA is the controlling and uses aggressive nomination. - At some point peerB receives a ICE USE-CANDIDATE in its socket coming from peerA's eth0 and another ICE USE-CANDIDATE in its same socket coming from peerA's eth1. Let's name those paths "pair1" and "pair2", both of them are "valid" (regardless which is the "selected"/"nominated" one). - And since it is being said in this thread that "ICE is not supposed to find a *single* transport path" then peerA sends two different DTLS ClientHello, one over pair1 and the other over pair2. - Both ClientHello reach the *same* socket on peerB. If peerB holds a single DTLS "virtual socket" (this is: a single DTLS session/context) then the second ClientHello will be discarded by the DTLS session (as it has already received a previous ClientHello with different seq number and so on). And it would be difficult for peerB to know whether it must send back its DTLS generated response packets to peerA's eth0 or eth1. Is it clear now what I mean? There are two ways to handle this "issue": 1) Ignore any DTLS packet received over a non selected/nominated ICE pair (so both peers must compute the same selected pair after ICE procedures and just use *that* for sending DTLS). 2) Allow DTLS packets received over any valid ICE pair (those from which the remote peer has sent valid and authenticated Binding requests with USE-CANDIDATE). For this a separate DTLS session/context/virtual-socket is needed for each valid ICE pair. PS: In the text above I'm assuming that peerA initiates two different DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to go, may we assume/mandate at least that peerA MUST perform a *single* DTLS handshake (regardless packets are sent and received via pair1 or pair2 or via both of them)? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Fri Aug 1 01:37:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE011A010D for ; Fri, 1 Aug 2014 01:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-RsFPCMsxxZ for ; Fri, 1 Aug 2014 01:36:59 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4741A00EA for ; Fri, 1 Aug 2014 01:36:59 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so5277505qgf.21 for ; Fri, 01 Aug 2014 01:36:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=zdfPhvviQlTciptdUIfJgfnygW6khJ7JVknh3+Re5SQ=; b=RvUb34kGrw6KMoZenuC/BXyLkzHC3EIL/Amydbl51805fkexqD5lQ16BZD3avdq9lQ nr+5MzB3Amm/BF0RW9QZznvkPd6RdgjVGdUJEldHK+AQ72dpeBSXeWjA+KPkequuX3rE 4VjQSzpo5PMOm6x3l+uxtH387Zh/xaTjHvY71WdaL5DrvUo8JjenpombZPEcwvjuFccX w+jzsfNAu+ckdyS7eC+pPjNuBQyAYff7yEnD7Mg40zUXZ7dAj4fJlogmu9i8M9t8aLAZ wdRbSyNC5cSj3Q/lLoP9IEAL/8yPcI+aUNi/wQutrLEF6znR3XVdgGG1+m8tZgAOsrn7 1VyA== X-Gm-Message-State: ALoCoQnr61N9JUGIzlBXGFQVOF+tRo4KLVY1ci1ZGdQMOyplQ0Y/MsPIB50Rtqdl5nV/CaX2ZxCr X-Received: by 10.140.107.4 with SMTP id g4mr6063245qgf.100.1406882218454; Fri, 01 Aug 2014 01:36:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.161 with HTTP; Fri, 1 Aug 2014 01:36:38 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 1 Aug 2014 10:36:38 +0200 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/la9v7AtPPAxuhSO8qCBBGSlQZpo Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 08:37:00 -0000 2014-08-01 10:15 GMT+02:00 I=C3=B1aki Baz Castillo : >> Think of ICE as a virtual socket. > > I assume you mean "DTLS" rather than "ICE". Sorry, you meant "ICE". Then I assume that I'm right in the PS comment at the end of my previous mail, is that correct? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Fri Aug 1 09:04:36 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F441B27EB for ; Fri, 1 Aug 2014 09:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnJJUxxl12hk for ; Fri, 1 Aug 2014 09:04:28 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E841A0B0C for ; Fri, 1 Aug 2014 09:04:27 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so4592764wes.1 for ; Fri, 01 Aug 2014 09:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=49oQwXezm9kZzFd7vgKYZRTrm2eAEJOuKBr3BMeDLU0=; b=fa93lcJz0UH/O6mqVJaQumzSj597eo0CqdR8RXtBdgiPqA+6WAqXbfyeZNqniZpwPe 7MBMp1BFH5b1sP57qK6AlasWhdITwKXdJbVLUDA10j998L8GkACaokyaKyZ+haXtWoV1 ZzxlGZc46WJWPtlkphvSF7VZbIpZupplWy6o+vz04/F7NQ48RcxnYi1gMdpPifqcclpD 3yKOzq4NkUKHna4yjpR7khqUs0fXBh4lmzDLJhlq03VwRVi5yx3o+u+fQGp43SVUKhT5 enMySHtNAmhQA0rBnHYkrhmtOKoyXcaqemxIQF6Z4xnlbotITLHWKWppdDURfi8Q+OQF 6ROw== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr9402889wjb.59.1406909065516; Fri, 01 Aug 2014 09:04:25 -0700 (PDT) Received: by 10.194.169.10 with HTTP; Fri, 1 Aug 2014 09:04:25 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> Date: Fri, 1 Aug 2014 09:04:25 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jh6rYeYpuxwjDZWKl-fNrHiOKAA Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:04:32 -0000 On 1 August 2014 01:15, I=C3=B1aki Baz Castillo wrote: > PS: In the text above I'm assuming that peerA initiates two different > DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to > go, may we assume/mandate at least that peerA MUST perform a *single* > DTLS handshake (regardless packets are sent and received via pair1 or > pair2 or via both of them)? You can only have one DTLS connection, however... Sending two ClientHellos is OK, because DTLS requires retransmission of ClientHello to deal with packet loss. The server should treat those as duplicates (and if they don't carry the same information, you are setting yourself up for failure when it comes to generating the Finished message). From nobody Fri Aug 1 16:03:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2818B1A0199 for ; Fri, 1 Aug 2014 16:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69EyO7jJN4RJ for ; Fri, 1 Aug 2014 16:03:04 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8591A0174 for ; Fri, 1 Aug 2014 16:03:03 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so7696225vcb.20 for ; Fri, 01 Aug 2014 16:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MWtdgPb35nFopA2D95+hne3whTqM+ECP+Q+6Mv3Afj8=; b=PGxExuDfLwk3q0bYHwZ3IuDjP8m0KsgX/EN4dGBw9eRJ408JqIpThUB7UriZC9Rkgn HoMi+RNQw7Zl7HpTHnB75JNQy28aSPw89sqG4iGLZbIn6t83+T7Iv+k7RkpGjFy/AnyQ eS4Pfvuft5jOahzIWoGGulHKqfKpcekVW9HzCBFjjXHc5+wuiFGa9R2b2LyvRRtwsS8r 2ot8ZdaEZzcabQkFsMm9TuK8qzqgpsGCnxjLJ8yTjV3teXSpIggTT6cS91W2N0vXWWvJ Zu3jYVA+Xq+1tiLxHX7833RjZcMMjmUltg4qM8nTDdRsPUhWGI/6zX5VCy4tw26RUZUA KV/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MWtdgPb35nFopA2D95+hne3whTqM+ECP+Q+6Mv3Afj8=; b=MznVMeIPWwjf5mtVpGR7ogyzmYGF1VklqI7z+3x/gDhGcWB5NowZU0H8AM9grgd/tC 9QbQH/bdg4LErkQzlaV2g28qTCG7btgK7Zj9VxeQ9I2LeTx0ctg8OTsy2+kC6naQX+FP 1KwhdRY7tDPxcUkj01keV3PyTS8V1MivmRVhLE4XrkJrZCZRgbMVn5Ft/fApqdVM6QXa UAztLVcLSNHxsmY1m+TvcbubxHWcBIKYI9pHsQu3mPylHT2I/Zl6RnMYaSQkgBVzo0Rx 3sW2dkuX+hlIqscGpX0NA6sBkQKR1RWj3GzcaagRU264sxtivjhD5b8lrGvrGI2Th11D 2opg== X-Gm-Message-State: ALoCoQlnUgQ4FCf/kT4BvFQWN/0JsykkBf61I4C8BwJ+0sdxaYUxvJ+dJIW8uTMHsaO3asKdVyQs X-Received: by 10.220.49.10 with SMTP id t10mr10335861vcf.34.1406934183018; Fri, 01 Aug 2014 16:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Fri, 1 Aug 2014 16:02:42 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: Justin Uberti Date: Fri, 1 Aug 2014 16:02:42 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0163412c33a5ce04ff996416 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CI_X-Tq0aLf_RhS96hp1mz5Gvkc Cc: mmusic , Jonathan Lennox Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 23:03:05 -0000 --089e0163412c33a5ce04ff996416 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 1, 2014 at 9:04 AM, Martin Thomson wrote: > On 1 August 2014 01:15, I=C3=B1aki Baz Castillo wrote: > > PS: In the text above I'm assuming that peerA initiates two different > > DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to > > go, may we assume/mandate at least that peerA MUST perform a *single* > > DTLS handshake (regardless packets are sent and received via pair1 or > > pair2 or via both of them)? > > You can only have one DTLS connection, however... > > Sending two ClientHellos is OK, because DTLS requires retransmission > of ClientHello to deal with packet loss. The server should treat > those as duplicates (and if they don't carry the same information, you > are setting yourself up for failure when it comes to generating the > Finished message). > Agreed. I don't understand why peerA would issue 2 *different* ClientHellos to the two remote candidates; peerA only wants to establish a *single* DTLS connection. --089e0163412c33a5ce04ff996416 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 1, 2014 at 9:04 AM, Martin Thomson &l= t;martin.thom= son@gmail.com> wrote:
On 1 August 2014 01:15, I=C3= =B1aki Baz Castillo <ibc@aliax.net&= gt; wrote:
> PS: In the text above I'm assuming that peerA initiates two differ= ent
> DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to<= br> > go, may we assume/mandate at least that peerA MUST perform a *single*<= br> > DTLS handshake (regardless packets are sent and received via pair1 or<= br> > pair2 or via both of them)?

You can only have one DTLS connection, however...

Sending two ClientHellos is OK, because DTLS requires retransmission
of ClientHello to deal with packet loss. =C2=A0The server should treat
those as duplicates (and if they don't carry the same information, you<= br> are setting yourself up for failure when it comes to generating the
Finished message).

Agreed. I don't = understand why peerA would issue 2 *different* ClientHellos to the two remo= te candidates; peerA only wants to establish a *single* DTLS connection.

--089e0163412c33a5ce04ff996416-- From nobody Sat Aug 2 15:06:51 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0731B29F8 for ; Sat, 2 Aug 2014 15:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9GC92nDjPg4 for ; Sat, 2 Aug 2014 15:06:46 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA0C1B29F6 for ; Sat, 2 Aug 2014 15:06:46 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so7807534pab.0 for ; Sat, 02 Aug 2014 15:06:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=x8AZPVd2GWulJ8H3Snqjheof8Cc+UcEwgjvv97+iX/g=; b=a0PQk6DK/1S8QZ071IcdceY87+GbvfX/Rp8pVHCC/QoUrjnMOHsMqBoWry3S/X0vPA NMjcx2OyyUuZNPMoeO6WR0pirR39qqJUaZPMsyBFzN9w3lumKWUpcCre7xuRXOf5/F9x sxJw/uGKSdFN9rf5QlCed0h2Rh/XLNpgmSsvXo6f5VId5Q/Ypkvr5Q6hqAXTLBDv/xs3 cF5lWQThdyvXIQlLDVlbruNtC9aCjawMf1Q2H9AhccEyohIhRHrcg4p5gwHvBPN0dwf4 /OGNJ3KL0c2I3WDAjx0BG7A0RfGj0PV1zoRV86A9d5IHk00dKtUbfs4RR0J70BMYjYAw bXvQ== X-Gm-Message-State: ALoCoQkS7+mxeD38ShDKTpt9JrvMTT522BTEmaUgVio08i371CuDMYzzppmgGcOsbNVBnlqJHGsa X-Received: by 10.70.103.106 with SMTP id fv10mr15117181pdb.63.1407017206181; Sat, 02 Aug 2014 15:06:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Sat, 2 Aug 2014 15:06:26 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 3 Aug 2014 00:06:26 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1Dpl2TVaNXqxJISjBi9GcN6I1Go Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 22:06:50 -0000 2014-08-01 18:04 GMT+02:00 Martin Thomson : > On 1 August 2014 01:15, I=C3=B1aki Baz Castillo wrote: >> PS: In the text above I'm assuming that peerA initiates two different >> DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to >> go, may we assume/mandate at least that peerA MUST perform a *single* >> DTLS handshake (regardless packets are sent and received via pair1 or >> pair2 or via both of them)? > > You can only have one DTLS connection, however... > > Sending two ClientHellos is OK, because DTLS requires retransmission > of ClientHello to deal with packet loss. The server should treat > those as duplicates (and if they don't carry the same information, you > are setting yourself up for failure when it comes to generating the > Finished message). OK, that's clear. If a single DTLS handshake is allowed then things become easier. Just a question: how to determine the remote address for sending data? Theoretically that is determined by the "selected ICE pair", but what about if, at some point, the remote peer sends a valid SRTP packet from a different address (let's imagine it is an address from which a valid ICE Binding request with USE-CANDIDATE was previously received assuming the remote peer uses aggressive nomination)?. Should the local peer change its sending address? --=20 I=C3=B1aki Baz Castillo From nobody Sat Aug 2 15:29:53 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245B51B2A0B for ; Sat, 2 Aug 2014 15:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M16XmEaq9rQa for ; Sat, 2 Aug 2014 15:29:50 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6CF1B2A0A for ; Sat, 2 Aug 2014 15:29:49 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so8958989vcb.34 for ; Sat, 02 Aug 2014 15:29:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1xHKSZ3vK0wMbkgxHrO/ZsrF6wEYNDH0cyo+Gsw4IqM=; b=c2lkuw4zIqP+Gk3urFEkcvIuc0zeENo3U59IgvadRzuBfmueDcotM3Tad2tA+nO9mw z4RtXBbgpNip0bIFB7cZluSMH/Gr1JOSK/SX3kREyTOXS7SnqJByBaTGsMVywZcSZA58 wYtfHF6FOMpvQdXmW1HFjPTmWQqtJWEIWQhnnKLtRhX0bsl0uSqSf4Sis2Z4x0wWklmR JtQCr/hZaVASb2jZQmzg/J2AGy2VEzqEoa6BqJ+sMI6B8n8jr5hbeT/TIAupQZv5Ol6+ Okru7cvd84mGvND9ylBS2UkkcEoGw/JDrfzlVwbKj9p8+eHYfHtiuPPWUQLW0F4QXhyo 2wXw== X-Gm-Message-State: ALoCoQndrTL15tLwonZ62V3HKRsi+zh7e1iO4DmeA23diEH+CxcqrWIeIKUEhscJ8Pw9kuVHlCzx X-Received: by 10.52.232.200 with SMTP id tq8mr4156012vdc.32.1407018588878; Sat, 02 Aug 2014 15:29:48 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx.google.com with ESMTPSA id mw6sm9871657vec.0.2014.08.02.15.29.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Aug 2014 15:29:47 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so8935580vcb.28 for ; Sat, 02 Aug 2014 15:29:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.244.81 with SMTP id xe17mr12755942vdc.24.1407018587719; Sat, 02 Aug 2014 15:29:47 -0700 (PDT) Received: by 10.221.2.199 with HTTP; Sat, 2 Aug 2014 15:29:47 -0700 (PDT) Received: by 10.221.2.199 with HTTP; Sat, 2 Aug 2014 15:29:47 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> Date: Sun, 3 Aug 2014 00:29:47 +0200 Message-ID: From: Emil Ivov To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c2c34a1d276804ffad0bc6 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nVnnEuTLmLiPAD-r3skVIIjI5Ew Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 22:29:52 -0000 --001a11c2c34a1d276804ffad0bc6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, that is exactly the case we set out to resolve for aggressive nomination before we decided to have ourselves a new version of ICE :-). If I understand correctly though, with the new ICE version (the one where regular is the new aggressive) you should be prepared to handle this case until you get a USE-CANDIDATE. From then on this would be your only pair. --sent from my mobile On 03 Aug 2014 12:06 AM, "I=C3=B1aki Baz Castillo" wrote: > 2014-08-01 18:04 GMT+02:00 Martin Thomson : > > On 1 August 2014 01:15, I=C3=B1aki Baz Castillo wrote: > >> PS: In the text above I'm assuming that peerA initiates two different > >> DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to > >> go, may we assume/mandate at least that peerA MUST perform a *single* > >> DTLS handshake (regardless packets are sent and received via pair1 or > >> pair2 or via both of them)? > > > > You can only have one DTLS connection, however... > > > > Sending two ClientHellos is OK, because DTLS requires retransmission > > of ClientHello to deal with packet loss. The server should treat > > those as duplicates (and if they don't carry the same information, you > > are setting yourself up for failure when it comes to generating the > > Finished message). > > OK, that's clear. If a single DTLS handshake is allowed then things > become easier. > > Just a question: how to determine the remote address for sending data? > Theoretically that is determined by the "selected ICE pair", but what > about if, at some point, the remote peer sends a valid SRTP packet > from a different address (let's imagine it is an address from which a > valid ICE Binding request with USE-CANDIDATE was previously received > assuming the remote peer uses aggressive nomination)?. Should the > local peer change its sending address? > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11c2c34a1d276804ffad0bc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Well, that is exactly the case we set out to resolve for agg= ressive nomination before we decided to have ourselves a new version of ICE= :-).

If I understand correctly though, with the new ICE version (= the one where regular is the new aggressive) you should be prepared to hand= le this case until you get a USE-CANDIDATE. From then on this would be your= only pair.

--sent from my mobile

On 03 Aug 2014 12:06 AM, "I=C3=B1aki Baz Ca= stillo" <ibc@aliax.net> wro= te:
2014-08-01 18:04 GMT+02:00 Martin Thomson <martin.thomson@gmail.com>:
> On 1 August 2014 01:15, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
>> PS: In the text above I'm assuming that peerA initiates two di= fferent
>> DTLS handshakes over pair1 and pair2. In case bullet 2) is the way= to
>> go, may we assume/mandate at least that peerA MUST perform a *sing= le*
>> DTLS handshake (regardless packets are sent and received via pair1= or
>> pair2 or via both of them)?
>
> You can only have one DTLS connection, however...
>
> Sending two ClientHellos is OK, because DTLS requires retransmission > of ClientHello to deal with packet loss. =C2=A0The server should treat=
> those as duplicates (and if they don't carry the same information,= you
> are setting yourself up for failure when it comes to generating the > Finished message).

OK, that's clear. If a single DTLS handshake is allowed then things
become easier.

Just a question: how to determine the remote address for sending data?
Theoretically that is determined by the "selected ICE pair", but = what
about if, at some point, the remote peer sends a valid SRTP packet
from a different address (let's imagine it is an address from which a valid ICE Binding request with USE-CANDIDATE was previously received
assuming the remote peer uses aggressive nomination)?. Should the
local peer change its sending address?

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic
--001a11c2c34a1d276804ffad0bc6-- From nobody Sun Aug 3 04:21:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FDB1A02E3 for ; Sun, 3 Aug 2014 04:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zELWU5empXRv for ; Sun, 3 Aug 2014 04:21:53 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672331A02E5 for ; Sun, 3 Aug 2014 04:21:52 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so7991210pde.23 for ; Sun, 03 Aug 2014 04:21:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=mfPMOXCulHeo/qJ73lm5piQYlpWyr3kWDbI3pjlrrNA=; b=BgYU8oKCigztI3u49z1dhoosulMK5mzAQgpL2+bXSpaUFO2NI/+Uqd3RZ9EFg6zVFW E81im2Z0/q1H9t+ObHNuTFxygUCgqQQ9wDsV82ZoQf1WMzmUzm6plZnzlB9Ghfq24rj2 2jDPruIyfQmZMwlumQhS/U+5Rm4ziKQq2eDH8h7LqES1+X9gXQ1xvJXMXQNw07r3aNQM SPSs9BCDCpjMr6xrSfHVgUFE/HNAj2CB5jjhu+lpbWb/4xOcLhyHygUfSUIbiOU8DNaU B2ON0h1UB4qpfyM3qRKw08QT1arHQY4KKwVQhsvWYpCr7kY9ALmWYTH/06nkO+xlyILL qwmg== X-Gm-Message-State: ALoCoQkWRG3NV301pI2WaLaMKK+2PoJhL0UPzLpkks0l7uPLer4Sr0188dZSonq8d5PPVDRLrcj8 X-Received: by 10.66.117.38 with SMTP id kb6mr17520194pab.37.1407064912045; Sun, 03 Aug 2014 04:21:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Sun, 3 Aug 2014 04:21:31 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 3 Aug 2014 13:21:31 +0200 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/9gebWUwWhYX0ndh9-JjlX8XmD6U Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 11:21:57 -0000 2014-08-03 0:29 GMT+02:00 Emil Ivov : > Well, that is exactly the case we set out to resolve for aggressive > nomination before we decided to have ourselves a new version of ICE :-). > > If I understand correctly though, with the new ICE version (the one where > regular is the new aggressive) you should be prepared to handle this case > until you get a USE-CANDIDATE. From then on this would be your only pair. Hi, which "new ICE version (the one where regular is the new aggressive)" do you mean? I'm lost. draft-rfc5245bis does not change that at all: http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-02#section-8.1.1 Do I miss something? Sure I do :) --=20 I=C3=B1aki Baz Castillo From nobody Sun Aug 3 06:43:30 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FA11A032F for ; Sun, 3 Aug 2014 06:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FelY3P5t55O for ; Sun, 3 Aug 2014 06:43:24 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF62C1A0326 for ; Sun, 3 Aug 2014 06:43:23 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so9326928vcb.6 for ; Sun, 03 Aug 2014 06:43:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BlCN79GyYVp6w7sczEqMYzdNoN4mdMwN9i5KaRDFpMw=; b=dMEzN8Hq/1aZbJQDsgmB41RMqed8zcDtjV9iKKBCUrh3uTUWaUrijufN/fyxrL8HZe PxnPJMiEIhHh1VOxH296evFACls7kMqTeIp60XBW6DpNxSqmMylkF4bWWUd/Gwss/eNY VyAXo6NuD3mlJyMG3icX3h0FPDpzsEiHHeYjwB5Uy0HXLNbYBL43fKutVxv/owjcGqxG KElWbCAQvGv6oP3tQZzLRkoUtQiehCfS6aTPOlNOvx5Q5iTm+njoaT0rRW3HB1ZBXEUE LziQEETxl6fzK4tDW4izne58LnrKvkmvIhLR7v26voEKbCRwxpZpMLGb3gIE5Vtd241Y aiMA== X-Gm-Message-State: ALoCoQmqU9mqb6hKTL0pzSUa5xgEImxSvI8uQsVeyuCP37y1AYGthfBTsVyg8ZCaegY6KCUlYWlm X-Received: by 10.220.250.203 with SMTP id mp11mr18070979vcb.2.1407073402759; Sun, 03 Aug 2014 06:43:22 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx.google.com with ESMTPSA id yx13sm37278955vdc.12.2014.08.03.06.43.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Aug 2014 06:43:21 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id hy10so9521455vcb.18 for ; Sun, 03 Aug 2014 06:43:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.238.227 with SMTP id vn3mr15267699vdc.47.1407073401285; Sun, 03 Aug 2014 06:43:21 -0700 (PDT) Received: by 10.221.2.199 with HTTP; Sun, 3 Aug 2014 06:43:20 -0700 (PDT) Received: by 10.221.2.199 with HTTP; Sun, 3 Aug 2014 06:43:20 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> Date: Sun, 3 Aug 2014 15:43:20 +0200 Message-ID: From: Emil Ivov To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a1135e2de41c98904ffb9ce6e Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jXNHAh5c9THDvt53hI-NMBArOH0 Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 13:43:27 -0000 --001a1135e2de41c98904ffb9ce6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The one that's currently being discussed on this list, where there won't be an explicit aggressive nomination mode and regular nomination would (really) allow for media to be exchanged before it completes (which it supposedly does already although it's a bit unclear on the matter) --sent from my mobile On 03 Aug 2014 1:21 PM, "I=C3=B1aki Baz Castillo" wrote: > 2014-08-03 0:29 GMT+02:00 Emil Ivov : > > Well, that is exactly the case we set out to resolve for aggressive > > nomination before we decided to have ourselves a new version of ICE :-)= . > > > > If I understand correctly though, with the new ICE version (the one whe= re > > regular is the new aggressive) you should be prepared to handle this ca= se > > until you get a USE-CANDIDATE. From then on this would be your only pai= r. > > Hi, which "new ICE version (the one where regular is the new > aggressive)" do you mean? I'm lost. draft-rfc5245bis does not change > that at all: > > http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-02#section-8.1.1 > > Do I miss something? Sure I do :) > > > > > -- > I=C3=B1aki Baz Castillo > > --001a1135e2de41c98904ffb9ce6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The one that's currently being discussed on this list, w= here there won't be an explicit aggressive nomination mode and regular = nomination would (really) allow for media to be exchanged before it complet= es (which it supposedly does already although it's a bit unclear on the= matter)

--sent from my mobile

On 03 Aug 2014 1:21 PM, "I=C3=B1aki Baz Cas= tillo" <ibc@aliax.net> wrot= e:
2014-08-03 0:29 GMT+02:00 Emil Ivov <= emcho@jitsi.org>:
> Well, that is exactly the case we set out to resolve for aggressive > nomination before we decided to have ourselves a new version of ICE :-= ).
>
> If I understand correctly though, with the new ICE version (the one wh= ere
> regular is the new aggressive) you should be prepared to handle this c= ase
> until you get a USE-CANDIDATE. From then on this would be your only pa= ir.

Hi, which "new ICE version (the one where regular is the new
aggressive)" do you mean? I'm lost. draft-rfc5245bis does not chan= ge
that at all:

http://tools.ietf.org/html/draft-ietf-mmusic-rf= c5245bis-02#section-8.1.1

Do I miss something? Sure I do :)




--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
--001a1135e2de41c98904ffb9ce6e-- From nobody Sun Aug 3 07:21:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F62A1A034A for ; Sun, 3 Aug 2014 07:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdOBHhr7WfpS for ; Sun, 3 Aug 2014 07:20:58 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E43B1A0346 for ; Sun, 3 Aug 2014 07:20:58 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so8458051pab.20 for ; Sun, 03 Aug 2014 07:20:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ZQ/hD1KF4xMKAhHQG70XCitrXaEH3stiuwk669zppRQ=; b=luysAjlsTkjpCdwu394eUUbBTUqsPwMd5OTD7p0Bc0OtXzq2AOrMALd1keTioXA/XI c1b+tK9vGRYg/qb5LVtUp86c41VoIQv0YervjjTWvC1bopgB9p1NX+qHFlP0sWPvHeff Jm8o8ZdEthS7RBp7yGNOnXKDT1ZjqnC0D0cZG+1UBv0TE+TbNZvtrOa94WFUDJtUYP+p 2IIRE0Iya1fgZ4ozFLuxDxXoot/Y2ZKb44nmsgQwnvUZzsR8GuCEszDd1rf7PhE3cVIJ SOWZGWl2blkRC6XV7mVTuZs3RMj7xa+Hy2d9KR0gL4z35SyFYBzIUkB0i6sEJMdLBxtj b0oQ== X-Gm-Message-State: ALoCoQkXbevcE9GSDuHem/ol3915qblojz4pOZTFDKF9DE6oz7CHk6frCtalqbzrcxDrsF5nkas0 X-Received: by 10.70.56.101 with SMTP id z5mr18415472pdp.47.1407075658221; Sun, 03 Aug 2014 07:20:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Sun, 3 Aug 2014 07:20:38 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 3 Aug 2014 16:20:38 +0200 Message-ID: To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/btVPSGJiig0C8qWPi7LyjXfkGMo Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 14:21:02 -0000 2014-08-03 15:43 GMT+02:00 Emil Ivov : > The one that's currently being discussed on this list, where there won't = be > an explicit aggressive nomination mode and regular nomination would (real= ly) > allow for media to be exchanged before it completes (which it supposedly > does already although it's a bit unclear on the matter) OK, got it. Just a comment: Regardless how the "new ICE" looks, please don't change the rule "just one DTLS handshake". I say that because in a previous mail it is said that ICE Binding requests may be encapsulated into DTLS HelloClient packets, so danger here: - PeerA is controlling and has two network interfaces. - PeerB has a single interface. - PeerA sends two connectivity checks (so DTLS HelloClient + ICE Binding Request), one from each interface, to the single interface of PeerB. - In that case both ICE Requests are different (different transactionId and so on) so both DTLS HelloClient packets must also be different, and hence we are talking about *two* separate DTLS handshakes, which means that PeerB MUST handle two different DTLS sessions into the same local candidate/interface. If so, the "just one DTLS handshake" rule and the rationale about "ICE is a virtual socket" get violated. Please consider that. --=20 I=C3=B1aki Baz Castillo From nobody Sun Aug 3 08:02:35 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C41D1A035B for ; Sun, 3 Aug 2014 08:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqjpk12mRiSt for ; Sun, 3 Aug 2014 08:02:32 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41301A0359 for ; Sun, 3 Aug 2014 08:02:31 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so5034613wiw.3 for ; Sun, 03 Aug 2014 08:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cvR2MH0xo+JZS5Mp/gFrELEVoiVal6e3smxP+X2S0sY=; b=OyPxWeE3SK4jbBpybraQjn1WWp4VTyTKnYj41IihZ4GYn1MKZafHDyzIdBAWc8oJFd BCYgikZSPTNfLwokRcfCU3orYp35vsj1VbmBDvyVrBQRXTk6m4mGXLIgJ4HkeQScWG4X qxar5HmL+CubbAsn87nqfXAc2PzWG0y1wK0tpWciEa/TaZeFbd38Uv8xBkijVOe2PGlz hukwQ7g+I57kFH3SUNoQa9rayRwdIOjXFSIE6kq9YBoH3m9yPe0yBnZxYhjP5i6nDAeg j/8lOyGTIsWEIDnUoXHPkzxNaWiL9NmyT5SbdBWEahGqn2316LjuAxq6M3dqi7F/kuLz bdew== MIME-Version: 1.0 X-Received: by 10.180.92.38 with SMTP id cj6mr22661003wib.64.1407078150170; Sun, 03 Aug 2014 08:02:30 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Sun, 3 Aug 2014 08:02:29 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Sun, 3 Aug 2014 08:02:29 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> Date: Sun, 3 Aug 2014 08:02:29 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f46d043c7faa4fefc904ffbae95c Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Ze9AwBQ_HIcrGmJM0mRo7FPQt70 Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 15:02:33 -0000 --f46d043c7faa4fefc904ffbae95c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Aug 3, 2014 7:20 AM, "I=C3=B1aki Baz Castillo" wrote: > - In that case both ICE Requests are different (different > transactionId and so on) so both DTLS HelloClient packets must also be > different, and hence we are talking about *two* separate DTLS > handshakes, which means that PeerB MUST handle two different DTLS > sessions into the same local candidate/interface. I think that you are jumping to conclusions here. What Dan suggested isn't really part of what Emil is talking about, it is an additional optimization. As such, it's orthogonal. If we were to couple DTLS with the connectivity check, it seems like we would have to require some tweaks to the process in order to avoid the problem you describe. I think that you have identified a real problem. It might be that we need to exclude that transaction identifier from the integrity check to fix that, which is a non-trivial change. The obvious solution - requiring identical transaction identifiers - removes the on-push guarantee, at least to the extent that an attacker can modify signaling and spoof valid source addresses. --f46d043c7faa4fefc904ffbae95c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 3, 2014 7:20 AM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
> - In that case both ICE Requests are different (different
> transactionId and so on) so both DTLS HelloClient packets must also be=
> different, and hence we are talking about *two* separate DTLS
> handshakes, which means that PeerB MUST handle two different DTLS
> sessions into the same local candidate/interface.

I think that you are jumping to conclusions here. What Dan s= uggested isn't really part of what Emil is talking about, it is an addi= tional optimization. As such, it's orthogonal.

If we were to couple DTLS with the connectivity check, it se= ems like we would have to require some tweaks to the process in order to av= oid the problem you describe. I think that you have identified a real probl= em. It might be that we need to exclude that transaction identifier from th= e integrity check to fix that, which is a non-trivial change. The obvious s= olution - requiring identical transaction identifiers - removes the on-push= guarantee, at least to the extent that an attacker can modify signaling an= d spoof valid source addresses.

--f46d043c7faa4fefc904ffbae95c-- From nobody Sun Aug 3 08:45:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390461A0068 for ; Sun, 3 Aug 2014 08:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q84TgCw78TiE for ; Sun, 3 Aug 2014 08:45:19 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8F51A0055 for ; Sun, 3 Aug 2014 08:45:19 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id eu11so8581011pac.3 for ; Sun, 03 Aug 2014 08:45:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=TT+1l9aLi15Bzn+q3Uhp2kt6T3gd9NZLi17fOWARn0g=; b=QQWoQlm/FYyPguDsxg5JDWawrgjawASij/e4cyUgQbk8OHfHaBIZWPiT7BXgn6ZWpM HPvSi4cJvNfDyZgKlVU1vthXje3wKY51Pm45CV8PY2bP0+VkkTNotAqyUtCVENxsTgeZ So7j5Mlm0PZzJGnyR/7vcWUq+rQj8gUqIzmSqqi651YS4zr/XL/VV33rCt3H/HFshenj B94fcg5TIztJ4pv1mg9ABEb9b79vWVzPSQyqBB7s64GzTKRpAboldTGrPA1UZlhu7te1 LKV2YySB1hROlamKpIbsu/OZHYa7jmXKXx8fP2x5e4Gmq6QJMVm/KyTGDG3UyI7W+MxE 05Sg== X-Gm-Message-State: ALoCoQnd5za41i6pfHksZb4HEvN1BeF58Afm0edTsjY65KMlvjtARugHZz6fa93PGYlhx2trt9Dr X-Received: by 10.70.1.100 with SMTP id 4mr1192941pdl.147.1407080719309; Sun, 03 Aug 2014 08:45:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Sun, 3 Aug 2014 08:44:58 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 3 Aug 2014 17:44:58 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2WcbMekOXlaE_gEZ9LHZysK4_zg Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 15:45:21 -0000 2014-08-03 17:02 GMT+02:00 Martin Thomson : > If we were to couple DTLS with the connectivity check, it seems like we > would have to require some tweaks to the process in order to avoid the > problem you describe. I think that you have identified a real problem. It > might be that we need to exclude that transaction identifier from the > integrity check to fix that, which is a non-trivial change. The obvious > solution - requiring identical transaction identifiers - removes the on-p= ush > guarantee, at least to the extent that an attacker can modify signaling a= nd > spoof valid source addresses. I don't like the idea of including an ICE Binding request into a DTLS packet. ICE requests are supposed to "open the path" and thus STUN packets should be the first ones. Instead, DTLS is "application data to be carried over the open path". We must respect that. So why not the opposite?: Add the DTLS ClientHello packet into a new STUN attribute (may be called "DTLS_PACKET"). Issues above solved: - STUN is processed as normal. - The *same* DTLS HelloClient can be set into *different* ICE Binding requests, so there is a single DTLS handshake. - From the point of view of the sender, it is the same scenario in which the sender sends a ICE Binding request followed by a DTLS HelloClient, but with the guarantee that the ICE request will arrive "first" :) - From the point of view of the receiver, it first receives (and validates) the ICE Binding request, then generates the ICE response and then processes the DTLS HelloClient contained in the "DTLS_PACKET" attribute of the Binding request. This adds very little complexity to existing implementations. Thoughts? --=20 I=C3=B1aki Baz Castillo From nobody Sun Aug 3 09:23:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254DE1A0AB2 for ; Sun, 3 Aug 2014 09:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29_B31JpHVMI for ; Sun, 3 Aug 2014 09:23:10 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DAE1A0AA9 for ; Sun, 3 Aug 2014 09:23:10 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id y10so8260285pdj.35 for ; Sun, 03 Aug 2014 09:23:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=qRb1uPFLMKH/oFBcAyvS10oUN9+CmuDUItGOuvyyOa0=; b=ZDLQjCPM/yB3qvrgxpJ5ZHsLJ8Z44JGE/GRJ9U7ZOLlwfi5rkSq7tFjBUuRgITXd9T ODt2LuALIxzEJXIIGM33qNiPetYasYwi6MFxO1m53EH5egXEFHy3GuwWkCRI+0DZskAX zRAMwiv3Vl3MZL+X3oB5x7ex1PLON1QDdfOyZMjrKKiGGV422vi+wv1CUvzDdW2kOTTg IBZ4H7CCM+OYciboMjeTaLW9OpVgS/o2Ghmmu+3DIAS5tmOftHplQxoFGQptsVm719mX S+2QoNkhSibykqhBpRyOWc+QJZZvINushr2iPuG4zziQfLBwr9QrMnjSp3lnFISJXdMS A1/w== X-Gm-Message-State: ALoCoQn6C/mcZhtJhYRyQc9hcNAR5xNQFO/5pt7VBTkGuJMpybS88MNpUmDFbBv0PDySIlxyPg6z X-Received: by 10.70.96.38 with SMTP id dp6mr1495501pdb.136.1407082989777; Sun, 03 Aug 2014 09:23:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Sun, 3 Aug 2014 09:22:49 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 3 Aug 2014 18:22:49 +0200 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nWDWT2QWBTX2pmIS52iIBwN6a2o Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 16:23:14 -0000 2014-08-03 17:44 GMT+02:00 I=C3=B1aki Baz Castillo : > So why not the opposite?: Add the DTLS ClientHello packet into a new > STUN attribute (may be called "DTLS_PACKET"). Issues above solved: > > - STUN is processed as normal. > > - The *same* DTLS HelloClient can be set into *different* ICE Binding > requests, so there is a single DTLS handshake. > > - From the point of view of the sender, it is the same scenario in > which the sender sends a ICE Binding request followed by a DTLS > HelloClient, but with the guarantee that the ICE request will arrive > "first" :) > > - From the point of view of the receiver, it first receives (and > validates) the ICE Binding request, then generates the ICE response > and then processes the DTLS HelloClient contained in the "DTLS_PACKET" > attribute of the Binding request. This adds very little complexity to > existing implementations. More on this: - If the receiver supports the "DTLS_PACKET" STUN attribute it will add the DTLS ServerHello response (along with others) into the "DTLS_PACKET" of the ICE Binding Response. - If the ICE response has no "DTLS_PACKET" attribute then the client must send a "common" DTLS ClientHello. - DTLS packets to be exchanged after the STUN exchange (regardless DTLS_PACKET was supported or not) can be directly sent over UDP/TCP. --=20 I=C3=B1aki Baz Castillo From nobody Sun Aug 3 11:02:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07221A0538 for ; Sun, 3 Aug 2014 11:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REAZ32Fq4grf for ; Sun, 3 Aug 2014 11:02:26 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126751A012D for ; Sun, 3 Aug 2014 11:02:25 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so9706979vcb.17 for ; Sun, 03 Aug 2014 11:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lp14PQ0sK6L/WxeDxoxxxFoD1yry2Dwskv95UAba0AA=; b=kvWSNNblrg7mhDHlXjdRuIy2alA692xWj304/lCJwRnkz5uzhNmG+d1r8oXaeZ6vPA sVWUI4qsdAdTWSHyqstoR+7Unn9+mfMztC0MYwpvUjEYIcGVSYR3jhGFBYBuRELVxCLF wT3I6TDBr5mRyGLpZEzSxp9899sM3Y1xnZQYge2J0uqhwlI+p0w31BlGileWyA/J60Ys 5oeozUPtxvhHeceUhXTdvWV7bntHRmqdP9UVjaD83g70FtY77Pz4ptY/TRPa4VW0GmiR LakA6JhdiTdJJnaOgEe7XKo9qcq8fabteiAcQKm82UxN52Jc+U+K2eE76okkaDW8qk7P nRkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lp14PQ0sK6L/WxeDxoxxxFoD1yry2Dwskv95UAba0AA=; b=SNBQmwYxRBLuvx5BfaYpsgZqjHIn89GjyPDASrE9paGsW2Yiqu+Om3UhL2EerNsJI9 XtyI4nhy87kY94TRiiVv/zYWL/hEoFLfPiecJ7nB0nGcY41W1L0ffkWvsez45Co58vdj C7xjDASYdfHEnYxIQRspfEp8Sot8VfM63Ree+8+r6jQR5mPQL34oXwPfb64ZuiLLvxdg Pr7D3EXeekR+ts8OD3/IAz3ofzOeVe9oVJyi+ZKPmoF8rUnB2Uu+9t9MI5wDLW5wXWlH Vn3QixLhGsyzDhVks91ztxtRi9TrcKXPkQrBXoEi+1972CwqSkLrP+K3p5V9WtS+MRd7 uBEw== X-Gm-Message-State: ALoCoQlhCsKAPO8YU7q1XB4/SViXlHzQ3aTt5zenVDxLZRTjTQW3fvYFxDqtwemNKDcN2pVt8Wph X-Received: by 10.52.3.40 with SMTP id 8mr1962826vdz.24.1407088945149; Sun, 03 Aug 2014 11:02:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Sun, 3 Aug 2014 11:02:05 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: Justin Uberti Date: Sun, 3 Aug 2014 11:02:05 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf3030c11fbe632304ffbd6ca4 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jT7ZeICO7JYLhIoh7tuR1uKs_WY Cc: mmusic , Jonathan Lennox Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 18:02:28 -0000 --20cf3030c11fbe632304ffbd6ca4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 3, 2014 at 8:02 AM, Martin Thomson wrote: > > On Aug 3, 2014 7:20 AM, "I=C3=B1aki Baz Castillo" wrote: > > - In that case both ICE Requests are different (different > > transactionId and so on) so both DTLS HelloClient packets must also be > > different, and hence we are talking about *two* separate DTLS > > handshakes, which means that PeerB MUST handle two different DTLS > > sessions into the same local candidate/interface. > > I think that you are jumping to conclusions here. What Dan suggested isn'= t > really part of what Emil is talking about, it is an additional > optimization. As such, it's orthogonal. > > > Yes. I think we've lost sight of the original intent of this thread - either allowing aggressive nomination to make dynamic decisions like regular nomination, or combining the two concepts entirely. Let's try to focus on the details of that particular problem in this thread= . --20cf3030c11fbe632304ffbd6ca4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Aug 3, 2014 at 8:02 AM, Martin Thomson &l= t;martin.thom= son@gmail.com> wrote:


On Aug 3, 2014 7:20 AM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote:
> - In that case both ICE Requests are different (different
> transactionId and so on) so both DTLS HelloClient packets must also be=
> different, and hence we are talking about *two* separate DTLS
> handshakes, which means that PeerB MUST handle two different DTLS
> sessions into the same local candidate/interface.

I think that you are jumping to conclusions here. What= Dan suggested isn't really part of what Emil is talking about, it is a= n additional optimization. As such, it's orthogonal.


Yes. I think we've lost sight = of the original intent of this thread - either allowing aggressive nominati= on to make dynamic decisions like regular nomination, or combining the two = concepts entirely.

Let's try to focus on the details of that particula= r problem in this thread.
--20cf3030c11fbe632304ffbd6ca4-- From nobody Sun Aug 3 11:07:09 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557821A0B12 for ; Sun, 3 Aug 2014 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzUlO4SQ4vm3 for ; Sun, 3 Aug 2014 11:07:05 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259D71A0B14 for ; Sun, 3 Aug 2014 11:07:01 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so9753380vcb.33 for ; Sun, 03 Aug 2014 11:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=K9oiXNuCrMeachjOl/pJ38vT06zwhGGa8FqIKk/7Pjk=; b=UqYZ2dTwbGTfaRjglKXNdP7uEGXs5Lu8pkrHfTcgCDaO+68OO7k9NFPErNNe6UB0bw reaGrnRKsibKwmjj9N6DS6b9D9jmAyYl45XlnR8PtjTVr1qZBj9HHCHOBB20am0h9tjC MxSdhdRCUkOpu1vDhvQntav3ZXR6Zpi/rbhGKegOR38S/NkFCdubyldUcLl5ZeBluydR mFfh1SGyQa7+v8UD9KGrFyqs5pIGHDC89A6Lq4s8M7BkGZJPiV7GhGqjWOHBZbRW8J87 lAxIPxgVfR/dZeiz/kaqDKuZByu7aUkQ8PKv5CnPoSvJ7iLvYtlqw9wPwRkuMaLbwmL7 p3QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=K9oiXNuCrMeachjOl/pJ38vT06zwhGGa8FqIKk/7Pjk=; b=VkKQ/6wbeODWDIC1uNIl295d1avZUc3Uzj+559liWQiyLuOiKPV8l3KltUNolBj2Zu njXFcBLA05twxV8ymoflz060UQbd7umAp1eIeH7Vih3DUhmXQ/b+2tTLRQgdp3bPKkZ2 jxN/XySHcsjZAEsXRnBeRGV4/gSJz5Y5R4kzBLPbAdy2QnO7QodzAv/wkxVnsZTuQIwd FRFp/9abFuIAU4j83vEd7CYjkjKM8UZgYTaBePBFpI9uHE8tSwJfj/RW92tNqR2+2Z6T ALXYhkIYN15yodbxmOUNqoBzhv1AzDTK8XjG6HDGiWPlRF1pQTLKLZJCqbLVjkUWU1VA RVsQ== X-Gm-Message-State: ALoCoQm6NL0aubQY8IDg7vbttcQ5aRme6l40jl05OH5gRDMu1DGLdOZ3y+EcpiUiGI6p47d/ylPQ X-Received: by 10.52.5.40 with SMTP id p8mr7931365vdp.28.1407089220942; Sun, 03 Aug 2014 11:07:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Sun, 3 Aug 2014 11:06:40 -0700 (PDT) From: Justin Uberti Date: Sun, 3 Aug 2014 11:06:40 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf3033447f2e9b1304ffbd7d31 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Nqw_TBdI-C1hRZ5ihMb5fR_5NYU Cc: Jonathan Lennox , mmusic Subject: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 18:07:07 -0000 --20cf3033447f2e9b1304ffbd7d31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 3, 2014 at 9:22 AM, I=C3=B1aki Baz Castillo wro= te: > 2014-08-03 17:44 GMT+02:00 I=C3=B1aki Baz Castillo : > > So why not the opposite?: Add the DTLS ClientHello packet into a new > > STUN attribute (may be called "DTLS_PACKET"). Issues above solved: > > > > - STUN is processed as normal. > > > > - The *same* DTLS HelloClient can be set into *different* ICE Binding > > requests, so there is a single DTLS handshake. > > > > - From the point of view of the sender, it is the same scenario in > > which the sender sends a ICE Binding request followed by a DTLS > > HelloClient, but with the guarantee that the ICE request will arrive > > "first" :) > > > > - From the point of view of the receiver, it first receives (and > > validates) the ICE Binding request, then generates the ICE response > > and then processes the DTLS HelloClient contained in the "DTLS_PACKET" > > attribute of the Binding request. This adds very little complexity to > > existing implementations. > > > More on this: > > - If the receiver supports the "DTLS_PACKET" STUN attribute it will > add the DTLS ServerHello response (along with others) into the > "DTLS_PACKET" of the ICE Binding Response. > > - If the ICE response has no "DTLS_PACKET" attribute then the client > must send a "common" DTLS ClientHello. > > - DTLS packets to be exchanged after the STUN exchange (regardless > DTLS_PACKET was supported or not) can be directly sent over UDP/TCP. > > I agree it would be better to have the DTLS packet inside of STUN, rather than the converse. I would also suggest that we make this agnostic of the encapsulated protocol, e.g. allow for something like TURN's DATA attribute to carry generic data in a binding request. Note that it the actual upside here may turn out to be somewhat limited given TLS 1.3's zero-RTT handshake modes. --20cf3033447f2e9b1304ffbd7d31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Aug 3, 2014 at 9:22 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
2014-08-03 17:44 GMT+02:00 I=C3=B1aki Baz Ca= stillo <ibc@aliax.net>:
> So why not the opposite?: Add the DTLS ClientHello pac= ket into a new
> STUN attribute (may be called "DTLS_PACKET"). Issues above s= olved:
>
> - STUN is processed as normal.
>
> - The *same* DTLS HelloClient can be set into *different* ICE Binding<= br> > requests, so there is a single DTLS handshake.
>
> - From the point of view of the sender, it is the same scenario in
> which the sender sends a ICE Binding request followed by a DTLS
> HelloClient, but with the guarantee that the ICE request will arrive > "first" :)
>
> - From the point of view of the receiver, it first receives (and
> validates) the ICE Binding request, then generates the ICE response > and then processes the DTLS HelloClient contained in the "DTLS_PA= CKET"
> attribute of the Binding request. This adds very little complexity to<= br> > existing implementations.


More on this:

- If the receiver supports the "DTLS_PACKET" STUN attribute it wi= ll
add the DTLS ServerHello response (along with others) into the
"DTLS_PACKET" of the ICE Binding Response.

- If the ICE response has no "DTLS_PACKET" attribute then the cli= ent
must send a "common" DTLS ClientHello.

- DTLS packets to be exchanged after the STUN exchange (regardless
DTLS_PACKET was supported or not) can be directly sent over UDP/TCP.

<= br>
I agree it would be better to have the DTLS packet inside of = STUN, rather than the converse. I would also suggest that we make this agno= stic of the encapsulated protocol, e.g. allow for something like TURN's= DATA attribute to carry generic data in a binding request.

Note that it the actual upside here may turn out to be = somewhat limited given TLS 1.3's zero-RTT handshake modes.
<= /div>
--20cf3033447f2e9b1304ffbd7d31-- From nobody Sun Aug 3 13:30:54 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9C91AD8CA for ; Sun, 3 Aug 2014 13:30:51 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFnR3gvmZ_j9 for ; Sun, 3 Aug 2014 13:30:50 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEBD71ABD17 for ; Sun, 3 Aug 2014 13:30:49 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so5260623wiv.0 for ; Sun, 03 Aug 2014 13:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3IqrVWGQbZc91nL46hIwUbAhnRgxmkXPATxG/6RjBus=; b=kOwDFX45Cxkh1snh2qJpRRRDyDkfc0yjeR6TRWXTCQITDqAEKQlnCeHHSHw3ghJltL kl+YY/nhgCNSDAhmg+bPWlgLzx2EYDRqoI9Yg4Yx5G0rqqQSxaqU6hsUDzUh7QBydWdI 0KC1fl/80kG2AnGtr4qu/Xg8yxnm53z7ou6xr80omL+/Au9FfLWSAOFRGfilXw4TAV3L ejzsp5bNRhi3XDSdDlElMv///dyJ8lKPdJsX4BuIQbpPx4F0jX11z5pyX3BakqEQL5eb BkgwQsLp2g4veQ6llE7vAZjR8MgOvE5R6ZIJY0t3K1JoZnTGkFBA+aZCWSlEETM+aH3r pgHg== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr23447734wiv.65.1407097848625; Sun, 03 Aug 2014 13:30:48 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Sun, 3 Aug 2014 13:30:48 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Aug 2014 13:30:48 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/31k1kE5IWO0r6XzstAFzN-kG0AA Cc: mmusic , Jonathan Lennox Subject: Re: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 20:30:51 -0000 On 3 August 2014 11:06, Justin Uberti wrote: > Note that it the actual upside here may turn out to be somewhat limited > given TLS 1.3's zero-RTT handshake modes. That's a good point. We've talked about loading the material necessary to do 0RTT into signaling. From nobody Mon Aug 4 02:36:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3241B1B2959 for ; Mon, 4 Aug 2014 02:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMfiV8F2I__U for ; Mon, 4 Aug 2014 02:36:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376E41B2957 for ; Mon, 4 Aug 2014 02:36:03 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id z11so5101797lbi.17 for ; Mon, 04 Aug 2014 02:36:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HAf2tPnZmQjxHs7eIZU7JJcRtBSIeGqSiDa/XzsCzPU=; b=DygZ0hh0dbuaUOUwjMrKvAvWpdMyaQ6lDwoi6vOGWzsPmy6Pd33kQKggi/sgqZ+LaK wD33LqxLOatI+YKDd+G8FfJi0V+krDh6WnwZEKq77qZlh6hPwtpyU93eYRuKo6a6+ZV7 /HkAbIVx7xpKTDNnjd0fy75cI4wHWAkHGFcTiWW77hrvSElXnUDe6684a4CHv1NdvdjO ZxFq3nihza1P7DkGVqD+uwz1tc3U1h+6RXc8SxGe+ydH42vLhLiYeQikRMEYYlq9UqtJ PO5/s2TfQ39XHxiL2PAVFEMbDzorft7Jv+dw5w5keNj+RunEexRsvDf8CQ82ZvDn92dE jlRw== X-Gm-Message-State: ALoCoQkbzIGWrcoicyuZe9b+ndolauKM2fPDKMYj8BVzmZXlY4/2NTBoDcR4fIYrnTiPsGQHQMB2 MIME-Version: 1.0 X-Received: by 10.112.173.201 with SMTP id bm9mr20888662lbc.16.1407144961834; Mon, 04 Aug 2014 02:36:01 -0700 (PDT) Received: by 10.152.37.40 with HTTP; Mon, 4 Aug 2014 02:36:01 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> Date: Mon, 4 Aug 2014 11:36:01 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/n6nWnGnpoKqNcro0FsKJmv0JyMw Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 09:36:06 -0000 Hi, 2014-07-31 0:01 GMT+02:00 Martin Thomson : > On 30 July 2014 14:48, Emil Ivov wrote: >> When it's RTP you don't care where you get it from as long as you do. If >> it's a DTLS client halo then what do you do exactly? >> >> Can the controlling agent simply respond on a different valid pair than = the >> one on which it received it? (This is what Chrome currently does but its >> frowned upon by the DTLS/SRTP draft which binds the context to a specifi= c >> address:port). Does the controlled agent need to resend it on the new pa= ir >> after it gets the USE-CANDIDATE? > > RFC 5764 says this: > A single DTLS-SRTP session only protects data carried over > a single UDP source and destination port pair. > > But I'll postulate that this is only because the alternative (a > shifting substrate) was not yet conceived. There is nothing in (D)TLS > that requires anything of the underlying transport protocol, > intentionally. (c.f., tcpinc wg) > > Firefox code seems to be OK (at least superficially) with the idea > that packets can arrive from anywhere. However, I can see why some > implementations might get sad if things shift around. Do you mean that some implementations might get sad because this is something they simply do not support today (managing a single DTLS connection with data coming form different underlying transport protocols) or that doing it leads to any backward compatibility issue? > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Jos=C3=A9 Luis Mill=C3=A1n From nobody Mon Aug 4 06:08:19 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75A61B2ADB for ; Mon, 4 Aug 2014 06:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcekEv0Bh71d for ; Mon, 4 Aug 2014 06:08:14 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5CE1B2AE6 for ; Mon, 4 Aug 2014 06:08:10 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id nu7so4484698obb.28 for ; Mon, 04 Aug 2014 06:08:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=77vBUnBT/hLjoHqLQ1JzTmu6OsBlYPV5b5nTmxdc8P0=; b=gtGzURqxgAqwFoReSRuzAJh7+/WRcO6nI7IOkSugKBPRLSguxTxgbTURx1HS7RAG17 mAVhCPQFa1FCjiiLmx4/51WpY5cysZmrnQAV2mTkKWFW7wbA13zFZQ5X+YAJxpDOgk6F ve6f63Fpj1YEeEG/zxswOOve5t5oQhC6nn3blczrgutM7TujNXhi6Cmy7U5dB7StJ7Zx SZfh4BFUaoFsI3Czfl7Z5fI+P6AWGOLAP93HXIF8VC2+l+uZTDTvH0/X69W4YV4elAyg GpCD3bFXj+ogAJXAnDEhdOq/n37wtz/Mx8eK0XFpTwg0X1CZbnygA9VHriVOPRTwN1LI rHpA== X-Gm-Message-State: ALoCoQkAvx4ej+yQlBWKaJvJnMpvrpzBNtvmZxbRW/A9ot6o0CV/VkBB2liQ8AZ7IGk+ZJFI8kWp X-Received: by 10.60.58.36 with SMTP id n4mr11323478oeq.73.1407157688063; Mon, 04 Aug 2014 06:08:08 -0700 (PDT) Received: from [192.168.1.96] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id zd1sm38999710obb.1.2014.08.04.06.08.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 06:08:06 -0700 (PDT) Message-ID: <53DF85B4.6060600@jive.com> Date: Mon, 04 Aug 2014 09:08:04 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/micKNMy1X-bzytmEY4C3z7bjePI Subject: Re: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 13:08:17 -0000 Le 2014-08-03 14:06, Justin Uberti a écrit : > I agree it would be better to have the DTLS packet inside of STUN, > rather than the converse. I would also suggest that we make this > agnostic of the encapsulated protocol, e.g. allow for something like > TURN's DATA attribute to carry generic data in a binding request. Another idea: put the DTLS and STUN next to each other. Since the STUN header contains the STUN message length, you can put data after it in the same UDP packet. Not saying it's a better idea, just something we could consider doing. Simon From nobody Mon Aug 4 06:12:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85911B2ACE for ; Mon, 4 Aug 2014 06:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq6cRziUTYgm for ; Mon, 4 Aug 2014 06:11:53 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8961B2AB1 for ; Mon, 4 Aug 2014 06:11:53 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id z10so9598774pdj.2 for ; Mon, 04 Aug 2014 06:11:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Vx8EJe9/6kaDN+pzitlVktTNx3fq3w2yDJCVwPHWppM=; b=kZ3ZsBJm0l8HNRoK8MntjubFKQ9uTQfXxKYcG0VE89r1tum1Yr47B68eApn3sM7w6g nkYFiKcFE2nC4yOpSxjBW2AQlZ79aXJoxYFQJAQ4fafu23Am78erQhV7xff1K7vCPBMs 46wNUUS5BY8zi15QNtnPOFiDhQ+s0PgYQyhNgz96dvscTgNtn0GxJnJUTaHbMwN54LSG 1epqV0bthKgYTivQ9kVpw8VUzMg7PJyKjZkq8DVr3WGRFf/5HIFIFt7owq7QWBpMI6tf LMadlQ881QNJYMr1wl92vCvQTosIxFQQePLcWD2vXlKIga2gqTsJZbSAaX/jJcsamXx7 Fdhw== X-Gm-Message-State: ALoCoQkjh1sK0QNOs7X0WpFSSU9jvgob2KhnjUmp2sNZ4/oOiIadTQH54Icdi2RktxFDzURcx+6h X-Received: by 10.68.161.101 with SMTP id xr5mr1828755pbb.168.1407157913194; Mon, 04 Aug 2014 06:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Mon, 4 Aug 2014 06:11:33 -0700 (PDT) In-Reply-To: <53DF85B4.6060600@jive.com> References: <53DF85B4.6060600@jive.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 4 Aug 2014 15:11:33 +0200 Message-ID: To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ML0zwPs-ErX_eQB-2clvh0BVooE Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 13:12:01 -0000 2014-08-04 15:08 GMT+02:00 Simon Perreault : >> I agree it would be better to have the DTLS packet inside of STUN, >> rather than the converse. I would also suggest that we make this >> agnostic of the encapsulated protocol, e.g. allow for something like >> TURN's DATA attribute to carry generic data in a binding request. > > > Another idea: put the DTLS and STUN next to each other. Since the STUN > header contains the STUN message length, you can put data after it in the > same UDP packet. > > Not saying it's a better idea, just something we could consider doing. Please don't forget STUN and DTLS over TCP, which is carried as per http://tools.ietf.org/html/rfc4571. --=20 I=C3=B1aki Baz Castillo From nobody Mon Aug 4 06:22:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC011B2ADD for ; Mon, 4 Aug 2014 06:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuzCB-RJxCDs for ; Mon, 4 Aug 2014 06:22:18 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B79F1B2AD7 for ; Mon, 4 Aug 2014 06:22:18 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id u20so4556763oif.16 for ; Mon, 04 Aug 2014 06:22:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XKJwdGlS9mK7rrFZa7gi1YpzYW6zlVb9Zx3M7HEQlZs=; b=Z9zjEZADw/yhi6cEqcA4t0ZNftwes8rQm0cnd2vjIsuoX70chOSnfsiFnd1RhAO/zZ VKocdbuB7ZxK8xQc0WNIQEmSVvMdlxnQe19nxgvTB1gLeVdo5BBr+q/mUjoVoY4f84l2 SmuHBUyAZqTsZLDal+lReWd1VSD86wdMLMXRtuBkwOJTy+enwH+rjdgCZTnXo2EV8+JC 8Re6/r9vAnnytf+rgQ+vZAbR/eUtpBFoupcJpfSD2GeHHSNWgs1byItipUSt92pKe5bJ AZbar4tDkl4eytPvqjaUAXPgG/OUFjSU7dUWVTqJC7k2Ph2+3LNUTYRaHneeU107qEmD kmlg== X-Gm-Message-State: ALoCoQkDFPSwgtSlkoWtr4htYlqV/2np8FS74pEFHHNLEh27X/5CafvIoK7dns9wsEbcwEo7tImR X-Received: by 10.60.97.40 with SMTP id dx8mr33197972oeb.27.1407158536162; Mon, 04 Aug 2014 06:22:16 -0700 (PDT) Received: from [192.168.1.96] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id tz6sm39067265obc.0.2014.08.04.06.22.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 06:22:14 -0700 (PDT) Message-ID: <53DF8904.6070904@jive.com> Date: Mon, 04 Aug 2014 09:22:12 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <53DF85B4.6060600@jive.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/4JPuNw_38G0Nnoxy-75fkV2g73Y Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 13:22:20 -0000 Le 2014-08-04 09:11, Iñaki Baz Castillo a écrit : >> Another idea: put the DTLS and STUN next to each other. Since the STUN >> header contains the STUN message length, you can put data after it in the >> same UDP packet. >> >> Not saying it's a better idea, just something we could consider doing. > > Please don't forget STUN and DTLS over TCP, which is carried as per > http://tools.ietf.org/html/rfc4571. Assuming you meant RTP over TCP... As this optimization would be for DTLS, I was assuming UDP only... Simon From nobody Mon Aug 4 06:31:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585B01B2AED for ; Mon, 4 Aug 2014 06:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XefyTQXSgN-G for ; Mon, 4 Aug 2014 06:31:48 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAFE1B2AF2 for ; Mon, 4 Aug 2014 06:31:47 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id ft15so9690264pdb.31 for ; Mon, 04 Aug 2014 06:31:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=E7DvO25TQ0vPogBKdsSyP1fJPIa6njyLO5sdCaflUKM=; b=aSDkkUa0LQTu5mP8ICbdvN1kVB30iS/ehmgUMgSNli6rk04MckZRgh4eofpQb/qUDS qPYqRNoS9qCXL6R8ahsXSTx4Tp/ku13kiJ+N3F8AyEHuByjWLdzZF0o2euI6/WCKsuG5 aHujZRfDhLW39beLvb67sF5A5KcqVbTOogrHHcoFy0BGSBxdkF2TvIjFGV1bEZtxVJOI QxP42x4A+xn2C0dsqbkIg4e2CcGMoCPjQX9yNIGpqGyHgbnpDjJ4eXikxBdX9J+JXtRC zw8fjk49xvqjNwa1hH9A8B8fR5eVupwksxivXqSw9QV2Trq7UBHhWydpK787uKtGZjit Y79w== X-Gm-Message-State: ALoCoQlIlQJCeEFaIFYSR7PhAhpIWNz8PWBMn0XJfwgwjmZiMBWE1L1rhj6sxRexh8JGhVCsq9W7 X-Received: by 10.70.89.139 with SMTP id bo11mr24122048pdb.50.1407159107680; Mon, 04 Aug 2014 06:31:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Mon, 4 Aug 2014 06:31:27 -0700 (PDT) In-Reply-To: <53DF8904.6070904@jive.com> References: <53DF85B4.6060600@jive.com> <53DF8904.6070904@jive.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 4 Aug 2014 15:31:27 +0200 Message-ID: To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ShuNFTc-JERe0XdHvpGNGhlJoLA Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 13:31:49 -0000 2014-08-04 15:22 GMT+02:00 Simon Perreault : > Le 2014-08-04 09:11, I=C3=B1aki Baz Castillo a =C3=A9crit : > >>> Another idea: put the DTLS and STUN next to each other. Since the STUN >>> header contains the STUN message length, you can put data after it in t= he >>> same UDP packet. >>> >>> Not saying it's a better idea, just something we could consider doing. >> >> >> Please don't forget STUN and DTLS over TCP, which is carried as per >> http://tools.ietf.org/html/rfc4571. > > > Assuming you meant RTP over TCP... > > As this optimization would be for DTLS, I was assuming UDP only... No, I mean STUN, DTLS and RTP over TCP. http://tools.ietf.org/html/rfc6544 Section 3: +----------+ | | | App | +----------+----------+ +----------+----------+ | | | | | | | STUN | (D)TLS | | STUN | App | +----------+----------+ +----------+----------+ | | | | | RFC 4571 | | RFC 4571 | +---------------------+ +---------------------+ | | | | | TCP | | TCP | +---------------------+ +---------------------+ | | | | | IP | | IP | +---------------------+ +---------------------+ Figure 1: ICE TCP Stack with and without (D)TLS --=20 I=C3=B1aki Baz Castillo From nobody Mon Aug 4 06:44:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCB11B2AF9 for ; Mon, 4 Aug 2014 06:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o_IoP9QFRQL for ; Mon, 4 Aug 2014 06:44:35 -0700 (PDT) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46AD41B2AC9 for ; Mon, 4 Aug 2014 06:44:35 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so5032302oag.16 for ; Mon, 04 Aug 2014 06:44:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bNEyRxU0dG5G3DVv1OBy7rY6xdi5AmWKtVgbLxont90=; b=PQIGAXoSmORzRr02yqoLeXkJ5iJ92xkDzHdGK0/iwnMukCcNxdFm3gP7oVdvcLE/hL mEBU9BnykTn/9APoFI8+Mfvv4vKPWapDO05WqEXsInEHuHvL00PZbOkdn5ieSOKDuwAJ hZLwmoDzW/JcoTOb9nM6pgOvmeQFXvpxb1MF1/2bzvqIeAdzPaVl1BF5r2y94JqygvzH B3MD1GxyZctVxtmfZARWqZOuFwuHnKZ7kBnFxKJHw1BsRlf8cesWLGEFz11H5yoCsNyf va1QryquDbwX3YZyBPHXT1rLeplYpkJFAdOWvXBXbQOnjqOySAeDLOoXmzIdiv2GCock bcgQ== X-Gm-Message-State: ALoCoQkkMGW4nWRfIo6SzY8T1Q1gAYjT81Y9W3aRGBc73sG8w6huV/CEkgnQ8uTdO4RyJ9kxVqca X-Received: by 10.182.33.99 with SMTP id q3mr17962045obi.28.1407159874295; Mon, 04 Aug 2014 06:44:34 -0700 (PDT) Received: from [192.168.1.96] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id h1sm16925736oem.5.2014.08.04.06.44.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 06:44:33 -0700 (PDT) Message-ID: <53DF8E3F.1000402@jive.com> Date: Mon, 04 Aug 2014 09:44:31 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <53DF85B4.6060600@jive.com> <53DF8904.6070904@jive.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PXjiLAhrFOEKkm3sFfgUtznRBoM Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE/DTLS optimization X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 13:44:37 -0000 Le 2014-08-04 09:31, Iñaki Baz Castillo a écrit : > No, I mean STUN, DTLS and RTP over TCP. > > http://tools.ietf.org/html/rfc6544 > > Section 3: > > +----------+ > | | > | App | > +----------+----------+ +----------+----------+ > | | | | | | > | STUN | (D)TLS | | STUN | App | > +----------+----------+ +----------+----------+ > | | | | > | RFC 4571 | | RFC 4571 | > +---------------------+ +---------------------+ > | | | | > | TCP | | TCP | > +---------------------+ +---------------------+ > | | | | > | IP | | IP | > +---------------------+ +---------------------+ > > Figure 1: ICE TCP Stack with and without (D)TLS Woah! I had not realized that RFC4571 included STUN and DTLS. *sigh* Thanks, Simon From nobody Mon Aug 4 06:49:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8521B2B02 for ; Mon, 4 Aug 2014 06:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4rYKX5bcgHJ for ; Mon, 4 Aug 2014 06:49:33 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643241B2AFB for ; Mon, 4 Aug 2014 06:49:33 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y13so9700600pdi.11 for ; Mon, 04 Aug 2014 06:49:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=F4lxnllYjphEDzjtbN4uQBLvemYWkuFEpufCy70wVOk=; b=YIKVzdKWbzJPzs9dQI5fLLOnyVANZc5/Am5g5+Esg7IbtR/YupNf5RNrdVrupL4jYw B64st9tzmkJcu5vUWws8H/6zHPE15Sg8+fXynoRD191FWVezLdQ6fV3GdqOGUg1na22b r8/KRuwQeQX7knTSXEHXXJ2sgIb47JpXm6etocPuqnqTs0ozZt7MyjMFKBL+1rKE0JAP 0Sc/BlVZ7Pa3Fb2uQXEq4jMPMrBVacuGSBJcIZkVIMM/gayAnRJxni/flVn+Dxccl3hg RBacogbse4hp5uKNwtG6R1u3OBqKhcrUdTFHBurkBnlR/gsdrtc2jcc0/7y0/VKrAo+g xbHw== X-Gm-Message-State: ALoCoQm1xsXUNfjvG0Zis0rDYk3/ITIH+mh86b/QywDPsswIKag2JIKRloya2uQ3APfX+WUPnDWX X-Received: by 10.70.128.164 with SMTP id np4mr2040011pdb.168.1407160173094; Mon, 04 Aug 2014 06:49:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Mon, 4 Aug 2014 06:49:13 -0700 (PDT) In-Reply-To: <53DF8E3F.1000402@jive.com> References: <53DF85B4.6060600@jive.com> <53DF8904.6070904@jive.com> <53DF8E3F.1000402@jive.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 4 Aug 2014 15:49:13 +0200 Message-ID: To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/cSNfrJWELVw_R2Lw6e0OjvgXsNw Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE/DTLS optimization X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 13:49:37 -0000 2014-08-04 15:44 GMT+02:00 Simon Perreault : > Woah! I had not realized that RFC4571 included STUN and DTLS. It does not. It just defines a mechanism for encapsulating RTP packets into TCP, but the same mechanism is perfectly valid for any other kind of packets and thus RTC 6544 makes use of it for STUN and DTLS. --=20 I=C3=B1aki Baz Castillo From nobody Mon Aug 4 06:50:51 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9C1B2B0A for ; Mon, 4 Aug 2014 06:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px2dgEvOEi3d for ; Mon, 4 Aug 2014 06:50:47 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625CA1B2B02 for ; Mon, 4 Aug 2014 06:50:47 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wp18so4468037obc.20 for ; Mon, 04 Aug 2014 06:50:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0HRjM+O8jp62volmqk644sWxqGUczGg3mdTgI+f3vp4=; b=gg/00M2kr8HbvLA4g9MmFKUN3oe4gymWg4epQKcl5lh7pavPEI61l6ClFGyumX6Xm5 l46jq6e3IEK8gBTgwCcK2H0f8XE75f7NCrDru+x9ojDUsfSGB0gPeQNJ5yCcPjg2iCIM QfKMCqoZUpfnEwow9vS6Zy3X4gFw+lYSCt7Hpk1ADB8rdpNoITtlGWgyJwEpxE6Qlmx+ JUm7XyAh7TSBf5hMRQXG8Wuo7CnBjI5j91ahynIpzsrLmsPOP5e7Rx17AZEQ0ObWNtA4 muJKtYFU3vHywdMM2BhZjcz37ERgxQOsvTUVIX/ZuMoTeNHfQrIVOd878a7AIDmCjwkO 359A== X-Gm-Message-State: ALoCoQkgnNdDT9ntY35nR/HCoAMIHMf2BGjS6zDvpk0CjDHWPVD2uZb+vPFlOySL4X+SzZBPjzEA X-Received: by 10.60.118.8 with SMTP id ki8mr32527790oeb.29.1407160246352; Mon, 04 Aug 2014 06:50:46 -0700 (PDT) Received: from [192.168.1.96] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id fu14sm75939355oeb.9.2014.08.04.06.50.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 06:50:45 -0700 (PDT) Message-ID: <53DF8FB1.4070200@jive.com> Date: Mon, 04 Aug 2014 09:50:41 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <53DF85B4.6060600@jive.com> <53DF8904.6070904@jive.com> <53DF8E3F.1000402@jive.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1wJNuBD_0Yx0MKkBmIcxwBBhAa0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE/DTLS optimization X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 13:50:50 -0000 Le 2014-08-04 09:49, Iñaki Baz Castillo a écrit : > 2014-08-04 15:44 GMT+02:00 Simon Perreault : >> Woah! I had not realized that RFC4571 included STUN and DTLS. > > It does not. It just defines a mechanism for encapsulating RTP packets > into TCP, but the same mechanism is perfectly valid for any other kind > of packets and thus RTC 6544 makes use of it for STUN and DTLS. Yes, that's what I meant. Thanks, Simon From nobody Mon Aug 4 10:58:42 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE871A00D7 for ; Mon, 4 Aug 2014 10:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHndJ09rRQVy for ; Mon, 4 Aug 2014 10:58:39 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F111A008B for ; Mon, 4 Aug 2014 10:58:38 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so6690184wiv.2 for ; Mon, 04 Aug 2014 10:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W6QgxuPyiJQAJr98svmSD/wWXMk2+UzhFfovIL8fOZ4=; b=M6MYF3Hk3wLi7OvpdKjDQGNH3O8OwXcbfbGEqtvtzOFwAIBIUpy4PbB203rhYGJdND m4oB4Ck6PR/jlwXmOQWZ+vpT1trbI4LX64YkX7g6ixUQOoQS5SB06bojPIq0bivc2c4l weSOnGqFqFBezM21f9rDi/PM7OLCFhBrZxR8aReavsp8W5VN5W14PVXmVWIuqnTAcLXH J/trvNaovvuPv/cRpoWw7prxuUe3PzpWDP2Iio2QUAj1FX7vx9+HIvueanAU9XSLgsPz iD5a/0elDafqC21C3QsxdHraWqFkXh5qf6wiZuEuEifNJEc+U3hs8P6FfzTxEiD42TI3 uZNQ== MIME-Version: 1.0 X-Received: by 10.180.187.197 with SMTP id fu5mr32376023wic.64.1407175116833; Mon, 04 Aug 2014 10:58:36 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Mon, 4 Aug 2014 10:58:36 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> Date: Mon, 4 Aug 2014 10:58:36 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/goYrfwJ0g1S5-SPFOSAhLLA_xJ0 Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:58:40 -0000 On 4 August 2014 02:36, Jos=C3=A9 Luis Mill=C3=A1n wrot= e: > Do you mean that some implementations might get sad because this is > something they simply do not support today (managing a single DTLS > connection with data coming form different underlying transport > protocols) or that doing it leads to any backward compatibility issue? If a DTLS implementation fixates on a 5-tuple, then that is a problem if critical packets arrive on other paths, and won't appear on the fixated path. That's not something I've seen, but it's a plausible outcome. From nobody Tue Aug 5 05:38:07 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEA01A0194 for ; Tue, 5 Aug 2014 05:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqDZ_InX9ZKI for ; Tue, 5 Aug 2014 05:37:59 -0700 (PDT) Received: from mail-2.sr.se (mail-2.sr.se [IPv6:2001:67c:d8:ee80::135]) (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 D91801A0188 for ; Tue, 5 Aug 2014 05:37:57 -0700 (PDT) CC: X-Halon-ID: e5a8f5f1-1c9c-11e4-b526-000c2951fa8d DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=cc:x-halon-id:received:received:from:to:subject:thread-topic:thread-index: date:message-id:references:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:content-type:content-transfer-encoding: mime-version; bh=KPB2rbAHHXnRrtvnkhO2EyF2Osc64ulT8v8WAZfaWQY=; b=Hc6/pQouyRTHGyVyDChpCWGJkwYal8/PQlZ732ubLI4VbAPAV0uF/wk8dWEYzJMm7oN7N7bZ6rRMq +bItaYpwSbYH+uK52V9U6XwZs4iPz6TM/f9XyK/5osV/X+/TmIzd2tPFyp04pY5htUnGQrXxOyzYHQ 7Td36NUe6+9xXw6o= Received: from STOEXCASHT02.sr.se (unknown [134.25.11.15]) by mail-2.sr.se (Halon Mail Gateway) with ESMTPS for ; Tue, 5 Aug 2014 14:34:52 +0200 (CEST) Received: from STOEXMBX01.sr.se ([fe80::3ca4:10d1:e63f:5b7f]) by STOEXCASHT02.sr.se ([fe80::88c7:d3b3:5c76:acd7%13]) with mapi id 14.03.0181.006; Tue, 5 Aug 2014 14:35:32 +0200 From: Fredrik Bergholtz To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis outstanding issues Thread-Index: Ac+By1gnkWozapFRScuYYj7YauRbWgAD5d0AAUom8YAEqYhvgAAMaTqAAASrOQAAAqivAAWrkziA Date: Tue, 5 Aug 2014 12:35:31 +0000 Message-ID: <6A5A8D4EF65AF1439301480747E29F434E42B417@STOEXMBX01.sr.se> References: <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com> <53BAA873.6050907@alum.mit.edu> <53BAD9A0.6060304@alum.mit.edu> In-Reply-To: <53BAD9A0.6060304@alum.mit.edu> Accept-Language: en-GB, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ycDeAey4WAMndzuuwmXxw_Igu78 Subject: Re: [MMUSIC] 4566bis outstanding issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 12:38:05 -0000 Hi. Excellent to see a summarised list of what is considered for 4566bis. Personally I would like to see ABNF definitions for all the attributes. I d= o realise the amount of work that is needed but, as someone else mentioned,= the 4566 is the base line for all extensions and I think that it is import= ant to make the base as well-defined as possible. One item that is not in your list that I would like to see is a clarificati= on of how to signal asymmetric sessions. By asymmetric sessions I mean usin= g the a=3Dsendonly and a=3Drecvonly in separate media definitions, specific= ally addressing the "same port" issue of section 5.14.=20 I realise that this is a more use-case oriented addition than an improvemen= t of the examples for the various attributes that has been discussed. Perha= ps this kind of clarification belong in something like rfc4317 rather than = in 4566. Do you have any thoughts on if and how such clarifications could a= nd should be made? Best regards, Fredrik Bergholtz Swedish Radio > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: den 7 juli 2014 19:32 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] 4566bis outstanding issues >=20 > Trimming again. >=20 > On 7/7/14 12:16 PM, Ali C. Begen (abegen) wrote: > > > > On Jul 7, 2014, at 11:02 PM, Paul Kyzivat wrote= : > > > >> On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote: > >>> Hi Paul, > >>> > >>> OK, no one else seems to be paying attention to this. I have some > comments inline and lets see whether we can reach an agreement: > >> > >> OK. > >> > >> I've trimmed to a few points to comment on... > >> > >>>>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote: > >> > >>>>>> 1) 4566bis needs to provide ABNF syntax for all of the attributes = 4566 > defined. > >>>>>> Comments: This was discussed again in a side meeting in London and > there was not a consensus whether we actually needed this. > >>>>> > >>>>> IIRC the argument against doing this is that we might get it wrong. > >>>>> > >>>>> But IMO we should do it because if we can't get it right how can we > expect readers to get it right? > >>> > >>> I personally don't wanna take on this task. It is a tedious task and = I am not > such an ABNF lover to get these definitions right. If you wanna volunteer= , by all > means, please do so. > >> > >> I'm willing to contribute to this, but won't have time until after the= Toronto > meeting. > > > > That is fine. > > > >> Also, I'm not intimately familiar with all of the attributes. > > > > Nobody is I am afraid. >=20 > There are a lots of people who at least *use* them, and so are familiar w= ith > them at that level. I don't "do" media, so when I'm trying to create exam= ples I > can get as far as "m=3Daudio", and I know there should be an "a=3Drtpmap"= , but > beyond that I need to find an example to copy. >=20 > >>> OK, this goes back to the issue #1. Personally, I suggest we do not d= efine the > abnfs for every sdp attribute in 4566, but then you have a good point. We= can > seek a format and provide a few good examples to show prospective authors= . > >>> > >>> To do this, obviously as you said, we need to agree on that format. H= as > there been a proposal in the past or does anyone have a good proposal to = start > with? > >> > >> Not a formal one. There has been some discussion about this during rev= iew > of individual attribute definitions. My take has been that there is not a= greement. > > > > If you can recall, can you point us to that proposal and maybe briefly = explain > the disagreements as well? >=20 > I think it will take a lot of searching to find it. So I can't do so quic= kly/easily. >=20 > >> One question is whether the definition of a new attribute should: > >> 1) define the full syntax of the line (starting with "a=3D"), > >> 2) should provide additional definitions of (via "/=3D") > >> 3) should provide additional definitions of and > >> (via "/=3D") > >> 4) provide definitions of the name and value that are consistent with > >> and without formally extending the > >> definitions of those. > >> > >> Note that 4566 loosely follows (4) but gives the definitions informall= y rather > than via ABNF. So it gives no guidance on how to use ABNF for this. A num= ber of > drafts have chosen to follow (2). Some have started to do (1) but I don't= know of > any that ended up that way. > >> > >> A question I have raised is: if (2) or (3) is followed, does that mean= that the > draft doing so must be considered as "updating" 4566? > > > > I dont see why it should. Personally most of the attributes I defined f= ollowed > (4). That seemed the easiest option. >=20 > I've been outnumbered on the discussions of this. ISTM that whenever I wr= ite >=20 > attribute =3D/ something new >=20 > then I have at least extended the rfc that defines and arguab= ly have > updated it. The reason it might be considered an update is that what I am > defining implicitly includes the definition of and thus proba= bly all the > abnf that includes the definition of . To verify my new abnf, = or to > generate a parser, I need to create a combined abnf. And abnf doesn't hav= e > namespaces. So all the rulenames I newly define must be distinct from tho= se > defined with . >=20 > And that is true for *every* extension. And for them to be compatible wit= h one > another they all must define rulenames that are unique among them all. >=20 > So effectively each one is an update. >=20 > It is subtly different if I follow (4), even if I use abnf to define the = syntax for my > new attribute, and even if I reuse rule definitions (like > ) from the base sdp definition. >=20 > >> One thing that people sometimes forget when defining new attributes is= that > the syntax of the new attribute MUST also be valid when parsed by the "ge= neric" > attribute syntax. AFAIK there is no way in ABNF to specify that. I think = that (4) > comes closest. > > > > Yes, but this must be checked during the last call by actual humans not= some > abnf parser. >=20 > For now that is true. I have found such errors while doing SDP directorat= e > reviews. >=20 > Thanks, > Paul >=20 > > -acbegen > > > >> > >> Thanks, > >> Paul > >> > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Aug 5 07:18:26 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635191B27F5 for ; Tue, 5 Aug 2014 07:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roHrStO-bxiI for ; Tue, 5 Aug 2014 07:18:19 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E6A1A0312 for ; Tue, 5 Aug 2014 07:18:19 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so1561569vcb.8 for ; Tue, 05 Aug 2014 07:18:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=4TgMuR6XPjQ0tfqAFRYtQxZO7hneIvzIMxoNBAmOZRQ=; b=heS04QRIL2qVQrn3jH8bDY6ZP3tAhxhHxcpm4Jg6GmJOZq2ULYV/yb6f8M+/ahtvWc kIBO6GPb4jpA6zY4CNtQ2msjffJmEk+Iw59D9Oy5yoBKfW09oBmagHQ1IqW/Os58k1r3 kw0uptOw9oUTnuFJVIhialSX9Zy0jx63s+5iE0HYv6DsOpAZkS/Vi60OVS9bdsIus1N+ IBMuKUIQusLyUitLWGxIySXj2Nb8RVNpx4xC/YkPkYjYq8Q2Ge5Vy/0HuSEOdBcACKjZ imVmDqrRE0bFj3RUXHg0Ei50hXGl/VclcUEk+ehcfHHEwXQV0+OEGwgUIKBgxWEWy2aY OyIg== X-Gm-Message-State: ALoCoQl+plZrK37dqeTDmOZ1WcAkxMyq523du+0qc8H13hbsy4SfySIsn+uxuavz5FtxJ/Mn7FZJ X-Received: by 10.53.3.169 with SMTP id bx9mr1529913vdd.80.1407247972705; Tue, 05 Aug 2014 07:12:52 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+wtz8/SRlEsRzHTeyKczkmwewwRA== Date: Tue, 5 Aug 2014 10:12:52 -0400 Message-ID: To: mmusic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nDB-bV6aueC0IlhGVWLXD5tqxuo Subject: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 14:18:24 -0000 Hi, Draft-ietf-mmusic-rfc4566bis-10 section 5.13 discusses two formats of attribute fields. However, it doesn't appear to clearly indicate the validity/invalidity of colon without a value. Is an attribute such as "a=rtcp-xr:" valid? For instance, RFC 3611 indicates that it is valid; however errata 3795 indicates that it potentially shouldn't be valid. Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to clarify the topic? Thanks, Brett From nobody Tue Aug 5 07:33:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612811B282E for ; Tue, 5 Aug 2014 07:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sQC5pgCgZRL for ; Tue, 5 Aug 2014 07:32:59 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4A31B2832 for ; Tue, 5 Aug 2014 07:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7750; q=dns/txt; s=iport; t=1407249178; x=1408458778; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tPvBJXvjGZt5Rx7AIlXaw24qUiXqXORfUNxLQdPYuo4=; b=YyhAD3gPyXfWd7iWZKczLOtp/+YEdxOR7upKDah+9PFg9h57r+5GWN3X SJUT9lpDDqYzPdRUlZwt2968aeYyHU7soCPhzUfwiJKl1cZYL7leRsfNa bTuspULMjlqmzoiyRzOm5Kg+uT8BGjM/g+qYpOX0gdnlDhPmbJA7Eb9MX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAMLq4FOtJA2K/2dsb2JhbABbgmojUlcEy2UMhnNTAYETFneEAwEBAQMBAQEBNzQLBQcEAgEIEQQBAQEeCQcnCxQJCAIEDgUJiDEIAQzDPReOeCEzBwaDKYEcBZcWhHeUYYNNbIFG X-IronPort-AV: E=Sophos;i="5.01,805,1400025600"; d="scan'208";a="66675582" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP; 05 Aug 2014 14:32:57 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s75EWuGC029667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 14:32:56 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 09:32:56 -0500 From: "Ali C. Begen (abegen)" To: Fredrik Bergholtz Thread-Topic: [MMUSIC] 4566bis outstanding issues Thread-Index: Ac+By1gnkWozapFRScuYYj7YauRbWgASkPUAAUom8IAEqYhwgAAMaTqAAASrOQAAAqivAAWoFliAAAQZfQA= Date: Tue, 5 Aug 2014 14:32:55 +0000 Message-ID: <5BF924B8-20CB-4CB2-A152-B49ED07651CD@cisco.com> References: <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com> <53BAA873.6050907@alum.mit.edu> <53BAD9A0.6060304@alum.mit.edu> <6A5A8D4EF65AF1439301480747E29F434E42B417@STOEXMBX01.sr.se> In-Reply-To: <6A5A8D4EF65AF1439301480747E29F434E42B417@STOEXMBX01.sr.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.110.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <2002B39603962941B8CBFB197B477A9B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UKMf8OlQb8_mzUxZS6KrzZs6ciM Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4566bis outstanding issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 14:33:09 -0000 Hi Fredrik There were some changes in the bis document regarding these attributes in -= 08: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-rfc4566bis-07&url2=3Dd= raft-ietf-mmusic-rfc4566bis-08 Do they help with your issue? If not, what else would you like to see? I remember seeing a discussion regarding the use of the same port at some p= oint but it was another draft (sorry I dont remember which one it was). -acbegen On Aug 5, 2014, at 3:35 PM, Fredrik Bergholtz wrote: > Hi. Excellent to see a summarised list of what is considered for 4566bis. >=20 > Personally I would like to see ABNF definitions for all the attributes. I= do realise the amount of work that is needed but, as someone else mentione= d, the 4566 is the base line for all extensions and I think that it is impo= rtant to make the base as well-defined as possible. >=20 > One item that is not in your list that I would like to see is a clarifica= tion of how to signal asymmetric sessions. By asymmetric sessions I mean us= ing the a=3Dsendonly and a=3Drecvonly in separate media definitions, specif= ically addressing the "same port" issue of section 5.14.=20 >=20 > I realise that this is a more use-case oriented addition than an improvem= ent of the examples for the various attributes that has been discussed. Per= haps this kind of clarification belong in something like rfc4317 rather tha= n in 4566. Do you have any thoughts on if and how such clarifications could= and should be made? >=20 > Best regards, > Fredrik Bergholtz > Swedish Radio >=20 >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: den 7 juli 2014 19:32 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] 4566bis outstanding issues >>=20 >> Trimming again. >>=20 >> On 7/7/14 12:16 PM, Ali C. Begen (abegen) wrote: >>>=20 >>> On Jul 7, 2014, at 11:02 PM, Paul Kyzivat wrote= : >>>=20 >>>> On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote: >>>>> Hi Paul, >>>>>=20 >>>>> OK, no one else seems to be paying attention to this. I have some >> comments inline and lets see whether we can reach an agreement: >>>>=20 >>>> OK. >>>>=20 >>>> I've trimmed to a few points to comment on... >>>>=20 >>>>>>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote: >>>>=20 >>>>>>>> 1) 4566bis needs to provide ABNF syntax for all of the attributes = 4566 >> defined. >>>>>>>> Comments: This was discussed again in a side meeting in London and >> there was not a consensus whether we actually needed this. >>>>>>>=20 >>>>>>> IIRC the argument against doing this is that we might get it wrong. >>>>>>>=20 >>>>>>> But IMO we should do it because if we can't get it right how can we >> expect readers to get it right? >>>>>=20 >>>>> I personally don't wanna take on this task. It is a tedious task and = I am not >> such an ABNF lover to get these definitions right. If you wanna voluntee= r, by all >> means, please do so. >>>>=20 >>>> I'm willing to contribute to this, but won't have time until after the= Toronto >> meeting. >>>=20 >>> That is fine. >>>=20 >>>> Also, I'm not intimately familiar with all of the attributes. >>>=20 >>> Nobody is I am afraid. >>=20 >> There are a lots of people who at least *use* them, and so are familiar = with >> them at that level. I don't "do" media, so when I'm trying to create exa= mples I >> can get as far as "m=3Daudio", and I know there should be an "a=3Drtpmap= ", but >> beyond that I need to find an example to copy. >>=20 >>>>> OK, this goes back to the issue #1. Personally, I suggest we do not d= efine the >> abnfs for every sdp attribute in 4566, but then you have a good point. W= e can >> seek a format and provide a few good examples to show prospective author= s. >>>>>=20 >>>>> To do this, obviously as you said, we need to agree on that format. H= as >> there been a proposal in the past or does anyone have a good proposal to= start >> with? >>>>=20 >>>> Not a formal one. There has been some discussion about this during rev= iew >> of individual attribute definitions. My take has been that there is not = agreement. >>>=20 >>> If you can recall, can you point us to that proposal and maybe briefly = explain >> the disagreements as well? >>=20 >> I think it will take a lot of searching to find it. So I can't do so qui= ckly/easily. >>=20 >>>> One question is whether the definition of a new attribute should: >>>> 1) define the full syntax of the line (starting with "a=3D"), >>>> 2) should provide additional definitions of (via "/=3D") >>>> 3) should provide additional definitions of and >>>> (via "/=3D") >>>> 4) provide definitions of the name and value that are consistent with >>>> and without formally extending the >>>> definitions of those. >>>>=20 >>>> Note that 4566 loosely follows (4) but gives the definitions informall= y rather >> than via ABNF. So it gives no guidance on how to use ABNF for this. A nu= mber of >> drafts have chosen to follow (2). Some have started to do (1) but I don'= t know of >> any that ended up that way. >>>>=20 >>>> A question I have raised is: if (2) or (3) is followed, does that mean= that the >> draft doing so must be considered as "updating" 4566? >>>=20 >>> I dont see why it should. Personally most of the attributes I defined f= ollowed >> (4). That seemed the easiest option. >>=20 >> I've been outnumbered on the discussions of this. ISTM that whenever I w= rite >>=20 >> attribute =3D/ something new >>=20 >> then I have at least extended the rfc that defines and argua= bly have >> updated it. The reason it might be considered an update is that what I a= m >> defining implicitly includes the definition of and thus prob= ably all the >> abnf that includes the definition of . To verify my new abnf,= or to >> generate a parser, I need to create a combined abnf. And abnf doesn't ha= ve >> namespaces. So all the rulenames I newly define must be distinct from th= ose >> defined with . >>=20 >> And that is true for *every* extension. And for them to be compatible wi= th one >> another they all must define rulenames that are unique among them all. >>=20 >> So effectively each one is an update. >>=20 >> It is subtly different if I follow (4), even if I use abnf to define the= syntax for my >> new attribute, and even if I reuse rule definitions (like >> ) from the base sdp definition. >>=20 >>>> One thing that people sometimes forget when defining new attributes is= that >> the syntax of the new attribute MUST also be valid when parsed by the "g= eneric" >> attribute syntax. AFAIK there is no way in ABNF to specify that. I think= that (4) >> comes closest. >>>=20 >>> Yes, but this must be checked during the last call by actual humans not= some >> abnf parser. >>=20 >> For now that is true. I have found such errors while doing SDP directora= te >> reviews. >>=20 >> Thanks, >> Paul >>=20 >>> -acbegen >>>=20 >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Aug 5 07:41:59 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90831B2836 for ; Tue, 5 Aug 2014 07:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7JzEIhSXTEW for ; Tue, 5 Aug 2014 07:41:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9CE1B282F for ; Tue, 5 Aug 2014 07:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1191; q=dns/txt; s=iport; t=1407249714; x=1408459314; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YELDdBlNAsOCAC2/UGoSmttj+rzSNjH9fck4Yru04v0=; b=iRxEPbsPyZuo140cLDjGUUoyPQN9Iz324W3mkKhDwIlvdZoZaia6TPsn +CvGfVQaeJLPNZ8PIV4/8qyuKytYpAB+xjAByCKmLRp3gFaisDM7tn1ZV EHDgwjLV3QpRIFW1ddMOl/e6l5VWm3ykLxjO859UQwQXwLw4WsASyXQRk k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAM3s4FOtJA2I/2dsb2JhbABbgmojUlcEy2UKhnVTAYETFneEBAEBAwEBAQE3NAsFCwIBCDYQJwslAQEEDgWIOggBDMM2EwSPGTMHgy+BHAWOe40SlGGDTWyBRg X-IronPort-AV: E=Sophos;i="5.01,805,1400025600"; d="scan'208";a="345242076" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP; 05 Aug 2014 14:41:48 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s75Efm7a024219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 14:41:48 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 09:41:48 -0500 From: "Ali C. Begen (abegen)" To: Brett Tate Thread-Topic: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value Thread-Index: Ac+wtz8/SRlEsRzHTeyKczkmwewwRAALgxgA Date: Tue, 5 Aug 2014 14:41:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.110.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <4BA7F1BDC33261458045E1092082873C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/fsMC-EunVc5ssNHlqSLhm11iqxM Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 14:41:59 -0000 On Aug 5, 2014, at 5:12 PM, Brett Tate wrote: > Hi, >=20 > Draft-ietf-mmusic-rfc4566bis-10 section 5.13 discusses two formats of > attribute fields. However, it doesn't appear to clearly indicate the > validity/invalidity of colon without a value. It says there are two forms. since "a=3D:" is not listed as a fo= rm, I guess it simply means it is not valid usage. >=20 > Is an attribute such as "a=3Drtcp-xr:" valid? =20 Not based on my knowledge. > For instance, RFC 3611 > indicates that it is valid; however errata 3795 indicates that it > potentially shouldn't be valid. I am not sure why that errate is not verified. To me, 3611 has an abnf synt= ax error that should be fixed. >=20 > Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to clarify > the topic? We can add a sentence to ban such a usage but now I wonder whether they hav= e been attributes defined in that form in the past. Is anyone aware of any? -acbegen >=20 > Thanks, > Brett >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Aug 5 08:12:52 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9821B2890 for ; Tue, 5 Aug 2014 08:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C23b2akRLacj for ; Tue, 5 Aug 2014 08:12:49 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0891B2873 for ; Tue, 5 Aug 2014 08:12:37 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id b0cC1o0041HzFnQ563Cc66; Tue, 05 Aug 2014 15:12:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id b3Cc1o00K3ZTu2S3a3CcCL; Tue, 05 Aug 2014 15:12:36 +0000 Message-ID: <53E0F464.3080600@alum.mit.edu> Date: Tue, 05 Aug 2014 11:12:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407251556; bh=djyZUC8DiDomDKVYACa/eoImpNMlwsiDYugfFvnCAuY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fvluUXP+5Wa3fafgUQshVpoDvv4VHBn2zEJZgLPbFduwxtYYfQ4FCo9zzSgOFgMCM T97QfzQFwAdG/xIs2dFtCGn5gldmIrL8oUpHY57XyuGYfjnc+tOv4ozyiz+BKjsrL3 y8pqzQ6BMYxeMT3ZuHENUsOQfBGkdX4ylEyIcWsAqNi2aCZVtg8+Rt032ZrQ0Pa++x U4987/BY2u+BI0qUSgKEq9BnSNTpxUQhQNk4PfzQHg/82NGym+tvwrpL1fJHOMPOJw fCUtet915uOPgrm/OgxnDc8ufi75fLpHXKb0Qd5Md6jdgpdQJJfqib7qEHGCHEwuCM pLawSjZV+rpYg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tbCu2CbWGZhuXuh5Sj_YqQJg5mo Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 15:12:51 -0000 On 8/5/14 10:12 AM, Brett Tate wrote: > Hi, > > Draft-ietf-mmusic-rfc4566bis-10 section 5.13 discusses two formats of > attribute fields. However, it doesn't appear to clearly indicate the > validity/invalidity of colon without a value. > > Is an attribute such as "a=rtcp-xr:" valid? For instance, RFC 3611 > indicates that it is valid; however errata 3795 indicates that it > potentially shouldn't be valid. > > Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to clarify > the topic? Yes, it probably should. Given how established SDP is, I think we need to be careful about *how* we clarify it, to minimize compatibility issues. The referenced erratum says that for one particular attribute the colon is required even if there is no value after it. And the proposed fix is to only permit the colon if there is a value. Another possibility would be to make the colon optional if there is no value. I am inclined to think that the *generic* syntax for attributes ought to work that way, in order to be most forgiving. The current syntax is: attribute = (att-field ":" att-value) / att-field att-field = token att-value = byte-string byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR, or LF I think we should at least *consider* changing it to: attribute = att-field [ ":" [att-value] ] It would be good to hear from anybody who thinks this change would be troublesome. Possibly the syntax of individual attributes can continue to be more restrictive. That will certainly be the case until/unless they are all updated. In principle we need to confront *that* for each of the attributes defined in 4566 if we are going to give ABNF for each of them. But it is only of concern for an attribute where the value is optional. I don't think that is the case for any attributes defined in 4566. Thanks, Paul From nobody Tue Aug 5 08:48:29 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA231B2A3E for ; Tue, 5 Aug 2014 08:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.864 X-Spam-Level: * X-Spam-Status: No, score=1.864 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4mNpihhClll for ; Tue, 5 Aug 2014 08:48:27 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4081B2A36 for ; Tue, 5 Aug 2014 08:48:27 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id b3bf1o0031YDfWL583oS6B; Tue, 05 Aug 2014 15:48:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id b3oS1o00C3ZTu2S3g3oSvx; Tue, 05 Aug 2014 15:48:26 +0000 Message-ID: <53E0FCCA.9000404@alum.mit.edu> Date: Tue, 05 Aug 2014 11:48:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407253706; bh=HNo20NyjZs00tt3Eh0ZNPN+EITTqMrhapjwTES+xJ0M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Dl6MKnehMqHnv0QqF01dmYhLSUub9iNFOhNbrkA45+g+fUBhA9MOSCiz1gmrrjB1n y2L6/1gWiD7TA6fn34e+X5JKcUCpWdMWsbPcZzt/HlYzCu+KNxXEZ51tGSn+oyCuj+ UEp1PGrawY/Qjh69gEURHtqae0xlpbnTmNkolX3ZoteGAL1fHekHhqmLF747uazSab i0om3hY7l7v7lwL0U2GfVueqWT6FemVfk+s/29pQoV2mtMRwTBMiNJ7yt+kVTW94qD 9FeAYxRo4xeJc7yu2NmVv0yIG88tqmB3Pnvh6/59mnewRXA1C6Ed7nbZY3A5ZOAtyh 1cFbh2LYcbEQg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/sqSaQn3Rg8NaWoWoigzWHeIywXE Subject: [MMUSIC] QUERY: info about a=cat, a=keywds, a=tool X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 15:48:28 -0000 I volunteered to draft ABNF syntax for the attributes defined in RFC4566 (SDP). There are some that I have very little information about: a=cat: a=keywds: a=tool: They have all been in SDP since RFC2327 in 1998. And I don't think I have ever seen any of them used. I did a google search over ietf.org looking for usages without luck. And they are all very vague about their syntax. The safe answer is to just define the value syntax for each of then as . But at least for a=cat the value (category) is specified as "dot-separated hierarchical category", so it seems reasonable that the syntax ought to involve dots in some way. Perhaps these should all be deprecated. Is there anybody still here who remembers when these were defined, and what the expectations were about the syntax? Thanks, Paul From nobody Tue Aug 5 10:10:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321111A0055 for ; Tue, 5 Aug 2014 10:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS--ln8i9eOi for ; Tue, 5 Aug 2014 10:10:13 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542FC1A03E7 for ; Tue, 5 Aug 2014 10:10:13 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so2065758vcb.1 for ; Tue, 05 Aug 2014 10:10:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=A07N6RoNy253DZbPO8un8+fbJnvrqUtPsTTCs1rLlX4=; b=h5IyAAKxc4OQOYE+tAvCLAvcUx24aafTbDBsCLOZhSoBkbXpPcll8V/q+AxJFeDDnv gWWabq3MuxmkmixMO4FuCo+JZrfyl7wNTXU6Bi8Ggh7zyIdcBUnuNM5pVdsLw3+w/Y61 /De4HsYJ+xTYecR1vXwPlPzYZEiykn70rq27gw7MXyORc9CWca4V+tddi+RCQ9eScSdz dOxoo4Wngxv7tX/AP4zdSCiCgOA7CM9lzeGw00NMVuUXq0NlR8Slp1c0IDbC2H19hOpA S+X+l3S3IvEIKEq5FmwCs5b0lZ0bmJY245prs7l2Z92UyJGWylUMe0h1S1QSv6xhBk9G 9FcQ== X-Gm-Message-State: ALoCoQnAVVn8kUJ62PReOG26shq1DYTaIUnvZKHSIb/jAtb1mI2k2QBshRvm550FapPyK4UyGzTf X-Received: by 10.52.138.175 with SMTP id qr15mr2382055vdb.94.1407258268763; Tue, 05 Aug 2014 10:04:28 -0700 (PDT) From: Brett Tate References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGOoE2KbpIxOGP3Is83t9nwJAFlDAKUUI93nC+x/AA= Date: Tue, 5 Aug 2014 13:04:28 -0400 Message-ID: To: "Ali C. Begen (abegen)" , mmusic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/T50hHJh4o5F1c-tqpW33JueME4g Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 17:10:15 -0000 Thanks for the response. I agree with your RFC 4566 interpretation. RFC 3211 did not conform to RFC 2327 (or RFC 4566) when introducing the rtcp-xr attribute. Thus I guess that it is just a matter of deciding how best to remedy the situation. Since the rfc4566bis ABNF is explicit, one option is potentially to recommend that errata 3795 be accepted and leave rfc4566bis as-is. RFC 4566: attribute-fields = *(%x61 "=" attribute CRLF) attribute = (att-field ":" att-value) / att-field att-field = token att-value = byte-string token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E token = 1*(token-char) byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR, or LF RFC 2327: attribute-fields = *("a=" attribute CRLF) attribute = (att-field ":" att-value) | att-field att-field = 1*(alpha-numeric) att-value = byte-string byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff) ;any byte except NUL, CR or LF -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Tuesday, August 05, 2014 10:42 AM To: Brett Tate Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value On Aug 5, 2014, at 5:12 PM, Brett Tate wrote: > Hi, > > Draft-ietf-mmusic-rfc4566bis-10 section 5.13 discusses two formats of > attribute fields. However, it doesn't appear to clearly indicate the > validity/invalidity of colon without a value. It says there are two forms. since "a=:" is not listed as a form, I guess it simply means it is not valid usage. > > Is an attribute such as "a=rtcp-xr:" valid? Not based on my knowledge. > For instance, RFC 3611 > indicates that it is valid; however errata 3795 indicates that it > potentially shouldn't be valid. I am not sure why that errate is not verified. To me, 3611 has an abnf syntax error that should be fixed. > > Should draft-ietf-mmusic-rfc4566bis-10 section 5.13 be updated to > clarify the topic? We can add a sentence to ban such a usage but now I wonder whether they have been attributes defined in that form in the past. Is anyone aware of any? -acbegen From nobody Tue Aug 5 10:54:48 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A99A1B2A9A for ; Tue, 5 Aug 2014 10:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffTRHHyBmqEn for ; Tue, 5 Aug 2014 10:54:39 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C101A0AAA for ; Tue, 5 Aug 2014 10:54:39 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so2135098vcb.20 for ; Tue, 05 Aug 2014 10:54:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=V98mO1/iWBNd4ND8sDuKD2nAm3PH6AJbR6xwWvSitHg=; b=Lc50/w/8OH3FDuVlSlGOjRtxWnEUtkat68Ry71Q6C5tJ+KD38Eqfnhrc1QZenyTikn 38kgoctU6FTwS4xkG8atBm4eR0yz5P5WHEjzyJfdR6KEhSTYQljy2Qm94YkGZwt3RxXj 1Xml6i84+zfEvB+1JIzc5oKnPO5ZsX0jDGSP0ZIIkURsp47VyKACY1RGWhXEWmuyJPtw CBdesupC5iBoAbnooM8FHcqqSHKK2QW9HrScs5qq5CVSGRuytQLU/RSbOMt/YP9bdJsI wTBhnteAgDFUFZexL1vAByanCYdVm7rSIlXVupAzn+bxOdKhk4BF5a4aKfajH3oBdUav cozg== X-Gm-Message-State: ALoCoQnWMkBp8LLAbAvtDgWoRx08RJsg62gXwQ+eeHHKcNNvv2+Z/X6zfxmmsmBqIyMju/ERqdf3 X-Received: by 10.52.144.232 with SMTP id sp8mr3520832vdb.61.1407261278812; Tue, 05 Aug 2014 10:54:38 -0700 (PDT) From: Brett Tate References: <53E0F464.3080600@alum.mit.edu> In-Reply-To: <53E0F464.3080600@alum.mit.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGOoE2KbpIxOGP3Is83t9nwJAFlDAGQHQwOnDff9VA= Date: Tue, 5 Aug 2014 13:54:38 -0400 Message-ID: To: Paul Kyzivat , mmusic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nVT4yg_rJaTgsOyqvaqn88NeAMM Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 17:54:45 -0000 > Given how established SDP is, I think we need to be careful about > *how* we clarify it, to minimize compatibility issues. I agree. One option is potentially to keep it invalid. A comment potentially could be added indicating that RFC 3611 is a reason to accommodate the unexpected ABNF expansion (i.e. sender not updated to comply with the errata). > The referenced erratum says that for one particular attribute the > colon is required even if there is no value after it. And the proposed > fix is to only permit the colon if there is a value. Errata 3795's proposed fix to RFC 3611 would allow the ABNF to comply with RFC 4566. > I think we should at least *consider* changing it to: > > attribute = att-field [ ":" [att-value] ] > > It would be good to hear from anybody who thinks this change > would be troublesome. It would cause the rfc4566bis attribute ABNF to not be backward compatible with RFC 4566 devices. This could cause issues with some RFC 4566 devices; however some already accommodate it for interoperability reasons. Thanks, Brett From nobody Tue Aug 5 11:06:24 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7621B2AAF for ; Tue, 5 Aug 2014 11:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmG1cWVK9X13 for ; Tue, 5 Aug 2014 11:06:22 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id C40161A00D2 for ; Tue, 5 Aug 2014 11:06:10 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta02.westchester.pa.mail.comcast.net with comcast id b4dv1o0091ap0As5166ASU; Tue, 05 Aug 2014 18:06:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id b66A1o0083ZTu2S3i66AH7; Tue, 05 Aug 2014 18:06:10 +0000 Message-ID: <53E11D12.4060803@alum.mit.edu> Date: Tue, 05 Aug 2014 14:06:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <53E0F464.3080600@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407261970; bh=ZLbhy2l/fMOgBexhOnldTfoEcuz+Ird2Ks1BSFJKJd4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mmul6og8po09PiLuDPTotnfG3c0HLpOlENZ+3pPGHhwW5Dyx4HEVZG6u5NYuB/5co PpBPMIm/YuYddMjyTs/JbyOvZvd4S3zGl/WQf3jAghaXw5wTKIHY5PKxkyrfaRAf5/ /BCG1i0+B00EbrkwB+CPCNbGJXwYi/zdsLHyCK+NMuZ3Dpy7VoirjM2OEYSMBbPZ19 7RgRA7t3K0hjmx/E9SBDh17UvGcisQB3MzaLA8GOheWUbd1bntbUqbq4ljAyYeYUgX sjHqCo/PlmrKkSjVCmPocNaQAlSMqkA/gMEXjWlWlP0sPGwGc9yh0S1qcc1I5BIO09 +mXgKUjyTZUoA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vKZmqEnQ1ItYitkbOn2k7htoEc8 Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 18:06:23 -0000 On 8/5/14 1:54 PM, Brett Tate wrote: >> Given how established SDP is, I think we need to be careful about >> *how* we clarify it, to minimize compatibility issues. > > I agree. One option is potentially to keep it invalid. A comment > potentially could be added indicating that RFC 3611 is a reason to > accommodate the unexpected ABNF expansion (i.e. sender not updated to > comply with the errata). > >> The referenced erratum says that for one particular attribute the >> colon is required even if there is no value after it. And the proposed >> fix is to only permit the colon if there is a value. > > Errata 3795's proposed fix to RFC 3611 would allow the ABNF to comply with > RFC 4566. > >> I think we should at least *consider* changing it to: >> >> attribute = att-field [ ":" [att-value] ] >> >> It would be good to hear from anybody who thinks this change >> would be troublesome. > > It would cause the rfc4566bis attribute ABNF to not be backward compatible > with RFC 4566 devices. > > This could cause issues with some RFC 4566 devices; however some already > accommodate it for interoperability reasons. In practice this is only an issue for attributes that are specified to be meaningful both with and without a value. We could investigate the current population to see how many fit into that category. I suspect it is very few. My thought in proposing the change was to encourage those ignoring attributes they don't understand to also ignore those with a colon and no value. But we don't want to encourage people to do that. If we only have one case that called for this usage, then maybe we just deal with it there. Thanks, Paula Thanks, Paul From nobody Wed Aug 6 00:44:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3F01B2CB9 for ; Wed, 6 Aug 2014 00:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ky1B-rCExQ3v for ; Wed, 6 Aug 2014 00:44:12 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5450C1B2CB8 for ; Wed, 6 Aug 2014 00:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2247; q=dns/txt; s=iport; t=1407311052; x=1408520652; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ijw0/zFMGPTHwP4YH7tKB2O8qT7kFxPNrm06EC4Twvw=; b=j0sjKwkSrit9W62bizTdFsFSVpVHUErjZobNAjvColUpzfu1R5AExwXY z5eab0e/WY7ivpgKJ4xLLZlRjP+Oalzr2kqaQlTjOy8m7zc3Ztt8T1R9Q VvSR7dJCoi/GDL4II/+UlN3BBYkd+3rTyRa9GBsmYx+DIoogCV3pS1iqT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcFAFnc4VOtJA2L/2dsb2JhbABZDoJcI1JXBMwRCoZ1UwGBDRZ3hAMBAQEDAQEBATc0CwULAgEIDgoeECcLJQIEDgWIOggBDMMQEwSPGTMHgy+BHAWcEpRlgxJCbIFG X-IronPort-AV: E=Sophos;i="5.01,810,1400025600"; d="scan'208";a="345440809" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 06 Aug 2014 07:44:11 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s767iBxw000848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Aug 2014 07:44:11 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 02:44:11 -0500 From: "Ali C. Begen (abegen)" To: Paul Kyzivat Thread-Topic: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value Thread-Index: AQHPsL+/lwH5oM3vOES81+mS9FmxcpvCnvgAgAADOQCAAOSMAA== Date: Wed, 6 Aug 2014 07:44:10 +0000 Message-ID: <27CEE70F-2CE0-4091-86D2-7BC1E6648A09@cisco.com> References: <53E0F464.3080600@alum.mit.edu> <53E11D12.4060803@alum.mit.edu> In-Reply-To: <53E11D12.4060803@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <703DC81A8326A942933564CA9A15129B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/D_-OC1Yw1Z12hu1yUtVBWgnClz4 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 07:44:14 -0000 On Aug 5, 2014, at 9:06 PM, Paul Kyzivat wrote: > On 8/5/14 1:54 PM, Brett Tate wrote: >>> Given how established SDP is, I think we need to be careful about >>> *how* we clarify it, to minimize compatibility issues. >>=20 >> I agree. One option is potentially to keep it invalid. A comment >> potentially could be added indicating that RFC 3611 is a reason to >> accommodate the unexpected ABNF expansion (i.e. sender not updated to >> comply with the errata). >>=20 >>> The referenced erratum says that for one particular attribute the >>> colon is required even if there is no value after it. And the proposed >>> fix is to only permit the colon if there is a value. >>=20 >> Errata 3795's proposed fix to RFC 3611 would allow the ABNF to comply wi= th >> RFC 4566. >>=20 >>> I think we should at least *consider* changing it to: >>>=20 >>> attribute =3D att-field [ ":" [att-value] ] >>>=20 >>> It would be good to hear from anybody who thinks this change >>> would be troublesome. >>=20 >> It would cause the rfc4566bis attribute ABNF to not be backward compatib= le >> with RFC 4566 devices. >>=20 >> This could cause issues with some RFC 4566 devices; however some already >> accommodate it for interoperability reasons. >=20 > In practice this is only an issue for attributes that are specified to be= meaningful both with and without a value. We could investigate the current= population to see how many fit into that category. I suspect it is very fe= w. >=20 > My thought in proposing the change was to encourage those ignoring attrib= utes they don't understand to also ignore those with a colon and no value. = But we don't want to encourage people to do that. If we only have one case = that called for this usage, then maybe we just deal with it there. I think errata 3795 should be accepted and we just make the clarification i= n the bis document (i.e., say "dont use just a column"). What is the process for reviving errata 3795? >=20 > Thanks, > Paula >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Aug 6 02:48:16 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0841B1B2CEC for ; Wed, 6 Aug 2014 02:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikanyrunPfmd for ; Wed, 6 Aug 2014 02:48:12 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532F11B2982 for ; Wed, 6 Aug 2014 02:48:12 -0700 (PDT) Received: from [81.187.2.149] (port=58278 helo=[192.168.0.76]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XExpK-00067c-4s; Wed, 06 Aug 2014 10:48:10 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <53E0FCCA.9000404@alum.mit.edu> Date: Wed, 6 Aug 2014 10:48:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2F623547-498A-4A23-BEF2-AB5308BC2215@csperkins.org> References: <53E0FCCA.9000404@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/6Yki2oNnGdsojl3BREKD_vYnRWA Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] QUERY: info about a=cat, a=keywds, a=tool X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 09:48:14 -0000 Paul, I think these come from the Mbone tools (Van Jacobson=92s sd and Mark = Handley=92s sdr), which used the combination of SDP and the Session = Announcement Protocol (SAP) for multicast session directories, TV = guide-style.=20 The a=3Dtool: attribute was introduced in draft-ietf-mmusic-sdp-03; the = others are both in http://tools.ietf.org/id/draft-ietf-mmusic-sdp-01.txt = (draft-ietf-mmusic-sdp-00 is missing from the archive). Mark Handley=92s = slides from the MMUSIC meeting at IETF 33 have some details = ftp://ftp.ietf.org/ietf-online-proceedings/95jul/area.and.wg.reports/tsv/m= music/mmusic.handley.slides.ps Colin On 5 Aug 2014, at 16:48, Paul Kyzivat wrote: > I volunteered to draft ABNF syntax for the attributes defined in = RFC4566 (SDP). >=20 > There are some that I have very little information about: >=20 > a=3Dcat: > a=3Dkeywds: > a=3Dtool: >=20 > They have all been in SDP since RFC2327 in 1998. And I don't think I = have ever seen any of them used. I did a google search over ietf.org = looking for usages without luck. And they are all very vague about their = syntax. >=20 > The safe answer is to just define the value syntax for each of then as = . But at least for a=3Dcat the value (category) is = specified as "dot-separated hierarchical category", so it seems = reasonable that the syntax ought to involve dots in some way. >=20 > Perhaps these should all be deprecated. >=20 > Is there anybody still here who remembers when these were defined, and = what the expectations were about the syntax? >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins http://csperkins.org/ From nobody Wed Aug 6 02:49:34 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FAC1B2CF7 for ; Wed, 6 Aug 2014 02:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhjV2fsDAgC4 for ; Wed, 6 Aug 2014 02:49:27 -0700 (PDT) Received: from mail-2.sr.se (mail-2.sr.se [IPv6:2001:67c:d8:ee80::135]) (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 B203D1B2CFC for ; Wed, 6 Aug 2014 02:49:17 -0700 (PDT) X-Halon-ID: 7d8b295c-1d4e-11e4-b526-000c2951fa8d DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=x-halon-id:received:received:from:to:cc:subject:thread-topic:thread-index: date:message-id:references:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:content-type:mime-version; bh=ujIi1zkQNuasDqiUpw5yqX6xQ4tP1rHUoKD7avFCi4Q=; b=Np3ErGBfB3hLm8zz0M1xDYwIRynwFAc5TjQxfydIJTFtKhNgbLAgeYhpaa2+Pd/G6jmxrqCTYL7hN WLdsaA7lVWptxqbWXX2t8fx3WIo57TS38gcJq3nZ9kET70GhRmx8XVGPm0ajBzmWf3XbvOMwgetZQD oTQUp/52ydIuPX6c= Received: from STOEXCASHT02.sr.se (unknown [134.25.11.15]) by mail-2.sr.se (Halon Mail Gateway) with ESMTPS; Wed, 6 Aug 2014 11:46:07 +0200 (CEST) Received: from STOEXMBX01.sr.se ([fe80::3ca4:10d1:e63f:5b7f]) by STOEXCASHT02.sr.se ([fe80::88c7:d3b3:5c76:acd7%13]) with mapi id 14.03.0181.006; Wed, 6 Aug 2014 11:49:10 +0200 From: Fredrik Bergholtz To: "Ali C. Begen (abegen)" Thread-Topic: [MMUSIC] 4566bis outstanding issues - Send, receive asymmetry and port numbers Thread-Index: AQHPsVus4fL0DD3l7kiyoL4ure303w== Date: Wed, 6 Aug 2014 09:49:10 +0000 Message-ID: <9D8A6737-45D2-44A5-84D1-772754B6E861@sverigesradio.se> References: <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com> <53BAA873.6050907@alum.mit.edu> <53BAD9A0.6060304@alum.mit.edu> <6A5A8D4EF65AF1439301480747E29F434E42B417@STOEXMBX01.sr.se> <5BF924B8-20CB-4CB2-A152-B49ED07651CD@cisco.com> In-Reply-To: <5BF924B8-20CB-4CB2-A152-B49ED07651CD@cisco.com> Accept-Language: en-GB, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9D8A673745D244A584D1772754B6E861sverigesradiose_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/2FbpBv3TYTikga4Oy257Uv2F0n0 Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] 4566bis outstanding issues - Send, receive asymmetry and port numbers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 09:49:30 -0000 --_000_9D8A673745D244A584D1772754B6E861sverigesradiose_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the reply, Ali. The change you referred to is good and helps to further the understanding o= f the attributes even though it doesn=92t explicitly deal with the asymmetr= y use-case that I have in mind. It does exemplify how to use these attribut= es on a media level and this is good. It might even be enough. I might want= to increase the clarity by changing the paragraph saying: Within the following SDP example, the "inactive=94 attribute applies to audio media and the "recvonly" attribute applies to video media. To something like: Within the following SDP example, the "inactive=94 attribute applies to all media. The =93recvonly=94 attribute in the video media description overrides the session-level =93inactive=94 attribute. The result is that the audio media is =93inactive=94 and the video media is =93recvonly". The original text for the =93sendonly" attribute mentions that one reason f= or using this would be if the unicast address was different for send and re= ceive, while this is true, it will be more common to use this when differen= t coding algorithms are to be used for send and receive. When I say more co= mmon, I mean in the radio broadcasting business segment, I can not make ass= umptions on other use-cases. The change, however, does not address the =93same port=94 issue. Section 5.= 14 of rfc 4566 states: =93The semantics of multiple "m=3D" lines using the = same transport address are undefined.=94 The text is not perfectly clear on= what the =93transport address=94 is, but it is implied that this is, in fa= ct the =93port=94 number(s). My thinking is that this restriction is only v= alid when the directionality of the media descriptions are the same. The following is an example of an asymmetrical SDP that might be used in a = radio broadcast use-case. From a reporter in the field, a reasonably high a= udio quality is required but the return from the studio to the reporter onl= y need to be good enough for spoken cues. v=3D0 o=3Dmtu-02 3599993974 3599993974 IN IP4 example.com s=3Dmtu-02 c=3DIN IP4 203.0.113.12 t=3D0 0 m=3Daudio 5004 RTP/AVP 96 a=3Drtpmap:96 aptx/32000/1 a=3Dfmtp:96 variant=3Denhanced; bitresolution=3D24 a=3Dsendonly a=3Dptime:20 m=3Daudio 5004 RTP/AVP 9 a=3Drtpmap:9 G722/8000 a=3Drecvonly As I understand it, this SDP example would strictly have undefined semantic= s even though I think that the semantics are very clear. I don=92t have any concise candidate text that clarifies my points but I co= uld try to think of some if there are no technical issues with the approach= that I am unaware of. Best regards, Fredrik Bergholtz Swedish Radio P.S. I am not a native English speaker, so all my suggested text would have= to be validated. On 05 Aug 2014, at 16:32, Ali C. Begen (abegen) > wrote: Hi Fredrik There were some changes in the bis document regarding these attributes in -= 08: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-rfc4566bis-07&url2=3Dd= raft-ietf-mmusic-rfc4566bis-08 Do they help with your issue? If not, what else would you like to see? I remember seeing a discussion regarding the use of the same port at some p= oint but it was another draft (sorry I dont remember which one it was). -acbegen On Aug 5, 2014, at 3:35 PM, Fredrik Bergholtz wrote: Hi. Excellent to see a summarised list of what is considered for 4566bis. Personally I would like to see ABNF definitions for all the attributes. I d= o realise the amount of work that is needed but, as someone else mentioned,= the 4566 is the base line for all extensions and I think that it is import= ant to make the base as well-defined as possible. One item that is not in your list that I would like to see is a clarificati= on of how to signal asymmetric sessions. By asymmetric sessions I mean usin= g the a=3Dsendonly and a=3Drecvonly in separate media definitions, specific= ally addressing the "same port" issue of section 5.14. I realise that this is a more use-case oriented addition than an improvemen= t of the examples for the various attributes that has been discussed. Perha= ps this kind of clarification belong in something like rfc4317 rather than = in 4566. Do you have any thoughts on if and how such clarifications could a= nd should be made? Best regards, Fredrik Bergholtz Swedish Radio -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: den 7 juli 2014 19:32 To: mmusic@ietf.org Subject: Re: [MMUSIC] 4566bis outstanding issues Trimming again. On 7/7/14 12:16 PM, Ali C. Begen (abegen) wrote: On Jul 7, 2014, at 11:02 PM, Paul Kyzivat wrote: On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote: Hi Paul, OK, no one else seems to be paying attention to this. I have some comments inline and lets see whether we can reach an agreement: OK. I've trimmed to a few points to comment on... On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote: 1) 4566bis needs to provide ABNF syntax for all of the attributes 4566 defined. Comments: This was discussed again in a side meeting in London and there was not a consensus whether we actually needed this. IIRC the argument against doing this is that we might get it wrong. But IMO we should do it because if we can't get it right how can we expect readers to get it right? I personally don't wanna take on this task. It is a tedious task and I am n= ot such an ABNF lover to get these definitions right. If you wanna volunteer, = by all means, please do so. I'm willing to contribute to this, but won't have time until after the Toro= nto meeting. That is fine. Also, I'm not intimately familiar with all of the attributes. Nobody is I am afraid. There are a lots of people who at least *use* them, and so are familiar wit= h them at that level. I don't "do" media, so when I'm trying to create exampl= es I can get as far as "m=3Daudio", and I know there should be an "a=3Drtpmap", = but beyond that I need to find an example to copy. OK, this goes back to the issue #1. Personally, I suggest we do not define = the abnfs for every sdp attribute in 4566, but then you have a good point. We c= an seek a format and provide a few good examples to show prospective authors. To do this, obviously as you said, we need to agree on that format. Has there been a proposal in the past or does anyone have a good proposal to st= art with? Not a formal one. There has been some discussion about this during review of individual attribute definitions. My take has been that there is not agr= eement. If you can recall, can you point us to that proposal and maybe briefly expl= ain the disagreements as well? I think it will take a lot of searching to find it. So I can't do so quickl= y/easily. One question is whether the definition of a new attribute should: 1) define the full syntax of the line (starting with "a=3D"), 2) should provide additional definitions of (via "/=3D") 3) should provide additional definitions of and (via "/=3D") 4) provide definitions of the name and value that are consistent with and without formally extending the definitions of those. Note that 4566 loosely follows (4) but gives the definitions informally rat= her than via ABNF. So it gives no guidance on how to use ABNF for this. A numbe= r of drafts have chosen to follow (2). Some have started to do (1) but I don't k= now of any that ended up that way. A question I have raised is: if (2) or (3) is followed, does that mean that= the draft doing so must be considered as "updating" 4566? I dont see why it should. Personally most of the attributes I defined follo= wed (4). That seemed the easiest option. I've been outnumbered on the discussions of this. ISTM that whenever I writ= e attribute =3D/ something new then I have at least extended the rfc that defines and arguably= have updated it. The reason it might be considered an update is that what I am defining implicitly includes the definition of and thus probabl= y all the abnf that includes the definition of . To verify my new abnf, or= to generate a parser, I need to create a combined abnf. And abnf doesn't have namespaces. So all the rulenames I newly define must be distinct from those defined with . And that is true for *every* extension. And for them to be compatible with = one another they all must define rulenames that are unique among them all. So effectively each one is an update. It is subtly different if I follow (4), even if I use abnf to define the sy= ntax for my new attribute, and even if I reuse rule definitions (like ) from the base sdp definition. One thing that people sometimes forget when defining new attributes is that the syntax of the new attribute MUST also be valid when parsed by the "gene= ric" attribute syntax. AFAIK there is no way in ABNF to specify that. I think th= at (4) comes closest. Yes, but this must be checked during the last call by actual humans not som= e abnf parser. For now that is true. I have found such errors while doing SDP directorate reviews. Thanks, Paul -acbegen Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_9D8A673745D244A584D1772754B6E861sverigesradiose_ Content-Type: text/html; charset="Windows-1252" Content-ID: <764060852489C44399FF6B6FBB2465EB@sverigesradio.se> Content-Transfer-Encoding: quoted-printable Thanks for the reply, Ali. 

The change you referred to is good and helps to further the understand= ing of the attributes even though it doesn=92t explicitly deal with the asy= mmetry use-case that I have in mind. It does exemplify how to use these att= ributes on a media level and this is good. It might even be enough. I might want to increase the clarity by = changing the paragraph saying:

Within= the following SDP example, the "inactive=94 attribute
applie= s to audio media and the "recvonly" attribute applies to
video = media.

To something like:

With= in the following SDP example, the "inactive=94 attribute
appl= ies to all media. The =93recvonly=94 attribute in the video 
media = description overrides the session-level =93inactive=94 
attrib= ute. The result is that the audio media is =93inactive=94 
and th= e video media is =93recvonly".
The original text for the =93sendonly" attribute mentions that on= e reason for using this would be if the unicast address was different for s= end and receive, while this is true, it will be more common to use this whe= n different coding algorithms are to be used for send and receive. When I say more common, I mean in the radio bro= adcasting business segment, I can not make assumptions on other use-cases.<= /div>

The change, however, does not address the =93same port=94 issue. Secti= on 5.14 of rfc 4566 states: =93The semantics of multiple "m=3D" l= ines using the same transport address are undefined.=94 The text is not per= fectly clear on what the =93transport address=94 is, but it is implied that this is, in fact the =93port=94 number(s). My thinking = is that this restriction is only valid when the directionality of the media= descriptions are the same.

The following is an example of an asymmetrical SDP that might be used = in a radio broadcast use-case. From a reporter in the field, a reasonably h= igh audio quality is required but the return from the studio to the reporte= r only need to be good enough for spoken cues.

v=3D0
o=3Dmtu= -02 3599993974 3599993974 IN IP4 example.com
s=3Dmtu= -02
c=3DIN = IP4 203.0.113.12
t=3D0 0=
m=3Daud= io 5004 RTP/AVP 96
a=3Drtp= map:96 aptx/32000/1
a=3Dfmt= p:96 variant=3Denhanced; bitresolution=3D24
a=3Dsendonly
a=3Dpti= me:20
m=3Daudio 5004 RTP/AVP 9
a=3Drtp= map:9 G722/8000
a=3Drec= vonly

As I understand it, this SDP example would strictly have undefined sem= antics even though I think that the semantics are very clear.

I don=92t have any concise candidate text that clarifies my points but= I could try to think of some if there are no technical issues with the app= roach that I am unaware of. 

Best regards,
Fredrik Bergholtz
Swedish Radio

P.S. I am not a native English speaker, so all my suggested text would= have to be validated.



On 05 Aug 2014, at 16:32, Ali C. Begen (abegen) <abegen@cisco.com> wrote:

Hi Fredrik

There were some changes in the bis document regarding these attributes in -= 08:
http://www.ietf.org/rfcdiff?= url1=3Ddraft-ietf-mmusic-rfc4566bis-07&url2=3Ddraft-ietf-mmusic-rfc4566= bis-08

Do they help with your issue? If not, what else would you like to see?


I remember seeing a discussion regarding the use of the same port at some p= oint but it was another draft (sorry I dont remember which one it was).

-acbegen

On Aug 5, 2014, at 3:35 PM, Fredrik Bergholtz <fredrik.bergholtz@sverige= sradio.se> wrote:

Hi. Excellent to see a summarised list of what is= considered for 4566bis.

Personally I would like to see ABNF definitions for all the attributes. I d= o realise the amount of work that is needed but, as someone else mentioned,= the 4566 is the base line for all extensions and I think that it is import= ant to make the base as well-defined as possible.

One item that is not in your list that I would like to see is a clarificati= on of how to signal asymmetric sessions. By asymmetric sessions I mean usin= g the a=3Dsendonly and a=3Drecvonly in separate media definitions, specific= ally addressing the "same port" issue of section 5.14.

I realise that this is a more use-case oriented addition than an improvemen= t of the examples for the various attributes that has been discussed. Perha= ps this kind of clarification belong in something like rfc4317 rather than = in 4566. Do you have any thoughts on if and how such clarifications could and should be made?

Best regards,
Fredrik Bergholtz
Swedish Radio

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: den 7 juli 2014 19:32
To: mmusic@ietf.org
Subject: Re: [MMUSIC] 4566bis outstanding issues

Trimming again.

On 7/7/14 12:16 PM, Ali C. Begen (abegen) wrote:

On Jul 7, 2014, at 11:02 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wro= te:

On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote:
Hi Paul,

OK, no one else seems to be paying attention to this. I have some
comments inline and lets see whether we can reach an agreement:

OK.

I've trimmed to a few points to comment on...

On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote:

1) 4566bis needs to provide ABNF syntax for all o= f the attributes 4566
defined.
Comments: This was discussed again in a side meet= ing in London and
there was not a consensus whether we actually needed this.

IIRC the argument against doing this is that we might get it wrong.

But IMO we should do it because if we can't get it right how can we
expect readers to get it right?

I personally don't wanna take on this task. It is a tedious task and I am n= ot
such an ABNF lover to get these definitions right. If you wanna volunteer, = by all
means, please do so.

I'm willing to contribute to this, but won't have time until after the Toro= nto
meeting.

That is fine.

Also, I'm not intimately familiar with all of the= attributes.

Nobody is I am afraid.

There are a lots of people who at least *use* them, and so are familiar wit= h
them at that level. I don't "do" media, so when I'm trying to cre= ate examples I
can get as far as "m=3Daudio", and I know there should be an &quo= t;a=3Drtpmap", but
beyond that I need to find an example to copy.

OK, this goes back to the issue #1. Personally, I= suggest we do not define the
abnfs for every sdp attribute in 4566, but then you have a good point. We c= an
seek a format and provide a few good examples to show prospective authors.<= br>

To do this, obviously as you said, we need to agree on that format. Has
there been a proposal in the past or does anyone have a good proposal to st= art
with?

Not a formal one. There has been some discussion about this during review
of individual attribute definitions. My take has been that there is not agr= eement.

If you can recall, can you point us to that proposal and maybe briefly expl= ain
the disagreements as well?

I think it will take a lot of searching to find it. So I can't do so quickl= y/easily.

One question is whether the definition of a new a= ttribute should:
1) define the full syntax of the line (starting with "a=3D"),
2) should provide additional definitions of <attribute> (via "/= =3D")
3) should provide additional definitions of <att-field> and <att-v= alue>
 (via "/=3D")
4) provide definitions of the name and value that are consistent with
 <att-field> and <att-value> without formally extending th= e
 definitions of those.

Note that 4566 loosely follows (4) but gives the definitions informally rat= her
than via ABNF. So it gives no guidance on how to use ABNF for this. A numbe= r of
drafts have chosen to follow (2). Some have started to do (1) but I don't k= now of
any that ended up that way.

A question I have raised is: if (2) or (3) is followed, does that mean that= the
draft doing so must be considered as "updating" 4566?

I dont see why it should. Personally most of the attributes I defined follo= wed
(4). That seemed the easiest option.

I've been outnumbered on the discussions of this. ISTM that whenever I writ= e

attribute = =3D/ something new

then I have at least extended the rfc that defines <attribute> and ar= guably have
updated it. The reason it might be considered an update is that what I am defining implicitly includes the definition of <attribute> and thus p= robably all the
abnf that includes the definition of <attribute>. To verify my new ab= nf, or to
generate a parser, I need to create a combined abnf. And abnf doesn't have<= br> namespaces. So all the rulenames I newly define must be distinct from those=
defined with <attribute>.

And that is true for *every* extension. And for them to be compatible with = one
another they all must define rulenames that are unique among them all.

So effectively each one is an update.

It is subtly different if I follow (4), even if I use abnf to define the sy= ntax for my
new attribute, and even if I reuse rule definitions (like
<token>) from the base sdp definition.

One thing that people sometimes forget when defin= ing new attributes is that
the syntax of the new attribute MUST also be valid when parsed by the "= ;generic"
attribute syntax. AFAIK there is no way in ABNF to specify that. I think th= at (4)
comes closest.

Yes, but this must be checked during the last call by actual humans not som= e
abnf parser.

For now that is true. I have found such errors while doing SDP directorate<= br> reviews.

Thanks,
Paul

-acbegen


Thanks,
Paul


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


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

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


--_000_9D8A673745D244A584D1772754B6E861sverigesradiose_-- From nobody Wed Aug 6 06:43:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E70B1A8BB7 for ; Wed, 6 Aug 2014 06:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsFnJp--rgvM for ; Wed, 6 Aug 2014 06:42:58 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4491A8BB1 for ; Wed, 6 Aug 2014 06:42:58 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id bQSp1o0041HzFnQ59Riyrm; Wed, 06 Aug 2014 13:42:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id bRiv1o00h3ZTu2S3aRixYy; Wed, 06 Aug 2014 13:42:58 +0000 Message-ID: <53E230DF.3060104@alum.mit.edu> Date: Wed, 06 Aug 2014 09:42:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <53E0F464.3080600@alum.mit.edu> <53E11D12.4060803@alum.mit.edu> <27CEE70F-2CE0-4091-86D2-7BC1E6648A09@cisco.com> In-Reply-To: <27CEE70F-2CE0-4091-86D2-7BC1E6648A09@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407332578; bh=wW0WWl7hzjuuHOgGh/OJ0EjQigiL71PNE6m2ETujkJg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RxXHT9tY0QAfK4GwzCdZMqLagNws743AG+PNPpXQOnwB3DMs7X7D4pGsfaaz20dic HGUvJ+fSxDkuhmw7a5gSq9rPmyO1EJKVUr0xli2NEovtJdy1ubE54Ix0fGDKA9xpx0 TAlnQijLwid05w4Mzw6CYD/63KjuesKvuz+jCzVCsHsTGR/MXfooG5PUrk6N2RYAGR WnHzL8DpMYVWOKqDUQB65VvZ4wwOiF8BSudf7vyerQrhjEsNs0bqxHQJUkvRYfxCj6 HweadY+idzerzIGv33rRgpjFHsO2qaDv67yKhxRuXSQQN0b8RWAj/tLXhuPDXprNCs FOOAb4HPX3Hkg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/bga07rEd7LqbllUw1OETWeSWXfY Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 13:42:59 -0000 On 8/6/14 3:44 AM, Ali C. Begen (abegen) wrote: > I think errata 3795 should be accepted and we just make the clarification in the bis document (i.e., say "dont use just a column"). OK. > What is the process for reviving errata 3795? I don't know. From nobody Wed Aug 6 06:47:43 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FF61B2D42 for ; Wed, 6 Aug 2014 06:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.265 X-Spam-Level: ** X-Spam-Status: No, score=2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, MANGLED_TOOL=2.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ8KDKqWYXVu for ; Wed, 6 Aug 2014 06:47:37 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9E81B2D37 for ; Wed, 6 Aug 2014 06:47:37 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta08.westchester.pa.mail.comcast.net with comcast id bPRV1o0060mv7h058Rnd9m; Wed, 06 Aug 2014 13:47:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id bRnc1o00l3ZTu2S3XRnczq; Wed, 06 Aug 2014 13:47:37 +0000 Message-ID: <53E231F8.5080604@alum.mit.edu> Date: Wed, 06 Aug 2014 09:47:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <539263E2.8010802@alum.mit.edu> <281DBAD0-3E23-4F2C-ABD0-6F8D5CB47629@cisco.com> <53BAA873.6050907@alum.mit.edu> <53BAD9A0.6060304@alum.mit.edu> <6A5A8D4EF65AF1439301480747E29F434E42B417@STOEXMBX01.sr.se> <5BF924B8-20CB-4CB2-A152-B49ED07651CD@cisco.com> <9D8A6737-45D2-44A5-84D1-772754B6E861@sverigesradio.se> In-Reply-To: <9D8A6737-45D2-44A5-84D1-772754B6E861@sverigesradio.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407332857; bh=mrCvHK7zjZE6M5RvY2k+DvXIiSE2XVis30C//VEmBVg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UyOLc2Wtnr84XzAAmGIThkn5LdGB4beoBRTdoiBWP8ndjfCbIaD2Grs1UOttwHqZU hbPpRHBMs0ghpMNrI2zomaIcxTQ6gGxDP4lfGELy3OyKhCmtfhmIRNYOtqyTRqK6RA ki8zLAUVhRwED+HVQNinhFro7DyfJrMoUwNye4vnUoMywXYXIrnb7/CQ7NzUXZnbPZ VjDjZ/fLvNzRrey6lpemt1hTvHMK2jAYfOhuhjF42FGbpZTUY2r1Byh+yAocVJGShX maQZajZGFvrbyXhTuRNl9hRw0K+XGOPTKhBx2mhjBHC7tbRzi7654Wi/XzYu3ZuVuV wLRMpfjVwq+CQ== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/FP8NUfZow8N_SLDdQhNCv3ipkg4 Subject: Re: [MMUSIC] 4566bis outstanding issues - Send, receive asymmetry and port numbers X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 13:47:39 -0000 Fredrik, There is now a solution to your asymmetric use case, using the BUNDLE draft: draft-ietf-mmusic-sdp-bundle-negotiation-07. Thanks, Paul On 8/6/14 5:49 AM, Fredrik Bergholtz wrote: > The change, however, does not address the “same port” issue. Section > 5.14 of rfc 4566 states: “The semantics of multiple "m=" lines using the > same transport address are undefined.” The text is not perfectly clear > on what the “transport address” is, but it is implied that this is, in > fact the “port” number(s). My thinking is that this restriction is only > valid when the directionality of the media descriptions are the same. > > The following is an example of an asymmetrical SDP that might be used in > a radio broadcast use-case. From a reporter in the field, a reasonably > high audio quality is required but the return from the studio to the > reporter only need to be good enough for spoken cues. > > |v=0| > |o=mtu-02 3599993974 3599993974 IN IP4 example.com | > |s=mtu-02| > |c=IN IP4 203.0.113.12| > |t=0 0| > |m=audio 5004 RTP/AVP 96| > |a=rtpmap:96 aptx/32000/1| > |a=fmtp:96 variant=enhanced; bitresolution=24| > a=sendonly > |a=ptime:20| > m=audio 5004 RTP/AVP 9 > |a=rtpmap:9 G722/8000| > |a=recvonly| > > As I understand it, this SDP example would strictly have undefined > semantics even though I think that the semantics are very clear. > > I don’t have any concise candidate text that clarifies my points but I > could try to think of some if there are no technical issues with the > approach that I am unaware of. > > Best regards, > Fredrik Bergholtz > Swedish Radio > > P.S. I am not a native English speaker, so all my suggested text would > have to be validated. > > > > On 05 Aug 2014, at 16:32, Ali C. Begen (abegen) > wrote: > >> Hi Fredrik >> >> There were some changes in the bis document regarding these attributes >> in -08: >> http://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rfc4566bis-07&url2=draft-ietf-mmusic-rfc4566bis-08 >> >> Do they help with your issue? If not, what else would you like to see? >> >> >> I remember seeing a discussion regarding the use of the same port at >> some point but it was another draft (sorry I dont remember which one >> it was). >> >> -acbegen >> >> On Aug 5, 2014, at 3:35 PM, Fredrik Bergholtz >> wrote: >> >>> Hi. Excellent to see a summarised list of what is considered for 4566bis. >>> >>> Personally I would like to see ABNF definitions for all the >>> attributes. I do realise the amount of work that is needed but, as >>> someone else mentioned, the 4566 is the base line for all extensions >>> and I think that it is important to make the base as well-defined as >>> possible. >>> >>> One item that is not in your list that I would like to see is a >>> clarification of how to signal asymmetric sessions. By asymmetric >>> sessions I mean using the a=sendonly and a=recvonly in separate media >>> definitions, specifically addressing the "same port" issue of section >>> 5.14. >>> >>> I realise that this is a more use-case oriented addition than an >>> improvement of the examples for the various attributes that has been >>> discussed. Perhaps this kind of clarification belong in something >>> like rfc4317 rather than in 4566. Do you have any thoughts on if and >>> how such clarifications could and should be made? >>> >>> Best regards, >>> Fredrik Bergholtz >>> Swedish Radio >>> >>>> -----Original Message----- >>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: den 7 juli 2014 19:32 >>>> To: mmusic@ietf.org >>>> Subject: Re: [MMUSIC] 4566bis outstanding issues >>>> >>>> Trimming again. >>>> >>>> On 7/7/14 12:16 PM, Ali C. Begen (abegen) wrote: >>>>> >>>>> On Jul 7, 2014, at 11:02 PM, Paul Kyzivat >>>>> wrote: >>>>> >>>>>> On 7/7/14 4:07 AM, Ali C. Begen (abegen) wrote: >>>>>>> Hi Paul, >>>>>>> >>>>>>> OK, no one else seems to be paying attention to this. I have some >>>> comments inline and lets see whether we can reach an agreement: >>>>>> >>>>>> OK. >>>>>> >>>>>> I've trimmed to a few points to comment on... >>>>>> >>>>>>>>> On 6/6/14 5:19 PM, Ali C. Begen (abegen) wrote: >>>>>> >>>>>>>>>> 1) 4566bis needs to provide ABNF syntax for all of the >>>>>>>>>> attributes 4566 >>>> defined. >>>>>>>>>> Comments: This was discussed again in a side meeting in London and >>>> there was not a consensus whether we actually needed this. >>>>>>>>> >>>>>>>>> IIRC the argument against doing this is that we might get it wrong. >>>>>>>>> >>>>>>>>> But IMO we should do it because if we can't get it right how can we >>>> expect readers to get it right? >>>>>>> >>>>>>> I personally don't wanna take on this task. It is a tedious task >>>>>>> and I am not >>>> such an ABNF lover to get these definitions right. If you wanna >>>> volunteer, by all >>>> means, please do so. >>>>>> >>>>>> I'm willing to contribute to this, but won't have time until after >>>>>> the Toronto >>>> meeting. >>>>> >>>>> That is fine. >>>>> >>>>>> Also, I'm not intimately familiar with all of the attributes. >>>>> >>>>> Nobody is I am afraid. >>>> >>>> There are a lots of people who at least *use* them, and so are >>>> familiar with >>>> them at that level. I don't "do" media, so when I'm trying to create >>>> examples I >>>> can get as far as "m=audio", and I know there should be an >>>> "a=rtpmap", but >>>> beyond that I need to find an example to copy. >>>> >>>>>>> OK, this goes back to the issue #1. Personally, I suggest we do >>>>>>> not define the >>>> abnfs for every sdp attribute in 4566, but then you have a good >>>> point. We can >>>> seek a format and provide a few good examples to show prospective >>>> authors. >>>>>>> >>>>>>> To do this, obviously as you said, we need to agree on that >>>>>>> format. Has >>>> there been a proposal in the past or does anyone have a good >>>> proposal to start >>>> with? >>>>>> >>>>>> Not a formal one. There has been some discussion about this during >>>>>> review >>>> of individual attribute definitions. My take has been that there is >>>> not agreement. >>>>> >>>>> If you can recall, can you point us to that proposal and maybe >>>>> briefly explain >>>> the disagreements as well? >>>> >>>> I think it will take a lot of searching to find it. So I can't do so >>>> quickly/easily. >>>> >>>>>> One question is whether the definition of a new attribute should: >>>>>> 1) define the full syntax of the line (starting with "a="), >>>>>> 2) should provide additional definitions of (via "/=") >>>>>> 3) should provide additional definitions of and >>>>>> >>>>>> (via "/=") >>>>>> 4) provide definitions of the name and value that are consistent with >>>>>> and without formally extending the >>>>>> definitions of those. >>>>>> >>>>>> Note that 4566 loosely follows (4) but gives the definitions >>>>>> informally rather >>>> than via ABNF. So it gives no guidance on how to use ABNF for this. >>>> A number of >>>> drafts have chosen to follow (2). Some have started to do (1) but I >>>> don't know of >>>> any that ended up that way. >>>>>> >>>>>> A question I have raised is: if (2) or (3) is followed, does that >>>>>> mean that the >>>> draft doing so must be considered as "updating" 4566? >>>>> >>>>> I dont see why it should. Personally most of the attributes I >>>>> defined followed >>>> (4). That seemed the easiest option. >>>> >>>> I've been outnumbered on the discussions of this. ISTM that whenever >>>> I write >>>> >>>> attribute =/ something new >>>> >>>> then I have at least extended the rfc that defines and >>>> arguably have >>>> updated it. The reason it might be considered an update is that what >>>> I am >>>> defining implicitly includes the definition of and thus >>>> probably all the >>>> abnf that includes the definition of . To verify my new >>>> abnf, or to >>>> generate a parser, I need to create a combined abnf. And abnf >>>> doesn't have >>>> namespaces. So all the rulenames I newly define must be distinct >>>> from those >>>> defined with . >>>> >>>> And that is true for *every* extension. And for them to be >>>> compatible with one >>>> another they all must define rulenames that are unique among them all. >>>> >>>> So effectively each one is an update. >>>> >>>> It is subtly different if I follow (4), even if I use abnf to define >>>> the syntax for my >>>> new attribute, and even if I reuse rule definitions (like >>>> ) from the base sdp definition. >>>> >>>>>> One thing that people sometimes forget when defining new >>>>>> attributes is that >>>> the syntax of the new attribute MUST also be valid when parsed by >>>> the "generic" >>>> attribute syntax. AFAIK there is no way in ABNF to specify that. I >>>> think that (4) >>>> comes closest. >>>>> >>>>> Yes, but this must be checked during the last call by actual humans >>>>> not some >>>> abnf parser. >>>> >>>> For now that is true. I have found such errors while doing SDP >>>> directorate >>>> reviews. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> -acbegen >>>>> >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>> >>>>> _______________________________________________ >>>>> mmusic mailing list >>>>> mmusic@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Aug 6 07:18:06 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F611B27D0 for ; Wed, 6 Aug 2014 07:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOqnt0ksnQJI for ; Wed, 6 Aug 2014 07:18:02 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB41B28C1 for ; Wed, 6 Aug 2014 07:18:01 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id bRZv1o0071ZXKqc5DSJ1kC; Wed, 06 Aug 2014 14:18:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id bSJ01o0123ZTu2S3hSJ0WL; Wed, 06 Aug 2014 14:18:01 +0000 Message-ID: <53E23918.7090505@alum.mit.edu> Date: Wed, 06 Aug 2014 10:18:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Colin Perkins References: <53E0FCCA.9000404@alum.mit.edu> <2F623547-498A-4A23-BEF2-AB5308BC2215@csperkins.org> In-Reply-To: <2F623547-498A-4A23-BEF2-AB5308BC2215@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407334681; bh=NjiAYF5GXwYzyfUmC2hJ8TdxwpY7wHBaq4105XK9rMg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XkqSR5LduvpbqX0xJ0JcrQsIwpaH0NZeQzBjk3+sHKDMYjS9doMfgLniMuRKHw5Lo Vs9UT+P+WTgoOe0+5/+1+eOK6BJomEzYc4fjzdlCltz2EPiyylRQPakUwpmYkhubOd QcPIKRPU6yw/+O5kWqNr1HQihsiwyVdDmBLmp5LFuz/h+Ac0m41rUgh5GSOsqa7cLT LzR2JF5baDhu7mjFnR0pMG5a3HkDugqHiOjkq7YzEtvOH+DxHTezzFqr5E4P2ppPaq IjZUXaHcn7QWeoHatoMAGyOEcPUMtGuQhHjHylsnXsTZvD4EIJUj817ZSz3gTrGSqB SSWK9geF1+rvA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/21-i0AZ4u3BCpPQBo0DbM4RpqBE Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] QUERY: info about a=cat, a=keywds, a=tool X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:18:04 -0000 On 8/6/14 5:48 AM, Colin Perkins wrote: > Paul, > > I think these come from the Mbone tools (Van Jacobson’s sd and Mark Handley’s sdr), which used the combination of SDP and the Session Announcement Protocol (SAP) for multicast session directories, TV guide-style. > > The a=tool: attribute was introduced in draft-ietf-mmusic-sdp-03; the others are both in http://tools.ietf.org/id/draft-ietf-mmusic-sdp-01.txt (draft-ietf-mmusic-sdp-00 is missing from the archive). Mark Handley’s slides from the MMUSIC meeting at IETF 33 have some details ftp://ftp.ietf.org/ietf-online-proceedings/95jul/area.and.wg.reports/tsv/mmusic/mmusic.handley.slides.ps Thanks for the pointers. From the slides: a=cat: * dot separated hierarchical category (similar to usenet news groups) * Experimental - hence not a field in its own right. * Need to sort out first level of hierarchy! * Is it any use if not compulsory? * Can have several cat attributes a=keywds: * a space separated list of keywords * Experimental - hence not a field in its own right. * Can only have one keywds attribute Nothing about a=tools in those slides. The above gives some insight, but I don't know if it is enough to nail down a syntax more specific that byte-string without running the risk of breaking something. If I were to hazard a guess, it would be: cat-value = token keywds-value = single-keywd *(SP single-keywd) single-keywd = non-ws-string Since allows dot, it can represent a dot separated hierarchical category for cat, while being fairly lenient. (But only ascii graphics.) Using is hopefully lenient enough to cover the intent. Thanks, Paul > Colin > > > > > On 5 Aug 2014, at 16:48, Paul Kyzivat wrote: >> I volunteered to draft ABNF syntax for the attributes defined in RFC4566 (SDP). >> >> There are some that I have very little information about: >> >> a=cat: >> a=keywds: >> a=tool: >> >> They have all been in SDP since RFC2327 in 1998. And I don't think I have ever seen any of them used. I did a google search over ietf.org looking for usages without luck. And they are all very vague about their syntax. >> >> The safe answer is to just define the value syntax for each of then as . But at least for a=cat the value (category) is specified as "dot-separated hierarchical category", so it seems reasonable that the syntax ought to involve dots in some way. >> >> Perhaps these should all be deprecated. >> >> Is there anybody still here who remembers when these were defined, and what the expectations were about the syntax? >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > From nobody Wed Aug 6 07:20:31 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96691B27D0 for ; Wed, 6 Aug 2014 07:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.265 X-Spam-Level: X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGOSbRkjulGY for ; Wed, 6 Aug 2014 07:20:30 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id BB3A51A034E for ; Wed, 6 Aug 2014 07:20:29 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id bS0d1o0061ZXKqc54SLVMD; Wed, 06 Aug 2014 14:20:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id bSLV1o0033ZTu2S3hSLVuS; Wed, 06 Aug 2014 14:20:29 +0000 Message-ID: <53E239AC.1060307@alum.mit.edu> Date: Wed, 06 Aug 2014 10:20:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= References: <53E0FCCA.9000404@alum.mit.edu> <7f0eb8bbeb1b60ffb2521d5758470a6b@roundcube.remlab.net> In-Reply-To: <7f0eb8bbeb1b60ffb2521d5758470a6b@roundcube.remlab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407334829; bh=GDcfoaj9ZFhyHDKW5t8oUZRN+QftFgT7FsHk2Un+t+A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=V972pDux0EX02YRYgU8XaiB38s5y/95zmJ3vaxiNbLsNuz4t6tPVYPyXQG0h7aGzB DK4G4l2Ax5N5dZaY3dxa1PwWnz9rO3Hm1cOrRbbkYfbVVCp7URJ2nQ3Ec/uEKfTpr4 lcW/qNyLiqJoaLPbvQ2cAesviFAd5SZj+xbtI70lWRNFxjIdvD4GgnUPtN4xfXGr8I IN6BOkCCUmXlYG/m91BKPww+ffqliA3miwGX2gr+gGlB8Qdwrb6sGeKFcYEHZibYQN c2XN3zv8sClisV1C6lZGlPMm2yVngjlofZeyqSYK/XOKx1zl2v5yki6H+ReZPmrSFK L8XJPSZ6Lmo6A== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/gsdNFcWqR9IgCQ_hQuZsv2WmTgo Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] QUERY: info about a=cat, a=keywds, a=tool X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:20:31 -0000 On 8/6/14 7:01 AM, Rémi Denis-Courmont wrote: > VLC uses a=tool and a=cat. The dot separator is handled. Of course, tool > can be replaced with User-Agent and Server headers in the case of SIP > and RTSP, but that just does not fly in the case of SAP. So please keep > them. > > Ideally, a=tool would use the User-Agent syntax, but it's too late. Just > leave it as free form. And anyway, the User-Agent syntax is violated as > often as it's respected. OK. I am inclined to define the value for tools as , which is as flexible as it can be. Thanks, Paul From nobody Wed Aug 6 07:27:03 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBC21B27D3 for ; Wed, 6 Aug 2014 07:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhMotIImYsNQ for ; Wed, 6 Aug 2014 07:27:01 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E741B27CF for ; Wed, 6 Aug 2014 07:27:01 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so4105572vcb.36 for ; Wed, 06 Aug 2014 07:27:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=9ItQfI8n+5zYbJSUTX1u8vdLFH+SjqOC486eBObIcBk=; b=SGtKpuN2YIccYWx37Wh3HqW1LHIo0vqMM+fQT28bf/jwbu1BVI2y8qk0Rwk5gYOa1Y rVZe1kHGHBTk1iBS1QX1OKxm9cvkwhNulbRk1MwuBujaEiYgiAgE7FGJ5PYugPE9LynW 49Gy8RBYLcrEj5TfgPJjB8N2W1y2w+9Ny/aTl3u1UCX4s3C1FYd2BCsbljLKoqwPk0ju 0ze03dPG1PxEfY9fMiSRwFDqJJAS5QbNVtkjMPK7uwPPPbmMPIz/ZWGs2o8+cOFlTnKk UtAzR5tTmyJJBW3SYuZI4RMbq8JpvJLBtQaOEx14KesEeaNCDgjA10pqnDU5cT/FDrLg 00cA== X-Gm-Message-State: ALoCoQksaT6CuAtPJCcosUV8CbdjempdE0nfwfdBAm+/v3KFLy19/6qHOdQIaAodRxRUiuKkRzd8 X-Received: by 10.221.24.7 with SMTP id rc7mr1246015vcb.54.1407335220371; Wed, 06 Aug 2014 07:27:00 -0700 (PDT) From: Brett Tate References: <53E0F464.3080600@alum.mit.edu> <53E11D12.4060803@alum.mit.edu> <27CEE70F-2CE0-4091-86D2-7BC1E6648A09@cisco.com> <53E230DF.3060104@alum.mit.edu> In-Reply-To: <53E230DF.3060104@alum.mit.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGOoE2KbpIxOGP3Is83t9nwJAFlDAGQHQwOAp4eurADHyl6xwHq9xjYAea7LuGb7L/SQA== Date: Wed, 6 Aug 2014 10:26:58 -0400 Message-ID: To: Paul Kyzivat , "Ali C. Begen (abegen)" , sjames@genband.com, mmusic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/AceZxtDrTs0VfCpGRwkJzkwEbTU Subject: Re: [MMUSIC] draft-ietf-mmusic-rfc4566bis-10: can attributes have a null value X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:27:03 -0000 > > What is the process for reviving errata 3795? > > I don't know. The status is Reported which means "reported but is unverified". http://www.rfc-editor.org/status_type_desc.html I sent an email to the avt list to attempt to initiate discussion. http://www.ietf.org/mail-archive/web/avt/current/msg16320.html I'm not sure if any off list discussion has occurred concerning RFC 3611 errata 3795. Stephan might know. Thanks, Brett From nobody Wed Aug 6 07:50:55 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD881B2A4A for ; Wed, 6 Aug 2014 07:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVE8Ef4qVNP2 for ; Wed, 6 Aug 2014 07:50:51 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id CF28A1A0053 for ; Wed, 6 Aug 2014 07:50:50 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id bQrt1o0050bG4ec55Sqqp9; Wed, 06 Aug 2014 14:50:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id bSqp1o00h3ZTu2S3PSqpZW; Wed, 06 Aug 2014 14:50:50 +0000 Message-ID: <53E240C9.60305@alum.mit.edu> Date: Wed, 06 Aug 2014 10:50:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407336650; bh=08TLsb0YWORpIUoEEq2m8wVPx9yK8IwwLkEftHzvJCc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kf9Q3oZO56p9qnG0uCBASN9wgM40oxN2cWXqxp5o0j84lKnPVpBjwQy+MBZwiH2vj wEBCAB9TOHE1HJoihXzh60FmYI0w1sgG5Mlb35aJb01ciEvlDcXwkMpzHWiK5bsah1 LEmaLBrxoF1DjBgMtA9Vm4JXYYT5sOo4rtOX4p/daWSdtsmy16l555dgKTkGMKh28C 5ak1rgQb2kRH4bswKQbyYcnT71pRJZvLP8QrELHFNse6J+K7+pQL5UueimA6DwW4wD T6By4lfSgBph59D45hrvQTt90zPS0M4mFrxKZqIRq+BwELO3uvvXVdAk4NkwPDCQ0s JgNQZi+A9f8kg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/bE0J0u_H0pryblHOOTD8CWOHfhk Subject: [MMUSIC] QUERY: are SDP attributes case sensitive? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:50:53 -0000 While thinking about how to give syntax for SDP attributes, I realized that it is not entirely clear whether SDP attribute names are intended to be case sensitive or not. 4566 says: An SDP session description consists of a number of lines of text of the form: = where MUST be exactly one case-significant character and is structured text whose format depends on . In general, is either a number of fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. Whitespace MUST NOT be used on either side of the "=" sign. And I find nothing stating that attributes are case sensitive. This is fine for attributes that are defined informally - they don't say anything to imply that attribute names are case insensitive. But it is a problem for those defined using ABNF. For example, consider the following definition from RFC5888: group-attribute = "a=group:" semantics *(SP identification-tag) semantics = "LS" / "FID" / semantics-extension semantics-extension = token ; token is defined in RFC 4566 ABNF says that matching against rules containing quoted strings is case-insensitive. So the above considers all of the following to be valid: a=group:ls A=GROUP:LS a=Group:Ls The SDP spec disallows the 'A=', but maybe not the others. If you want to specify a case-sensitive string constant in ABNF you must do so by specifying each byte numerically. That isn't very convenient or readable. (We do it for SIP method names, and I hate it.) A straightforward solution to this is to only specify the attribute *values* with ABNF, not the *names*. Specify the names independently, and note that they are case sensitive. But that won't help for those that have already been defined in other drafts using ABNF and quoted strings. What I really want to avoid is saying that we are defining syntax using ABNF, but that *our* ABNF treats quoted strings in a case-sensitive way. If that is what we want, then we should try to get an upgrade to ABNF to support both case-sensitive and case-insensitive strings. For *values*, if they are already defined in ABNF, then case sensitivity is as defined by ABNF. We might have to be very careful about this when defining the syntax for the attributes defined in 4566. A couple of questions: 1) does anybody think attribute *names* are/should-be case-*in*sensitive? 2) does anybody think that the ABNF *values* currently defined in ABNF (such as the example from 5888 above) are intended to be matched in a case-*sensitive* way in violation of the ABNF matching rules? Thanks, Paul From nobody Fri Aug 8 03:49:57 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C171B2A8E for ; Fri, 8 Aug 2014 03:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEyL4BWMvlkT for ; Fri, 8 Aug 2014 03:49:54 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B451B2A6A for ; Fri, 8 Aug 2014 03:49:54 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so7117873pab.15 for ; Fri, 08 Aug 2014 03:49:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=KA8T3Y32r2vsiNvb7vpGESSRL8a82NQsLMzMHQUe9dQ=; b=jOWgMJHPWZ18EFhvRnXOiJdtNzK8VmlKW1Pw+LY6uE91d7NDD1aWfTJrypOZYsE8NW pP7W8CKGOd3Z4mdCrogqTeiJppFIRH+RBWdhdWktOatt5C1aRAxwf3tjihdZIyqnk5oB npcNR0N57oIj4j4iCvW7inaaUsrE33fg0as2JPJSquHSTZ4rx5fUDEMSrhCrUx4sp76z w4fUbUkFcPLUi4FTocOMd3ZzpyARc1OXowd2CmTajlHqw0n8P1BVAaVLdcXapC7GJcUF GiZO2efTNE6QCyuR+i+qvmNnv/iDkur/40ETyz6xYCDU/nr10GPzxP6iguguV3uFciGx GVUg== X-Gm-Message-State: ALoCoQnr2RmjNezF6aO70zIagudR52GfDv3Tfqt0aYLQbYKbjE83byyPhv/dztT/2xmlgY31BP7F X-Received: by 10.70.64.225 with SMTP id r1mr333820pds.167.1407494994055; Fri, 08 Aug 2014 03:49:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Fri, 8 Aug 2014 03:49:34 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 8 Aug 2014 12:49:34 +0200 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/V9xjVDbbeiElj2M_a3c5_6x-_b8 Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 10:49:55 -0000 2014-07-31 21:08 GMT+02:00 Justin Uberti : > As discussed earlier, DTLS does not require a separate context for each > tuple. DTLS should be agnostic about the lower layer protocol (and we sho= uld > probably create an errata to resolve this confusion). Hi Justin, I agree with that (and I like that), but Chrome does not behave in that way. My experiment: - The server gives a UDP and TCP candidate to Chrome. - Chrome nominates UDP (ICE stuff), sends the DTLS handshake and then media= . - Later the server closes its UDP socket, so STUN requests from Chrome are not replied. - At some point Chrome decides to open a TCP connection with the TCP candidate. It also sends ICE stuff (OK). - The problem: Chrome *sends* a new DTLS handshake over the new TCP connect= ion. This is wrong since the server already has a *working* and *established* DTLS session (which as you say MUST be transport agnostic), so the new DTLS HelloClient is ignored by the DTLS machinery at server side and thus, media is never sent. IMHO Chrome should not attempt a new DTLS handshake given that it was already done before over the "ICE virtual socket". You opinion please? BTW: Let me know if you want me to open a bug report, but I would love having this clear :) --=20 I=C3=B1aki Baz Castillo From nobody Fri Aug 8 04:21:26 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819941B2A4E for ; Fri, 8 Aug 2014 04:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IBfqLDgfNHh for ; Fri, 8 Aug 2014 04:21:22 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA121A02D1 for ; Fri, 8 Aug 2014 04:21:22 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id ty20so4551177lab.32 for ; Fri, 08 Aug 2014 04:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gzWICJYn14xMmbFiqMcNqHQHavvdADKvPCUhpmSBnxA=; b=f9w6kp1+Y/72UFQMRqgwyg33d323V/HbYqe9DtVlUUvSGTpobfnR3SFAUoJga6heTT jcGqk7fZlbNWa/iPF/0MDxlpeddQLGgNgWW1k2u5mgPOMZl+sf3Z0fM6/d9Zo9akUAon 0C2kOEB4FUSx7viCYuZfLSAjTIDlkhivDSmmEQNdweof1eJtRsd2p4JBqiFcZJwpoAMq jU1GJ3H1yqUIdFjG6HPxYeuY0wSYz5ItqeOzNOq7jZLivhipGIFK/1JBUkbicSc1Dv7e h2GcSmbvTCCvmnmLliS9zgn/rHexmcP3L36cLmWsjrBn2LAFiaewXqEZSpqqIaZ550Wb O5nw== MIME-Version: 1.0 X-Received: by 10.152.87.34 with SMTP id u2mr21957036laz.12.1407496880520; Fri, 08 Aug 2014 04:21:20 -0700 (PDT) Received: by 10.114.23.36 with HTTP; Fri, 8 Aug 2014 04:21:20 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> Date: Fri, 8 Aug 2014 12:21:20 +0100 Message-ID: From: Kevin Dempsey To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c237c696038c05001c6728 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/8mOm1jrvJDbpSFrUwiASty0IeSo Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 11:21:24 -0000 --001a11c237c696038c05001c6728 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Does the new TCP connection require an ICE restart? If so, then I think an new DTLS handshake (and fingerprint check) should be required as the server may not be connected to the same endpoint anymore. On 8 August 2014 11:49, I=C3=B1aki Baz Castillo wrote: > 2014-07-31 21:08 GMT+02:00 Justin Uberti : > > As discussed earlier, DTLS does not require a separate context for each > > tuple. DTLS should be agnostic about the lower layer protocol (and we > should > > probably create an errata to resolve this confusion). > > Hi Justin, I agree with that (and I like that), but Chrome does not > behave in that way. My experiment: > > - The server gives a UDP and TCP candidate to Chrome. > > - Chrome nominates UDP (ICE stuff), sends the DTLS handshake and then > media. > > - Later the server closes its UDP socket, so STUN requests from Chrome > are not replied. > > - At some point Chrome decides to open a TCP connection with the TCP > candidate. It also sends ICE stuff (OK). > > - The problem: Chrome *sends* a new DTLS handshake over the new TCP > connection. > > This is wrong since the server already has a *working* and > *established* DTLS session (which as you say MUST be transport > agnostic), so the new DTLS HelloClient is ignored by the DTLS > machinery at server side and thus, media is never sent. > > > IMHO Chrome should not attempt a new DTLS handshake given that it was > already done before over the "ICE virtual socket". You opinion please? > > BTW: Let me know if you want me to open a bug report, but I would love > having this clear :) > > > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11c237c696038c05001c6728 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Does the new TCP connection require an ICE restart? If so,= then I think an new DTLS handshake (and fingerprint check) should be requi= red as the server may not be connected to the same endpoint anymore.=C2=A0<= /div>


On 8 August 2= 014 11:49, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
2014-07-31 21:08 GMT+02:00 Justin Uberti <juberti@google.com>:
> As discussed earlier, DTLS does not require a separate= context for each
> tuple. DTLS should be agnostic about the lower layer protocol (and we = should
> probably create an errata to resolve this confusion).

Hi Justin, I agree with that (and I like that), but Chrome does not behave in that way. My experiment:

- The server gives a UDP and TCP candidate to Chrome.

- Chrome nominates UDP (ICE stuff), sends the DTLS handshake and then media= .

- Later the server closes its UDP socket, so STUN requests from Chrome
are not replied.

- At some point Chrome decides to open a TCP connection with the TCP
candidate. It also sends ICE stuff (OK).

- The problem: Chrome *sends* a new DTLS handshake over the new TCP connect= ion.

This is wrong since the server already has a *working* and
*established* DTLS session (which as you say MUST be transport
agnostic), so the new DTLS HelloClient is ignored by the DTLS
machinery at server side and thus, media is never sent.


IMHO Chrome should not attempt a new DTLS handshake given that it was
already done before over the "ICE virtual socket". You opinion pl= ease?

BTW: Let me know if you want me to open a bug report, but I would love
having this clear :)




--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

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

--001a11c237c696038c05001c6728-- From nobody Fri Aug 8 04:29:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920801B2ADF for ; Fri, 8 Aug 2014 04:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTFmKXnTxtkd for ; Fri, 8 Aug 2014 04:29:39 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AB21B2A6B for ; Fri, 8 Aug 2014 04:29:39 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id v10so974208pde.38 for ; Fri, 08 Aug 2014 04:29:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=4vsx8y9ak+7Fp1fSwvIFsMDvB3gqpWFPIqKzzlys+qI=; b=RHzSl0okk6rdXwGPCIfNHhGU/vtIF5dpzrbaxCllT3DGdfmqtNNMpdi+mwV31Gtbyi mCM+UfsrqvGm3VUlwdZO/id3TBUKm2o5miOI2LcLm+ljeSVCRzcVr7uFv18sHX4kdd7C ojhCa5+3Rfskcw3U8OvBeXfN/uUfnZMfqwI1rHkvyE9SmdvH3/QYTeD9ae5SY6eEX81M +tr9p0BUiPqqlIULtinJAqgpFTkz8xDkLjSLRJNh+pd1mAGQY6B/MN5nC/Fxg4GRqbzx YBHE3nJMYdqTUNjINMXNm90qdV6OXDEKqwyXiEJqRmBxjSOGHu/KsbmDwBvZPOxq8K7/ kgXA== X-Gm-Message-State: ALoCoQkK5eKiIbIUC23kDr+CVcMyAOlkynDZ/lI7xGLcillvWnudzpHpCffa1aGwRwLtM5bXTVc9 X-Received: by 10.68.213.34 with SMTP id np2mr541895pbc.167.1407497378735; Fri, 08 Aug 2014 04:29:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Fri, 8 Aug 2014 04:29:18 -0700 (PDT) In-Reply-To: References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 8 Aug 2014 13:29:18 +0200 Message-ID: To: Kevin Dempsey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DjkBKdr3GCnOiaFacMkwhCpFudg Cc: Jonathan Lennox , mmusic Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 11:29:40 -0000 2014-08-08 13:21 GMT+02:00 Kevin Dempsey : > Does the new TCP connection require an ICE restart? If so, then I think a= n > new DTLS handshake (and fingerprint check) should be required as the serv= er > may not be connected to the same endpoint anymore. Why is ICE restart required at all? We are stating that ICE is a virtual socket regardless how many valid pairs (UDP or TCP) it handles. The peer can send media (so also DTLS) over any of those valid pairs at any time without requiring ICE restart (am I wrong?). My scenario is a good example of how good ICE can be by itself, without requiring "restart" or a new SDP O/A signaling. Upon TCP disconnection there is no need to perform a new DTLS handshake since the "ICE virtual socket" was still open and both Chrome and the server have already agreed on which layer 4 tuples can be used to carry media and DTLS stuff is done. Both peers should be able to change the valid pair at any time without requiring signaling or ICE restart. NOTE: Issue open in Chrome: https://code.google.com/p/chromium/issues/detail?id=3D401923 > On 8 August 2014 11:49, I=C3=B1aki Baz Castillo wrote: >> >> 2014-07-31 21:08 GMT+02:00 Justin Uberti : >> > As discussed earlier, DTLS does not require a separate context for eac= h >> > tuple. DTLS should be agnostic about the lower layer protocol (and we >> > should >> > probably create an errata to resolve this confusion). >> >> Hi Justin, I agree with that (and I like that), but Chrome does not >> behave in that way. My experiment: >> >> - The server gives a UDP and TCP candidate to Chrome. >> >> - Chrome nominates UDP (ICE stuff), sends the DTLS handshake and then >> media. >> >> - Later the server closes its UDP socket, so STUN requests from Chrome >> are not replied. >> >> - At some point Chrome decides to open a TCP connection with the TCP >> candidate. It also sends ICE stuff (OK). >> >> - The problem: Chrome *sends* a new DTLS handshake over the new TCP >> connection. >> >> This is wrong since the server already has a *working* and >> *established* DTLS session (which as you say MUST be transport >> agnostic), so the new DTLS HelloClient is ignored by the DTLS >> machinery at server side and thus, media is never sent. >> >> >> IMHO Chrome should not attempt a new DTLS handshake given that it was >> already done before over the "ICE virtual socket". You opinion please? >> >> BTW: Let me know if you want me to open a bug report, but I would love >> having this clear :) >> >> >> >> >> -- >> I=C3=B1aki Baz Castillo >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > --=20 I=C3=B1aki Baz Castillo From nobody Sat Aug 9 11:48:45 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A593D1A0196; Sat, 9 Aug 2014 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSQSEH-718yU; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C66561A0009; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s79ImD3G015211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Aug 2014 13:48:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Sat, 9 Aug 2014 13:48:13 -0500 X-Mao-Original-Outgoing-Id: 429302893.093861-e61d2b4180cda6697e5d18b3ca4c2570 Content-Transfer-Encoding: quoted-printable Message-Id: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: To: tsvwg@ietf.org, avt@ietf.org, "clue@ietf.org" , mmusic@ietf.org, rtcweb@ietf.org, rmcat@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/tcdl4px9VoAoj7uQYPZ4ScFFTE0 Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org Subject: [MMUSIC] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 18:48:24 -0000 Hi, The DART working group has started a last call for = draft-ietf-dart-dscp-rtp-02, ending on August 22. This informational = draft describes considerations for the use of DiffServ code points in = situations where one multiplexes multiple RTP packet streams, and = potentially other protocol streams, that share the same 5-tuple.=20 Since this draft is likely of interest to several working groups, I = would like to solicit additional reviews from participants of TSVWG, = AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback = (including feedback to the effect of "this is ready to progress") to the = DART working group mailing list. Thanks! Ben. Begin forwarded message: > Resent-From: draft-alias-bounces@tools.ietf.org > From: Ben Campbell > Subject: WGLC: draft-ietf-dart-dscp-rtp-02 > Date: August 9, 2014 at 12:50:16 PM CDT > Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com > To: dart@ietf.org > Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, = Richard Barnes >=20 > This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. = It's available on the data tracker at the following URL: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > The WGLC will conclude on 22 August, 2014. Please send your comments = to the authors and the DART mailing list. If you've reviewed it and = think it's good to go, please say so. >=20 > Thanks! >=20 > Ben. >=20 From nobody Mon Aug 11 15:10:20 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB161A01EA for ; Mon, 11 Aug 2014 15:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.865 X-Spam-Level: **** X-Spam-Status: No, score=4.865 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94EO6w1huItF for ; Mon, 11 Aug 2014 15:10:03 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id D15DD1A01D9 for ; Mon, 11 Aug 2014 15:10:02 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id dZxk1o0011GhbT857aA2LH; Mon, 11 Aug 2014 22:10:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id daA11o00Q3ZTu2S3TaA110; Mon, 11 Aug 2014 22:10:02 +0000 Message-ID: <53E93F39.5090401@alum.mit.edu> Date: Mon, 11 Aug 2014 18:10:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: multipart/mixed; boundary="------------040505090206040906010206" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407795002; bh=Q/IHQibNv5kHlOnXfKYnjPiVT4knuNSezfCGCKKORiY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=murhnQDLsPbHFoUUHOM6fIvyKF5uagFG6Hba9ik6OsqJrDIDITm88oGyPhtqV8BGC XtMrwVFl0BEGXSeYgNlOWXuoX2Utm0fduZqJ38N8+nvWX9EfRSX1+L4Ih7rgE2isxe W9+9k5l3S9T9ep1UKtgS0A/K8UmVE9JUrOqHVj0kjw+RVRi3x481v/xpCMPvESa1CC E640Si40AGvOOJQYqmFhMltzX1n+1JVfJaI2j+s0ZkgWwiIZwbK395CgKnNavinGSy QWwLcfzlAAJ9j5GoxmnY7q2PHsNg2Eky09s2choqcy1xFtdnGXzgLnJyuFLqou7Mml 5VyI5RY/e8nYg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CqBEDMdT5Y9fXRzoqTCfsbSS45E Subject: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 22:10:10 -0000 This is a multi-part message in MIME format. --------------040505090206040906010206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I took an action item to make a proposal for the syntax of attributes in 4566bis. I've *started* on it, and have enough that I would like to get some feedback before going further. Attached is a snippet from section 6 of 4566bis (SDP Attributes) to which I have added some ABNF syntax for just the values. (Each addition starts with "Syntax:") This isn't necessarily the *form* it will take when done. For now what I'm looking for is feedback on the substance. Of particular concern - when the format has text values, should those be case-sensitive (the default for SDP), or case-insensitive? I think we need to sort this out by what the common usage is. Thanks, Paul --------------040505090206040906010206 Content-Type: text/plain; charset=UTF-8; name="rfc4566bis-attributes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rfc4566bis-attributes.txt" a=cat: This attribute gives the dot-separated hierarchical category of the session. This is to enable a receiver to filter unwanted sessions by category. There is no central registry of categories. It is a session-level attribute, and it is not dependent on charset. Syntax: cat-value = category category = byte-string ; OR category = token ; Note: syntax is vague because deployed usage is not understood a=keywds: Like the cat attribute, this is to assist identifying wanted sessions at the receiver. This allows a receiver to select interesting session based on keywords describing the purpose of the session; there is no central registry of keywords. It is a session-level attribute. It is a charset-dependent attribute, meaning that its value should be interpreted in the charset specified for the session description if one is specified, or by default in ISO 10646/UTF-8. Syntax: keywds-value = keywords keywords = byte-string ; Note: syntax is vague because deployed usage is not understood a=tool: This gives the name and version number of the tool used to create the session description. It is a session-level attribute, and it is not dependent on charset. Syntax: tool-value = tool-name-and-version tool-name-and-version = byte-string ; Note: syntax is vague because deployed usage is not understood a=ptime: This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data, but may be used with other media types if it makes sense. It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetisation of audio. It is a media-level attribute, and it is not dependent on charset. Syntax: ptime-value = packet-time packet-time = integer ; do we want to define a limited range for this? a=maxptime: This gives the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. For frame-based codecs, the time SHOULD be an integer multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media-level attribute, and it is not dependent on charset. Note that this attribute was introduced after [RFC2327], and non-updated implementations will ignore this attribute. Syntax: maxptime-value = packet-time ; do we want to define a limited range for this? a=rtpmap: / [/] Syntax: rtpmap-value = payload-type SP encoding-name "/" clock-rate [ "/" encoding-params ] payload-type = integer encoding-name = token ; ? clock-rate = integer ; do we want to define a limited range for this? encoding-params = token ; ? ; 4566 is vague about what this can be. The only example is an integer. ; nor is it clear how multiple params would be encoded This attribute maps from an RTP payload type number (as used in an "m=" line) to an encoding name denoting the payload format to be used. It also provides information on the clock rate and encoding parameters. It is a media-level attribute that is not dependent on charset. Although an RTP profile may make static assignments of payload type numbers to payload formats, it is more common for that assignment to be done dynamically using "a=rtpmap:" attributes. As an example of a static payload type, consider u-law PCM coded single-channel audio sampled at 8 kHz. This is completely defined in the RTP Audio/Video profile as payload type 0, so there is no need for an "a=rtpmap:" attribute, and the media for such a stream sent to UDP port 49232 can be specified as: m=audio 49232 RTP/AVP 0 An example of a dynamic payload type is 16-bit linear encoded stereo audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP payload type 98 for this stream, additional information is required to decode it: m=audio 49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2 Up to one rtpmap attribute can be defined for each media format specified. Thus, we might have the following: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 RTP profiles that specify the use of dynamic payload types MUST define the set of valid encoding names and/or a means to register encoding names if that profile is to be used with SDP. The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for encoding names, under the top-level media type denoted in the "m=" line. In the example above, the media types are "audio/ l8" and "audio/l16". For audio streams, indicates the number of audio channels. This parameter is OPTIONAL and may be omitted if the number of channels is one, provided that no additional parameters are needed. For video streams, no encoding parameters are currently specified. Additional encoding parameters MAY be defined in the future, but codec-specific parameters SHOULD NOT be added. Parameters added to an "a=rtpmap:" attribute SHOULD only be those required for a session directory to make the choice of appropriate media to participate in a session. Codec-specific parameters should be added in other attributes (for example, "a=fmtp:"). Note: RTP audio formats typically do not include information about the number of samples per packet. If a non-default (as defined in the RTP Audio/Video Profile) packetisation is required, the "ptime" attribute is used as given above. a=recvonly, a=sendrecv, a=sendonly, a=inactive At most one of recvonly/sendrecv/sendonly/inactive MAY appear at session level, and at most one MAY appear in each media section. If any one of these appears in a media section then it applies for that media section. If none appear in a media section then the one from session level, if any, applies to that media section. If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present at either session level or media level, "sendrecv" SHOULD be assumed as the default for sessions that are not of the conference type "broadcast" or "H332" (see below). Within the following SDP example, the "inactive" attribute applies to audio media and the "recvonly" attribute applies to video media. v=0 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.1/127 t=2873397496 2873404696 a=inactive m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 a=recvonly a=recvonly This specifies that the tools should be started in receive-only mode where applicable. It can be either a session- or media- level attribute, and it is not dependent on charset. Note that recvonly applies to the media only, not to any associated control protocol (e.g., an RTP-based system in recvonly mode SHOULD still send RTCP packets). a=sendrecv This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools that default to receive-only mode. It can be either a session or media-level attribute, and it is not dependent on charset. a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session- or media-level attribute, but would normally only be used as a media attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal. a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system SHOULD still send RTCP, even if started inactive. It can be either a session or media-level attribute, and it is not dependent on charset. a=orient: Normally this is only used for a whiteboard or presentation tool. It specifies the orientation of a the workspace on the screen. It is a media-level attribute. Permitted values are "portrait", "landscape", and "seascape" (upside-down landscape). It is not dependent on charset. Syntax: orient-value = portrait / landscape / seascape portrait = %x70.6f.72.74.72.61.69.74 ; %s"portrait" landscape = %x6c.61.6e.64.73.63.61.70.65 ; %s"landscape" seascape = %x73.65.61.73.63.61.70.65 ; %s"seascape" ; Note: this assumes the intent was to be case-sensitive a=type: This specifies the type of the conference. Suggested values are "broadcast", "meeting", "moderated", "test", and "H332". "recvonly" should be the default for "type:broadcast" sessions, "type:meeting" should imply "sendrecv", and "type:moderated" should indicate the use of a floor control tool and that the media tools are started so as to mute new sites joining the conference. Specifying the attribute "type:H332" indicates that this loosely coupled session is part of an H.332 session as defined in the ITU H.332 specification [ITU.H332.1998]. Media tools should be started "recvonly". Specifying the attribute "type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users. The type attribute is a session-level attribute, and it is not dependent on charset. Syntax: type-value = conference-type conference-type = broadcast / meeting / moderated / test / H332 broadcast = %x62.72.6f.61.64.63.61.73.74 ; OR "broadcast" meeting = %x6d.65.65.74.69.6e.67 ; OR "meeting" moderated = %x6d.6f.64.65.72.61.74.65.64 ; OR "moderated" test = %x74.65.73.74 ; OR "test" H332 = %x48.33.33.32 ; OR "H332" ; NOTE: are these names intended to be case-sensitive? ; Should there be an extensibility hook? A registry? a=charset: Syntax: charset-value = iana-charset-preferred-mime-name iana-charset-preferred-mime-name = 1*40VCHAR ; Should we be using Preferred MIME Name or Name? ; Should SP be allowed in the name? The character set names may be up to 40 characters taken from the printable characters of US-ASCII This specifies the character set to be used to display the session name and information data. By default, the ISO-10646 character set in UTF-8 encoding is used. If a more compact representation is required, other character sets may be used. For example, the ISO 8859-1 is specified with the following SDP attribute: a=charset:ISO-8859-1 This is a session-level attribute and is not dependent on charset. The charset specified MUST be one of those registered with IANA, such as ISO-8859-1. The character set identifier is a US-ASCII string and MUST be compared against the IANA identifiers using a case-insensitive comparison. If the identifier is not recognised or not supported, all strings that are affected by it SHOULD be regarded as octet strings. Note that a character set specified MUST still prohibit the use of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring the use of these characters MUST define a quoting mechanism that prevents these bytes from appearing within text fields. a=sdplang: This can be a session-level attribute or a media-level attribute. Multiple sdplang attributes can be provided either at session or media level if the session description or media use multiple languages. As a session-level attribute, it specifies the language for the session description. As a media-level attribute, it specifies the language for any media-level SDP information field associated with that media, overriding any sdplang attributes specified at session-level. In general, sending session descriptions consisting of multiple languages is discouraged. Instead, multiple descriptions SHOULD be sent describing the session, one in each language. However, this is not possible with all transport mechanisms, and so multiple sdplang attributes are allowed although NOT RECOMMENDED. The "sdplang" attribute value must be a single [RFC5646] language tag in US-ASCII. It is not dependent on the charset attribute. An "sdplang" attribute SHOULD be specified when a session is distributed with sufficient scope to cross geographic boundaries, where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. Syntax: sdplang-value = Language-Tag ; defined in RFC5234 a=lang: This can be a session-level attribute or a media-level attribute. Multiple lang attributes can be provided either at session or media level if the session or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media, from most important to least important. As a session-level attribute, it specifies the default language for the session being described. As a media-level attribute, it specifies the language for that media, overriding any session-level languages specified. The "lang" attribute value must be a single [RFC5646] language tag in US-ASCII. It is not dependent on the charset attribute. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. Syntax: lang-value = Language-Tag ; defined in RFC5234 a=framerate: This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. Decimal representations of fractional values using the notation "." are allowed. It is a media-level attribute, defined only for video media, and it is not dependent on charset. Syntax: framerate-value = positive-real-number positive-real-number = (integer / "0") [ "." *integer ] ; Notes: ; - this permits a zero value. OK? ; - do we want to restrict the range or precision? a=quality: This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. For video, the value is in the range 0 to 10, with the following suggested meaning: 10 - the best still-image quality the compression scheme can give. 5 - the default behaviour given no quality suggestion. 0 - the worst still-image quality the codec designer thinks is still usable. It is a media-level attribute, and it is not dependent on charset. Syntax: quality-value = integer a=fmtp: This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. At most one instance of this attribute is allowed for each format. It is a media-level attribute, and it is not dependent on charset. Syntax: fmtp-value = fmt SP format-specific-params format-specific-params = byte-string ; Notes: ; - I've assumed a space separator is required. ; - the rest is vague because it is format-specific. --------------040505090206040906010206-- From nobody Tue Aug 12 09:06:13 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87951A0043 for ; Tue, 12 Aug 2014 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.565 X-Spam-Level: *** X-Spam-Status: No, score=3.565 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0a-iK4MJ2hp for ; Tue, 12 Aug 2014 09:06:03 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9C21A002C for ; Tue, 12 Aug 2014 09:06:02 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta10.westchester.pa.mail.comcast.net with comcast id do7p1o0040cZkys5As625B; Tue, 12 Aug 2014 16:06:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id ds611o00q3ZTu2S3Ws623s; Tue, 12 Aug 2014 16:06:02 +0000 Message-ID: <53EA3B69.8090902@alum.mit.edu> Date: Tue, 12 Aug 2014 12:06:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <53E93F39.5090401@alum.mit.edu> In-Reply-To: <53E93F39.5090401@alum.mit.edu> Content-Type: multipart/mixed; boundary="------------070503000706080202050107" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407859562; bh=ll72OziuNMaALAiFPNdg3stayKYfXuaGmwDZ6ieHJow=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PNQgfZNDO+TzEzqpRsP8d4B+oMQeynXArayFxkLalM4qODkFTmubOrBtE+6ShOtJV gLXQFwHr0vAO7kAIk64gWGd+pyjGc2fKdYdZ3kYt4asPTaqB1fwEz0h95EefmqfjRX HSZ4s13zdmZphVt7AiXXNceuyaUD8tl8ZhzK7cAI7mNXt7cI0n5G5uTqm37GbM8YuG bSfqMBdJmZtZ8GSsnkHhTl1beNDlHGKlMUl4QaAHvDbO1Y1ll+4j8gbME500DKM3E0 ggCEi9SbkVblzh8jjgLTnKqjcCeo+tj/tCMJi6u4qFlnjrFJWZLH3NAPZm8U1Q7xUN xhzi8X+wKP4Jg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jsdTNQncJLJHHbPkeGl9hECsgyA Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 16:06:10 -0000 This is a multi-part message in MIME format. --------------070503000706080202050107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I made some corrections based on offline comments from Christian Groves. Revised version attached. Thanks, Paul On 8/11/14 6:10 PM, Paul Kyzivat wrote: > I took an action item to make a proposal for the syntax of attributes in > 4566bis. > > I've *started* on it, and have enough that I would like to get some > feedback before going further. > > Attached is a snippet from section 6 of 4566bis (SDP Attributes) to > which I have added some ABNF syntax for just the values. (Each addition > starts with "Syntax:") > > This isn't necessarily the *form* it will take when done. For now what > I'm looking for is feedback on the substance. > > Of particular concern - when the format has text values, should those be > case-sensitive (the default for SDP), or case-insensitive? I think we > need to sort this out by what the common usage is. > > Thanks, > Paul > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --------------070503000706080202050107 Content-Type: text/plain; charset=UTF-8; name="rfc4566bis-attributes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rfc4566bis-attributes.txt" a=cat: This attribute gives the dot-separated hierarchical category of the session. This is to enable a receiver to filter unwanted sessions by category. There is no central registry of categories. It is a session-level attribute, and it is not dependent on charset. Syntax: cat-value = category category = byte-string ; OR category = token ; Note: syntax is vague because deployed usage is not understood a=keywds: Like the cat attribute, this is to assist identifying wanted sessions at the receiver. This allows a receiver to select interesting session based on keywords describing the purpose of the session; there is no central registry of keywords. It is a session-level attribute. It is a charset-dependent attribute, meaning that its value should be interpreted in the charset specified for the session description if one is specified, or by default in ISO 10646/UTF-8. Syntax: keywds-value = keywords keywords = byte-string ; Note: syntax is vague because deployed usage is not understood a=tool: This gives the name and version number of the tool used to create the session description. It is a session-level attribute, and it is not dependent on charset. Syntax: tool-value = tool-name-and-version tool-name-and-version = byte-string ; Note: syntax is vague because deployed usage is not understood a=ptime: This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data, but may be used with other media types if it makes sense. It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetisation of audio. It is a media-level attribute, and it is not dependent on charset. Syntax: ptime-value = packet-time packet-time = integer ; do we want to define a limited range for this? a=maxptime: This gives the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. For frame-based codecs, the time SHOULD be an integer multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media-level attribute, and it is not dependent on charset. Note that this attribute was introduced after [RFC2327], and non-updated implementations will ignore this attribute. Syntax: maxptime-value = packet-time ; do we want to define a limited range for this? a=rtpmap: / [/] This attribute maps from an RTP payload type number (as used in an "m=" line) to an encoding name denoting the payload format to be used. It also provides information on the clock rate and encoding parameters. It is a media-level attribute that is not dependent on charset. Although an RTP profile may make static assignments of payload type numbers to payload formats, it is more common for that assignment to be done dynamically using "a=rtpmap:" attributes. As an example of a static payload type, consider u-law PCM coded single-channel audio sampled at 8 kHz. This is completely defined in the RTP Audio/Video profile as payload type 0, so there is no need for an "a=rtpmap:" attribute, and the media for such a stream sent to UDP port 49232 can be specified as: m=audio 49232 RTP/AVP 0 An example of a dynamic payload type is 16-bit linear encoded stereo audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP payload type 98 for this stream, additional information is required to decode it: m=audio 49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2 Up to one rtpmap attribute can be defined for each media format specified. Thus, we might have the following: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 RTP profiles that specify the use of dynamic payload types MUST define the set of valid encoding names and/or a means to register encoding names if that profile is to be used with SDP. The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for encoding names, under the top-level media type denoted in the "m=" line. In the example above, the media types are "audio/ l8" and "audio/l16". For audio streams, indicates the number of audio channels. This parameter is OPTIONAL and may be omitted if the number of channels is one, provided that no additional parameters are needed. For video streams, no encoding parameters are currently specified. Additional encoding parameters MAY be defined in the future, but codec-specific parameters SHOULD NOT be added. Parameters added to an "a=rtpmap:" attribute SHOULD only be those required for a session directory to make the choice of appropriate media to participate in a session. Codec-specific parameters should be added in other attributes (for example, "a=fmtp:"). Note: RTP audio formats typically do not include information about the number of samples per packet. If a non-default (as defined in the RTP Audio/Video Profile) packetisation is required, the "ptime" attribute is used as given above. Syntax: rtpmap-value = payload-type SP encoding-name "/" clock-rate [ "/" encoding-params ] payload-type = integer ; do we want to define a limited range for this ; based on how big a PT can be in RTP? encoding-name = token ; To be matched in a case-insensitive way! ; RFC4855 seems to be the primary definition for this. ; It refers both to RFC2045 and RFC4288 for the definition. ; The definition in RFC2045 is messy, but equivalent to SDP . ; The definition in RFC4288 () is more restrictive, ; and governs what can be registered. ; Since ultimately only registered names can be referenced, ; using here seems safe and easy. clock-rate = integer ; do we want to define a limited range for this? encoding-params = channels ; 4566 is vague about what this can be. RFC4855 seems to be ; the authoritative source, and only allows the ; value of the media subtype "channels" parameter - the number ; of audio channels. ; Does anyone think this can be used for something else??? ; (The implication that multiple parameters might be included ; seems a misdirection - additional parameters are ; to go into a=fmtp.) ; Does anyone have an example of other parameters in this field? channels = integer ; Is there any reason to make this less restrictive? a=recvonly, a=sendrecv, a=sendonly, a=inactive At most one of recvonly/sendrecv/sendonly/inactive MAY appear at session level, and at most one MAY appear in each media section. If any one of these appears in a media section then it applies for that media section. If none appear in a media section then the one from session level, if any, applies to that media section. If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present at either session level or media level, "sendrecv" SHOULD be assumed as the default for sessions that are not of the conference type "broadcast" or "H332" (see below). Within the following SDP example, the "inactive" attribute applies to audio media and the "recvonly" attribute applies to video media. v=0 o=jdoe 2890844526 2890842807 IN IP4 198.51.100.1 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe) c=IN IP4 233.252.0.1/127 t=2873397496 2873404696 a=inactive m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 a=recvonly a=recvonly This specifies that the tools should be started in receive-only mode where applicable. It can be either a session- or media- level attribute, and it is not dependent on charset. Note that recvonly applies to the media only, not to any associated control protocol (e.g., an RTP-based system in recvonly mode SHOULD still send RTCP packets). a=sendrecv This specifies that the tools should be started in send and receive mode. This is necessary for interactive conferences with tools that default to receive-only mode. It can be either a session or media-level attribute, and it is not dependent on charset. a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session- or media-level attribute, but would normally only be used as a media attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal. a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system SHOULD still send RTCP, even if started inactive. It can be either a session or media-level attribute, and it is not dependent on charset. a=orient: Normally this is only used for a whiteboard or presentation tool. It specifies the orientation of a the workspace on the screen. It is a media-level attribute. Permitted values are "portrait", "landscape", and "seascape" (upside-down landscape). It is not dependent on charset. Syntax: orient-value = portrait / landscape / seascape portrait = %x70.6f.72.74.72.61.69.74 ; %s"portrait" landscape = %x6c.61.6e.64.73.63.61.70.65 ; %s"landscape" seascape = %x73.65.61.73.63.61.70.65 ; %s"seascape" ; Note: this assumes the intent was to be case-sensitive ; Does anything think this should be matched in a ; case-insensitive way??? a=type: This specifies the type of the conference. Suggested values are "broadcast", "meeting", "moderated", "test", and "H332". "recvonly" should be the default for "type:broadcast" sessions, "type:meeting" should imply "sendrecv", and "type:moderated" should indicate the use of a floor control tool and that the media tools are started so as to mute new sites joining the conference. Specifying the attribute "type:H332" indicates that this loosely coupled session is part of an H.332 session as defined in the ITU H.332 specification [ITU.H332.1998]. Media tools should be started "recvonly". Specifying the attribute "type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users. The type attribute is a session-level attribute, and it is not dependent on charset. Syntax: type-value = conference-type conference-type = broadcast / meeting / moderated / test / H332 broadcast = %x62.72.6f.61.64.63.61.73.74 ; OR "broadcast" meeting = %x6d.65.65.74.69.6e.67 ; OR "meeting" moderated = %x6d.6f.64.65.72.61.74.65.64 ; OR "moderated" test = %x74.65.73.74 ; OR "test" H332 = %x48.33.33.32 ; OR "H332" ; NOTE: are these names intended to be case-sensitive? ; Should there be an extensibility hook? A registry? a=charset: The character set names may be up to 40 characters taken from the printable characters of US-ASCII This specifies the character set to be used to display the session name and information data. By default, the ISO-10646 character set in UTF-8 encoding is used. If a more compact representation is required, other character sets may be used. For example, the ISO 8859-1 is specified with the following SDP attribute: a=charset:ISO-8859-1 This is a session-level attribute and is not dependent on charset. The charset specified MUST be one of those registered with IANA, such as ISO-8859-1. The character set identifier is a US-ASCII string and MUST be compared against the IANA identifiers using a case-insensitive comparison. If the identifier is not recognised or not supported, all strings that are affected by it SHOULD be regarded as octet strings. Note that a character set specified MUST still prohibit the use of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets requiring the use of these characters MUST define a quoting mechanism that prevents these bytes from appearing within text fields. Syntax: charset-value = iana-charset-preferred-mime-name iana-charset-preferred-mime-name = 1*40VCHAR ; Should we be using Preferred MIME Name or Name? ; Should SP be allowed in the name? a=sdplang: This can be a session-level attribute or a media-level attribute. Multiple sdplang attributes can be provided either at session or media level if the session description or media use multiple languages. As a session-level attribute, it specifies the language for the session description. As a media-level attribute, it specifies the language for any media-level SDP information field associated with that media, overriding any sdplang attributes specified at session-level. In general, sending session descriptions consisting of multiple languages is discouraged. Instead, multiple descriptions SHOULD be sent describing the session, one in each language. However, this is not possible with all transport mechanisms, and so multiple sdplang attributes are allowed although NOT RECOMMENDED. The "sdplang" attribute value must be a single [RFC5646] language tag in US-ASCII. It is not dependent on the charset attribute. An "sdplang" attribute SHOULD be specified when a session is distributed with sufficient scope to cross geographic boundaries, where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. Syntax: sdplang-value = Language-Tag Language-Tag = token ; the actual definition of in RFC5646. ; That is a proper subset of . Since the use here is ; to reference definitions done elsewhere against the ; more restrictive definition, it seems reasonable to use ; the simpler syntax here. a=lang: This can be a session-level attribute or a media-level attribute. Multiple lang attributes can be provided either at session or media level if the session or media use multiple languages, in which case the order of the attributes indicates the order of importance of the various languages in the session or media, from most important to least important. As a session-level attribute, it specifies the default language for the session being described. As a media-level attribute, it specifies the language for that media, overriding any session-level languages specified. The "lang" attribute value must be a single [RFC5646] language tag in US-ASCII. It is not dependent on the charset attribute. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. Syntax: lang-value = Language-Tag a=framerate: This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. Decimal representations of fractional values using the notation "." are allowed. It is a media-level attribute, defined only for video media, and it is not dependent on charset. Syntax: framerate-value = positive-real-number positive-real-number = (integer / "0") [ "." [integer] ] ; Notes: ; - this permits a zero value. OK? ; - this permits "1.". Desirable, or not? ; - do we want to restrict the range or precision? a=quality: This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. For video, the value is in the range 0 to 10, with the following suggested meaning: 10 - the best still-image quality the compression scheme can give. 5 - the default behaviour given no quality suggestion. 0 - the worst still-image quality the codec designer thinks is still usable. It is a media-level attribute, and it is not dependent on charset. Syntax: quality-value = integer ; Do we want to restrict the range? ; The definition above limits the range to [0-10] *for video*, ; but seems to leave usage open for other media. a=fmtp: This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. At most one instance of this attribute is allowed for each format. It is a media-level attribute, and it is not dependent on charset. Syntax: fmtp-value = fmt SP format-specific-params format-specific-params = byte-string ; Notes: ; - I've assumed a space separator is required. ; - the rest is vague because it is format-specific. --------------070503000706080202050107-- From nobody Tue Aug 12 21:52:11 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B841A0A8D; Tue, 12 Aug 2014 16:56:54 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmvFOxsHpewP; Tue, 12 Aug 2014 16:56:52 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C8D1A079F; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id nu7so7848740obb.0 for ; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TvOMDq5bVsm7hrc0pMtqzJ3nCKU6PoaHcLOkO23aYxw=; b=Q2edh9KLW9eYpiJj7ynYizJxi2kDLXhA+WMrRGDFSwuWjFjw6l7ID0T4Cg4ifLYflI 9krQwPRmtajzhKepJRPiSlzdXx726KuTAfhsHatbGMn2PfyKAhIOjoWJ27DuD5y/A53P PbBoP81QEVdyfvvvWR+QdV0mYtj+A0i99lN7eVoE+OCrf6UcJ3EuE1I5sJw/CxQVrurK gV3yjCrAWpFCOV+tm+2rpCZZpgVDtgUDTu1gC4rdWCmoxN0AKcgu1WZGgiZm1gEsMV37 1KinnXCsG9qOV6vcurtE3jA6biqj7Ww9hH7tH+XHpMIS5p83eAeiKksRp4xThpJgT3y9 f1VQ== MIME-Version: 1.0 X-Received: by 10.60.74.104 with SMTP id s8mr1039793oev.5.1407887811135; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) In-Reply-To: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> Date: Tue, 12 Aug 2014 16:56:51 -0700 Message-ID: From: Dave Taht To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kEcrY2jl16LT_JB-9ihIbMQ_jb0 X-Mailman-Approved-At: Tue, 12 Aug 2014 21:52:10 -0700 Cc: mmusic@ietf.org, draft-ietf-dart-dscp-rtp.all@tools.ietf.org, "clue@ietf.org" , avt@ietf.org, "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:56:54 -0000 This is also of some interest to me at least, and perhaps some members of the AQM working group who are working out weighted fair queuing and wred like approaches to these needs. Anyway, I do try to track thinking in this area in the ongoing development of cerowrt's sqm system, which has pluggable modules for all the known aqm and fq schedulers, and a three tier system modeled on wondershaper for managing traffic, which uses what diffserv markings that I have observed make sense... Some relevant links: http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt= _310 http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management Missing from this discussion so far is what is actually deployed out there... I am only familiar with stuff like the above as an egress/ingress queue management system... AND: in the case of linux based wireless routers, none of the AF codepoints are respected explicitly, and how the codepoints are mapped are described by 802.11e - and that is far more about scheduling priority for airtime rather than drop probability. It is kind of hard to wrap your head around how 802.11e actually works, but, this is a start: http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel= _access_.28EDCA.29 In linux wifi at least: CS0, CS3 are mapped into the BE hw queue CS1, CS2 are mapped into the BK hw queue CS4, CS5 are mapped into the VI hw queue CS6, CS7 are mapped into the VO hw queue Bit patterns for the other classes to whatever extent they map into CSX are mapped into the underlying hardware queue. I am not saying this is an optimal state of affairs, (as notably VO should be as completely disabled as possible in the 802.11n and ac age), and am very interested in how other OSes (ios, osx, windows), and router/switch OSes do it, but the wireless scheduling aspect of all these codepoints does not seem to be well touched upon. On a personal note I tend to think that having 17+ ways to slice up traffic is about 13 or 14 too many, particularly those targetting a drop probability. When you have drop rates well below a few percentage points, adding another percentage point of granularity seems futile. Lastly, there is also an implementation issue in linux presently in that doing extensive diffserv classification basically requires one iptables or tc rule per class, which is inefficient. Someone (not me!) doing some code for doing diffserv saner there would go a long way... On Sat, Aug 9, 2014 at 11:48 AM, Ben Campbell wrote: > Hi, > > The DART working group has started a last call for draft-ietf-dart-dscp-r= tp-02, ending on August 22. This informational draft describes consideratio= ns for the use of DiffServ code points in situations where one multiplexes = multiple RTP packet streams, and potentially other protocol streams, that s= hare the same 5-tuple. > > Since this draft is likely of interest to several working groups, I would= like to solicit additional reviews from participants of TSVWG, AVTCORE, MM= USIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback= to the effect of "this is ready to progress") to the DART working group ma= iling list. > > Thanks! > > Ben. > > Begin forwarded message: > >> Resent-From: draft-alias-bounces@tools.ietf.org >> From: Ben Campbell >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 >> Date: August 9, 2014 at 12:50:16 PM CDT >> Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com >> To: dart@ietf.org >> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, Ric= hard Barnes >> >> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. I= t's available on the data tracker at the following URL: >> >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >> >> The WGLC will conclude on 22 August, 2014. Please send your comments to = the authors and the DART mailing list. If you've reviewed it and think it's= good to go, please say so. >> >> Thanks! >> >> Ben. >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Wed Aug 13 04:41:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED6A1A086A for ; Wed, 13 Aug 2014 04:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rknU7w3BSQq for ; Wed, 13 Aug 2014 04:40:58 -0700 (PDT) Received: from mail-3.sr.se (mail-3.sr.se [192.165.8.135]) (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 26C4D1A0464 for ; Wed, 13 Aug 2014 04:40:57 -0700 (PDT) X-Halon-ID: 2b03aade-22de-11e4-a0f2-000c2976599e DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=cc:x-halon-id:received:received:from:to:subject:thread-topic:thread-index: date:message-id:references:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:content-type:content-transfer-encoding: mime-version; bh=UQmby13U/k4UX0/toGC8Nqz3mmRfj7hdDKG/omdBQyQ=; b=Sr+SM9DlADcixc0fizFNRFdvxNNB+2EeuZm0ko4jtKgOUirzRqTH1xK4jwSuL6Qg/sjcK7VyDJLd9 6d5IGJGr1rNJmqoXN13GgIt7lKbm4T9qAy+kE8fJG8o64UEW+ijdT6ELxmM+WUvGxVpBiJavxRByc+ I7024BerhHnrPxxg= Received: from STOEXCASHT01.sr.se (unknown [134.25.10.15]) by mail-3.sr.se (Halon Mail Gateway) with ESMTPS; Wed, 13 Aug 2014 13:37:12 +0200 (CEST) Received: from STOEXMBX01.sr.se ([fe80::3ca4:10d1:e63f:5b7f]) by STOEXCASHT01.sr.se ([fe80::d59a:f815:3925:e9c8%13]) with mapi id 14.03.0181.006; Wed, 13 Aug 2014 13:37:48 +0200 From: Fredrik Bergholtz To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED Thread-Index: AQHPtbEQGum7dNrLIEqp0Jhju2ac+ZvNAbWAgAFe75A= Date: Wed, 13 Aug 2014 11:37:47 +0000 Message-ID: <6A5A8D4EF65AF1439301480747E29F434E431EB2@STOEXMBX01.sr.se> References: <53E93F39.5090401@alum.mit.edu> <53EA3B69.8090902@alum.mit.edu> In-Reply-To: <53EA3B69.8090902@alum.mit.edu> Accept-Language: en-GB, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/T1kCoqcCl-dX_SuWufGHXc70P5o Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 11:41:00 -0000 Good job. I wonder if it would be wrong or bad to change fmtp-value =3D fmt SP format-specific-params to fmtp-value =3D payload-type SP format-specific-params thus using the definition of payload-type from a=3Drtpmap rather than addin= g a new definition of fmt that would, as I understand it, be essentially th= e same. Another issue is that I know of one "extension" that would become invalid i= f this syntax for a=3Dptime is introduced. This extension is not yet an off= icial extension of SDP but the standard is accepted as of 2013 within Audio= Engineering Society (AES). Section 8.1 of AES67-2013 states: 8.1 Packet time Packet time is described with two SDP attributes defined in RFC 4566. a=3Dptime [.] a=3Dmaxptime [.] Signaled packet time multiplied by sampling frequency rounded to the ne= arest integer indicates the number of samples in each packet. The packet time descriptions shall be given wit= h error less than half a sample period so that the calculated number of samples per packet rounds to the intended= integer value. In many cases, this requires the inclusion of the in the description= . If SDP is to allow that kind of usage, the type for ptime, and possibly als= o maxptime, should be the positive-real-number definition as used in a=3Dfr= amerate: packet-time =3D positive-real-number Concerning the questions about adding range limits on values, I think that = only if the value references something that is range- limited by specificat= ion, such as RTP payload type, should the SDP specify a matching range limi= tation. This means that the integer of the payload-type should be limited t= o a seven bit, unsigned integer. The other class of values would be values = that are limited only by implementation. Among these I count packet times, = clock rates, frame rates etc. For these values I would prefer that SDP does= not limit the ranges. Best regards Fredrik Bergholtz Swedish Radio > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: den 12 augusti 2014 18:06 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED >=20 > I made some corrections based on offline comments from Christian Groves. > Revised version attached. >=20 > Thanks, > Paul >=20 > On 8/11/14 6:10 PM, Paul Kyzivat wrote: > > I took an action item to make a proposal for the syntax of attributes > > in 4566bis. > > > > I've *started* on it, and have enough that I would like to get some > > feedback before going further. > > > > Attached is a snippet from section 6 of 4566bis (SDP Attributes) to > > which I have added some ABNF syntax for just the values. (Each > > addition starts with "Syntax:") > > > > This isn't necessarily the *form* it will take when done. For now what > > I'm looking for is feedback on the substance. > > > > Of particular concern - when the format has text values, should those > > be case-sensitive (the default for SDP), or case-insensitive? I think > > we need to sort this out by what the common usage is. > > > > Thanks, > > Paul > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > From nobody Wed Aug 13 07:47:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842201A0700 for ; Wed, 13 Aug 2014 07:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.965 X-Spam-Level: * X-Spam-Status: No, score=1.965 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTuxpO811XMJ for ; Wed, 13 Aug 2014 07:47:34 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 347B71A020B for ; Wed, 13 Aug 2014 07:47:34 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id eCmw1o0091GhbT855EnZoY; Wed, 13 Aug 2014 14:47:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id eEnZ1o00c3ZTu2S3TEnZyk; Wed, 13 Aug 2014 14:47:33 +0000 Message-ID: <53EB7A85.9050107@alum.mit.edu> Date: Wed, 13 Aug 2014 10:47:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Fredrik Bergholtz , "mmusic@ietf.org" References: <53E93F39.5090401@alum.mit.edu> <53EA3B69.8090902@alum.mit.edu> <6A5A8D4EF65AF1439301480747E29F434E431EB2@STOEXMBX01.sr.se> In-Reply-To: <6A5A8D4EF65AF1439301480747E29F434E431EB2@STOEXMBX01.sr.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407941253; bh=hA2IFddvlvCKnzHpkv5ZDc1MrZyMP8EJd/FqGxYB7To=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mxfUEC6QP7AbYfaNE/6iuHpiZLokhuiICtglZOQRMXi+ROduTyVJYCmNOi4XrCdzK OGjay27W23sC9LMyXC63bm8XMsOJsq+8udsH7Ik+UD+d9k2WovAdrFiZ5AcjbguKvy kFnPPVx2VK24BtIinjqZ6SZ/C84eZhh1DnCEIXt25ShRqDEme1FuaK2Xi1YhVrtMaS iKcDIeuW/5cPCRczc4VUzA2ta2j2XXUkOSj+nVp1iXWxeccPVrdH46iqt7bCE9qKSg 4Z6rr637hz/H36uwjXUbVf7HzyTTCNOIFi7laQKH5uuk6LbR7w4Eg3HJtCzSqgddnh Q7b+BQ7Q7pQxA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/UY6ckfwvM77ykP0ADWu_iAKuNxI Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 14:47:37 -0000 On 8/13/14 7:37 AM, Fredrik Bergholtz wrote: > Good job. > > I wonder if it would be wrong or bad to change > > fmtp-value = fmt SP format-specific-params > > to > > fmtp-value = payload-type SP format-specific-params > > thus using the definition of payload-type from a=rtpmap rather than adding a new definition of fmt that would, as I understand it, be essentially the same. That would be wrong. The definition of each gets to constrain the syntax of the values allowed with it. The RTP family of values require that the values be integers. So when those same values show up in rtpmap, they are still constrained to be integers, because rtpmap is only used in those cases. OTOH, fmtmap may be used with any type, so it must allow the more general value. > Another issue is that I know of one "extension" that would become invalid if this syntax for a=ptime is introduced. This extension is not yet an official extension of SDP but the standard is accepted as of 2013 within Audio Engineering Society (AES). Section 8.1 of AES67-2013 states: > > 8.1 Packet time > Packet time is described with two SDP attributes defined in RFC 4566. > > a=ptime [.] > a=maxptime [.] > > Signaled packet time multiplied by sampling frequency rounded to the nearest integer indicates the number of > samples in each packet. The packet time descriptions shall be given with error less than half a sample period so > that the calculated number of samples per packet rounds to the intended integer value. In many cases, this > requires the inclusion of the in the description. > > If SDP is to allow that kind of usage, the type for ptime, and possibly also maxptime, should be the positive-real-number definition as used in a=framerate: > > packet-time = positive-real-number If this is being proposed as an *extension*, what provision is being made for backward compatibility? I suspect many implementations won't accept a fractional value. > Concerning the questions about adding range limits on values, I think that only if the value references something that is range- limited by specification, such as RTP payload type, should the SDP specify a matching range limitation. This means that the integer of the payload-type should be limited to a seven bit, unsigned integer. The other class of values would be values that are limited only by implementation. Among these I count packet times, clock rates, frame rates etc. For these values I would prefer that SDP does not limit the ranges. I'm not inclined to impose the range in *syntax*. We can specify it as a semantic constraint, but should probably be careful about when we do this. So I'm looking for opinions about when it is important to specify this and when it is not - on a case by case basis. Thanks, Paul > Best regards > Fredrik Bergholtz > Swedish Radio > > >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: den 12 augusti 2014 18:06 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED >> >> I made some corrections based on offline comments from Christian Groves. >> Revised version attached. >> >> Thanks, >> Paul >> >> On 8/11/14 6:10 PM, Paul Kyzivat wrote: >>> I took an action item to make a proposal for the syntax of attributes >>> in 4566bis. >>> >>> I've *started* on it, and have enough that I would like to get some >>> feedback before going further. >>> >>> Attached is a snippet from section 6 of 4566bis (SDP Attributes) to >>> which I have added some ABNF syntax for just the values. (Each >>> addition starts with "Syntax:") >>> >>> This isn't necessarily the *form* it will take when done. For now what >>> I'm looking for is feedback on the substance. >>> >>> Of particular concern - when the format has text values, should those >>> be case-sensitive (the default for SDP), or case-insensitive? I think >>> we need to sort this out by what the common usage is. >>> >>> Thanks, >>> Paul >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> > > From nobody Wed Aug 13 09:49:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FB91A002C for ; Wed, 13 Aug 2014 09:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.549 X-Spam-Level: * X-Spam-Status: No, score=1.549 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDXU0bHDJPfS for ; Wed, 13 Aug 2014 09:49:15 -0700 (PDT) Received: from mail-1.sr.se (mail-1.sr.se [IPv6:2001:67c:d8:ed80::87]) (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 E78791A0028 for ; Wed, 13 Aug 2014 09:49:14 -0700 (PDT) CC: X-Halon-ID: 386304b7-2309-11e4-b51f-000c299c41b4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sverigesradio.se; s=sverigesradio; h=cc:x-halon-id:received:received:from:to:subject:thread-topic:thread-index: date:message-id:references:accept-language:content-language:x-ms-has-attach: x-ms-tnef-correlator:content-type:content-transfer-encoding:mime-version; bh=2WNsjZ584UIvTb3tj/WqPbMG/rcU+umrNXklZjW6Aik=; b=YW1/LZ1DNe47hBxpv515lR60qnXHGGMbuUTtn90Iv9i2HiYIl5oo7sFZoLnxZo0kmJn75vWXkJeH2 07nPbC6AkiqBKhgAyuAaWQkQFKabjs3ZRGhKnAWX19aUFXpEyFoIgs4varlojgYYSWQnfaGjPPYnyb I+j0PqZGIQpZfyoM= Received: from STOEXCASHT02.sr.se (unknown [134.25.11.15]) by mail-1.sr.se (Halon Mail Gateway) with ESMTPS for ; Wed, 13 Aug 2014 18:45:23 +0200 (CEST) Received: from STOEXMBX01.sr.se ([fe80::3ca4:10d1:e63f:5b7f]) by STOEXCASHT02.sr.se ([fe80::88c7:d3b3:5c76:acd7%13]) with mapi id 14.03.0181.006; Wed, 13 Aug 2014 18:44:34 +0200 From: Fredrik Bergholtz To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED Thread-Index: AQHPtbEQGum7dNrLIEqp0Jhju2ac+ZvNAbWAgAFe75CAAB16gIAAO7pwgAAGZsA= Date: Wed, 13 Aug 2014 16:44:33 +0000 Message-ID: <6A5A8D4EF65AF1439301480747E29F434E43398E@STOEXMBX01.sr.se> References: <53E93F39.5090401@alum.mit.edu> <53EA3B69.8090902@alum.mit.edu> <6A5A8D4EF65AF1439301480747E29F434E431EB2@STOEXMBX01.sr.se> <53EB7A85.9050107@alum.mit.edu> Accept-Language: en-GB, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/xFNuZudGbZ8SV_K_AtALg6n2lpk Subject: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 16:49:17 -0000 Ah. I did not consider the reality of other transport than RTP, thanks for = reminding me. :-) I understand the backwards compatibility risk of the ptime route taken in A= ES67. I have been working with another possible future extension that has s= ome theoretical overlap with AES67. In this we used a different approach of= extending ptime functionality by introducing a completely new attribute. T= his work is being done by a subgroup of the ACIP working group of the Europ= ean Broadcasting Union (EBU). The EBU work is just about ready as a first d= raft to be agreed upon within EBU. The actual path of getting this or the A= ES work approved by IETF has not yet begun, but it is likely that feedback = such as this will cause changes in both the AES standard and the coming EBU= standard.=20 I agree that range constraints would have to be carefully thought through. = In light of this I think that I change my vote to not having any such const= raints at all. Of course, I don't have the full understanding of all attrib= utes and there may be some that I am unaware of that would benefit from thi= s. So I suppose that I didn't really help answering the questions. Thanks, Fredrik Bergholtz Swedish Radio =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: den 13 augusti 2014 16:48 > To: Fredrik Bergholtz; mmusic@ietf.org > Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED >=20 > On 8/13/14 7:37 AM, Fredrik Bergholtz wrote: > > Good job. > > > > I wonder if it would be wrong or bad to change > > > > fmtp-value =3D fmt SP format-specific-params > > > > to > > > > fmtp-value =3D payload-type SP format-specific-params > > > > thus using the definition of payload-type from a=3Drtpmap rather than=20 > > adding a > new definition of fmt that would, as I understand it, be essentially the = same. >=20 > That would be wrong. >=20 > The definition of each gets to constrain the syntax of the=20 > values allowed with it. The RTP family of values require=20 > that the values be integers. So when those same values show up=20 > in rtpmap, they are still constrained to be integers, because rtpmap is o= nly used in those cases. >=20 > OTOH, fmtmap may be used with any type, so it must allow the=20 > more general value. >=20 > > Another issue is that I know of one "extension" that would become=20 > > invalid if > this syntax for a=3Dptime is introduced. This extension is not yet an=20 > official extension of SDP but the standard is accepted as of 2013=20 > within Audio Engineering Society (AES). Section 8.1 of AES67-2013 states: > > > > 8.1 Packet time > > Packet time is described with two SDP attributes defined in RFC 45= 66. > > > > a=3Dptime [.] > > a=3Dmaxptime [.] > > > > Signaled packet time multiplied by sampling frequency rounded=20 > > to the > nearest integer indicates the number of > > samples in each packet. The packet time descriptions shall be=20 > > given with > error less than half a sample period so > > that the calculated number of samples per packet rounds to the=20 > > intended > integer value. In many cases, this > > requires the inclusion of the in the descri= ption. > > > > If SDP is to allow that kind of usage, the type for ptime, and=20 > > possibly also > maxptime, should be the positive-real-number definition as used in a=3Dfr= amerate: > > > > packet-time =3D positive-real-number >=20 > If this is being proposed as an *extension*, what provision is being=20 > made for backward compatibility? I suspect many implementations won't=20 > accept a fractional value. >=20 > > Concerning the questions about adding range limits on values, I=20 > > think that only > if the value references something that is range- limited by=20 > specification, such as RTP payload type, should the SDP specify a=20 > matching range limitation. This means that the integer of the=20 > payload-type should be limited to a seven bit, unsigned integer. The=20 > other class of values would be values that are limited only by=20 > implementation. Among these I count packet times, clock rates, frame rate= s etc. For these values I would prefer that SDP does not limit the ranges. >=20 > I'm not inclined to impose the range in *syntax*. > We can specify it as a semantic constraint, but should probably be=20 > careful about when we do this. So I'm looking for opinions about when=20 > it is important to specify this and when it is not - on a case by case ba= sis. >=20 > Thanks, > Paul >=20 > > Best regards > > Fredrik Bergholtz > > Swedish Radio > > > > > >> -----Original Message----- > >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul=20 > >> Kyzivat > >> Sent: den 12 augusti 2014 18:06 > >> To: mmusic@ietf.org > >> Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK=20 > >> REQUESTED > >> > >> I made some corrections based on offline comments from Christian Grove= s. > >> Revised version attached. > >> > >> Thanks, > >> Paul > >> > >> On 8/11/14 6:10 PM, Paul Kyzivat wrote: > >>> I took an action item to make a proposal for the syntax of=20 > >>> attributes in 4566bis. > >>> > >>> I've *started* on it, and have enough that I would like to get=20 > >>> some feedback before going further. > >>> > >>> Attached is a snippet from section 6 of 4566bis (SDP Attributes)=20 > >>> to which I have added some ABNF syntax for just the values. (Each=20 > >>> addition starts with "Syntax:") > >>> > >>> This isn't necessarily the *form* it will take when done. For now=20 > >>> what I'm looking for is feedback on the substance. > >>> > >>> Of particular concern - when the format has text values, should=20 > >>> those be case-sensitive (the default for SDP), or case-insensitive? > >>> I think we need to sort this out by what the common usage is. > >>> > >>> Thanks, > >>> Paul > >>> > >>> > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >>> > > > > From nobody Wed Aug 13 16:42:39 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4401A0250 for ; Wed, 13 Aug 2014 16:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMP8D0Y0Q9RG for ; Wed, 13 Aug 2014 16:42:36 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410611A01AF for ; Wed, 13 Aug 2014 16:42:36 -0700 (PDT) Received: from ppp118-209-186-33.lns20.mel6.internode.on.net ([118.209.186.33]:53357 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XHi9d-0003Bf-VX for mmusic@ietf.org; Thu, 14 Aug 2014 09:40:30 +1000 Message-ID: <53EBF7E4.8030502@nteczone.com> Date: Thu, 14 Aug 2014 09:42:28 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic mailing list References: <53E93F39.5090401@alum.mit.edu> <53E97AA4.7050000@nteczone.com> <53EA3BC4.6090506@alum.mit.edu> <53EAC3BC.9050209@nteczone.com> In-Reply-To: <53EAC3BC.9050209@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/TXSRcWIM5yrFxnflvQMZnTFFNw8 Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 23:42:37 -0000 > Hello Paul, > > No worries. Please see below. > > I guess the question is whether you want to use the same syntax as > what has already been defined or whether you want to offer new syntax > imposing extra restrictions. No clear answer on that one. > > Regards, Christian > > On 13/08/2014 2:07 AM, Paul Kyzivat wrote: >> Christian, >> >> Thanks for being the first with feedback! Comments inline. >> >> Thanks, >> Paul >> >> On 8/11/14 10:23 PM, Christian Groves wrote: >>> Hello Paul, >>> >>> A few comments: >>> >>> a=rtpmap: >>> ----------- >>> a=rtpmap: / [/>> parameters>] >>> >>> Syntax: >>> >>> rtpmap-value = payload-type SP encoding-name "/" clock-rate >>> [ "/" encoding-params ] >>> payload-type = integer >>> encoding-name = token ; ? >>> clock-rate = integer >>> ; do we want to define a limited range for this? >>> encoding-params = token ; ? >>> ; 4566 is vague about what this can be. The only example is >>> an integer. >>> ; nor is it clear how multiple params would be encoded >>> >>> 1) Would you be better sticking to "fmt" for the payload-type as >>> that is >>> what is already used in the 4566 syntax? i.e. >>> >>> media-field = %x6d "=" media SP port ["/" integer] >>> SP proto 1*(SP fmt) CRLF >> >> rtpmap is only used for protos from the rtp family, where the fmts >> are integers. So I don't think we should be more general than that. >> >> IIUC, the pt is carried in a fixed size field in RTP, so we might >> want to limit the range to what that allows. > [CNG] I was thinking also of consistency. Your a=ftmp syntax uses > "fmt" for the same field. > >> >>> 2) encoding-name: According to RFC4855 the media subtype >>> (encoding-name) >>> is encoding according to RFC2045 i.e. subtype := extension-token / >>> iana-token. If you want to get more precise you could refer to RFC4288 >>> cl. 4.2. >> >> Thanks for the research! >> >> Section 3 of RFC4855 (Media Type Registration of RTP Payload Formats) >> says that encoding-name is equivalent to defined in RFC2045. >> This ultimately seems to be defined in that rfc. And that is: >> >> token := 1*> or tspecials> >> >> tspecials := "(" / ")" / "<" / ">" / "@" / >> "," / ";" / ":" / "\" / <"> >> "/" / "[" / "]" / "?" / "=" >> >> This is hard to reference directly. But if you study it, it is >> equivalent to the RFC4566 definition of . >> >> RFC4855 also refers to RFC4288 (Media Type Specifications and >> Registration Procedures) as the basic mechanism for registering >> encoding-names as mime subtypes. The definition there is more >> restrictive: >> >> reg-name = 1*127reg-name-chars >> reg-name-chars = ALPHA / DIGIT / "!" / >> "#" / "$" / "&" / "." / >> "+" / "-" / "^" / "_" >> >> So I think we have to possibilities: >> >> encoding-name = token >> encoding-name = subtype-name >> ; as defined in RFC4288 >> >> Since the names must be registered, I think we are safe in going the >> easy way and just using . > [CNG] I think it would be better to use the restrictive syntax. If the > IANA procedures say one thing and the syntax another, its open to > heartache at some point. Token doesn't equal reg-name. > >> >>> 3) RFC4855 last paragraph cl.3 indicates case insensitivity. >> >> OK. That has to be specified in semantics, not syntax. > [CNG] Yes >> >>> 4) For the Clock Rate and Encoding parameters RFC4288 cl.4.3 indicates >>> requirements for the names / values. >> >> That gives the generic syntax for all names and values. But these >> parameters are intended to be numeric. Do we really want to use a >> syntax that allows them to be non-numeric? > [CNG] I agree clock rate is meant to be numeric. The general encoding > parameters could basically be anything. >> >>> a=sdplang & a=lang >>> -------------------- >>> 1) Do you have the right reference in: >>> sdplang-value = Language-Tag ; defined in RFC5234 >>> >>> should this be RFC5646? >> >> Yes. That is where I was looking. I just typed the wrong thing. >> >> Examining that definition further, it is a proper subset of SDP >> . We may prefer to just use that, since the registries will >> enforce the subsetting for valid tags. > [CNG] Even though it may ultimately be a token I think its worth > referencing the RFC5646 syntax. At least people then are forced to try > and understand it. If its just left as TOKEN it could be anything. >> >> >>> a=framerate >>> ----------- >>> 1) positive-real-number = (integer / "0") [ "." *integer ] is the * >>> before the last integer needed? It would make sense if integer was >>> digit. >> >> Oops. What I meant was: >> >> positive-real-number = (integer / "0") [ "." [integer] ] >> >> Or we could be more restrictive, as: >> >> positive-real-number = (integer / "0") [ "." integer ] > [CNG] I can't see why someone would use "1." which the first option > would allow. I'd prefer the restrictive option however I can see the > argument that given the number of implementations out there it may pay > to be more lax. >> >> >>> a=quality >>> --------- >>> 1) If the value range is 0 to 10. Should you limit the values in the >>> syntax also? i.e. just using "integer" would allow sending "11". >> >> I saw that. But it says *for video* the range is 0 to 10. But AFAIK >> this isn't restricted to use for other types of media. It just >> doesn't define what it means for other media. > [CNG] Perhaps it might be worth proposing that this is only for video > and see if anybody screams? If someone is using a value quality=150 > for audio. What does that mean? Outside of some proprietary usage it > doesn't seem particularly interoperable. >> >> Thanks, >> Paul >> From nobody Thu Aug 14 10:34:02 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36EF1A0887 for ; Thu, 14 Aug 2014 10:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_19=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq9Y-6kBjaW7 for ; Thu, 14 Aug 2014 10:34:01 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id BD2391A01C6 for ; Thu, 14 Aug 2014 10:34:00 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id edia1o0031vXlb851ha08o; Thu, 14 Aug 2014 17:34:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta17.westchester.pa.mail.comcast.net with comcast id ehZz1o00g3Ge9ey3dha0yi; Thu, 14 Aug 2014 17:34:00 +0000 Message-ID: <53ECF307.9050808@alum.mit.edu> Date: Thu, 14 Aug 2014 13:33:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic@ietf.org References: <53E93F39.5090401@alum.mit.edu> <53E97AA4.7050000@nteczone.com> <53EA3BC4.6090506@alum.mit.edu> <53EAC3BC.9050209@nteczone.com> <53EBF7E4.8030502@nteczone.com> In-Reply-To: <53EBF7E4.8030502@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408037640; bh=AtAZWRB6mTAYWZAPF7IlLUMuAAhMbRa8XzwxSOa6Cug=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=anZ0JgJWZ5cko2y/x4S6Dn/KsKAg1AfjM2xhHy/eNNcxd9XPq2SCn2RSsEjK1vqqX /4wItNns2INaq53C2nZsXJVglAR5FJM5XMaMeGAAO9klJ2/ZdFgfZI5PqSJX/qMJSY 38Kqk7r5EOPlggy8Ndi0T6Ah7Of42Zqab3FMJVeqVc0ra8mOfJsMV9nwxmMDsT+YFe 9UgyIFG9HgZPSa2BrvQjpgRKxKWxwlfdDtDnGF8ngiZNuG7orJzGGohH/Ic1exjOkN 8Gh00tDbNMcNVzm/9PhzZv697JDTt7bcAM/XBBP9MugcLbS+UGLJuwMSWYtq0Br8CI X4LU4H+XGnUXg== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Z6UlAALK6y6kj4yvXjryw8LangE Subject: Re: [MMUSIC] 4566bis - Attribute syntax: FEEDBACK REQUESTED X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 17:34:02 -0000 [trimming a little bit for clarity] On 8/13/14 7:42 PM, Christian Groves wrote: >>>> a=rtpmap: >>>> ----------- >>>> a=rtpmap: / [/>>> parameters>] >>>> >>>> Syntax: >>>> >>>> rtpmap-value = payload-type SP encoding-name "/" clock-rate >>>> [ "/" encoding-params ] >>>> payload-type = integer >>>> encoding-name = token ; ? >>>> clock-rate = integer >>>> ; do we want to define a limited range for this? >>>> encoding-params = token ; ? >>>> ; 4566 is vague about what this can be. The only example is >>>> an integer. >>>> ; nor is it clear how multiple params would be encoded >>>> >>>> 1) Would you be better sticking to "fmt" for the payload-type as >>>> that is >>>> what is already used in the 4566 syntax? i.e. >>>> >>>> media-field = %x6d "=" media SP port ["/" integer] >>>> SP proto 1*(SP fmt) CRLF >>> >>> rtpmap is only used for protos from the rtp family, where the fmts >>> are integers. So I don't think we should be more general than that. >>> >>> IIUC, the pt is carried in a fixed size field in RTP, so we might >>> want to limit the range to what that allows. >> [CNG] I was thinking also of consistency. Your a=ftmp syntax uses >> "fmt" for the same field. I explained this in another reply. rtpmap only applies in cases where the fmt happens to be a PT number, but fmtp can be used in cases where it is not. >>>> 2) encoding-name: According to RFC4855 the media subtype >>>> (encoding-name) >>>> is encoding according to RFC2045 i.e. subtype := extension-token / >>>> iana-token. If you want to get more precise you could refer to RFC4288 >>>> cl. 4.2. >>> >>> Thanks for the research! >>> >>> Section 3 of RFC4855 (Media Type Registration of RTP Payload Formats) >>> says that encoding-name is equivalent to defined in RFC2045. >>> This ultimately seems to be defined in that rfc. And that is: >>> >>> token := 1*>> or tspecials> >>> >>> tspecials := "(" / ")" / "<" / ">" / "@" / >>> "," / ";" / ":" / "\" / <"> >>> "/" / "[" / "]" / "?" / "=" >>> >>> This is hard to reference directly. But if you study it, it is >>> equivalent to the RFC4566 definition of . >>> >>> RFC4855 also refers to RFC4288 (Media Type Specifications and >>> Registration Procedures) as the basic mechanism for registering >>> encoding-names as mime subtypes. The definition there is more >>> restrictive: >>> >>> reg-name = 1*127reg-name-chars >>> reg-name-chars = ALPHA / DIGIT / "!" / >>> "#" / "$" / "&" / "." / >>> "+" / "-" / "^" / "_" >>> >>> So I think we have to possibilities: >>> >>> encoding-name = token >>> encoding-name = subtype-name >>> ; as defined in RFC4288 >>> >>> Since the names must be registered, I think we are safe in going the >>> easy way and just using . >> [CNG] I think it would be better to use the restrictive syntax. If the >> IANA procedures say one thing and the syntax another, its open to >> heartache at some point. Token doesn't equal reg-name. I'm willing to go either way here. I'd like to get some other opinions. My reasoning is that we don't need to define the syntax to constrain to only valid values because there is also a semantic constraint that the name used be registered. >>>> 4) For the Clock Rate and Encoding parameters RFC4288 cl.4.3 indicates >>>> requirements for the names / values. >>> >>> That gives the generic syntax for all names and values. But these >>> parameters are intended to be numeric. Do we really want to use a >>> syntax that allows them to be non-numeric? >> [CNG] I agree clock rate is meant to be numeric. The general encoding >> parameters could basically be anything. >>> >>>> a=sdplang & a=lang >>>> -------------------- >>>> 1) Do you have the right reference in: >>>> sdplang-value = Language-Tag ; defined in RFC5234 >>>> >>>> should this be RFC5646? >>> >>> Yes. That is where I was looking. I just typed the wrong thing. >>> >>> Examining that definition further, it is a proper subset of SDP >>> . We may prefer to just use that, since the registries will >>> enforce the subsetting for valid tags. >> [CNG] Even though it may ultimately be a token I think its worth >> referencing the RFC5646 syntax. At least people then are forced to try >> and understand it. If its just left as TOKEN it could be anything. My reluctance is because the definition in 5646 is long and complex. Anyone who wants to formally verify the SDP syntax would have to pull in that definition (and resolve any naming conflicts) to do the verification. And the same argument I used above for encoding-name applies here as well: the name used in SDP must be one that has previously been defined in compliance with 5646. What if we formally defined it as token but pointed to 5646 in a comment? >>>> a=framerate >>>> ----------- >>>> 1) positive-real-number = (integer / "0") [ "." *integer ] is the * >>>> before the last integer needed? It would make sense if integer was >>>> digit. >>> >>> Oops. What I meant was: >>> >>> positive-real-number = (integer / "0") [ "." [integer] ] >>> >>> Or we could be more restrictive, as: >>> >>> positive-real-number = (integer / "0") [ "." integer ] >> [CNG] I can't see why someone would use "1." which the first option >> would allow. I'd prefer the restrictive option however I can see the >> argument that given the number of implementations out there it may pay >> to be more lax. I don't care here - I'm looking for the choice that will cause the least trouble with existing implementations. Can others chime in here please? >>>> a=quality >>>> --------- >>>> 1) If the value range is 0 to 10. Should you limit the values in the >>>> syntax also? i.e. just using "integer" would allow sending "11". >>> >>> I saw that. But it says *for video* the range is 0 to 10. But AFAIK >>> this isn't restricted to use for other types of media. It just >>> doesn't define what it means for other media. >> [CNG] Perhaps it might be worth proposing that this is only for video >> and see if anybody screams? If someone is using a value quality=150 >> for audio. What does that mean? Outside of some proprietary usage it >> doesn't seem particularly interoperable. Does anybody think it is valid to use this with values outside the range [0-10], either with video or non-video media? Thanks, Paul From nobody Sat Aug 16 13:44:38 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9421A0356 for ; Sat, 16 Aug 2014 13:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVmo_u6UIdqi for ; Sat, 16 Aug 2014 13:44:34 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1E71A0351 for ; Sat, 16 Aug 2014 13:44:33 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-84-53efc2af4b09 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B8.8E.02247.FA2CFE35; Sat, 16 Aug 2014 22:44:31 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.174.1; Sat, 16 Aug 2014 22:44:31 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4E8F411029B; Sat, 16 Aug 2014 23:44:31 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DDEC858AF1; Sat, 16 Aug 2014 23:45:15 +0300 (EEST) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4BAFB58AEC; Sat, 16 Aug 2014 23:45:15 +0300 (EEST) Message-ID: <53EFC2B4.5090000@ericsson.com> Date: Sat, 16 Aug 2014 14:44:36 -0600 From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje76Q++DDS6+NLB4f0HXYuryxywO TB5Tfm9k9Viy5CdTAFMUl01Kak5mWWqRvl0CV8b/ZY/ZCnqYK549+MzcwLidqYuRk0NCwETi 5pOlrBC2mMSFe+vZuhi5OIQEjjJKTLjZww7hbGCUuHVlBiuEs5dR4trNBYwQzjpGic6DZ6B6 VjBKbH70iQVkGK+AtsTWP/vABrMIqEocPnsZLM4mYC9xc8J1dhBbVCBZYs3WSewQ9YISJ2c+ AasREZCR2LtpMzOILSxgJLHw+ls2EJtZwFbiwpzrLBC2vMT2t3OYIQ5Xk7h6bhOYLQS06+q/ V4wTGIVmIRk7C0n7LCTtCxiZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIEBvPBLb+tdjAe fO54iFGAg1GJh1dhzvtgIdbEsuLK3EOM0hwsSuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAGB1Wr+DhLMH0Vn9tq/w5ocOqncGfDr9sky6XCJZlPDq3OrWpvcZXXLK/OCfXIvdo z5dItk7vmp/OXZUv5ny0XSaTwSQstCnM598f543pOzOm+mQXebprHBK5VfFUO7FX7fzFz+8f rPkreWxpxcHNnqu5Vi/9Fni3VX564fPXx6ufsev/YXigxFKckWioxVxUnAgAvNBym0cCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/DyaRS2ps8RFhzHGTp8nMp-DAVQ4 Subject: [MMUSIC] Draft MMUSIC Meeting Minutes from IETF 90 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 20:44:36 -0000 Hi all, The draft meeting minutes for the two MMUSIC sessions at IETF 90 in Toronto are available at: http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic Please take a look and let us know if you have any questions or comments. The formatting is a bit broken in the HTML file, but we'll fix that for the final version. Thanks, Ari & Flemming (MMUSIC co-chairs) From nobody Thu Aug 21 02:52:28 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16C71A00CA for ; Thu, 21 Aug 2014 02:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyoHISr50M_R for ; Thu, 21 Aug 2014 02:52:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6F31A00D1 for ; Thu, 21 Aug 2014 02:52:21 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-f1-53f5c15381b2 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 59.AF.21334.351C5F35; Thu, 21 Aug 2014 11:52:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Thu, 21 Aug 2014 11:52:19 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: receiver-id text Thread-Index: Ac+8eVzWUZ+sCQn4TayP+LcUZEdZdgAq84cA Date: Thu, 21 Aug 2014 09:52:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D42516E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D42516EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW7Iwa/BBo/tLaYuf8ziwOixZMlP pgDGKC6blNSczLLUIn27BK6MnfdZC6aeZqw4eWIyYwPjm82MXYycHBICJhLTbrxlgrDFJC7c W8/WxcjFISRwlFGi/+sLFghnCaPEpv+3gDIcHGwCFhLd/7RBGkQE1CW+7u1hBrGFBRQlHt2A GCoioCZx9ddmJgjbSOLoyQcsIDaLgKrEw1+9rCA2r4CvxO8pU8FsRqDF30+tAatnFhCXuPVk PtRBAhJL9pxnhrBFJV4+/scKcoIE0K7l/XIQ5fkSjR83Q40UlDg58wnLBEahWUgmzUJSNgtJ GURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJ ERgRB7f81t3BuPq14yFGAQ5GJR7eByu/BAuxJpYVV+YeYpTmYFES5110bl6wkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBkav6+s5k7I+NPofXsPpELP2W+4CE/05STt03M/+qQ+O/L/GNXrb HI8rwnwtJWkZJ69uPpuglXSocX/Yskknwy36VH/9uXJnfqrk60yHlS7uakcuOisr223f9zv/ rMyx7J1XN7/Z89Uwv+pMT/KlLZUt7+aU+lrx73zC/nL1DIXFyzg0+P8Je7sqsRRnJBpqMRcV JwIADCEYV2kCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vHDmfYWVinOnD95s3DnlPgpsZjI Subject: [MMUSIC] BUNDLE: receiver-id text X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 09:52:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D42516EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is the first version of the "receiver-id" text, which defines the new= SDES item and RTP header extension for transporting the mid value. I intend to organize a phone meeting at some point, to discuss this, but be= fore that I think it's good to have some e-mail discussions :) Thanks to Colin and Bo for performing an initial review of the text. Regards, Christer -------------- 11. Receiver ID Mechanism 11.1. General SDP Offerers and Answerers [RFC3264] can assign values, mid values, to SDP Media Descriptions (m=3D lines) within SDP Offers and Answers, using the procedures in [RFC5888]. Each mid value uniquely references an m=3D line. This section defines a new RTP SDES item [RFC3550], 'MID', which is used to carry mid values within RTCP SDES packets. This section also defines a new RTP header extension [RFC5285], which can be used to carry the mid value in RTP packets. The SDES item and RTP header extension makes is possible for a receiver to associate received RTCP- and RTP packets with a specific m=3D line, to which the receiver has assigned a mid value, even if those m=3D lines are part of the same RTP session. The endpoint informs the remote endpoint about the mid values using the procedures in [RFC5888], and the remote endpoint then inserts the mid values in RTCP- and RTP packets sent towards the other endpoint. NOTE: This text above defines how the mid value is carried in SDP Offers and Answers. The usage of other signalling protocols for carrying the mid value is not prevented, but the usage of such protocols is outside the scope of this document. The RTP MID SDES item SHOULD be sent in the first few RTCP packets sent on joining the session, and SHOULD be sent regularly thereafter. The exact number of RTCP packets in which this SDES item is sent is intentionally not specified here, as it will depend on the expected packet loss rate, the RTCP reporting interval, and the allowable overhead. The RTP MID header extension SHOULD be included in some RTP packets at the start of the session and whenever the SSRC changes. It might also be useful to include the header extension in RTP packets that comprise random access points in the media (e.g., with video I-frames). The exact number of RTP packets in which this header extension is sent is intentionally not specified here, as it will depend on expected packet loss rate and loss patterns, the overhead the application can tolerate, and the importance of immediate receipt of the mid value. For robustness purpose, endpoints need to be prepared for situations where the mid value is delayed, and SHOULD NOT terminate sessions in such cases, as the mid value is likely to arrive soon. 11.2. RTP MID SDES Item 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MID=3DTBD | length | mid value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The mid value payload is UTF-8 encoded, as in SDP. 11.3. RTP MID Header Extension The payload, containing the mid value, of the RTP MID header extension element can be encoded using either the one-byte or two- byte header [RFC5285]. The mid value payload is UTF-8 encoded, as in SDP. 11.4. IANA Considerations [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] [RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value.] This document adds the MID SDES item to the IANA "RTP SDES item types" registry as follows: Value: TBD Abbrev.: MID Name: Media Identification Reference: RFCXXXX This document defines a new extension URI in the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data: Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Description: Media identification Contact: christer.holmberg@ericsson.com Reference: RFCXXXX --_000_7594FB04B1934943A5C02806D1A2204B1D42516EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

Below is the first version of the ”receiver-id= ” text, which defines the new SDES item and RTP header extension for = transporting the mid value.=

 

I intend to organize a phone meeting at some point, = to discuss this, but before that I think it’s good to have some e-mai= l discussions :)

 

Thanks to Colin and Bo for performing an initial rev= iew of the text.

 

Regards,

 

Christer

 

 

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

 

11.  Receiver ID Mechanism

 

11.1.  General

 

   SDP Offerers and Answerers [RFC3264] can assi= gn values, mid values,

   to SDP Media Descriptions (m=3D lines) within= SDP Offers and Answers,

   using the procedures in [RFC5888].  Each= mid value uniquely

   references an m=3D line.

 

   This section defines a new RTP SDES item [RFC= 3550], 'MID', which is

   used to carry mid values within RTCP SDES pac= kets.  This section also

   defines a new RTP header extension [RFC5285],= which can be used to

   carry the mid value in RTP packets.

 

   The SDES item and RTP header extension makes = is possible for a

   receiver to associate received RTCP- and RTP = packets with a specific

   m=3D line, to which the receiver has assigned= a mid value, even if

   those m=3D lines are part of the same RTP ses= sion.  The endpoint

  informs the remote endpoint about the mid valu= es using the procedures

   in [RFC5888], and the remote endpoint then in= serts the mid values in

   RTCP- and RTP packets sent towards the other = endpoint.

 

   NOTE: This text above defines how the mid val= ue is carried in SDP

   Offers and Answers.  The usage of other = signalling protocols for

   carrying the mid value is not prevented, but = the usage of such

   protocols is outside the scope of this docume= nt.

 

   The RTP MID SDES item SHOULD be sent in the f= irst few RTCP packets

   sent on joining the session, and SHOULD be se= nt regularly thereafter.

   The exact number of RTCP packets in which thi= s SDES item is sent is

   intentionally not specified here, as it will = depend on the expected

   packet loss rate, the RTCP reporting interval= , and the allowable

   overhead.

 

   The RTP MID header extension SHOULD be includ= ed in some RTP packets

   at the start of the session and whenever the = SSRC changes.  It might

   also be useful to include the header extensio= n in RTP packets that

   comprise random access points in the media (e= .g., with video

   I-frames).  The exact number of RTP pack= ets in which this header

   extension is sent is intentionally not specif= ied here, as it will

   depend on expected packet loss rate and loss = patterns, the overhead

   the application can tolerate, and the importa= nce of immediate receipt

   of the mid value.

 

   For robustness purpose, endpoints need to be = prepared for situations

   where the mid value is delayed, and SHOULD NO= T terminate sessions in

   such cases, as the mid value is likely to arr= ive soon.

 

 

11.2.  RTP MID SDES Item

 

 

       0   &n= bsp;            = ;   1          =          2    &= nbsp;           &nbs= p;  3

       0 1 2 3 4 5 6 7 8 9 0= 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |    &n= bsp; MID=3DTBD  |     length    | m= id value           &= nbsp;       ...

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

 

 

   The mid value payload is UTF-8 encoded, as in= SDP.

 

11.3.  RTP MID Header Extension

 

   The payload, containing the mid value, of the= RTP MID header

   extension element can be encoded using either= the one-byte or two-

   byte header [RFC5285].  The mid value pa= yload is UTF-8 encoded, as in

   SDP.

 

11.4.  IANA Considerations

 

   [RFC EDITOR NOTE: Please replace RFCXXXX with= the RFC number of this

   document.]

 

   [RFC EDITOR NOTE: Please replace TBD with the= assigned SDES

   identifier value.]

 

   This document adds the MID SDES item to the I= ANA "RTP SDES item

   types" registry as follows:

 

 

       Value:   &n= bsp;  TBD

       Abbrev.:  &= nbsp; MID

       Name:  &nbs= p;    Media Identification

       Reference:  RFCX= XXX

 

 

   This document defines a new extension URI in = the RTP Compact Header

   Extensions subregistry of the Real-Time Trans= port Protocol (RTP)

   Parameters registry, according to the followi= ng data:

 

 

       Extension URI: urn:ie= tf:params:rtp-hdrext:sdes:mid

       Description: &nb= sp; Media identification

       Contact:  &= nbsp;    christer.holmberg@ericsso= n.com

       Reference:  = ;   RFCXXXX

 

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D42516EESESSMB209erics_-- From nobody Fri Aug 22 01:04:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038431A012D; Fri, 22 Aug 2014 01:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv3tpLh3eiem; Fri, 22 Aug 2014 01:04:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3F21A0119; Fri, 22 Aug 2014 01:04:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140822080419.31261.81618.idtracker@ietfa.amsl.com> Date: Fri, 22 Aug 2014 01:04:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/gZllCQrP4rwxJYBN78zgjTdGjcc Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 08:04:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-08.txt Pages : 41 Date : 2014-08-22 Abstract: This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for sending and receiving media associated with multiple SDP media descriptions ("m=" lines). This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264, in order to allow an answerer to in an SDP answer assign a non- zero port value to an "m=" line, even if the offerer in the associated SDP offer had assigned a zero port value to the "m=" line. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 22 01:07:18 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82131A013B for ; Fri, 22 Aug 2014 01:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 gO3rp3I876PB for ; Fri, 22 Aug 2014 01:07:01 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AE91A0119 for ; Fri, 22 Aug 2014 01:07:00 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-a1-53f6fa2285ff Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 15.AA.02247.22AF6F35; Fri, 22 Aug 2014 10:06:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Fri, 22 Aug 2014 10:06:58 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-08 Thread-Index: Ac+937ri4uvYKKpWT+O9BL1YQHRfCg== Date: Fri, 22 Aug 2014 08:06:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D427519@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D427519ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja7Sr2/BBtN/mVtMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGcvnNDEV7DKquHp3NWsD4zadLkZODgkBE4mdVzqYIGwxiQv3 1rOB2EICRxkl3rV4dDFyAdlLGCV2bV0IVMTBwSZgIdH9TxukRkRAXeLr3h5mEFtYQFVi34IL TBBxLYlX0x6zQ9h6Ej/OHWAFsVmAalbuXMYCYvMK+EpcO9gM1ssItPf7qTVgvcwC4hK3nsyH ukdAYsme88wQtqjEy8f/WCFsRYn2pw2MEPX5ElevT2OFmCkocXLmE5YJjEKzkIyahaRsFpIy iLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMj MCIObvlttYPx4HPHQ4wCHIxKPLwJv78GC7EmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxo0nH0q+9t7YOWsNs0Ovw27JxQHL596ZOr87j9ezN2Nv9DVRvdJ7 WjJe8rMe2iXxMLDf3jZxYsgulg0BYicWvrcKbli/8N77h7cevZc8UTOjbcM+kdQFmz/ITZlQ 7RWfdTqq9c2Zo/dVrTzefpx2aP701I/6aanPea781f8X1unTXssplLtn5UwlluKMREMt5qLi RACiSC/vaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/YQkE7c78SsbBphRJlbMEAYzFhPE Subject: [MMUSIC] Draft new version: BUNDLE-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 08:07:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D427519ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of BUNDLE. The changes are: - The receiver-id mechanism text has been added - The open issue regarding whether to include the 'rtcp' attribute= in SDP answers has been closed. There are currently no open technical issues in the document. Flemming has provided editorial comments, which I will address in the next = version. Others are of course also welcome to provide comments :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D427519ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version of BUNDLE.

 

The changes are:

-     &= nbsp;    The receiver-id mechanism text has been added<= /o:p>

-     &= nbsp;    The open issue regarding whether to include the = 216;rtcp’ attribute in SDP answers has been closed.

 

There are currently no open technical issues in the = document.

 

Flemming has provided editorial comments, which I wi= ll address in the next version. Others are of course also welcome to provid= e comments :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D427519ESESSMB209erics_-- From nobody Tue Aug 26 00:04:22 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9233B1A0A92 for ; Tue, 26 Aug 2014 00:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqv4LM-0dPxY for ; Tue, 26 Aug 2014 00:04:11 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E8C1A0970 for ; Tue, 26 Aug 2014 00:04:10 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-4f-53fc316853c5 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 80.B4.21334.8613CF35; Tue, 26 Aug 2014 09:04:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Tue, 26 Aug 2014 09:04:08 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Combining SDP O/A sections? Thread-Index: Ac/A++Fe1WUzxQoKTk67/BEzcl4beA== Date: Tue, 26 Aug 2014 07:04:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D42BCAE@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D42BCAEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW6m4Z9ggzOnWC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMmnW1kKetMrrv5rYW9g/BrUxcjJISFgIrH0zRRmCFtM4sK9 9WxdjFwcQgJHGSV2nFsF5SxhlHi95CJrFyMHB5uAhUT3P22QBhEBdYmve3vAmoUFdCRen9rA BhE3lJjVvoYdwtaTuH37CFicRUBV4uqUVrB6XgFfiZd3boPFGYEWfz+1hgnEZhYQl7j1ZD4T xEECEkv2nIc6TlTi5eN/YCdICChJTNuaBlGeL/HzwxF2iJGCEidnPmGZwCg0C8mkWUjKZiEp g4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYx AiPi4JbfujsYV792PMQowMGoxMO7oPJ3sBBrYllxZe4hRmkOFiVx3kXn5gULCaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYCw4/WvJdt6QqETmOOeH60U0vta/yTGdyxL2R2K5yhkNpu41RgXJ hkW2VdMFtVZMe7Z/z+JL4bM+Mc1355vqGlJV+ndD7Kq41Ye75vjOYPphfGXqjvNn11ao5r3c sG3NX1umyhpvtQ4Ony97C17Xr6gvfuEl8W/fNU6HiZddP782SHiiPWeu+VMlluKMREMt5qLi RADcoINdaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/CfhGlH3L1zeEu9b3bnRDkAktNis Subject: [MMUSIC] BUNDLE: Combining SDP O/A sections? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:04:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D42BCAEESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Currently the Offer/Answer procedures for the BUNDLE grouping mechanism and= the 'bundle-only' attribute are defined in different sections (5.2 and 6.3= ). Flemming has suggested that they should be combined into a single section. = In addition, he also suggested that the "SDP Information Considerations" se= ction should not be part of the O/A proceudres. So, that means the structure would look something like (don't pay attention= to the page numbers): 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 13 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 13 7. SDP Information Considerations . . . . . . . . . . . . . . . 7 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 6 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 8 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 8 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11 ...instead of the current structure: 5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 6 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 5.2.2. SDP Information Considerations . . . . . . . . . . . 7 5.2.3. Generating the Initial SDP Offer . . . . . . . . . . 8 5.2.4. Generating the SDP Answer . . . . . . . . . . . . . . 8 5.2.5. Offerer Processing of the SDP Answer . . . . . . . . 10 5.2.6. Modifying the Session . . . . . . . . . . . . . . . . 11 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 13 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 14 6.3.1. Generating the Initial SDP Offer . . . . . . . . . . 14 6.3.2. Generating the SDP Answer . . . . . . . . . . . . . . 14 6.3.3. Offerer Processing of the SDP Answer . . . . . . . . 14 6.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15 Such change is doable, but it will take some time and effort, so I would fi= rst like to ask whether someone would object to such change. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D42BCAEESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Currently the Offer/Answer procedures for the BUNDLE= grouping mechanism and the ‘bundle-only’ attribute are defined= in different sections (5.2 and 6.3).

 

Flemming has suggested that they should be combined = into a single section. In addition, he also suggested that the “SDP I= nformation Considerations” section should not be part of the O/A proc= eudres.

 

So, that means the structure would look something li= ke (don’t pay attention to the page numbers):

 

  5.  SDP Grouping Framework BUNDLE Extension Semantics . . =
. . . .   6
     5.1.  General . . . . . . . . . . . . . =
. . . . . . . . . . . .  6
  6.  SDP 'bundle-only' Attribute . . . . . . . . . . . . . =
. . . .   13
     6.1.  General . . . . . . . . . . . . . =
. . . . . . . . . . . .  13
     6.2.  Syntax  . . . . . . . . . . .=
 . . . . . . . . . . . . . .  13
       6.2.1.  General . . . . . . =
. . . . . . . . . . . . . . . . .  13
       6.2.2.  ABNF  . . . . .=
 . . . . . . . . . . . . . . . . . . .  13
  7.  SDP Information Considerations  . . . . . . . . .=
 . . . . . .   7
  8.  SDP Offer/Answer Procedures . . . . . . . . . . . . . =
. . . .   6
     8.1.  General . . . . . . . . . . . . . =
. . . . . . . . . . . .  6
     8.2.  Generating the Initial SDP Offer&n=
bsp; . . . . . . . . . . . .  8
     8.3.  Generating the SDP Answer . . . . =
. . . . . . . . . . . .  8
     8.4.  Offerer Processing of the SDP Answ=
er  . . . . . . . . . .  10
     8.5.  Modifying the Session . . . . . . =
. . . . . . . . . . . .  11

 

…instead of the current structure:<= /p>

 

  5.  SDP Grouping Framework BUNDLE Extension Se= mantics . . . . . .   6

     5.1.  General . . . . . . . = . . . . . . . . . . . . . . . . . .   6

     5.2.  SDP Offer/Answer Proce= dures . . . . . . . . . . . . . . .   6

       5.2.1.  General = . . . . . . . . . . . . . . . . . . . . . . .   6

       5.2.2.  SDP Info= rmation Considerations  . . . . . . . . . . .   7=

       5.2.3.  Generati= ng the Initial SDP Offer  . . . . . . . . . .   8=

       5.2.4.  Generati= ng the SDP Answer . . . . . . . . . . . . . .   8

       5.2.5.  Offerer = Processing of the SDP Answer  . . . . . . . .  10

       5.2.6.  Modifyin= g the Session . . . . . . . . . . . . . . . .  11

   6.  SDP 'bundle-only' Attribute . . . . = . . . . . . . . . . . . .  13

     6.1.  General . . . . . . . = . . . . . . . . . . . . . . . . . .  13

     6.2.  Syntax  . . . . .= . . . . . . . . . . . . . . . . . . . .  13

       6.2.1.  General = . . . . . . . . . . . . . . . . . . . . . . .  13

       6.2.2.  ABNF&nbs= p; . . . . . . . . . . . . . . . . . . . . . . . .  13

     6.3.  SDP Offer/Answer Proce= dures . . . . . . . . . . . . . . .  14

       6.3.1.  Generati= ng the Initial SDP Offer  . . . . . . . . . .  14

       6.3.2.  Generati= ng the SDP Answer . . . . . . . . . . . . . .  14

       6.3.3.  Offerer = Processing of the SDP Answer  . . . . . . . .  14

       6.3.4.  Modifyin= g the Session . . . . . . . . . . . . . . . .  15

 

Such change is doable, but it will take some time an= d effort, so I would first like to ask whether someone would object to such= change.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D42BCAEESESSMB209erics_-- From nobody Tue Aug 26 20:30:44 2014 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38EB1A039F for ; Tue, 26 Aug 2014 20:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_i260HecdMg for ; Tue, 26 Aug 2014 20:30:42 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9581A0396 for ; Tue, 26 Aug 2014 20:30:42 -0700 (PDT) Received: from ppp118-209-27-161.lns20.mel4.internode.on.net ([118.209.27.161]:54155 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XMTuv-000830-Rf for mmusic@ietf.org; Wed, 27 Aug 2014 13:29:02 +1000 Message-ID: <53FD50DB.4050903@nteczone.com> Date: Wed, 27 Aug 2014 13:30:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mmusic mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/ZdvnKZTEdnX4I23EEALavPTpBPo Subject: [MMUSIC] BUNDLE and draft-ietf-mmusic-sdp-mux-attributes-02 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 03:30:44 -0000 The BUNDLE draft indicates in clause 5.2.2.2 that the nettype must be IN and addrtype 'IP4' or 'IP6'. In clause 5.2.2.4 it indicates that [I-D.nandakumar-mmusic-sdp-mux-attributes] (this actually needs to be draft-ietf-mmusic-sdp-mux-attributes-02]) should be consulted regarding rules and restrictions for SDP attributes. draft-ietf-mmusic-sdp-mux-attributes-02 in clause 5.39 describes ATM related attributes. All the attributes are listed as "NORMAL". It then goes on to say that "bearer connection may be bundled in a singe media group". However ATM is not in scope of the BUNDLE draft. Should the NORMAL status be changed or at some text added to indicate that multiplexing is theoretically possible but the current BUNDLE mechanism does not describe multiplexing of non-IP transports? Regards, Christian