From nobody Tue Oct 14 06:05:17 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B521A87CA; Tue, 14 Oct 2014 06:05:07 -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 w3u3ehDzo8GU; Tue, 14 Oct 2014 06:05:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A12F41A87B3; Tue, 14 Oct 2014 06:05:05 -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.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014130505.4271.1192.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 06:05:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/Nn_n8H1-hgGG6BfVXuXhIu9rj2M Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 13:05:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : RTP Stream Pause and Resume Authors : Bo Burman Azam Akram Roni Even Magnus Westerlund Filename : draft-ietf-avtext-rtp-stream-pause-03.txt Pages : 48 Date : 2014-10-14 Abstract: With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTCP feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real- time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 14 06:17:02 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098CD1A880E for ; Tue, 14 Oct 2014 06:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Znjfyvdx1nJu for ; Tue, 14 Oct 2014 06:16:56 -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 20D3C1A87EB for ; Tue, 14 Oct 2014 06:16:55 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-62-543d22454a5e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 40.B7.21334.5422D345; Tue, 14 Oct 2014 15:16:53 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.170]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 15:16:53 +0200 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: I-D Action: draft-ietf-avtext-rtp-stream-pause-03.txt Thread-Index: AQHP56+FrmkiQD5ydUeq+Jhf2Myt1Zwvj9tg Date: Tue, 14 Oct 2014 13:16:51 +0000 Message-ID: References: <20141014130505.4271.1192.idtracker@ietfa.amsl.com> In-Reply-To: <20141014130505.4271.1192.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja6rkm2IwfkHmhYf791gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsNjD5kK3shV7Lo5j6mB8aZ4FyMnh4SAicTFw68ZIWwxiQv3 1rN1MXJxCAkcZZRo+XCLEcJZwihx5dMWsCo2AQ2J+TvugtkiAuoSd6ZfYAOxhQWcJP5O2MUO EXeWOP5pCRuEbSQx+e9PsDiLgKrEw2MLWUBsXgFfia8P/zKD2EIC9hK7Dx5l7WLk4OAUcJDo mWoEEmYUkJW4//0eWDmzgLjErSfzmSAOFZBYsuc8M4QtKvHy8T+wVgkBJYlpW9MgynUkFuz+ xAZha0ssW/iaGWKroMTJmU9YJjCKzkIydRaSlllIWmYhaVnAyLKKUbQ4tbg4N93IWC+1KDO5 uDg/Ty8vtWQTIzAiDm75rbuDcfVrx0OMAhyMSjy8C5ptQoRYE8uKK3MPMUpzsCiJ8y46Ny9Y SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PGQhXj6Qq80fkhEv857dvWf+w4uFx3ukHfCdu+ oh2yHA+TJydxzsn0dbNurpjx+da0yoONW4QXmtW8XMPx6NFSJWmfS1dkr09ItFzw2fngJJaz Z9gWrpw95fqt2pT6uNAdkrMvaLkyvSveX16aOkfIuzNywRoZ0fulP10+HUhSndm8wCOpI1yJ pTgj0VCLuag4EQBvYVfGaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/yUxVOFdC5S5NxrNTLqCRF72_jp4 Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 13:16:59 -0000 WG,=20 This update includes text changes from recent discussions on this mailing l= ist. A brief description: o Changed the section on SDP signaling to be more explicit and clear in what is supported, replacing the 'paused' parameter and the 'dir' attribute with a 'config' parameter that can take a value, and an explicit listing of what each value means. o Added a sentence in section on paused state (Section 6.3) that pause must not affect RTP keepalive. o Replaced REFUSE message name with REFUSED throughout, to better indicate that it is not a command but a notification. o Added text in a few places, clarifying that PAUSED message may be used unsolicited due to RTP sender local considerations, and also clarified the interaction between this usage and an RTP stream receiver pausing the stream. Also added an example describing this case. o Clarified that when TMMBN 0 is used as PAUSED message, and when sent unsolicited due to RTP sender local considerations, the TMMBN message includes the RTP stream sender itself as part of the bounding set. o Clarified that there is no reply to a PAUSED indication. o Improved the IANA section. o Editorial improvements. Further comments are, as usual, welcome. Cheers, Bo > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 14 oktober 2014 15:05 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: I-D Action: draft-ietf-avtext-rtp-stream-pause-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Extensions Workin= g Group of the IETF. >=20 > Title : RTP Stream Pause and Resume > Authors : Bo Burman > Azam Akram > Roni Even > Magnus Westerlund > Filename : draft-ietf-avtext-rtp-stream-pause-03.txt > Pages : 48 > Date : 2014-10-14 >=20 > Abstract: > With the increased popularity of real-time multimedia applications, > it is desirable to provide good control of resource usage, and users > also demand more control over communication sessions. This document > describes how a receiver in a multimedia conversation can pause and > resume incoming data from a sender by sending real-time feedback > messages when using Real-time Transport Protocol (RTP) for real time > data transport. This document extends the Codec Control Messages > (CCM) RTCP feedback package by explicitly allowing and describing > specific use of existing CCM messages and adding a group of new real- > time feedback messages used to pause and resume RTP data streams. > This document updates RFC 5104. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-stream-pause-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt From nobody Tue Oct 14 08:25:56 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DA31A8935; Tue, 14 Oct 2014 08:25:51 -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 5HPGXfTEkeGC; Tue, 14 Oct 2014 08:25:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B991A1A8927; Tue, 14 Oct 2014 08:25:49 -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.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014152549.11102.62144.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 08:25:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/EYC6E0r6tO02yKchCHebXFzi_Kk Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:25:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : RTP Stream Pause and Resume Authors : Bo Burman Azam Akram Roni Even Magnus Westerlund Filename : draft-ietf-avtext-rtp-stream-pause-04.txt Pages : 49 Date : 2014-10-14 Abstract: With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTCP feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real- time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 14 08:29:27 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6121A894C for ; Tue, 14 Oct 2014 08:29:18 -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 5OUCVUMCUPJp for ; Tue, 14 Oct 2014 08:29:16 -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 59F3D1A894A for ; Tue, 14 Oct 2014 08:29:16 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-85-543d414a1593 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C7.75.04387.A414D345; Tue, 14 Oct 2014 17:29:14 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.170]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 17:29:14 +0200 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: I-D Action: draft-ietf-avtext-rtp-stream-pause-04.txt Thread-Index: AQHP58Mtq3L7mfaVoEe/fFg0xVuWQJwvt5NA Date: Tue, 14 Oct 2014 15:29:13 +0000 Message-ID: References: <20141014152549.11102.62144.idtracker@ietfa.amsl.com> In-Reply-To: <20141014152549.11102.62144.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja6Xo22IwbrXmhYf791gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsfmh4wF60QqZv9uYW5g/MPfxcjJISFgInH2yjsmCFtM4sK9 9WxdjFwcQgJHGSXubv/EDOEsYZRo6lrACFLFJqAhMX/HXTBbREBd4s70C2wgtrCAk8Snrv9Q cWeJGZueMEHYRhL/Dk0Ci7MIqEqsfnkXLM4r4Csx4fk9sLiQgKPEtMZfYDYn0Jwnh9tZQWxG AVmJ+9/vsYDYzALiEreezIe6VEBiyZ7zzBC2qMTLx/+A6jmAbCWJaVvTIMp1JBbs/sQGYWtL LFv4mhliraDEyZlPWCYwis5CMnUWkpZZSFpmIWlZwMiyilG0OLW4ODfdyEgvtSgzubg4P08v L7VkEyMwJg5u+W21g/Hgc8dDjAIcjEo8vAuabUKEWBPLiitzDzFKc7AoifMuPDcvWEggPbEk NTs1tSC1KL6oNCe1+BAjEwenVAPjouwKqYsG5iEexjXnk6Qm2nILd3DINog0Cl4QmFB3XFKG /Yzm+pdtZXLLD1jeEiy26qmyFdjya/MLoSTR2/K32NMXf9q6WHH59MJnK7qd9fwPLHQ5eWYT o9WVljD2W/UlAe8cuUXb+ztsH/nEyV2fFJgh8zG71nylICP/No2dPIxrJrK7eiixFGckGmox FxUnAgCwIFydagIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/tFrCFfF-Fep3XAtcspuNLdWf_Q4 Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 15:29:18 -0000 Change of copyright boilerplate. > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 14 oktober 2014 17:26 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: I-D Action: draft-ietf-avtext-rtp-stream-pause-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Extensions Workin= g Group of the IETF. >=20 > Title : RTP Stream Pause and Resume > Authors : Bo Burman > Azam Akram > Roni Even > Magnus Westerlund > Filename : draft-ietf-avtext-rtp-stream-pause-04.txt > Pages : 49 > Date : 2014-10-14 >=20 > Abstract: > With the increased popularity of real-time multimedia applications, > it is desirable to provide good control of resource usage, and users > also demand more control over communication sessions. This document > describes how a receiver in a multimedia conversation can pause and > resume incoming data from a sender by sending real-time feedback > messages when using Real-time Transport Protocol (RTP) for real time > data transport. This document extends the Codec Control Messages > (CCM) RTCP feedback package by explicitly allowing and describing > specific use of existing CCM messages and adding a group of new real- > time feedback messages used to pause and resume RTP data streams. > This document updates RFC 5104. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-stream-pause-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt From nobody Fri Oct 17 11:46:27 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573281A1A93 for ; Fri, 17 Oct 2014 11:46:26 -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 nyf48hr2uBie for ; Fri, 17 Oct 2014 11:46:23 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD461A1A92 for ; Fri, 17 Oct 2014 11:46:22 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id fb4so2821019wid.12 for ; Fri, 17 Oct 2014 11:46:21 -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=WJ6mq0SGxDxCVsI1+VctnFedp11on/x5fgkcco2PzqM=; b=PCXbk3Wi7csBYKrEhuUrlP40vXgR6L7TfDtgweEyB6tP+mZr37zEE0PfsUjxFLRchK xU9C4/79Pxt+WTnYkufrXaHfVmAZyiS1cESRcqkgu0j3mvqTx+HM+oyBwH1XzB4cy4lt vJ+Q17ZKRM7cVDDz5d210vlWg7+zKGrlYjeOjocrh9d1nsq8zBcKKmAzeq6m2WbBx5TM CUJNRaEB8uWyP2ycA9oY2KVr9JwsdSrZ9PBRWDVhxyZzQGoC99ClZGWBM9O8n3nUoKJY hJe2FOGMsk3KhqIy4FC9ZdbCv0/gdhhSyIVxxm/2KdLKLLlq8XDIxBS3hz2TqvusAm6/ zmFg== X-Gm-Message-State: ALoCoQn+XTqMVaJ3MJHSLwni9l6rQFttZ2q3pvM/670zCkQG5gAPTGJ0J1snYLqCA58gMh+VoPwy X-Received: by 10.180.75.116 with SMTP id b20mr765577wiw.49.1413571581407; Fri, 17 Oct 2014 11:46:21 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id cx1sm446843wib.1.2014.10.17.11.46.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 11:46:19 -0700 (PDT) Message-ID: <544163FB.6000806@jitsi.org> Date: Fri, 17 Oct 2014 20:46:19 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "avtext@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/rVWtSef7yZPZYbcCVS2uxtk1Xgo Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:46:26 -0000 I went quickly over the draft and have one question. I didn't see anything about acknowledging TMMBNs. Specifically TMMBN=0. A sender may single-sidedly decide to drop a high quality simulcast or an SST-MS SVC layer for congestion control reasons. TMMBN=0 would come very handy in that case as it would allow a receiving SFU to quickly switch to a lower quality layer. Wouldn't it be a good idea to cover this? -- https://jitsi.org From nobody Sun Oct 19 08:17:14 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2219E1A1AED for ; Sun, 19 Oct 2014 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT5QGRIFQ43l for ; Sun, 19 Oct 2014 08:17:09 -0700 (PDT) Received: from BLU004-OMC3S31.hotmail.com (blu004-omc3s31.hotmail.com [65.55.116.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C601A1A98 for ; Sun, 19 Oct 2014 08:17:09 -0700 (PDT) Received: from BLU181-W80 ([65.55.116.72]) by BLU004-OMC3S31.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 19 Oct 2014 08:17:08 -0700 X-TMN: [0UehuhkLLSLPXYWmFPwgA5xHc0gYPyl6] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_9f1aaca1-7d13-499e-907f-c72e3d061267_" From: Bernard Aboba To: Emil Ivov , "DRAGE, Keith Keith" , "avtext@ietf.org" Date: Sun, 19 Oct 2014 08:17:08 -0700 Importance: Normal In-Reply-To: <544163FB.6000806@jitsi.org> References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com>, <544163FB.6000806@jitsi.org> MIME-Version: 1.0 X-OriginalArrivalTime: 19 Oct 2014 15:17:08.0932 (UTC) FILETIME=[BFF4A840:01CFEBAF] Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/a5mzVDJMqN2p0UvdB1MOqP6xxpQ Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 15:17:11 -0000 --_9f1aaca1-7d13-499e-907f-c72e3d061267_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C in the current draft it seems that TMMBNs are unacknowledged. That= is also true of codec-specificmessages such as SEI Layer Drop=2C but those= are sent in the RTP stream so they have a sequence numberthat makes it cle= ar exactly when the layer in question stopped being sent=2C and also are th= erefore subjectto loss indications (such as NACK). =20 I suppose that the sender could send multiple TMMBN=3D0 messages to improve= the chances for delivery=2C but still it represents an imperfect substitut= e if the intent is for future SST-MS implementations to forgo codec-specifi= c layer drop messages. =20 Emil said: =20 > I didn't see anything about acknowledging TMMBNs. Specifically TMMBN=3D0. = --_9f1aaca1-7d13-499e-907f-c72e3d061267_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes=2C in the current draft it s= eems that TMMBNs are unacknowledged.  =3B That is also true of codec-sp= ecific
messages such as SEI Layer Drop=2C but those are sent in the RTP= stream so they have a sequence number
that makes it clear exactl= y when the layer in question stopped being sent=2C and also are therefore s= ubject
to loss indications (such as NACK).  =3B
I suppose that the sender could send multiple TMMBN=3D0 message= s =3Bto improve the chances for deli= very=2C =3B
but sti= ll it represents an imperfect substitute if the intent is for future SST-MS= implementations to =3B
forgo codec-specific =3B= layer drop messages.  =3B

Emil said:  =3B=
>=3B I didn't see anything about acknowledging TMMBNs. Specifically T= MMBN=3D0.

= --_9f1aaca1-7d13-499e-907f-c72e3d061267_-- From nobody Tue Oct 21 07:45:17 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D42A1A700B for ; Tue, 21 Oct 2014 07:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 JCWl5z2L40LE for ; Tue, 21 Oct 2014 07:45: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 C94A91A6FFF for ; Tue, 21 Oct 2014 07:45:10 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-bf-5446717429b1 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.73.21334.47176445; Tue, 21 Oct 2014 16:45:08 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.247]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 16:45:08 +0200 From: Bo Burman To: Bernard Aboba , Emil Ivov , "DRAGE, Keith Keith" , "avtext@ietf.org" Thread-Topic: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 Thread-Index: Ac+oI8943NA5z66dRdGqdkJ2oCY7RRCBhCOAAF1G9gAAZwcAcA== Date: Tue, 21 Oct 2014 14:45:07 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com>, <544163FB.6000806@jitsi.org> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E35D236ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3Rrek0C3E4MEaXYuP926wWuxfcpnZ Ys3OCSwWTxvPMjqweLQ+28vq8bjnDJvHkiU/mTz+vwkMYInisklJzcksSy3St0vgyli8cAtj wb3YiikzfjE3MD4K6mLk5JAQMJFY1neTCcIWk7hwbz1bFyMXh5DAUUaJ/r3TmCGcJYwS2w9c ZgOpYhPQkJi/4y4jSEJEYBWjRMevV6wgCWEBV4mpj+4xg9giAm4Sv+7sZIOwnSRmN+8Ds1kE VCXmbH7ACGLzCvhKrJs3AWrdCkaJbVM7wJo5Bawkrlw/AlbEKCArcf/7PRYQm1lAXOLWk/lQ twpILNlznhnCFpV4+fgf0BEcQLaixPJ+OYjyfImV3V1QuwQlTs58wjKBUWQWkkmzkJTNQlIG EdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIE RuDBLb91dzCufu14iFGAg1GJh1dhn2uIEGtiWXFl7iFGaQ4WJXHeRefmBQsJpCeWpGanphak FsUXleakFh9iZOLglGpgNDp/KOelsbe3o5OqbWNnkbTMggemum2rO9fP07zMw+eeM996+wI+ rxTmedyXrrM+9JgykeN0/wStuaInJctlWtdrF1i5lOVI3spND0/e9OzExOzlc13ZObIvbHvM NGEW98kdjK5aVmpRd38EuDoVHuphs90ZVeV6dt1TzWCuoMde76vrSiWVWIozEg21mIuKEwHb ClewoQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/OVq7MEfUcUqqZETuVQsf5NTB2zM Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:45:15 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E35D236ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Emil, I assume unsolicited TMMBN 0 is what you mean with "acknowledging TM= MBN", not that the TMMBN (being a type of ACK to TMMBR) in itself needs an = ACK? It seems to me that you, Bernard, instead discuss the possible need for ack= nowledging TMMBN 0 ("PAUSED"), meaning asking the media receiver's consent = before a media sender, without being asked to and based on some local decis= ions, pauses an RTP stream. Correct? That's a different issue and not curre= ntly in the intended scope of the draft. Should it be? Please note that the draft was already updated as a result of previous disc= ussions on this list since IETF90. Latest version is now -04: http://tools.ietf.org/html/draft-ietf-avtext-rtp= -stream-pause-04 Diff here (-03 was just missing a copyright boilerplate change): https://ww= w.ietf.org/rfcdiff?url1=3Ddraft-ietf-avtext-rtp-stream-pause-02&difftype=3D= --html&submit=3DGo%21&url2=3Ddraft-ietf-avtext-rtp-stream-pause-04 Many of those changes are related to the use of unsolicited TMMBN 0, just a= s I think Emil suggests below. I think that it was already pretty clear in = the draft that the new PAUSED message could be sent unsolicited by the medi= a sender as a result of "local considerations", and that TMMBN 0 could be s= emantically the same as PAUSED. I however agree that the combination of tho= se was somewhat opaque and have added what I hope to be clarifying text for= it in several places. Assuming that the original question was related to unsolicited TMMBN 0, ple= ase review the changes in -04 and see if they meet your needs. Cheers, /Bo From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: den 19 oktober 2014 17:17 To: Emil Ivov; DRAGE, Keith Keith; avtext@ietf.org Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 Yes, in the current draft it seems that TMMBNs are unacknowledged. That i= s also true of codec-specific messages such as SEI Layer Drop, but those are sent in the RTP stream so th= ey have a sequence number that makes it clear exactly when the layer in question stopped being sent, = and also are therefore subject to loss indications (such as NACK). I suppose that the sender could send multiple TMMBN=3D0 messages to improve= the chances for delivery, but still it represents an imperfect substitute if the intent is for future= SST-MS implementations to forgo codec-specific layer drop messages. Emil said: > I didn't see anything about acknowledging TMMBNs. Specifically TMMBN=3D0. --_000_BBE9739C2C302046BD34B42713A1E2A22E35D236ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Emil, I assume unsolicite= d TMMBN 0 is  what you mean with “acknowledging TMMBN”, no= t that the TMMBN (being a type of ACK to TMMBR) in itself needs an ACK?

 <= /p>

It seems to me that you, = Bernard, instead discuss the possible need for acknowledging TMMBN 0 (̶= 0;PAUSED”), meaning asking the media receiver’s consent before a media sender, without being asked to and based on some local decisions, = pauses an RTP stream. Correct? That’s a different issue and not curre= ntly in the intended scope of the draft. Should it be?

 <= /p>

Please note that the draf= t was already updated as a result of previous discussions on this list sinc= e IETF90.

Latest version is now -04= : http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-04=

Diff here (-03 was just m= issing a copyright boilerplate change): https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-avtext-rtp-stream-pause-02&a= mp;difftype=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-avtext-rtp-st= ream-pause-04

 <= /p>

Many of those changes are= related to the use of unsolicited TMMBN 0, just as I think Emil suggests b= elow. I think that it was already pretty clear in the draft that the new PAUSED message could be sent unsolicited by the media sender = as a result of "local considerations", and that TMMBN 0 could be = semantically the same as PAUSED. I however agree that the combination of th= ose was somewhat opaque and have added what I hope to be clarifying text for it in several places.

 <= /p>

Assuming that the origina= l question was related to unsolicited TMMBN 0, please review the changes in= -04 and see if they meet your needs.

 <= /p>

Cheers,=

/Bo

 <= /p>

From: avtext [= mailto:avtext-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: den 19 oktober 2014 17:17
To: Emil Ivov; DRAGE, Keith Keith; avtext@ietf.org
Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02=

 

Yes, in the current draft it seems that TMMBNs are unack= nowledged.   That is also true of codec-specific

messages such as SEI Layer Drop, but those are sent in t= he RTP stream so they have a sequence number

that makes it clear exactly when the layer in question s= topped being sent, and also are therefore subject

to loss indications (such as NACK).  

 

I suppose that the sender could send multiple TMMBN=3D0 = messages to improve the chances for delivery, <= /p>

but still it represents an imperfect substitute if the i= ntent is for future SST-MS implementations to 

forgo codec-specific layer drop messages.  

 

Emil said:  
> I didn't see anything about acknowledging TMMBNs. Specifically TMMBN= =3D0.

--_000_BBE9739C2C302046BD34B42713A1E2A22E35D236ESESSMB105erics_-- From nobody Tue Oct 21 13:09:00 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5691A6F01 for ; Tue, 21 Oct 2014 13:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 RXGMuuh5lyLW for ; Tue, 21 Oct 2014 13:08:39 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922011A6EFC for ; Tue, 21 Oct 2014 13:08:10 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id y10so2158602wgg.15 for ; Tue, 21 Oct 2014 13:08: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1PCOnuxfupK+T4tH6WqASw8pT/BCX7IyWz1Jg22BjsE=; b=EK9/tf52vFTia/9yPCpG/HkHVYiI5q7eXRZfYFrOt5ZGNOseV3l+sgmY3vPuXuyUji EaVJmFSbKLRt+VKKgHMftfQude6rWV6WWRELtPF/NZ7ITiIw8h409OWtnQUBFad3RVVf 6w2WFXQPAYLGOd+63taMwKGI4tyqWXG0fDsKuPhWUu2QvYSLnXihLAJpJGU+HEmgeLEi Pg+QLu+rnj9yJti28MyW0PW/m390VLmt+CvJRClVgJY/mYJWcHZkJ6rbHFqNGUQ5p7XY sUuJNHPch7YBHS2VXT14D2tHRRqRCdCTSh9DhjOg+slDePeU7Hs0RP7n+OR904cqebdL 0B8Q== X-Gm-Message-State: ALoCoQk1yX7ZwDleaH/MFOzBcD4LF+DqN6A4yFdr7IRZTvfjhV/u6hN8HV1v5YUzSkrDsQroCZmu X-Received: by 10.194.103.230 with SMTP id fz6mr41308861wjb.53.1413922089749; Tue, 21 Oct 2014 13:08:09 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id q10sm16450883wjq.35.2014.10.21.13.08.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 13:08:08 -0700 (PDT) Message-ID: <5446BD32.9080608@jitsi.org> Date: Tue, 21 Oct 2014 22:08:18 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bo Burman , Bernard Aboba , "DRAGE, Keith Keith" , "avtext@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com>, <544163FB.6000806@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/TC-7mpEZpRXq9h9pN403XAsLwdY Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 20:08:42 -0000 Hey Bo, On 21.10.14, 16:45, Bo Burman wrote: > Emil, I assume unsolicited TMMBN 0 is what you mean with “acknowledging > TMMBN”, Yes. > not that the TMMBN (being a type of ACK to TMMBR) in itself > needs an ACK? Correct! > Many of those changes are related to the use of unsolicited TMMBN 0, > just as I think Emil suggests below. I think that it was already pretty > clear in the draft that the new PAUSED message could be sent unsolicited > by the media sender as a result of "local considerations", and that > TMMBN 0 could be semantically the same as PAUSED. Yes, it was indeed, but I think clarifying it was nice, thanks! (still not done though). > I however agree that > the combination of those was somewhat opaque and have added what I hope > to be clarifying text for it in several places. > > Assuming that the original question was related to unsolicited TMMBN 0, > please review the changes in -04 and see if they meet your needs. Unfortunately no. It still says nothing about acknowledging unsolicited TMMBNs. There is even the following part you added in there: There is no reply to a PAUSED indication; it is simply an explicit indication of the fact that an RTP stream is paused. This can be helpful for the RTP stream receiver, for example to understand that transmission is deliberately and temporarily suspended and no specific corrective action is needed. I don't think the part of "no specific action needed" would always be true. Imagine for example, that at first (time t0) sender "S" is simulcasting *two* SSRCs to receiver "R". SSRC 1 is a low res video stream (LQ) and SSRC2 is a high res version of the same stream (HQ). Then, at time t1, due to local conditions, S decides that it no longer wishes to stream the HQ layer and stops doing that. S continues to stream the LQ layer though. At that point S would send an unsolicited TMMBN=0. Now imagine that R is actually an SFU and that at t0 it was relaying S's HQ stream to a number of other receivers. So this SFU (R) needs to learn about the layer drop, as quickly as possible, in order to switch to relaying S's LQ stream to all the other receivers it was servicing. This is where the delivery of a TMMBN=0 would be crucial. Without it, R (the SFU) would have a hard time distinguishing between loss bursts and an actual layer drop. We are currently experimenting with this and this is a real problem that we are often experiencing. We are forced to rely on detecting starvation for a specific SSRC and that is either inconveniently slow, or it triggers too many false positives. Does this make sense? Emil -- https://jitsi.org From nobody Tue Oct 21 23:29:57 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55B61A6F85 for ; Tue, 21 Oct 2014 23:29:55 -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 ja9HnSnTgkdr for ; Tue, 21 Oct 2014 23:29:53 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6996F1A01EC for ; Tue, 21 Oct 2014 23:29:53 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ge10so2332191lab.38 for ; Tue, 21 Oct 2014 23:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=J6Cg4qW4ozQbtB4XE/ZBgz5CJOSIJ4AvYncxvEXwblo=; b=NpizRx7sRFtFGLEmGbspIOgRnl1q/CVo7EgQEeF8CmeQh4aA0VuZ35bSvFNiojkan0 wOykVu/ykGNA2lmQu20aGvenx3//e36z49466Ldx0Niok588UlrzPzDbCzixgamfNujv pKURvEQ07zSd4bOGEbgDQikksfnlkigw045YrPQjv9IuKn8Stnborg5WApGFCn/K6NEg JSgm886a5PepI+DwicTnur/D2AavBz1Y6H8FjuDYoIvEt2WJ7gY26xc4IsdE1z3TFEAu v+HTbqI58Ui6VR1mdwr9W75YsgNJZAw6S4etnl9o8CGjiArblntMEF5H9n12jGvxgs+8 viTw== X-Received: by 10.112.28.103 with SMTP id a7mr39564205lbh.8.1413959391748; Tue, 21 Oct 2014 23:29:51 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id uh7sm5398911lac.1.2014.10.21.23.29.50 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Oct 2014 23:29:51 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" , References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <544163FB.6000806@jitsi.org> In-Reply-To: <544163FB.6000806@jitsi.org> Date: Wed, 22 Oct 2014 09:29:46 +0300 Message-ID: <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhH02Gyk79w0rDQuKQlPGCcHD8EAKKJP9TnITx7rA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/16tYnlXVD5v2XTyje5m7CW8Z7js Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 06:29:56 -0000 Hi Emil, The unsolicited PAUSED or TMMBN=0 are an indication that the sender stopped sending the stream, I am not sure it needs to be acknowledged, the procedure is to repeat the message and send it when a new party joins the RTP session. The sender does not need any respond from the receiver for this indication Roni > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Emil Ivov > Sent: 17 October, 2014 9:46 PM > To: DRAGE, Keith (Keith); avtext@ietf.org > Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 > > I went quickly over the draft and have one question. > > I didn't see anything about acknowledging TMMBNs. Specifically TMMBN=0. > > A sender may single-sidedly decide to drop a high quality simulcast or an SST- > MS SVC layer for congestion control reasons. TMMBN=0 would come very > handy in that case as it would allow a receiving SFU to quickly switch to a lower > quality layer. > > Wouldn't it be a good idea to cover this? > > -- > https://jitsi.org > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Wed Oct 22 10:01:00 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FBE1ACE49 for ; Wed, 22 Oct 2014 10:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, 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 NPyKFktNwZ1K for ; Wed, 22 Oct 2014 10:00:56 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6561ACE52 for ; Wed, 22 Oct 2014 10:00:54 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id fb4so1950657wid.16 for ; Wed, 22 Oct 2014 10:00: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z/XPc/8LHbKuZfCY/EVx0zAHedNgfWMgTUTfBr93MgA=; b=F3JjPmqyW0IbAYxXgBtoC27uw1zqXTG9qSxdxGt3fGaJztm0KzgVYKWe3ssl86HwmJ F32vfN/F68FrLC4J5prwAwlgt7UzqA3NyNs0cp04Lmyf3dAgRovNmFGyVNxvPu9N9wy0 lRzlyB3bpECYhCfqtIv9FUAQpn8OYB8ND+swJ8EehDhpW/u2xbEHhsFWFQiNVK6WR8Ah EpbNu777OJJv5YgFzld/ZnlmmPK8qYzEF5ll6xirKZeVkDoSr+6E05hsitM2cJ6zlFOk tpVkGzbP6qQaeAoEjV1BrHahL4eIJ0KqB/o6MtYuJU1y3c7hk/GTN8JkBqnT22tZN9Jn e07g== X-Gm-Message-State: ALoCoQlUAsBvED6ajR8JBSimctu/p5N3NuMAYwSH7oC/vY88CwFlGa9bR+AmaGsGXTbmncLZuVZn X-Received: by 10.180.208.101 with SMTP id md5mr39610893wic.9.1413997253553; Wed, 22 Oct 2014 10:00:53 -0700 (PDT) Received: from porcinet.u-strasbg.fr (porcinet.u-strasbg.fr. [130.79.91.167]) by mx.google.com with ESMTPSA id cs2sm2567585wib.2.2014.10.22.10.00.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 10:00:51 -0700 (PDT) Message-ID: <5447E2C2.7030009@jitsi.org> Date: Wed, 22 Oct 2014 19:00:50 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roni Even , avtext@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <544163FB.6000806@jitsi.org> <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> In-Reply-To: <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/YqnbAFj23iEVvnQVL_UpFAmlDrA Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 17:00:58 -0000 Hey Roni, On 22.10.14, 08:29, Roni Even wrote: > Hi Emil, > The unsolicited PAUSED or TMMBN=0 are an indication that the sender stopped > sending the stream, Yes, it is. > I am not sure it needs to be acknowledged, the procedure > is to repeat the message and send it when a new party joins the RTP session. I am not sure I follow you here. The point is that an SFU may want to rely on unsolicited PAUSED/TMMBNs in order to switch from one simulcast stream to another, or to potentially drop a sender from the SSRCs that it is sending to a receiver and replace it with another sender. This would be the case in large conferences where only receiver is only getting a subset of the participants. In order to rely on receiving TMMBNs, the SFU would need to know that they are reliable though. So in other words: Yes! The sender does not need a response for its indication. It is the receiver that needs to know that it can rely on receiving the indication. > The sender does not need any respond from the receiver for this indication Cheers, Emil > Roni > >> -----Original Message----- >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Emil Ivov >> Sent: 17 October, 2014 9:46 PM >> To: DRAGE, Keith (Keith); avtext@ietf.org >> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >> >> I went quickly over the draft and have one question. >> >> I didn't see anything about acknowledging TMMBNs. Specifically TMMBN=0. >> >> A sender may single-sidedly decide to drop a high quality simulcast or an > SST- >> MS SVC layer for congestion control reasons. TMMBN=0 would come very >> handy in that case as it would allow a receiving SFU to quickly switch to > a lower >> quality layer. >> >> Wouldn't it be a good idea to cover this? >> >> -- >> https://jitsi.org >> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext > > -- https://jitsi.org From nobody Thu Oct 23 01:50:19 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6C61A8932 for ; Thu, 23 Oct 2014 01:50:17 -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 3RfL-kPuveCE for ; Thu, 23 Oct 2014 01:50:05 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369781A8928 for ; Thu, 23 Oct 2014 01:50:04 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so580778wgh.23 for ; Thu, 23 Oct 2014 01:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=onKsTyvhfId5RbWJNZK7XJ5jpo9hqdXR8Ic9+bD4KB8=; b=dBjivUjfhO0TdRZFyFI1mvzBb2GkTFw+OkXHC1NcTvCSLHpTz65PAJOlaxMuwpag8a u5C4FiVSJE6z8vAI7M3DapC50yDr1eJmzWxlbiCNTJq6XUfx0l/AlZ+Wm1FHDH8Oozs/ ZEZ1O1jsD9alnP57+lrHn/aFpabX1kdQCJrs/p1Hchr1IrcH3yIcjIJiLzkAAkYf4gK1 BQM34QXOvO4CqCK4nYtjYZ28VsKXWqOvWpFsclUdJR7sneUEbxb5gq+Y6+hMFjdSLNys d1nuG3ZKz1VPJ0Ug/Ei6/ppabqmsZQjN5MTLcpsq2vdIaV6+qDgKVOnzQVpzr/xQR8sY uGWA== X-Received: by 10.194.246.167 with SMTP id xx7mr837764wjc.118.1414054203770; Thu, 23 Oct 2014 01:50:03 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id fv2sm1819849wib.2.2014.10.23.01.50.01 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Oct 2014 01:50:03 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" , References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <544163FB.6000806@jitsi.org> <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> <5447E2C2.7030009@jitsi.org> In-Reply-To: <5447E2C2.7030009@jitsi.org> Date: Thu, 23 Oct 2014 11:49:59 +0300 Message-ID: <04af01cfee9e$54fc5460$fef4fd20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhH02Gyk79w0rDQuKQlPGCcHD8EAKKJP9TAbiFe2ECuvVxKZxjDZEg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/9OF9L22xg8Z-sQhl9ww7flIT57g Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 08:50:17 -0000 Hi Emil, I am not sure what is the case you describe. My view is that an SFU ( I assume it is a conferencing bridge?) may use TMMBR/PAUSE to stop unused video streams, these are acknowledged messages by the sender. Another example is that for some reason a current sender will Pause a stream (I would think that it will be a stream not used currently) even though it did not get a TMMBR/PAUSE by learning somehow that the stream is unused. This will be unsolicited. If I understand you have another case where a sender will pause, for some reason, a stream in use by the SFU and may send a TMMBN=0/PAUSED for this stream. Are you asking for a method by which the SFU will know if the sender supports TMMBN=0/PAUSED and will always send it when pausing a stream in use? I am not sure what is Acknowledge by the SFU to the media sender is and when is it sent, for this case? Roni > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: 22 October, 2014 8:01 PM > To: Roni Even; avtext@ietf.org > Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 > > Hey Roni, > > On 22.10.14, 08:29, Roni Even wrote: > > Hi Emil, > > The unsolicited PAUSED or TMMBN=0 are an indication that the sender > > stopped sending the stream, > > Yes, it is. > > > I am not sure it needs to be acknowledged, the procedure is to repeat > > the message and send it when a new party joins the RTP session. > > I am not sure I follow you here. The point is that an SFU may want to rely on > unsolicited PAUSED/TMMBNs in order to switch from one simulcast stream to > another, or to potentially drop a sender from the SSRCs that it is sending to a > receiver and replace it with another sender. This would be the case in large > conferences where only receiver is only getting a subset of the participants. > > In order to rely on receiving TMMBNs, the SFU would need to know that they > are reliable though. > > So in other words: Yes! The sender does not need a response for its indication. > It is the receiver that needs to know that it can rely on receiving the indication. > > > The sender does not need any respond from the receiver for this > > indication > > Cheers, > Emil > > > Roni > > > >> -----Original Message----- > >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Emil Ivov > >> Sent: 17 October, 2014 9:46 PM > >> To: DRAGE, Keith (Keith); avtext@ietf.org > >> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 > >> > >> I went quickly over the draft and have one question. > >> > >> I didn't see anything about acknowledging TMMBNs. Specifically TMMBN=0. > >> > >> A sender may single-sidedly decide to drop a high quality simulcast > >> or an > > SST- > >> MS SVC layer for congestion control reasons. TMMBN=0 would come very > >> handy in that case as it would allow a receiving SFU to quickly > >> switch to > > a lower > >> quality layer. > >> > >> Wouldn't it be a good idea to cover this? > >> > >> -- > >> https://jitsi.org > >> > >> _______________________________________________ > >> avtext mailing list > >> avtext@ietf.org > >> https://www.ietf.org/mailman/listinfo/avtext > > > > > > -- > https://jitsi.org From nobody Thu Oct 23 03:04:55 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B9F1A8AA7 for ; Thu, 23 Oct 2014 03:04:53 -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 5_9HT_7LEO3u for ; Thu, 23 Oct 2014 03:04:51 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82291A8A77 for ; Thu, 23 Oct 2014 03:04:50 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id bs8so3643021wib.17 for ; Thu, 23 Oct 2014 03:04:49 -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=OlpIXo6GCU18XtinpncNQzIQCaINLjUa2vrqZYhRqmM=; b=IGgtFQItZghy8JUOcv5DmhcfPN5VmM42stbdwZPu4NxlqO3XQZTY+Rd4UJdLP7Entr v0nktgpSS/iFni/RHbCHW8/ME7/SzmpKIYqDmku4avpOzuZva1VIHaMUVgiNq4IPuiNh SsNF/0GEYwu13lAF7tS6a/cVcBf0mbQhDm4gTPajgmyEcgHBR6fYWgqZlLjTTQ/Sn8Yi wxnEbNSO0fToK9k2ncv9i6rKemd72ZQnrVQWC6WPhWaW/nsuID1RTspe92Zn8ir596H9 JcRYk03Oxcdgf26aVLrWEa2LPKtBnyMgQpc0sJzcphkVVNfjXHAap9hZwYA/8yvmi2op VqpA== X-Gm-Message-State: ALoCoQmmj4+MYUueB16sIOfOG4ILs5uOQ2urkCJ8g+Vk2lXfWwFLx+pagaYmKkmxtF8b1rS3ZS42 X-Received: by 10.180.85.68 with SMTP id f4mr35080738wiz.10.1414058689226; Thu, 23 Oct 2014 03:04:49 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id wl1sm1600295wjb.4.2014.10.23.03.04.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 03:04:48 -0700 (PDT) Message-ID: <5448D2C0.2000509@jitsi.org> Date: Thu, 23 Oct 2014 12:04:48 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roni Even , avtext@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <544163FB.6000806@jitsi.org> <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> <5447E2C2.7030009@jitsi.org> <04af01cfee9e$54fc5460$fef4fd20$@gmail.com> In-Reply-To: <04af01cfee9e$54fc5460$fef4fd20$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/gXCgZA6PS0GP1MiL3Z3TznM377A Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 10:04:53 -0000 Hey Roni, On 23.10.14, 10:49, Roni Even wrote: > Hi Emil, > I am not sure what is the case you describe. > My view is that an SFU ( I assume it is a conferencing bridge?) may use > TMMBR/PAUSE to stop unused video streams, these are acknowledged messages by > the sender. Correct! > Another example is that for some reason a current sender will Pause a stream > (I would think that it will be a stream not used currently) even though it > did not get a TMMBR/PAUSE by learning somehow that the stream is unused. > This will be unsolicited. Learning that a stream is unused is not the only reason why a Sender can stop streaming something. The sender can also drop a stream because it detected congestion. > If I understand you have another case where a sender will pause, for some > reason, a stream in use by the SFU and may send a TMMBN=0/PAUSED for this > stream. Are you asking for a method by which the SFU will know if the sender > supports TMMBN=0/PAUSED and will always send it when pausing a stream in > use? I am not sure what is Acknowledge by the SFU to the media sender is and > when is it sent, for this case? An unsolicited TMMBN=0 (as any RTCP message sent over UDP) can be lost. If that happens the Receiver/SFU would not know that an in-use stream is being intentionally dropped. That unsolicited TMMBN=0 would need to be retransmitted by the Sender until it is eventually received by the Receiver. That's what I am asking for and that's what I am calling "making it reliable". Is this clearer now? Emil > Roni > > >> -----Original Message----- >> From: Emil Ivov [mailto:emcho@jitsi.org] >> Sent: 22 October, 2014 8:01 PM >> To: Roni Even; avtext@ietf.org >> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >> >> Hey Roni, >> >> On 22.10.14, 08:29, Roni Even wrote: >>> Hi Emil, >>> The unsolicited PAUSED or TMMBN=0 are an indication that the sender >>> stopped sending the stream, >> >> Yes, it is. >> >>> I am not sure it needs to be acknowledged, the procedure is to repeat >>> the message and send it when a new party joins the RTP session. >> >> I am not sure I follow you here. The point is that an SFU may want to rely > on >> unsolicited PAUSED/TMMBNs in order to switch from one simulcast stream to >> another, or to potentially drop a sender from the SSRCs that it is sending > to a >> receiver and replace it with another sender. This would be the case in > large >> conferences where only receiver is only getting a subset of the > participants. >> >> In order to rely on receiving TMMBNs, the SFU would need to know that they >> are reliable though. >> >> So in other words: Yes! The sender does not need a response for its > indication. >> It is the receiver that needs to know that it can rely on receiving the > indication. >> >>> The sender does not need any respond from the receiver for this >>> indication >> >> Cheers, >> Emil >> >>> Roni >>> >>>> -----Original Message----- >>>> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Emil Ivov >>>> Sent: 17 October, 2014 9:46 PM >>>> To: DRAGE, Keith (Keith); avtext@ietf.org >>>> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >>>> >>>> I went quickly over the draft and have one question. >>>> >>>> I didn't see anything about acknowledging TMMBNs. Specifically TMMBN=0. >>>> >>>> A sender may single-sidedly decide to drop a high quality simulcast >>>> or an >>> SST- >>>> MS SVC layer for congestion control reasons. TMMBN=0 would come very >>>> handy in that case as it would allow a receiving SFU to quickly >>>> switch to >>> a lower >>>> quality layer. >>>> >>>> Wouldn't it be a good idea to cover this? >>>> >>>> -- >>>> https://jitsi.org >>>> >>>> _______________________________________________ >>>> avtext mailing list >>>> avtext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avtext >>> >>> >> >> -- >> https://jitsi.org > > -- https://jitsi.org From nobody Thu Oct 23 04:08:48 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2CA1A8AC3 for ; Thu, 23 Oct 2014 04:08:43 -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 7sKXMTABUufW for ; Thu, 23 Oct 2014 04:08:39 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F32E1A8ABF for ; Thu, 23 Oct 2014 04:08:35 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so814987wgh.34 for ; Thu, 23 Oct 2014 04:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=oMzAxEt/9pBzl1sOFjaOeda2nzBRkxP61WThirh7jOs=; b=ZWd/CBzytf+a6BQL+oukflC5c+s1S9MF7nQx70RyrrCkA5gbqTEtDIgnExM6KyDoXI 5wP8zj9/OADAPXNoYmjG7vkjD2QCFewfuY8br20Wirmb0c6iSxrFnFkmHx4le1la4S6v wR9mLjYJt5y9CBtved/MDeWMQ/71IWDsCwMijLevnKVMBkKkYJ3WkE2ytial6PbtF2C0 /3JJ2RXk1eKG4OAJXqxsN/qsooXIM+vszmWlb3/XV9e+4PE1Gyf6vq5tQpq68nUAdPu4 65WlJRUEdjcb25Ykon20cGWucjScCw8Ezrw1Q0yGkntXbanpoEAt/fwOqszuuQRTjZPW zAZg== X-Received: by 10.194.79.201 with SMTP id l9mr4536480wjx.59.1414062513407; Thu, 23 Oct 2014 04:08:33 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id ee3sm2212828wic.4.2014.10.23.04.08.31 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 23 Oct 2014 04:08:32 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" , References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <544163FB.6000806@jitsi.org> <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> <5447E2C2.7030009@jitsi.org> <04af01cfee9e$54fc5460$fef4fd20$@gmail.com> <5448D2C0.2000509@jitsi.org> In-Reply-To: <5448D2C0.2000509@jitsi.org> Date: Thu, 23 Oct 2014 14:08:28 +0300 Message-ID: <04e201cfeeb1$adf54c30$09dfe490$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhH02Gyk79w0rDQuKQlPGCcHD8EAKKJP9TAbiFe2ECuvVxKQJMivCaAb4cajicQtf9YA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/CBpssgWzSUoyYhstrJjaIgIiMOw Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 11:08:45 -0000 Hi Emil, OK, now I got it. I agree that we need some text addressing reliability of the unsolicited TMMBN and PAUSED. I think I got confused by the work acknowledging and it seems to me that Bo had the same problem. But still since RTCP is runs over UDP there is still no guarantee that the RTCP packet will arrive even if we sent it with every scheduled RTCP packet. I agree that it will be good to add text about the unreliability of these indications and propose to repeat them based on implementation decision. Roni > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: 23 October, 2014 1:05 PM > To: Roni Even; avtext@ietf.org > Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 > > Hey Roni, > > On 23.10.14, 10:49, Roni Even wrote: > > Hi Emil, > > I am not sure what is the case you describe. > > My view is that an SFU ( I assume it is a conferencing bridge?) may > > use TMMBR/PAUSE to stop unused video streams, these are acknowledged > > messages by the sender. > > Correct! > > > Another example is that for some reason a current sender will Pause a > > stream (I would think that it will be a stream not used currently) > > even though it did not get a TMMBR/PAUSE by learning somehow that the > stream is unused. > > This will be unsolicited. > > Learning that a stream is unused is not the only reason why a Sender can stop > streaming something. The sender can also drop a stream because it detected > congestion. > > > If I understand you have another case where a sender will pause, for > > some reason, a stream in use by the SFU and may send a TMMBN=0/PAUSED > > for this stream. Are you asking for a method by which the SFU will > > know if the sender supports TMMBN=0/PAUSED and will always send it > > when pausing a stream in use? I am not sure what is Acknowledge by the > > SFU to the media sender is and when is it sent, for this case? > > An unsolicited TMMBN=0 (as any RTCP message sent over UDP) can be lost. > If that happens the Receiver/SFU would not know that an in-use stream is being > intentionally dropped. That unsolicited TMMBN=0 would need to be > retransmitted by the Sender until it is eventually received by the Receiver. > > That's what I am asking for and that's what I am calling "making it reliable". > > Is this clearer now? > > Emil > > > > Roni > > > > > >> -----Original Message----- > >> From: Emil Ivov [mailto:emcho@jitsi.org] > >> Sent: 22 October, 2014 8:01 PM > >> To: Roni Even; avtext@ietf.org > >> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 > >> > >> Hey Roni, > >> > >> On 22.10.14, 08:29, Roni Even wrote: > >>> Hi Emil, > >>> The unsolicited PAUSED or TMMBN=0 are an indication that the sender > >>> stopped sending the stream, > >> > >> Yes, it is. > >> > >>> I am not sure it needs to be acknowledged, the procedure is to > >>> repeat the message and send it when a new party joins the RTP session. > >> > >> I am not sure I follow you here. The point is that an SFU may want to > >> rely > > on > >> unsolicited PAUSED/TMMBNs in order to switch from one simulcast > >> stream to another, or to potentially drop a sender from the SSRCs > >> that it is sending > > to a > >> receiver and replace it with another sender. This would be the case > >> in > > large > >> conferences where only receiver is only getting a subset of the > > participants. > >> > >> In order to rely on receiving TMMBNs, the SFU would need to know that > >> they are reliable though. > >> > >> So in other words: Yes! The sender does not need a response for its > > indication. > >> It is the receiver that needs to know that it can rely on receiving > >> the > > indication. > >> > >>> The sender does not need any respond from the receiver for this > >>> indication > >> > >> Cheers, > >> Emil > >> > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Emil > >>>> Ivov > >>>> Sent: 17 October, 2014 9:46 PM > >>>> To: DRAGE, Keith (Keith); avtext@ietf.org > >>>> Subject: Re: [avtext] WGLC for > >>>> draft-ietf-avtext-rtp-stream-pause-02 > >>>> > >>>> I went quickly over the draft and have one question. > >>>> > >>>> I didn't see anything about acknowledging TMMBNs. Specifically > TMMBN=0. > >>>> > >>>> A sender may single-sidedly decide to drop a high quality simulcast > >>>> or an > >>> SST- > >>>> MS SVC layer for congestion control reasons. TMMBN=0 would come > >>>> very handy in that case as it would allow a receiving SFU to > >>>> quickly switch to > >>> a lower > >>>> quality layer. > >>>> > >>>> Wouldn't it be a good idea to cover this? > >>>> > >>>> -- > >>>> https://jitsi.org > >>>> > >>>> _______________________________________________ > >>>> avtext mailing list > >>>> avtext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/avtext > >>> > >>> > >> > >> -- > >> https://jitsi.org > > > > > > -- > https://jitsi.org From nobody Thu Oct 23 14:41:31 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8691D1A6EE8 for ; Thu, 23 Oct 2014 14:41:12 -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 h-PNZ0ykdJXj for ; Thu, 23 Oct 2014 14:41:08 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5148D1A0262 for ; Thu, 23 Oct 2014 14:41:08 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so2030060wgh.21 for ; Thu, 23 Oct 2014 14:41:06 -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=rscaGPlkoQcEmzL7Np6RRt7v4501iTbV1wFChGZpN00=; b=RjDQQOpc0VtGCK1KsOgyKGNddcLl8yPe+2wZvTFp72iW809itJLoZcYC+rV0G9gPVD gue80IlyNU4ICiVnSG5gaS8cgdyaW2ebV7b5YEpj1OvqeCsxAFqMBNYWkIpHyHBD9h9Y jU/rHBArWeVKVVDrCdT9SV71YoohXh5QjUP+FdklHePNcnbrK73lENYp1cO83798Czop nU/jVqf3f9xYWWZ6BGGvnGU+7TnnbKirOIy13/fq1Sq+yTP6rW30XzLN5pwbIXjzR1V8 jp+lrnCki9hGQlgKfIT7cMrQ/chfgS3d4bbmJtuy217jBhF7ly63dFbHaEgKMZdwft3E J5yQ== X-Gm-Message-State: ALoCoQndnspZRw7/6iqKAIWK9RMlHEUJXAwGX9wE6GAlxQoxrhYGggtrup3qRRqvMeuzwOIaCax1 X-Received: by 10.194.2.129 with SMTP id 1mr395795wju.12.1414100466824; Thu, 23 Oct 2014 14:41:06 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id ws5sm3537767wjb.9.2014.10.23.14.41.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 14:41:04 -0700 (PDT) Message-ID: <544975F3.6090007@jitsi.org> Date: Thu, 23 Oct 2014 23:41:07 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roni Even , avtext@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <544163FB.6000806@jitsi.org> <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> <5447E2C2.7030009@jitsi.org> <04af01cfee9e$54fc5460$fef4fd20$@gmail.com> <5448D2C0.2000509@jitsi.org> <04e201cfeeb1$adf54c30$09dfe490$@gmail.com> In-Reply-To: <04e201cfeeb1$adf54c30$09dfe490$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/iah611S_UEh7-zz-ULYtmWJSkuI Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 21:41:12 -0000 Hey Roni, On 23.10.14, 13:08, Roni Even wrote: > Hi Emil, > OK, now I got it. I agree that we need some text addressing reliability of > the unsolicited TMMBN and PAUSED. I think I got confused by the work > acknowledging and it seems to me that Bo had the same problem. > But still since RTCP is runs over UDP there is still no guarantee that the > RTCP packet will arrive even if we sent it with every scheduled RTCP packet. > > I agree that it will be good to add text about the unreliability of these > indications and propose to repeat them based on implementation decision. I wonder if we could come up with an easy way to ACK the TMMBN=0 ... how about resending the same TMMBN=0 (with the same SSRCs) in the opposite direction? Emil > > Roni > >> -----Original Message----- >> From: Emil Ivov [mailto:emcho@jitsi.org] >> Sent: 23 October, 2014 1:05 PM >> To: Roni Even; avtext@ietf.org >> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >> >> Hey Roni, >> >> On 23.10.14, 10:49, Roni Even wrote: >>> Hi Emil, >>> I am not sure what is the case you describe. >>> My view is that an SFU ( I assume it is a conferencing bridge?) may >>> use TMMBR/PAUSE to stop unused video streams, these are acknowledged >>> messages by the sender. >> >> Correct! >> >>> Another example is that for some reason a current sender will Pause a >>> stream (I would think that it will be a stream not used currently) >>> even though it did not get a TMMBR/PAUSE by learning somehow that the >> stream is unused. >>> This will be unsolicited. >> >> Learning that a stream is unused is not the only reason why a Sender can > stop >> streaming something. The sender can also drop a stream because it detected >> congestion. >> >>> If I understand you have another case where a sender will pause, for >>> some reason, a stream in use by the SFU and may send a TMMBN=0/PAUSED >>> for this stream. Are you asking for a method by which the SFU will >>> know if the sender supports TMMBN=0/PAUSED and will always send it >>> when pausing a stream in use? I am not sure what is Acknowledge by the >>> SFU to the media sender is and when is it sent, for this case? >> >> An unsolicited TMMBN=0 (as any RTCP message sent over UDP) can be lost. >> If that happens the Receiver/SFU would not know that an in-use stream is > being >> intentionally dropped. That unsolicited TMMBN=0 would need to be >> retransmitted by the Sender until it is eventually received by the > Receiver. >> >> That's what I am asking for and that's what I am calling "making it > reliable". >> >> Is this clearer now? >> >> Emil >> >> >>> Roni >>> >>> >>>> -----Original Message----- >>>> From: Emil Ivov [mailto:emcho@jitsi.org] >>>> Sent: 22 October, 2014 8:01 PM >>>> To: Roni Even; avtext@ietf.org >>>> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >>>> >>>> Hey Roni, >>>> >>>> On 22.10.14, 08:29, Roni Even wrote: >>>>> Hi Emil, >>>>> The unsolicited PAUSED or TMMBN=0 are an indication that the sender >>>>> stopped sending the stream, >>>> >>>> Yes, it is. >>>> >>>>> I am not sure it needs to be acknowledged, the procedure is to >>>>> repeat the message and send it when a new party joins the RTP session. >>>> >>>> I am not sure I follow you here. The point is that an SFU may want to >>>> rely >>> on >>>> unsolicited PAUSED/TMMBNs in order to switch from one simulcast >>>> stream to another, or to potentially drop a sender from the SSRCs >>>> that it is sending >>> to a >>>> receiver and replace it with another sender. This would be the case >>>> in >>> large >>>> conferences where only receiver is only getting a subset of the >>> participants. >>>> >>>> In order to rely on receiving TMMBNs, the SFU would need to know that >>>> they are reliable though. >>>> >>>> So in other words: Yes! The sender does not need a response for its >>> indication. >>>> It is the receiver that needs to know that it can rely on receiving >>>> the >>> indication. >>>> >>>>> The sender does not need any respond from the receiver for this >>>>> indication >>>> >>>> Cheers, >>>> Emil >>>> >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Emil >>>>>> Ivov >>>>>> Sent: 17 October, 2014 9:46 PM >>>>>> To: DRAGE, Keith (Keith); avtext@ietf.org >>>>>> Subject: Re: [avtext] WGLC for >>>>>> draft-ietf-avtext-rtp-stream-pause-02 >>>>>> >>>>>> I went quickly over the draft and have one question. >>>>>> >>>>>> I didn't see anything about acknowledging TMMBNs. Specifically >> TMMBN=0. >>>>>> >>>>>> A sender may single-sidedly decide to drop a high quality simulcast >>>>>> or an >>>>> SST- >>>>>> MS SVC layer for congestion control reasons. TMMBN=0 would come >>>>>> very handy in that case as it would allow a receiving SFU to >>>>>> quickly switch to >>>>> a lower >>>>>> quality layer. >>>>>> >>>>>> Wouldn't it be a good idea to cover this? >>>>>> >>>>>> -- >>>>>> https://jitsi.org >>>>>> >>>>>> _______________________________________________ >>>>>> avtext mailing list >>>>>> avtext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/avtext >>>>> >>>>> >>>> >>>> -- >>>> https://jitsi.org >>> >>> >> >> -- >> https://jitsi.org > > -- https://jitsi.org From nobody Fri Oct 24 08:43:20 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B856A1A1AC3 for ; Fri, 24 Oct 2014 08:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 DUH0IE8KR_tc for ; Fri, 24 Oct 2014 08:43:14 -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 ACACA1A1A9B for ; Fri, 24 Oct 2014 08:42:28 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-63-544a7362691d Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 63.DB.21334.2637A445; Fri, 24 Oct 2014 17:42:26 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.247]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 17:42:25 +0200 From: Bo Burman To: Emil Ivov , Roni Even , "avtext@ietf.org" Thread-Topic: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 Thread-Index: Ac+oI8943NA5z66dRdGqdkJ2oCY7RRCBhCOAAOG7vwAAFgotAAAhJhCAAAKc6QAAAjk6AAAWGFWAACg2RzA= Date: Fri, 24 Oct 2014 15:42:25 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <544163FB.6000806@jitsi.org> <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> <5447E2C2.7030009@jitsi.org> <04af01cfee9e$54fc5460$fef4fd20$@gmail.com> <5448D2C0.2000509@jitsi.org> <04e201cfeeb1$adf54c30$09dfe490$@gmail.com> <544975F3.6090007@jitsi.org> In-Reply-To: <544975F3.6090007@jitsi.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW5SsVeIwZUGZYuP926wWqzZOYHF 4m87swOzx85Zd9k9liz5yeTx/01gAHMUl01Kak5mWWqRvl0CV8biozOYC+7ZV9z4epulgXGB URcjJ4eEgInEzKlvmSBsMYkL99azdTFycQgJHGWU+LBqHjuEs4RR4sa8g6wgVWwCGhLzd9xl BLFFBLIk/mw+D9YtLOAqMfXRPWaIuJvErzs72SDsJInDfZNZQGwWAVWJ9uUQc3gFfCUO/Gpl hFhwi0lixrN3YAlOAU2Jny9XsYPYjAKyEve/3wNrZhYQl7j1ZD7UqQISS/acZ4awRSVePv7H CmErSfzYcAmqXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsY RYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAmPn4JbfujsYV792PMQowMGoxMO7YJNniBBrYllx Ze4hRmkOFiVx3kXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYExT/fK9nfv6kYoXnA+z jzHlO225YH6L4djymZpnDdxO+htGvlq2J7xvndxlO4Ud/Jl/vhf9XD5p4d29JzyVRS3sJjAe /bb7z67JjsdW/V9z7lLFgTrHqQd1Xtc/WWQ9WfLZxILb/M9bD+eVLwyeIOnGLukiO/uMjeuM fatbk+8d/hj/KSdZvtRAiaU4I9FQi7moOBEABpq3Jn4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/oHhhOpmx8LCVnrNU-lFlm8_Mey4 Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:43:17 -0000 > I wonder if we could come up with an easy way to ACK the TMMBN=3D0 ... ho= w about resending the same TMMBN=3D0 (with > the same SSRCs) in the opposite direction? Would certainly be possible, but a bit un-orthodox maybe... That TMMBN-ACK,= or PAUSED-ACK, could also be lost, right? I think that the least we should do is to describe (definitely in 4.6 and 8= .5, and maybe also in 6.4) that the timing and message re-transmission for = any unsolicited PAUSED or TMMBN=3D0 should be the same as is currently spec= ified for TMMBR>0 (RESUME) in the draft. This, because the importance of an= unsolicited TMMBN=3D0 (PAUSED) can be just as high as for a TMMBR>0 (RESUM= E). Have a look at the text for RESUME and see if you think it is appropriate! I don't know if this is sufficient. The major difference between PAUSED and= RESUME is that PAUSED has no implicit ACK through RTP transmission state c= hanges (as RESUME has), and that has to be handled somehow. Assuming that we agree that unsolicited PAUSED (same for TMMBN=3D0, of cour= se) must be sent in a way that tries to mitigate loss to the largest extent= possible, given existing RTCP bandwidth, I think the question then becomes= for how long and how often should PAUSED be repeated until considered rece= ived. Could we suggest to use regular RTCP loss reporting to make an estima= te on how many times it has to be repeated? For example, if there is 20% lo= ss, it takes 5 repetitions to get down to 0.032% loss probability for the P= AUSED (given random loss). The overhead for that is really nothing compared= to the media stream itself (that was just paused). Specifying even more re= petitions should not be a problem, just being limited by the available RTCP= bandwidth and timing! Do we need a new use case (section 3) and design consideration (section 4) = for timing of unsolicited PAUSED? I think that might be appropriate! > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Emil Ivov > Sent: den 23 oktober 2014 23:41 > To: Roni Even; avtext@ietf.org > Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >=20 > Hey Roni, >=20 > On 23.10.14, 13:08, Roni Even wrote: > > Hi Emil, > > OK, now I got it. I agree that we need some text addressing > > reliability of the unsolicited TMMBN and PAUSED. I think I got > > confused by the work acknowledging and it seems to me that Bo had the s= ame problem. > > But still since RTCP is runs over UDP there is still no guarantee that > > the RTCP packet will arrive even if we sent it with every scheduled RTC= P packet. > > > > I agree that it will be good to add text about the unreliability of > > these indications and propose to repeat them based on implementation de= cision. >=20 > I wonder if we could come up with an easy way to ACK the TMMBN=3D0 ... ho= w about resending the same TMMBN=3D0 (with > the same SSRCs) in the opposite direction? >=20 > Emil >=20 >=20 > > > > Roni > > > >> -----Original Message----- > >> From: Emil Ivov [mailto:emcho@jitsi.org] > >> Sent: 23 October, 2014 1:05 PM > >> To: Roni Even; avtext@ietf.org > >> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 > >> > >> Hey Roni, > >> > >> On 23.10.14, 10:49, Roni Even wrote: > >>> Hi Emil, > >>> I am not sure what is the case you describe. > >>> My view is that an SFU ( I assume it is a conferencing bridge?) may > >>> use TMMBR/PAUSE to stop unused video streams, these are acknowledged > >>> messages by the sender. > >> > >> Correct! > >> > >>> Another example is that for some reason a current sender will Pause > >>> a stream (I would think that it will be a stream not used currently) > >>> even though it did not get a TMMBR/PAUSE by learning somehow that > >>> the > >> stream is unused. > >>> This will be unsolicited. > >> > >> Learning that a stream is unused is not the only reason why a Sender > >> can > > stop > >> streaming something. The sender can also drop a stream because it > >> detected congestion. > >> > >>> If I understand you have another case where a sender will pause, > >>> for some reason, a stream in use by the SFU and may send a > >>> TMMBN=3D0/PAUSED for this stream. Are you asking for a method by whic= h > >>> the SFU will know if the sender supports TMMBN=3D0/PAUSED and will > >>> always send it when pausing a stream in use? I am not sure what is > >>> Acknowledge by the SFU to the media sender is and when is it sent, fo= r this case? > >> > >> An unsolicited TMMBN=3D0 (as any RTCP message sent over UDP) can be lo= st. > >> If that happens the Receiver/SFU would not know that an in-use stream > >> is > > being > >> intentionally dropped. That unsolicited TMMBN=3D0 would need to be > >> retransmitted by the Sender until it is eventually received by the > > Receiver. > >> > >> That's what I am asking for and that's what I am calling "making it > > reliable". > >> > >> Is this clearer now? > >> > >> Emil > >> > >> > >>> Roni > >>> > >>> > >>>> -----Original Message----- > >>>> From: Emil Ivov [mailto:emcho@jitsi.org] > >>>> Sent: 22 October, 2014 8:01 PM > >>>> To: Roni Even; avtext@ietf.org > >>>> Subject: Re: [avtext] WGLC for > >>>> draft-ietf-avtext-rtp-stream-pause-02 > >>>> > >>>> Hey Roni, > >>>> > >>>> On 22.10.14, 08:29, Roni Even wrote: > >>>>> Hi Emil, > >>>>> The unsolicited PAUSED or TMMBN=3D0 are an indication that the > >>>>> sender stopped sending the stream, > >>>> > >>>> Yes, it is. > >>>> > >>>>> I am not sure it needs to be acknowledged, the procedure is to > >>>>> repeat the message and send it when a new party joins the RTP sessi= on. > >>>> > >>>> I am not sure I follow you here. The point is that an SFU may want > >>>> to rely > >>> on > >>>> unsolicited PAUSED/TMMBNs in order to switch from one simulcast > >>>> stream to another, or to potentially drop a sender from the SSRCs > >>>> that it is sending > >>> to a > >>>> receiver and replace it with another sender. This would be the case > >>>> in > >>> large > >>>> conferences where only receiver is only getting a subset of the > >>> participants. > >>>> > >>>> In order to rely on receiving TMMBNs, the SFU would need to know > >>>> that they are reliable though. > >>>> > >>>> So in other words: Yes! The sender does not need a response for its > >>> indication. > >>>> It is the receiver that needs to know that it can rely on receiving > >>>> the > >>> indication. > >>>> > >>>>> The sender does not need any respond from the receiver for this > >>>>> indication > >>>> > >>>> Cheers, > >>>> Emil > >>>> > >>>>> Roni > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Emil > >>>>>> Ivov > >>>>>> Sent: 17 October, 2014 9:46 PM > >>>>>> To: DRAGE, Keith (Keith); avtext@ietf.org > >>>>>> Subject: Re: [avtext] WGLC for > >>>>>> draft-ietf-avtext-rtp-stream-pause-02 > >>>>>> > >>>>>> I went quickly over the draft and have one question. > >>>>>> > >>>>>> I didn't see anything about acknowledging TMMBNs. Specifically > >> TMMBN=3D0. > >>>>>> > >>>>>> A sender may single-sidedly decide to drop a high quality > >>>>>> simulcast or an > >>>>> SST- > >>>>>> MS SVC layer for congestion control reasons. TMMBN=3D0 would come > >>>>>> very handy in that case as it would allow a receiving SFU to > >>>>>> quickly switch to > >>>>> a lower > >>>>>> quality layer. > >>>>>> > >>>>>> Wouldn't it be a good idea to cover this? > >>>>>> > >>>>>> -- > >>>>>> https://jitsi.org > >>>>>> > >>>>>> _______________________________________________ > >>>>>> avtext mailing list > >>>>>> avtext@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/avtext > >>>>> > >>>>> > >>>> > >>>> -- > >>>> https://jitsi.org > >>> > >>> > >> > >> -- > >> https://jitsi.org > > > > >=20 > -- > https://jitsi.org >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Sat Oct 25 16:19:00 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4841A6EF0 for ; Sat, 25 Oct 2014 16:18:57 -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 ffms87fZnCxF for ; Sat, 25 Oct 2014 16:18:54 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D6C1A6EE5 for ; Sat, 25 Oct 2014 16:18:53 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id n3so3533609wiv.5 for ; Sat, 25 Oct 2014 16:18: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5ZG3g+hL1nl1WYVNbDj6C10blGzzwOj0UAyzKkY1MBA=; b=DH1A3qrfky+aDnuYxoPGLoKVlKHx9l/kwb2dMUsnWK63tJi9PuX+9r8512YJZnX/nU uX3RZxTrnAv0cy4xDCmqwpRh0zD1IGaPDDgicdtTfBFlD1W5ShX6e8Ie5u8hkMq5EEPK aJHKgscOdW38gwCj1U0EJZ8pUYlWLjD2RXvSyl2oYwOBxVWAygqlsqxfRtdVpVKX3gm0 yhxvDOjq5m4mHX1Yk4AO4+2PKg3v1RXLEee3jzds6z9lQyqcYsI3UGVxDaYMPpzosDGc VPSTOX+gOIK1CIG6wfF+S01JDNLRa5f8f5q7OxY5ZjfX2qBYG6x5aZypAPJ4AkHdN1o0 7/wQ== X-Gm-Message-State: ALoCoQm2ZI0hytaropohUzF1n+03qS/s8PEqEWxPTp1L8G8mSkH9YIFNXQuwT5GaO3y4IifxCjEm X-Received: by 10.180.206.173 with SMTP id lp13mr12344525wic.78.1414279132006; Sat, 25 Oct 2014 16:18:52 -0700 (PDT) Received: from [192.168.1.21] (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id ci9sm2918500wid.24.2014.10.25.16.18.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Oct 2014 16:18:50 -0700 (PDT) Message-ID: <544C2FD8.40603@jitsi.org> Date: Sun, 26 Oct 2014 01:18:48 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bo Burman , Roni Even , "avtext@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <544163FB.6000806@jitsi.org> <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> <5447E2C2.7030009@jitsi.org> <04af01cfee9e$54fc5460$fef4fd20$@gmail.com> <5448D2C0.2000509@jitsi.org> <04e201cfeeb1$adf54c30$09dfe490$@gmail.com> <544975F3.6090007@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/5eBJqC34TSwE-wk9E5s3l6-f5_s Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 23:18:57 -0000 Hey Bo, On 24.10.14, 17:42, Bo Burman wrote: >> I wonder if we could come up with an easy way to ACK the TMMBN=0 >> ... how about resending the same TMMBN=0 (with the same SSRCs) in >> the opposite direction? > > Would certainly be possible, but a bit un-orthodox maybe... That > TMMBN-ACK, or PAUSED-ACK, could also be lost, right? I am not sure I get the question. If you mean that new ACK message that we could add, then yes of course ... and obviously the idea would be to resend the TMMBN=0 until the ACK is received. I guess I must have misunderstood though, so could you please clarify what you meant? > I think that the least we should do is to describe (definitely in 4.6 > and 8.5, and maybe also in 6.4) that the timing and message > re-transmission for any unsolicited PAUSED or TMMBN=0 should be the > same as is currently specified for TMMBR>0 (RESUME) in the draft. > This, because the importance of an unsolicited TMMBN=0 (PAUSED) can > be just as high as for a TMMBR>0 (RESUME). > > Have a look at the text for RESUME and see if you think it is > appropriate! I am not sure which section you are referring to. 8.3 maybe? I didn't see anything there that talks about reliability or retransmissions. Did I miss something? > I don't know if this is sufficient. The major difference between > PAUSED and RESUME is that PAUSED has no implicit ACK through RTP > transmission state changes (as RESUME has), and that has to be > handled somehow. Right! > Assuming that we agree that unsolicited PAUSED (same for TMMBN=0, of > course) must be sent in a way that tries to mitigate loss to the > largest extent possible, given existing RTCP bandwidth, I think the > question then becomes for how long and how often should PAUSED be > repeated until considered received. Could we suggest to use regular > RTCP loss reporting to make an estimate on how many times it has to > be repeated? For example, if there is 20% loss, it takes 5 > repetitions to get down to 0.032% loss probability for the PAUSED > (given random loss). The overhead for that is really nothing compared > to the media stream itself (that was just paused). Specifying even > more repetitions should not be a problem, just being limited by the > available RTCP bandwidth and timing! I think this is a good idea. Just to be clear, are you intentionally avoiding the possibility for using a retransmit-until-acked mechanism? Are you thinking that having to wait for an ACK may incur so much latency that the receiver could have a good guess that transmission has stopped? > Do we need a new use case (section 3) and design consideration > (section 4) for timing of unsolicited PAUSED? I think that might be > appropriate! If you decide that's necessary I can try to send some text next week. Emil >> -----Original Message----- From: avtext >> [mailto:avtext-bounces@ietf.org] On Behalf Of Emil Ivov Sent: den >> 23 oktober 2014 23:41 To: Roni Even; avtext@ietf.org Subject: Re: >> [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >> >> Hey Roni, >> >> On 23.10.14, 13:08, Roni Even wrote: >>> Hi Emil, OK, now I got it. I agree that we need some text >>> addressing reliability of the unsolicited TMMBN and PAUSED. I >>> think I got confused by the work acknowledging and it seems to me >>> that Bo had the same problem. But still since RTCP is runs over >>> UDP there is still no guarantee that the RTCP packet will arrive >>> even if we sent it with every scheduled RTCP packet. >>> >>> I agree that it will be good to add text about the unreliability >>> of these indications and propose to repeat them based on >>> implementation decision. >> >> I wonder if we could come up with an easy way to ACK the TMMBN=0 >> ... how about resending the same TMMBN=0 (with the same SSRCs) in >> the opposite direction? >> >> Emil >> >> >>> >>> Roni >>> >>>> -----Original Message----- From: Emil Ivov >>>> [mailto:emcho@jitsi.org] Sent: 23 October, 2014 1:05 PM To: >>>> Roni Even; avtext@ietf.org Subject: Re: [avtext] WGLC for >>>> draft-ietf-avtext-rtp-stream-pause-02 >>>> >>>> Hey Roni, >>>> >>>> On 23.10.14, 10:49, Roni Even wrote: >>>>> Hi Emil, I am not sure what is the case you describe. My view >>>>> is that an SFU ( I assume it is a conferencing bridge?) may >>>>> use TMMBR/PAUSE to stop unused video streams, these are >>>>> acknowledged messages by the sender. >>>> >>>> Correct! >>>> >>>>> Another example is that for some reason a current sender will >>>>> Pause a stream (I would think that it will be a stream not >>>>> used currently) even though it did not get a TMMBR/PAUSE by >>>>> learning somehow that the >>>> stream is unused. >>>>> This will be unsolicited. >>>> >>>> Learning that a stream is unused is not the only reason why a >>>> Sender can >>> stop >>>> streaming something. The sender can also drop a stream because >>>> it detected congestion. >>>> >>>>> If I understand you have another case where a sender will >>>>> pause, for some reason, a stream in use by the SFU and may >>>>> send a TMMBN=0/PAUSED for this stream. Are you asking for a >>>>> method by which the SFU will know if the sender supports >>>>> TMMBN=0/PAUSED and will always send it when pausing a stream >>>>> in use? I am not sure what is Acknowledge by the SFU to the >>>>> media sender is and when is it sent, for this case? >>>> >>>> An unsolicited TMMBN=0 (as any RTCP message sent over UDP) can >>>> be lost. If that happens the Receiver/SFU would not know that >>>> an in-use stream is >>> being >>>> intentionally dropped. That unsolicited TMMBN=0 would need to >>>> be retransmitted by the Sender until it is eventually received >>>> by the >>> Receiver. >>>> >>>> That's what I am asking for and that's what I am calling >>>> "making it >>> reliable". >>>> >>>> Is this clearer now? >>>> >>>> Emil >>>> >>>> >>>>> Roni >>>>> >>>>> >>>>>> -----Original Message----- From: Emil Ivov >>>>>> [mailto:emcho@jitsi.org] Sent: 22 October, 2014 8:01 PM To: >>>>>> Roni Even; avtext@ietf.org Subject: Re: [avtext] WGLC for >>>>>> draft-ietf-avtext-rtp-stream-pause-02 >>>>>> >>>>>> Hey Roni, >>>>>> >>>>>> On 22.10.14, 08:29, Roni Even wrote: >>>>>>> Hi Emil, The unsolicited PAUSED or TMMBN=0 are an >>>>>>> indication that the sender stopped sending the stream, >>>>>> >>>>>> Yes, it is. >>>>>> >>>>>>> I am not sure it needs to be acknowledged, the procedure >>>>>>> is to repeat the message and send it when a new party >>>>>>> joins the RTP session. >>>>>> >>>>>> I am not sure I follow you here. The point is that an SFU >>>>>> may want to rely >>>>> on >>>>>> unsolicited PAUSED/TMMBNs in order to switch from one >>>>>> simulcast stream to another, or to potentially drop a >>>>>> sender from the SSRCs that it is sending >>>>> to a >>>>>> receiver and replace it with another sender. This would be >>>>>> the case in >>>>> large >>>>>> conferences where only receiver is only getting a subset of >>>>>> the >>>>> participants. >>>>>> >>>>>> In order to rely on receiving TMMBNs, the SFU would need to >>>>>> know that they are reliable though. >>>>>> >>>>>> So in other words: Yes! The sender does not need a response >>>>>> for its >>>>> indication. >>>>>> It is the receiver that needs to know that it can rely on >>>>>> receiving the >>>>> indication. >>>>>> >>>>>>> The sender does not need any respond from the receiver >>>>>>> for this indication >>>>>> >>>>>> Cheers, Emil >>>>>> >>>>>>> Roni >>>>>>> >>>>>>>> -----Original Message----- From: avtext >>>>>>>> [mailto:avtext-bounces@ietf.org] On Behalf Of Emil >>>>>>>> Ivov Sent: 17 October, 2014 9:46 PM To: DRAGE, Keith >>>>>>>> (Keith); avtext@ietf.org Subject: Re: [avtext] WGLC >>>>>>>> for draft-ietf-avtext-rtp-stream-pause-02 >>>>>>>> >>>>>>>> I went quickly over the draft and have one question. >>>>>>>> >>>>>>>> I didn't see anything about acknowledging TMMBNs. >>>>>>>> Specifically >>>> TMMBN=0. >>>>>>>> >>>>>>>> A sender may single-sidedly decide to drop a high >>>>>>>> quality simulcast or an >>>>>>> SST- >>>>>>>> MS SVC layer for congestion control reasons. TMMBN=0 >>>>>>>> would come very handy in that case as it would allow a >>>>>>>> receiving SFU to quickly switch to >>>>>>> a lower >>>>>>>> quality layer. >>>>>>>> >>>>>>>> Wouldn't it be a good idea to cover this? >>>>>>>> >>>>>>>> -- https://jitsi.org >>>>>>>> >>>>>>>> _______________________________________________ avtext >>>>>>>> mailing list avtext@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/avtext >>>>>>> >>>>>>> >>>>>> >>>>>> -- https://jitsi.org >>>>> >>>>> >>>> >>>> -- https://jitsi.org >>> >>> >> >> -- https://jitsi.org >> >> _______________________________________________ avtext mailing >> list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext > -- https://jitsi.org From nobody Mon Oct 27 09:59:05 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4581A00AB for ; Mon, 27 Oct 2014 09:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Xk98E4eAQvjn for ; Mon, 27 Oct 2014 09:58:59 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4E21A1B4F for ; Mon, 27 Oct 2014 09:58:51 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-e2-544e79c97c53 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A1.AE.24955.9C97E445; Mon, 27 Oct 2014 17:58:49 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.247]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 17:58:48 +0100 From: Bo Burman To: Emil Ivov , Roni Even , "avtext@ietf.org" Thread-Topic: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 Thread-Index: Ac+oI8943NA5z66dRdGqdkJ2oCY7RRCBhCOAAOG7vwAAFgotAAAhJhCAAAKc6QAAAjk6AAAWGFWAACg2RzAAP8hJAABYTh3Q Date: Mon, 27 Oct 2014 16:58:48 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <544163FB.6000806@jitsi.org> <038701cfedc1$94dc4b90$be94e2b0$@gmail.com> <5447E2C2.7030009@jitsi.org> <04af01cfee9e$54fc5460$fef4fd20$@gmail.com> <5448D2C0.2000509@jitsi.org> <04e201cfeeb1$adf54c30$09dfe490$@gmail.com> <544975F3.6090007@jitsi.org> <544C2FD8.40603@jitsi.org> In-Reply-To: <544C2FD8.40603@jitsi.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7JSr8Qg3V3DS0+3rvBarFm5wQW i7/tzA7MHjtn3WX3WLLkJ5PH/zeBAcxRXDYpqTmZZalF+nYJXBkP3jSyFcwvq/izaR5zA+O6 2C5GTg4JAROJ5T+eMEPYYhIX7q1nA7GFBI4wSjxYm9jFyAVkL2GUePduFztIgk1AQ2L+jruM ILaIQJbEn83nmUBsYQFXiamP7jFDxN0kft3ZyQZh50n0XoewWQRUJV5duglm8wr4StzdeJwF YsFuZomdu7eANXMKqEscv70AbBmjgKzE/e/3WEBsZgFxiVtP5jNBXCogsWTPeairRSVePv7H CmErSfzYcAmqXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsY RYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAiPn4JbfqjsYL79xPMQowMGoxMP7ocY3RIg1say4 MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MOqsbr9kcG257JT4h2/Z XDP6N0oY7zT4Y2ztdDHm8RGz2bmrdorzfK6+9vdEPMuOZ0mrf2jVsgcv3MRwPGZ93zyF4Baj XyrBMped1r6LkCoWMY6JXaV02P/7Xa4ZjRtPun+wV3X7+HpVz9Nlmc63rkh3rzrRZRywX/1n hOee6xP02Szcf80pq1FiKc5INNRiLipOBAC8z2tvfQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/tpTR__6buumy-clPUmrB0iTorDM Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:59:03 -0000 Hi Emil, inline. > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: den 26 oktober 2014 01:19 > To: Bo Burman; Roni Even; avtext@ietf.org > Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >=20 > Hey Bo, >=20 > On 24.10.14, 17:42, Bo Burman wrote: > >> I wonder if we could come up with an easy way to ACK the TMMBN=3D0 ... > >> how about resending the same TMMBN=3D0 (with the same SSRCs) in the > >> opposite direction? > > > > Would certainly be possible, but a bit un-orthodox maybe... That > > TMMBN-ACK, or PAUSED-ACK, could also be lost, right? >=20 > I am not sure I get the question. If you mean that new ACK message that w= e could add, then yes of course ... and > obviously the idea would be to resend the TMMBN=3D0 until the ACK is rece= ived. >=20 > I guess I must have misunderstood though, so could you please clarify wha= t you meant? [BoB] Apologies for being unclear, again. I really meant to say that if you= anyway specify TMMBN=3D0 (PAUSED) to be re-sent multiple times (similar to= RESUME, as I suggest below), ACK can be seen as a kind of optimization tha= t stops such repetition as soon as possible. When the (new) ACK is lost, th= e repetition of PAUSED continues for a while longer, and since ACK may get = lost it is not guaranteed that message repetition is stopped as soon as PAU= SED is received. ACK is thus not required to get the functionality I (now f= inally; thank you Roni for helping out) understand you want. >=20 > > I think that the least we should do is to describe (definitely in 4.6 > > and 8.5, and maybe also in 6.4) that the timing and message > > re-transmission for any unsolicited PAUSED or TMMBN=3D0 should be the > > same as is currently specified for TMMBR>0 (RESUME) in the draft. > > This, because the importance of an unsolicited TMMBN=3D0 (PAUSED) can b= e > > just as high as for a TMMBR>0 (RESUME). > > > > Have a look at the text for RESUME and see if you think it is > > appropriate! >=20 > I am not sure which section you are referring to. 8.3 maybe? I didn't see= anything there that talks about reliability or > retransmissions. Did I miss something? [BoB] I meant to point to the following parts of the document: Section 4.6 Request Retransmission says (for resume): When it comes to resume requests that are more time critical, the best resume performance may be achieved by repeating the request as often as possible until a sufficient number have been sent to reach a high probability of request delivery, or the stream gets delivered. I propose to amend this paragraph to something like:=20 When it comes to resume requests or paused indications that are more tim= e critical, the best performance may be achieved by repeating the message as often as possible until a sufficient number have been sent to reach a high probability of message delivery, or at an explicit indication that = the message was delivered. For resume requests, such indication can be that the requested stream gets delivered. For paused indications <...text to be inserted, reflecting upcoming agreement from this discuss= ion...> Section 6.4 Local Paused State: This state can be entered at any time, based on local decision from the RTP stream sender. As for Paused State (Section 6.3), the RTP stream sender SHALL send a PAUSED indication to all known RTP stream receivers, when entering the state, and repeat it in the next two regular RTCP reports, unless the stream was already in paused state (Section 6.3). I suggest to amend this to something like: This state can be entered at any time, based on local decision from the RTP stream sender. As for Paused State (Section 6.3), the RTP stream sender SHALL send a PAUSED indication to all known RTP stream receivers, when entering the state, and repeat it until <...condition to be defined...>, unless the stream was already in paused state (Section 6.3). Section 8.5 Transmission Rules: o The first transmission of PAUSED for each (non-wrapped) PauseID SHOULD be sent with Immediate or Early timing, while subsequent PAUSED for that PauseID SHOULD use Regular timing. o RESUME SHOULD always use Immediate or Early timing. I suggest to change this to: o The first transmission of PAUSED for each (non-wrapped) PauseID SHOULD be sent with Immediate or Early timing, while subsequent PAUSED for that PauseID SHOULD use Regular timing. Unsolicited PAUSED SHOULD always use Immediate or Early timing, until PAUSED for that PauseID is considered delivered at least once by all receivers of the paused RTP stream, after which it SHOULD use Regular timing. <...text about when "considered delivered" is true...> o RESUME SHOULD always use Immediate or Early timing. >=20 > > I don't know if this is sufficient. The major difference between > > PAUSED and RESUME is that PAUSED has no implicit ACK through RTP > > transmission state changes (as RESUME has), and that has to be handled > > somehow. >=20 > Right! >=20 > > Assuming that we agree that unsolicited PAUSED (same for TMMBN=3D0, of > > course) must be sent in a way that tries to mitigate loss to the > > largest extent possible, given existing RTCP bandwidth, I think the > > question then becomes for how long and how often should PAUSED be > > repeated until considered received. Could we suggest to use regular > > RTCP loss reporting to make an estimate on how many times it has to be > > repeated? For example, if there is 20% loss, it takes 5 repetitions to > > get down to 0.032% loss probability for the PAUSED (given random > > loss). The overhead for that is really nothing compared to the media > > stream itself (that was just paused). Specifying even more repetitions > > should not be a problem, just being limited by the available RTCP > > bandwidth and timing! >=20 > I think this is a good idea. Just to be clear, are you intentionally avoi= ding the possibility for using a retransmit-until-acked > mechanism? [BoB] I am trying to understand if this can work sufficiently well without = it, yes. If we decide that we indeed need a PAUSED-ACK, do you think that PAUSE will= do (from the new messages in this draft, if using those) as confirmation? = The semantics of PAUSE is "OK, I don't need this stream right now", and is = thus not in any way mandating to pause the (in this case already paused) st= ream. This should be fully consistent with the RTP stream receiver being ab= le to send a RESUME (TMMBR > 0) at a later point in time to try to resume t= he stream, even if the RTP stream sender has the last say for a locally pau= sed stream as long as the "local consideration" still applies. If this use = of PAUSE is not clear enough, we may need to consider defining a new messag= e. Even if (new message from this draft) PAUSE semantics is OK as PAUSED ACK, = and even if PAUSE is "normally" equivalent to TMMBR=3D0, it would obviously= not always be appropriate to use TMMBR=3D0 as TMMBN=3D0 confirmation, sinc= e the RTP stream sender then cannot resume the RTP stream unless the stream= receiver explicitly allows it by sending a TMMBR>0. Regardless if we use PAUSE or some new message as PAUSED-ACK for the new me= ssages defined in this draft, I agree with your proposal that for "TMMBR/TM= MBN-mode" it would likely work to use TMMBN=3D0 with the same SSRC as in th= e ACK'ed TMMBN=3D0. This, since the SSRC in the TMMBN FCI expresses the own= er of the tuple and is semantically correct regardless of which way it is s= ent. SSRC of packet sender must of course be set correctly to the source of= the notification, which will be different in the two directions (for TMMBN= =3D0 and TMMBN=3D0-ACK). >=20 > Are you thinking that having to wait for an ACK may incur so much latency= that the receiver could have a good guess that > transmission has stopped? [BoB] That is a possibility I would like to explore, yes. >=20 > > Do we need a new use case (section 3) and design consideration > > (section 4) for timing of unsolicited PAUSED? I think that might be > > appropriate! >=20 > If you decide that's necessary I can try to send some text next week. [BoB] I think it will at least help make the motivations for choosing this = strict PAUSED timing more clear to future readers. Text proposals are welco= me. >=20 > Emil >=20 > >> -----Original Message----- From: avtext > >> [mailto:avtext-bounces@ietf.org] On Behalf Of Emil Ivov Sent: den > >> 23 oktober 2014 23:41 To: Roni Even; avtext@ietf.org Subject: Re: > >> [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 > >> > >> Hey Roni, > >> > >> On 23.10.14, 13:08, Roni Even wrote: > >>> Hi Emil, OK, now I got it. I agree that we need some text addressing > >>> reliability of the unsolicited TMMBN and PAUSED. I think I got > >>> confused by the work acknowledging and it seems to me that Bo had > >>> the same problem. But still since RTCP is runs over UDP there is > >>> still no guarantee that the RTCP packet will arrive even if we sent > >>> it with every scheduled RTCP packet. > >>> > >>> I agree that it will be good to add text about the unreliability of > >>> these indications and propose to repeat them based on implementation > >>> decision. > >> > >> I wonder if we could come up with an easy way to ACK the TMMBN=3D0 ... > >> how about resending the same TMMBN=3D0 (with the same SSRCs) in the > >> opposite direction? > >> > >> Emil > >> > >> > >>> > >>> Roni > >>> > >>>> -----Original Message----- From: Emil Ivov [mailto:emcho@jitsi.org] > >>>> Sent: 23 October, 2014 1:05 PM To: > >>>> Roni Even; avtext@ietf.org Subject: Re: [avtext] WGLC for > >>>> draft-ietf-avtext-rtp-stream-pause-02 > >>>> > >>>> Hey Roni, > >>>> > >>>> On 23.10.14, 10:49, Roni Even wrote: > >>>>> Hi Emil, I am not sure what is the case you describe. My view is > >>>>> that an SFU ( I assume it is a conferencing bridge?) may use > >>>>> TMMBR/PAUSE to stop unused video streams, these are acknowledged > >>>>> messages by the sender. > >>>> > >>>> Correct! > >>>> > >>>>> Another example is that for some reason a current sender will > >>>>> Pause a stream (I would think that it will be a stream not used > >>>>> currently) even though it did not get a TMMBR/PAUSE by learning > >>>>> somehow that the > >>>> stream is unused. > >>>>> This will be unsolicited. > >>>> > >>>> Learning that a stream is unused is not the only reason why a > >>>> Sender can > >>> stop > >>>> streaming something. The sender can also drop a stream because it > >>>> detected congestion. > >>>> > >>>>> If I understand you have another case where a sender will pause, > >>>>> for some reason, a stream in use by the SFU and may send a > >>>>> TMMBN=3D0/PAUSED for this stream. Are you asking for a method by > >>>>> which the SFU will know if the sender supports TMMBN=3D0/PAUSED and > >>>>> will always send it when pausing a stream in use? I am not sure > >>>>> what is Acknowledge by the SFU to the media sender is and when is > >>>>> it sent, for this case? > >>>> > >>>> An unsolicited TMMBN=3D0 (as any RTCP message sent over UDP) can be > >>>> lost. If that happens the Receiver/SFU would not know that an > >>>> in-use stream is > >>> being > >>>> intentionally dropped. That unsolicited TMMBN=3D0 would need to be > >>>> retransmitted by the Sender until it is eventually received by the > >>> Receiver. > >>>> > >>>> That's what I am asking for and that's what I am calling "making it > >>> reliable". > >>>> > >>>> Is this clearer now? > >>>> > >>>> Emil > >>>> > >>>> > >>>>> Roni > >>>>> > >>>>> > >>>>>> -----Original Message----- From: Emil Ivov > >>>>>> [mailto:emcho@jitsi.org] Sent: 22 October, 2014 8:01 PM To: > >>>>>> Roni Even; avtext@ietf.org Subject: Re: [avtext] WGLC for > >>>>>> draft-ietf-avtext-rtp-stream-pause-02 > >>>>>> > >>>>>> Hey Roni, > >>>>>> > >>>>>> On 22.10.14, 08:29, Roni Even wrote: > >>>>>>> Hi Emil, The unsolicited PAUSED or TMMBN=3D0 are an > >>>>>>> indication that the sender stopped sending the stream, > >>>>>> > >>>>>> Yes, it is. > >>>>>> > >>>>>>> I am not sure it needs to be acknowledged, the procedure > >>>>>>> is to repeat the message and send it when a new party > >>>>>>> joins the RTP session. > >>>>>> > >>>>>> I am not sure I follow you here. The point is that an SFU > >>>>>> may want to rely > >>>>> on > >>>>>> unsolicited PAUSED/TMMBNs in order to switch from one > >>>>>> simulcast stream to another, or to potentially drop a > >>>>>> sender from the SSRCs that it is sending > >>>>> to a > >>>>>> receiver and replace it with another sender. This would be > >>>>>> the case in > >>>>> large > >>>>>> conferences where only receiver is only getting a subset of > >>>>>> the > >>>>> participants. > >>>>>> > >>>>>> In order to rely on receiving TMMBNs, the SFU would need to > >>>>>> know that they are reliable though. > >>>>>> > >>>>>> So in other words: Yes! The sender does not need a response > >>>>>> for its > >>>>> indication. > >>>>>> It is the receiver that needs to know that it can rely on > >>>>>> receiving the > >>>>> indication. > >>>>>> > >>>>>>> The sender does not need any respond from the receiver > >>>>>>> for this indication > >>>>>> > >>>>>> Cheers, Emil > >>>>>> > >>>>>>> Roni > >>>>>>> > >>>>>>>> -----Original Message----- From: avtext > >>>>>>>> [mailto:avtext-bounces@ietf.org] On Behalf Of Emil > >>>>>>>> Ivov Sent: 17 October, 2014 9:46 PM To: DRAGE, Keith > >>>>>>>> (Keith); avtext@ietf.org Subject: Re: [avtext] WGLC > >>>>>>>> for draft-ietf-avtext-rtp-stream-pause-02 > >>>>>>>> > >>>>>>>> I went quickly over the draft and have one question. > >>>>>>>> > >>>>>>>> I didn't see anything about acknowledging TMMBNs. > >>>>>>>> Specifically > >>>> TMMBN=3D0. > >>>>>>>> > >>>>>>>> A sender may single-sidedly decide to drop a high > >>>>>>>> quality simulcast or an > >>>>>>> SST- > >>>>>>>> MS SVC layer for congestion control reasons. TMMBN=3D0 > >>>>>>>> would come very handy in that case as it would allow a > >>>>>>>> receiving SFU to quickly switch to > >>>>>>> a lower > >>>>>>>> quality layer. > >>>>>>>> > >>>>>>>> Wouldn't it be a good idea to cover this? > >>>>>>>> > >>>>>>>> -- https://jitsi.org > >>>>>>>> > >>>>>>>> _______________________________________________ avtext > >>>>>>>> mailing list avtext@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/avtext > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- https://jitsi.org > >>>>> > >>>>> > >>>> > >>>> -- https://jitsi.org > >>> > >>> > >> > >> -- https://jitsi.org > >> > >> _______________________________________________ avtext mailing > >> list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext > > >=20 > -- > https://jitsi.org From nobody Mon Oct 27 16:49:09 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0241A012D; Mon, 27 Oct 2014 16:49:03 -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 C_FWhVv4RlVI; Mon, 27 Oct 2014 16:49:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 099931A1B01; Mon, 27 Oct 2014 16:49:01 -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.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027234901.3692.59843.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 16:49:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/jjnDuKhwdqSeX2hSp0KBTrnD_Cg Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-05.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:49:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : RTP Stream Pause and Resume Authors : Bo Burman Azam Akram Roni Even Magnus Westerlund Filename : draft-ietf-avtext-rtp-stream-pause-05.txt Pages : 49 Date : 2014-10-27 Abstract: With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTCP feedback package by explicitly allowing and describing specific use of existing CCM messages and adding a group of new real- time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rtp-stream-pause-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 28 05:11:03 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C996E1A6FBE for ; Tue, 28 Oct 2014 05:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 UYvl_-2pNWeJ for ; Tue, 28 Oct 2014 05:10:28 -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 6F11C1A87EC for ; Tue, 28 Oct 2014 05:05:52 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-c0-544f869e9d65 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F6.75.04231.E968F445; Tue, 28 Oct 2014 13:05:50 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.247]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 13:05:49 +0100 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: I-D Action: draft-ietf-avtext-rtp-stream-pause-05.txt Thread-Index: AQHP8kChh27zWRBAGkCzoehY8v0mWpxFaXBw Date: Tue, 28 Oct 2014 12:05:49 +0000 Message-ID: References: <20141027234901.3692.59843.idtracker@ietfa.amsl.com> In-Reply-To: <20141027234901.3692.59843.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje68Nv8Qg40zNCw+3rvB6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDO/pjIWzBavOHjhC3sD4wKhLkZODgkBE4kZB28xQthiEhfu rWfrYuTiEBI4wihxaf5sFghnCaPE6Zcz2UGq2AQ0JObvuAvWISKgLnFn+gU2EFtYwEni0dxn bBBxZ4mbCyeyQNhGEue37gWrZxFQlVi/6jsziM0r4Ctx8O8BsHohAQeJyS++gM3nFHCUuNV3 AcxmFJCVuP/9HtgcZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/rBC2osTV6cuZIOp1JBbs/sQG YWtLLFv4GmqvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbQ4tbg4N93IWC+1KDO5uDg/ Ty8vtWQTIzAqDm75rbuDcfVrx0OMAhyMSjy8G9j8Q4RYE8uKK3MPMUpzsCiJ8y46Ny9YSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2P+cZ4fzbUbf6TurXvtWq6iuOfafdeSDZbLbMMbomct qZgUfKNgwhbes53GP/373xwz3ZhueGDfrJBgPosfDhHVQvWzk5NvLykx1f4T8v7yTNf0s9Zf 3mxq+Fr07ZpA/Kef+3fashqb5uVOcftpmHK6adm/Yypumnf26l+vU9u5mvf3/2P1SSuVWIoz Eg21mIuKEwFni9ivawIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/e0pjUYG2CduxJuULO7QLA4U9968 Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-stream-pause-05.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 12:10:31 -0000 This version contains changes related to what I believe to be our common un= derstanding so far on timing and reliability of unsolicited PAUSED (TMMBN= =3D0), as discussed on this list. I think it is already pretty far progress= ed, but will need some more discussion until fully concluded. There are a f= ew Editor's notes in places where I expect that more text may be needed. Cheers, Bo > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 28 oktober 2014 00:49 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: I-D Action: draft-ietf-avtext-rtp-stream-pause-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Extensions Workin= g Group of the IETF. >=20 > Title : RTP Stream Pause and Resume > Authors : Bo Burman > Azam Akram > Roni Even > Magnus Westerlund > Filename : draft-ietf-avtext-rtp-stream-pause-05.txt > Pages : 49 > Date : 2014-10-27 >=20 > Abstract: > With the increased popularity of real-time multimedia applications, > it is desirable to provide good control of resource usage, and users > also demand more control over communication sessions. This document > describes how a receiver in a multimedia conversation can pause and > resume incoming data from a sender by sending real-time feedback > messages when using Real-time Transport Protocol (RTP) for real time > data transport. This document extends the Codec Control Messages > (CCM) RTCP feedback package by explicitly allowing and describing > specific use of existing CCM messages and adding a group of new real- > time feedback messages used to pause and resume RTP data streams. > This document updates RFC 5104. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-rtp-stream-pause-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-stream-pause-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt From nobody Tue Oct 28 09:01:20 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2BC1A901C for ; Tue, 28 Oct 2014 09:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwLY5htjecHh for ; Tue, 28 Oct 2014 09:01:18 -0700 (PDT) Received: from server209.appriver.com (server209i.appriver.com [8.31.233.124]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FC71A8AF2 for ; Tue, 28 Oct 2014 09:01:06 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/28/2014 12:01:05 PM X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 10/17/2014 9:19:05 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-258/SG:2 10/28/2014 12:00:22 PM X-GBUdb-Analysis: 0, 67.231.149.202, Ugly c=0.751056 p=-0.968558 Source White X-Signature-Violations: 0-0-0-2825-c X-Note-419: 15.627 ms. Fail:0 Chk:1329 of 1329 total X-Note: SCH-CT/SI:0-1329/SG:1 10/28/2014 12:00:57 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.149.202 X-Note-Reverse-DNS: mx0a-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G237 G238 G239 G240 G244 G245 G357 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.149.202] (HELO mx0a-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTP id 22538916 for avtext@ietf.org; Tue, 28 Oct 2014 12:01:05 -0400 Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id s9SFxkoV026613 for ; Tue, 28 Oct 2014 12:01:05 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1qa6fs0342-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 28 Oct 2014 12:01:05 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 11:01:04 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Call for agenda requests: AVTEXT at IETF 91 Thread-Index: AQHP8shfN5ib8xD+Ekix31bIZMdqlA== Date: Tue, 28 Oct 2014 16:01:03 +0000 Message-ID: <80E8B201-A3E8-4B55-8A49-4A1E393464AD@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <94235601B46EC64ABCE35322EB89BD03@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-28_07:2014-10-28,2014-10-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410280149 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/tVEtl5lZPzJjnC8a5A3QjgrkljY Subject: [avtext] Call for agenda requests: AVTEXT at IETF 91 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:01:19 -0000 AVTEXT is scheduled to meet for two hours at IETF 91: TUESDAY, November 11, 2014 1520-1720 Afternoon Session II Kahili RAI avtext Audio/Video Transport Extensions WG Please send the chairs requests for agenda items. Please indicate what draft you wish to discuss, who will be presenting, and= how much time you think would be appropriate. Priority will be given to working group items. Thank you! Jonathan Lennox AVTEXT co-chair= From nobody Fri Oct 31 14:22:35 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F220E1A1B96 for ; Fri, 31 Oct 2014 14:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33TgfKHo_hwd for ; Fri, 31 Oct 2014 14:22:33 -0700 (PDT) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5AE1A1B8A for ; Fri, 31 Oct 2014 14:22:33 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/31/2014 5:22:29 PM X-Policy: vidyo.com - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 10/17/2014 9:19:05 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-208/SG:2 10/31/2014 5:22:17 PM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.752802 p=-0.962366 Source White X-Signature-Violations: 0-0-0-4000-c X-Note-419: 0 ms. Fail:0 Chk:1329 of 1329 total X-Note: SCH-CT/SI:0-1329/SG:1 10/31/2014 5:22:17 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL->UNITED STATES-> X-Note-Sending-IP: 67.231.157.197 X-Note-Reverse-DNS: mx0b-00198e01.pphosted.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G241 G242 G243 G244 G248 G249 G361 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [67.231.157.197] (HELO mx0b-00198e01.pphosted.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTP id 23678625 for avtext@ietf.org; Fri, 31 Oct 2014 17:22:29 -0400 Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id s9VLGmUK023411 for ; Fri, 31 Oct 2014 17:22:29 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1qbtfr8j3n-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 31 Oct 2014 17:22:29 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 16:22:28 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: Agenda for AVTEXT meeting in Honolulu Thread-Index: AQHP9VDFwS41Mz3YwkSDZ5VJ6/vejw== Date: Fri, 31 Oct 2014 21:22:28 +0000 Message-ID: <9AADAB5A-8215-4CF9-BCAB-DB1E793B39BD@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: <52160E099E56A04A8B99F2C9035E5CBC@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-31_08:2014-10-31,2014-10-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410310203 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/7Or9T9zAJbIhKAayb1VMya1chg0 Subject: [avtext] Agenda for AVTEXT meeting in Honolulu X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 21:22:35 -0000 Hello, all =97 Here is the draft agenda for the AVTEXT meeting in Honolulu. Please send a= ny comments, suggestions, or additions to the chairs. AVTEXT Audio/Video Transport Extensions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tuesday 15:20 - 17:20 HST (Kahili) Chairs: Keith Drage / Jonathan Lennox 15:20 Agenda bash, status update, and review of related protocol items (10 min) Chairs draft-ietf-avtext-splicing-notification-00 At least two reviewers required. =20 draft-uberti-payload-vp9-00 Review proposed feedback message. 15:30 Taxonomy (30 min) Bo Burman draft-ietf-avtext-rtp-grouping-taxonomy-02 Complete all open issues in order to start WGLC immediately following IETF 91. =20 16:00 RTP Stream Pause / Resume (30 min) Bo Burman draft-ietf-avtext-rtp-stream-pause-05 Close all open issues to enable publication request. 16:30 Header Extension for SDES Items (20 min) Mo Zanaty draft-westerlund-avtext-sdes-hdr-ext-02=20 Decide whether should be adopted as WG item. 16:50 Close