From nobody Wed Aug 6 03:19:21 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 CD91D1B2D12 for ; Wed, 6 Aug 2014 03:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 o2JqlVzY6KQu for ; Wed, 6 Aug 2014 03:19:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3301B28B9 for ; Wed, 6 Aug 2014 03:19:18 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A866EA2E38C3E for ; Wed, 6 Aug 2014 10:19:14 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s76AJG13018135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Aug 2014 12:19:16 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 6 Aug 2014 12:19:16 +0200 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: WGLC for draft-ietf-avtext-rtp-stream-pause-02 Thread-Index: Ac+oI8943NA5z66dRdGqdkJ2oCY7RQJO/uWw Date: Wed, 6 Aug 2014 10:19:15 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B21A72B@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/TBbdfPCdPF1begLPcwZa4ZVm7ZM 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, 06 Aug 2014 10:19:20 -0000 A reminder of the working group last call on this document. Please respond. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: 25 July 2014 17:17 > To: avtext@ietf.org > Subject: WGLC for draft-ietf-avtext-rtp-stream-pause-02 >=20 > (As WG cochair) >=20 > This is to announce a Working Group Last Call on=20 >=20 > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ >=20 > draft-ietf-avtext-rtp-stream-pause-02 >=20 > Please comment on the document by August 18th, 2014. >=20 > Comments preferably to the AVTEXT list. >=20 > It is helpful if you categorise your comments into Editorial,=20 > Minor technical, Major issue. >=20 > The author has posed some open questions to the list. The=20 > chairs do not believe this should impact the appriateness of=20 > starting the WGLC now. However do please respond to those questions. >=20 > The chairs realise this is a period when people will be=20 > disappearing on leave - if you intend commenting on the=20 > document but such leave means you need more time, please=20 > email the chairs with that information and when you think you=20 > might complete a WGLC review. >=20 >=20 >=20 > Regards >=20 > Keith= From nobody Mon Aug 18 04:03:08 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 BFCD31A0383 for ; Mon, 18 Aug 2014 04:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5bq0T1Tb1T6 for ; Mon, 18 Aug 2014 04:03:04 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF54D1A039B for ; Mon, 18 Aug 2014 04:03:03 -0700 (PDT) Received: from ppp118-209-81-109.lns20.mel4.internode.on.net ([118.209.81.109]:49914 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJKhb-0002CE-Aa for avtext@ietf.org; Mon, 18 Aug 2014 21:02:15 +1000 Message-ID: <53F1DD5D.6030204@nteczone.com> Date: Mon, 18 Aug 2014 21:02:53 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: 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 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/RU1QhsFqp7fg3MXHq1KJsdRHJwM 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, 18 Aug 2014 11:03:05 -0000 On reading the draft I didn't really see a discussion regarding the pause / resume point. E.g. an RTP receiver could request a pause in the transmission of RTP and then at a later point request a resumption of the stream. I assume there would be two options for the sender. (1) Continue sending RTP packets related to media from the time of the pause OR (2) send RTP packets from the time of the resumption. E.g. the RTP stream may relate to a movie, the initial pause point is 5min into the movie, a request for resumption occurs 2min after. The sender could send RTP related to the media from the 5min or 7min point in the movie. For a real time voice stream probably only (2) makes sense. Is the assumption of the draft that only option (2) is supported? The other question is related to media sender pause/resume. Cl.5.3 of the draft indicates that the RTP sender can choose to pause a stream at any time. However cl.5.4 only mentions that the RTP receiver can request to resume a stream. Is this intentional? I would have thought the sender could also decide to resume at any time? Regards, Christian On 26/07/2014 2:36 AM, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > This is to announce a Working Group Last Call on > > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ > > draft-ietf-avtext-rtp-stream-pause-02 > > Please comment on the document by August 18th, 2014. > > Comments preferably to the AVTEXT list. > > It is helpful if you categorise your comments into Editorial, Minor technical, Major issue. > > The author has posed some open questions to the list. The chairs do not believe this should impact the appriateness of starting the WGLC now. However do please respond to those questions. > > The chairs realise this is a period when people will be disappearing on leave - if you intend commenting on the document but such leave means you need more time, please email the chairs with that information and when you think you might complete a WGLC review. > > > > Regards > > Keith > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > From nobody Tue Aug 19 01:34:12 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 34C771A0363 for ; Tue, 19 Aug 2014 01:34:11 -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 AsbOZ5N_yimR for ; Tue, 19 Aug 2014 01:34:08 -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 109641A0347 for ; Tue, 19 Aug 2014 01:34:07 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-56-53f30bfee1cb Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 44.17.24955.EFB03F35; Tue, 19 Aug 2014 10:34:06 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.48]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Tue, 19 Aug 2014 10:34:05 +0200 From: Bo Burman To: Christian Groves , "avtext@ietf.org" Thread-Topic: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 Thread-Index: Ac+oI8943NA5z66dRdGqdkJ2oCY7RQSn2IaAAC2sUTA= Date: Tue, 19 Aug 2014 08:34:04 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53F1DD5D.6030204@nteczone.com> In-Reply-To: <53F1DD5D.6030204@nteczone.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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje4/7s/BBj/WiFp8vHeD1eLL+0YW ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugStjzqd3rAWT9Cv+9LcyNTC+Vu1i5OSQEDCR +HF1JyuELSZx4d56ti5GLg4hgaOMErfm/GeCcBYzSjR/WMYIUsUmoCExf8ddMFtEIFpia89n ZhBbWMBVYuqje8wQcTeJX3d2skHYVhJfpq5hB7FZBFQlzjW+BdvGK+Ar0dJzhQXEFhKokfh9 5B0TiM0poCOxdcVqsHpGAVmJ+9/vgdUwC4hL3HoynwniUgGJJXvOM0PYohIvH/+D+kBRYufZ dmaIeh2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLU7K TTcy1kstykwuLs7P08tLLdnECIyUg1t+q+5gvPzG8RCjAAejEg/vA7ZPwUKsiWXFlbmHGKU5 WJTEeReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbEuTFyvpXT+NBnd56cTuSWYp9dt Ovdi78qTP+7/2KEWlHPR/vym2GlslyJCMydXP4uKyfiU1h38P3LalY+9WgESOt8VTt7qDl28 9naExtt1Vzimq3vYtG3bVVHPLBBRbjLz7fEjhhtn7uhd1ngr9ndAtcp1l7krbhyNuvbTRfby rm2TZN9FmbxSYinOSDTUYi4qTgQA712RBXUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/HTexInpNT6Ez9FtQ9kHF_gy8toY 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, 19 Aug 2014 08:34:11 -0000 Thank you for the review! Regarding your first question, the assumption was that the scope is real-ti= me streams and thus only (2) makes sense, as you say. To maybe state the ob= vious, it does not make much sense to specify for a real-time (live) media = source that pausing should start buffering data at the sender, where a resu= me would then start to play out data that may be several minutes old. I als= o assume that a movie-player type application would not have the real-time = requirements on the signaling that motivates the use of this draft, but tha= t it rather uses RTSP or some other media-player protocol that often has th= e possibility to explicitly specify resume points. I think it makes sense to be clear and include a few sentences on pause / r= esume point at least in 4.1 "Real-time Nature", but maybe also point it out= again in 5.4 "Requesting to Resume". Do you agree? Regarding your second question, it sounds reasonable that a media sender ca= n have some local considerations (not a RESUME request from someone else) t= hat makes it decide to resume transmission. This local decision to resume a= stream can be seen as the media sender sending RESUME to itself (internall= y), similar to that pausing a stream based on a local decision can be seen = as the media sender sending PAUSE to itself (internally). I would however b= e interested to know if you have some concrete example scenario as to when = this could happen? I would expect such conditions making a media sender resume a stream based = on local considerations include the ones described in the next-to-last para= graph of 5.2, where local considerations makes a media sender REFUSE to pau= se a stream. I suggest including a sentence in 5.4 that a media sender MAY resume a paus= ed stream at any point in time due to local considerations. It should then = be pointed out (in line what is already described in next-to-last paragraph= of 5.2) that for the case when the *media receiver* paused the stream usin= g TMMBR 0, this "local resume" is not permitted, since it is incompatible w= ith the TMMBR semantics! It would however be OK either when (only) the medi= a sender paused the stream due to local considerations, or when using PAUSE= /RESUME messages defined in this draft. OK? To elaborate further, for the case of TMMBR/TMMBN signaling and assuming th= at the media sender has paused the stream due to local considerations, the = PAUSED indication would be a TMMBR 0 containing the media sender itself (SS= RC) as owning the bitrate (0) restriction. A media receiver that does not n= eed to receive the (already paused) RTP stream could also send a TMMBR 0, a= nd the restriction would then be jointly owned by both RTP end points. Assu= me that the local restrictions at the media sender that made it pause the s= tream in the first place are lifted, and following CCM [RFC 5104] rules, a = new TMMBR 0 would be sent out where the media sender SSRC is no longer in t= he bounding set, only the media receiver. Even though the media sender is O= K with not having the stream paused any longer, the media receiver still de= sires it to be paused and TMMBR semantics requires the bitrate to be kept a= t 0.=20 Cheers, Bo > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Christian Grov= es > Sent: den 18 augusti 2014 13:03 > To: avtext@ietf.org > Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >=20 > On reading the draft I didn't really see a discussion regarding the pause= / resume point. E.g. an RTP receiver could request > a pause in the transmission of RTP and then at a later point request a re= sumption of the stream. I assume there would be > two options for the sender. (1) Continue sending RTP packets related to m= edia from the time of the pause OR (2) send > RTP packets from the time of the resumption. E.g. the RTP stream may rela= te to a movie, the initial pause point is 5min > into the movie, a request for resumption occurs 2min after. The sender co= uld send RTP related to the media from the > 5min or 7min point in the movie. For a real time voice stream probably on= ly (2) makes sense. Is the assumption of the > draft that only option (2) is supported? >=20 > The other question is related to media sender pause/resume. Cl.5.3 of the= draft indicates that the RTP sender can choose > to pause a stream at any time. However cl.5.4 only mentions that the RTP = receiver can request to resume a stream. Is this > intentional? I would have thought the sender could also decide to resume = at any time? >=20 > Regards, Christian >=20 > On 26/07/2014 2:36 AM, DRAGE, Keith (Keith) wrote: > > (As WG cochair) > > > > This is to announce a Working Group Last Call on > > > > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ > > > > draft-ietf-avtext-rtp-stream-pause-02 > > > > Please comment on the document by August 18th, 2014. > > > > Comments preferably to the AVTEXT list. > > > > It is helpful if you categorise your comments into Editorial, Minor tec= hnical, Major issue. > > > > The author has posed some open questions to the list. The chairs do not= believe this should impact the appriateness of > starting the WGLC now. However do please respond to those questions. > > > > The chairs realise this is a period when people will be disappearing on= leave - if you intend commenting on the > document but such leave means you need more time, please email the chairs= with that information and when you think > you might complete a WGLC review. > > > > > > > > Regards > > > > Keith > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Aug 19 23:36:08 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 2E9D21A890B for ; Tue, 19 Aug 2014 23:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 2JWCdf66qG89 for ; Tue, 19 Aug 2014 23:36:03 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13621A8A39 for ; Tue, 19 Aug 2014 23:36:02 -0700 (PDT) Received: from ppp118-209-164-72.lns20.mel6.internode.on.net ([118.209.164.72]:54793 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJzUs-0007c5-Qp; Wed, 20 Aug 2014 16:35:51 +1000 Message-ID: <53F441C3.5050201@nteczone.com> Date: Wed, 20 Aug 2014 16:35:47 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bo Burman , "avtext@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53F1DD5D.6030204@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/5Nnnof-p8P70eP0SjulHyE9pzJg 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, 20 Aug 2014 06:36:06 -0000 Hello Bo, Thanks for your response. Please see my responses below and some further = comments: 1) A minor nit: The headings titles for 4.5 and 12 are the same. Maybe=20 change 4.5 to "Message acknowledgements". 2) Clause 9: Use of PAUSE and PAUSED: I must admit I find the=20 distinction between these two parameters really confusing. Especially=20 when the draft says that they are different functions but that "pause"=20 encompasses "paused". It is really necessary to have two parameters? It=20 seems that a node can do the following with respect to the messages: a) Both send and receive PAUSE, RESUME, PAUSED and REFUSE b) Send PAUSE, RESUME and receive PAUSED and REFUSE only c) Receive PAUSE, RESUME and send PAUSED and REFUSE only d) Do not receive messages but send a PAUSED only. The issue seems to come when considering the local PAUSE functionality.=20 As the draft notes that "pause" contains the full "paused"=20 functionality", I could assume that a) b) and c) contain the local PAUSE = functionality. d) would also have to contain the local PAUSE=20 functionality. However I'm not sure b) would be valid because the node=20 would have to be able to send PAUSED as a result of clause 5.3. Whilst=20 the intent is that 'pause' and 'paused' are different functions there=20 would appear to be interactions. e.g. It would be strange to set=20 'pause=3Drecvonly' and 'paused=3Drecvonly'. I think the usage at least needs to be clarified as there appears to be=20 some overlap and inconsistencies with other sections. Preferably it=20 would be good to try to use one parameter. 3) Clause 5.1 indicates "/ Capability to understand PAUSED=20 indication is defined separately from the others to support partial=20 implementation, which is specifically believed to be feasible for the=20 RTP Mixer to Media Sender use case (Section 3.2)./" I guess the=20 important thing is that its the media sender that must at least support=20 the PAUSED indication, the mixer needs to support PAUSE. 4) Clause 10.1 paragraph below the figure. Indicates "/includes the=20 "nowait" sub-parameter for both "pause" and "paused" parameters/"=20 however the nowait parameter is only specified in the example offer for=20 pause + nowait is not defined for paused in the ABNF syntax. The last=20 paragraph in clause 9.1 also indicates that possibility to support=20 "nowait" for "paused" i.e. "/The answerer MUST NOT add "nowait" on the=20 "pause" line in the answer unless it is present on the "paused" line in=20 the offer./" This isn't possible due to the syntax. 5) Clause 9.1 paragraph 2: "/In other words, an offer for "paused=20 dir=3Dsendonly" means that the offerer intends to send PAUSED indications= =20 whenever it pauses RTP stream delivery in any of its streams./" Would a=20 pause in one stream require sending a PAUSED indication in multiple strea= ms? 6) Clause 9.1 para.1 nit: "...functionality if the answer.." 7) Clause 9.2 first paragraph: The third sentence indicates that it is=20 normally only necessary to include either "pause" or "paused" however=20 clause 9 indicates "SHOULD" for including both and clause 9.1 indicates=20 "is RECOMMENDED" to include both. It seems the reasoning to use both is=20 the same for O/A and declarative use, i.e. implementations may have=20 different support levels. Regards, Christian On 19/08/2014 6:34 PM, Bo Burman wrote: > Thank you for the review! > > Regarding your first question, the assumption was that the scope is rea= l-time streams and thus only (2) makes sense, as you say. To maybe state = the obvious, it does not make much sense to specify for a real-time (live= ) media source that pausing should start buffering data at the sender, wh= ere a resume would then start to play out data that may be several minute= s old. I also assume that a movie-player type application would not have = the real-time requirements on the signaling that motivates the use of thi= s draft, but that it rather uses RTSP or some other media-player protocol= that often has the possibility to explicitly specify resume points. > > I think it makes sense to be clear and include a few sentences on pause= / resume point at least in 4.1 "Real-time Nature", but maybe also point = it out again in 5.4 "Requesting to Resume". Do you agree? [CNG] I agree with your reasoning. I think it would be good to add some=20 sentences to clarify this. Perhaps it would also be worth adding a=20 formal definition for the term "pause"? I think naturally people assume=20 the media player usage of the term as to expected behaviour as that's=20 what they are used to. > > Regarding your second question, it sounds reasonable that a media sende= r can have some local considerations (not a RESUME request from someone e= lse) that makes it decide to resume transmission. This local decision to = resume a stream can be seen as the media sender sending RESUME to itself = (internally), similar to that pausing a stream based on a local decision = can be seen as the media sender sending PAUSE to itself (internally). I w= ould however be interested to know if you have some concrete example scen= ario as to when this could happen? [CNG] I don't have a particular scenario in mind. The question was=20 largely triggered by the ability in 5.3 to have a local PAUSE. It seemed = that if there were local conditions that triggered a PAUSE that the=20 clearing of those conditions may result in a resumption of RTP flow. > > I would expect such conditions making a media sender resume a stream ba= sed on local considerations include the ones described in the next-to-las= t paragraph of 5.2, where local considerations makes a media sender REFUS= E to pause a stream. [CNG] Not sure. "local conditions" are really enumerated by the draft.=20 There could be media processing reasons e.g. para 2 clause 5.3. It could = be related to a service e.g. hold etc. > > I suggest including a sentence in 5.4 that a media sender MAY resume a = paused stream at any point in time due to local considerations. It should= then be pointed out (in line what is already described in next-to-last p= aragraph of 5.2) that for the case when the *media receiver* paused the s= tream using TMMBR 0, this "local resume" is not permitted, since it is in= compatible with the TMMBR semantics! It would however be OK either when (= only) the media sender paused the stream due to local considerations, or = when using PAUSE/RESUME messages defined in this draft. OK? [CNG] Yes this sounds OK. I agree that the resume doesn't apply when=20 TMMBR 0 is used. > > To elaborate further, for the case of TMMBR/TMMBN signaling and assumin= g that the media sender has paused the stream due to local considerations= , the PAUSED indication would be a TMMBR 0 containing the media sender it= self (SSRC) as owning the bitrate (0) restriction. A media receiver that = does not need to receive the (already paused) RTP stream could also send = a TMMBR 0, and the restriction would then be jointly owned by both RTP en= d points. Assume that the local restrictions at the media sender that mad= e it pause the stream in the first place are lifted, and following CCM [R= FC 5104] rules, a new TMMBR 0 would be sent out where the media sender SS= RC is no longer in the bounding set, only the media receiver. Even though= the media sender is OK with not having the stream paused any longer, the= media receiver still desires it to be paused and TMMBR semantics require= s the bitrate to be kept at 0. > Cheers, > Bo > >> -----Original Message----- >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Christian G= roves >> Sent: den 18 augusti 2014 13:03 >> To: avtext@ietf.org >> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >> >> On reading the draft I didn't really see a discussion regarding the pa= use / resume point. E.g. an RTP receiver could request >> a pause in the transmission of RTP and then at a later point request a= resumption of the stream. I assume there would be >> two options for the sender. (1) Continue sending RTP packets related t= o media from the time of the pause OR (2) send >> RTP packets from the time of the resumption. E.g. the RTP stream may r= elate to a movie, the initial pause point is 5min >> into the movie, a request for resumption occurs 2min after. The sender= could send RTP related to the media from the >> 5min or 7min point in the movie. For a real time voice stream probably= only (2) makes sense. Is the assumption of the >> draft that only option (2) is supported? >> >> The other question is related to media sender pause/resume. Cl.5.3 of = the draft indicates that the RTP sender can choose >> to pause a stream at any time. However cl.5.4 only mentions that the R= TP receiver can request to resume a stream. Is this >> intentional? I would have thought the sender could also decide to resu= me at any time? >> >> Regards, Christian >> >> On 26/07/2014 2:36 AM, DRAGE, Keith (Keith) wrote: >>> (As WG cochair) >>> >>> This is to announce a Working Group Last Call on >>> >>> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ >>> >>> draft-ietf-avtext-rtp-stream-pause-02 >>> >>> Please comment on the document by August 18th, 2014. >>> >>> Comments preferably to the AVTEXT list. >>> >>> It is helpful if you categorise your comments into Editorial, Minor t= echnical, Major issue. >>> >>> The author has posed some open questions to the list. The chairs do n= ot believe this should impact the appriateness of >> starting the WGLC now. However do please respond to those questions. >>> The chairs realise this is a period when people will be disappearing = on leave - if you intend commenting on the >> document but such leave means you need more time, please email the cha= irs with that information and when you think >> you might complete a WGLC review. >>> >>> >>> Regards >>> >>> Keith >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >>> >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext From nobody Wed Aug 20 00:46:10 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 419D01A008B for ; Wed, 20 Aug 2014 00:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 PDNNJworxj1D for ; Wed, 20 Aug 2014 00:46:07 -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 674F91A0060 for ; Wed, 20 Aug 2014 00:46:00 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-25-53f452361575 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.D4.21334.63254F35; Wed, 20 Aug 2014 09:45:58 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.48]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Wed, 20 Aug 2014 09:45:57 +0200 From: Bo Burman To: "Mo Zanaty (mzanaty)" , "avtext@ietf.org" , Christer Holmberg Thread-Topic: Taxonomy Thread-Index: AQHPpjNe2+XlKjJ7DkCPUQ4TsxnXHpvYH6jA Date: Wed, 20 Aug 2014 07:45:57 +0000 Message-ID: References: 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.19] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E28E549ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja5Z0Jdgg+Y7chYf791gtXjxYA6T A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXRNW8qW8GFmIqGlnlMDYynAroYOTkkBEwk th4+zA5hi0lcuLeerYuRi0NI4CijxILOs4wgCSGBxYwSW8/5g9hsAhoS83fcBYuLCHQwSsw6 VQBiCwuISrRe+cAMEReTWHlhG5RtJDHly0c2EJtFQFViUe9doGUcHLwCvhJLd2lCjNeT+NL1 lQUkzCmgL3HnSxxImFFAVuL+93ssIDazgLjErSfzmSDOFJBYsuc8M4QtKvHy8T9WCFtRov1p AyNEfb7E+W+HwHp5BQQlTs58wjKBUWQWklGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHH TMjiCxjZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExtTBLb91dzCufu14iFGAg1GJh3fB hM/BQqyJZcWVuYcYpTlYlMR5F52bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcdrt+SYn Z4o1O/U3OnWl3ure/f5RzZvTZfp/pyooh+Y6JlYKHrhRcz4n4fvE7TLTkr84crMuvS/hNcfF UHsLt8Ah9n+VdffYrOrjuY4azbVjn1Xe5cHSs8H8//qT4ZqT/mpvdD65UGqTo//Co1qxxxlk TA11FGUKi0vOyL40l/lrv67K6UuDEktxRqKhFnNRcSIArrgNkooCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/iNfDCti3WYs9PZWutdEjrGkX4D4 Subject: Re: [avtext] Taxonomy 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, 20 Aug 2014 07:46:09 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E28E549ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mo, all, see inline. From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Mo Zanaty (mzana= ty) Sent: den 23 juli 2014 07:03 To: avtext@ietf.org Subject: [avtext] Taxonomy Hi, In today's AVTEXT session, the following issues related to the taxonomy dra= ft were discussed. 1. MST/SST: I suggest new terminology focused on Single/Multiple Transport = (rather than RTP Session) combined with Single/Multiple RTP Stream. MRMT (Multiple RTP Streams over Multiple Transports) MRST (Multiple RTP Streams over Single Transport) SRST (Single RTP Stream over Single Transport) [BoB] I have no problem with that, if it can finally remove the confusion a= round this issue. 2. There is no term for referring to a media source or sink. Endpoint comes= to mind, but that is fundamentally different in -taxonomy. Terminal is ano= ther possibility, but is generally not used in RTP (outside H.323). Another= possibility is simply 'media source/sink', if the usage is not expected to= be very high. This issue came up in drafting text for the BUNDLE RTP mid, = which applies to all RTP streams between a pair of media sources/sinks. [BoB] Endpoint (or End Point) is different in -taxonomy in that a single En= d Point may handle/contain several media sources or sinks, if that is an im= portant aspect. I currently don't have a good name suggestion for a single = "media source/sink", being one part of an End Point. Suggestions are welcom= e! 3. There is no term for referring to the set of RTP streams between a media= source and sink. Transport comes to mind, but that is fundamentally differ= ent in -taxonomy. Channel is another possibility, but is generally not used= in RTP. Another possibility is simply 'RTP streams between media source/si= nk X/Y', if the usage is not expected to be very high. This issue came up i= n drafting text for the BUNDLE RTP mid, which applies to all RTP streams be= tween a pair of media sources/sinks. [BoB] Given that most applicable terms will already have been used somewher= e, I guess we cannot start totally fresh in that choosing a term will poten= tially "conflict" with existing RFCs. I see you don't suggest "RTP channel"= because it is not used, so I assume a "new" term is also not desirable? Wh= at about "RTP flow", which I have seen being used as a set of RTP streams (= one or more)? I checked its use in several RFCs and it is consistently used= that way; probably more often denoting a single RTP stream than several, b= ut I think that is manageable by including a note in -taxonomy on use of th= e term in pre-taxonomy RFCs. In that case, I think an RTP flow would have t= o be defined as distinctly different from "transport flow", which is more g= eneral and a heavily overloaded term that should probably be avoided in -ta= xonomy. Mo --_000_BBE9739C2C302046BD34B42713A1E2A22E28E549ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mo, all, see inline.

 <= /p>

From: avtext [= mailto:avtext-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty)
Sent: den 23 juli 2014 07:03
To: avtext@ietf.org
Subject: [avtext] Taxonomy

 

Hi,

In today’s AVTEXT sessio= n, the following issues related to the taxonomy draft were discussed.<= /o:p>

 

1. MST/SST: I suggest new term= inology focused on Single/Multiple Transport (rather than RTP Session) comb= ined with Single/Multiple RTP Stream.

MRMT (Multiple RTP Streams ove= r Multiple Transports)

MRST (Multiple RTP Streams ove= r Single Transport)

SRST (Single RTP Stream over S= ingle Transport)

[BoB] I have no pro= blem with that, if it can finally remove the confusion around this issue.

 

2. There is no term for referr= ing to a media source or sink. Endpoint comes to mind, but that is fundamen= tally different in -taxonomy. Terminal is another possibility, but is generally not used in RTP (outside H.323). Another possibility is s= imply ‘media source/sink’, if the usage is not expected to be v= ery high. This issue came up in drafting text for the BUNDLE RTP mid, which= applies to all RTP streams between a pair of media sources/sinks.

[BoB] Endpoint (or = End Point) is different in –taxonomy in that a single End Point may h= andle/contain several media sources or sinks, if that is an important aspect. I currently don’t have a good name suggestion for a singl= e “media source/sink”, being one part of an End Point. Sugg= estions are welcome!

 

3. There is no term for referr= ing to the set of RTP streams between a media source and sink. Transport co= mes to mind, but that is fundamentally different in -taxonomy. Channel is another possibility, but is generally not used in RTP. Another = possibility is simply ‘RTP streams between media source/sink X/Y̵= 7;, if the usage is not expected to be very high. This issue came up in dra= fting text for the BUNDLE RTP mid, which applies to all RTP streams between a pair of media sources/sinks.

[BoB] Given that mo= st applicable terms will already have been used somewhere, I guess we canno= t start totally fresh in that choosing a term will potentially “conflict” with existing RFCs. I see you don’t suggest &= #8220;RTP channel” because it is not used, so I assume a “new&#= 8221; term is also not desirable? What about “RTP flow”, which = I have seen being used as a set of RTP streams (one or more)? I checked its= use in several RFCs and it is consistently used that way; probably more often denoting a = single RTP stream than several, but I think that is manageable by including= a note in –taxonomy on use of the term in pre-taxonomy RFCs. In that= case, I think an RTP flow would have to be defined as distinctly different from “transport flow”, w= hich is more general and a heavily overloaded term that should probably be = avoided in -taxonomy.<= /span>

 

Mo

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E28E549ESESSMB105erics_-- From nobody Wed Aug 20 05:06:22 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 7D7901A0290 for ; Wed, 20 Aug 2014 05:06:19 -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, HTML_MESSAGE=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 8xUmZKlpcLSN for ; Wed, 20 Aug 2014 05:06:10 -0700 (PDT) Received: from server209.appriver.com (server209h.appriver.com [8.31.233.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49791A02D5 for ; Wed, 20 Aug 2014 05:06:08 -0700 (PDT) X-Note-AR-ScanTimeLocal: 8/20/2014 8:06:05 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: alex@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-325/SG:5 8/20/2014 8:06:03 AM X-GBUdb-Analysis: 0, 67.231.157.197, Ugly c=0.78845 p=-0.946743 Source White X-Signature-Violations: 0-0-0-24067-c X-Note-419: 31.2526 ms. Fail:1 Chk:1335 of 1335 total X-Note: SCH-CT/SI:1-1335/SG:1 8/20/2014 8:06:03 AM 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: alex@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453 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.8) with ESMTP id 148669627; Wed, 20 Aug 2014 08:06:05 -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 s7KC55wO001762; Wed, 20 Aug 2014 08:06:05 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.213] (may be forged)) by mx0b-00198e01.pphosted.com with ESMTP id 1nv9hq0fmw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 20 Aug 2014 08:06:04 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 07:06:04 -0500 From: Alex Eleftheriadis To: Bo Burman Thread-Topic: [avtext] Taxonomy Thread-Index: AQHPpjNe2+XlKjJ7DkCPUQ4TsxnXHpvYH6jAgAHF/IA= Date: Wed, 20 Aug 2014 12:06:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.131.72.96] Content-Type: multipart/alternative; boundary="_000_E9AACA7B1CF94EC5B2822A55B989DEAEvidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-20_04:2014-08-20,2014-08-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=audit_notspam policy=audit 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-1408200119 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/ZCjzGDnYER8wQeI7lANY5qkyfZs Cc: "avtext@ietf.org" , Christer Holmberg Subject: Re: [avtext] Taxonomy 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, 20 Aug 2014 12:06:20 -0000 --_000_E9AACA7B1CF94EC5B2822A55B989DEAEvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I like Mo's suggestions for (1), they appear clear enough. For (2), maybe the best choice is to avoid a specific term and use the full= "single media source/sink" or "individual media source/sink". For (3), what about distinguishing between "multiple media streams between = endpoints", vs. "multiple media streams between media sources/sinks". If th= e term "endpoint" can refer to both single and multiple sources/sinks, woul= d both cases of "multimedia media streams" be referred to as flows? Part of the problem (in my mind) with the word flow is that it is lacking t= he grouping connotation - it could equally well apply to a single media str= eam. Could "bundle" work better? --Alex On Aug 20, 2014, at 10:45 AM, Bo Burman > wrote: Hi Mo, all, see inline. From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Mo Zanaty (mzana= ty) Sent: den 23 juli 2014 07:03 To: avtext@ietf.org Subject: [avtext] Taxonomy Hi, In today=92s AVTEXT session, the following issues related to the taxonomy d= raft were discussed. 1. MST/SST: I suggest new terminology focused on Single/Multiple Transport = (rather than RTP Session) combined with Single/Multiple RTP Stream. MRMT (Multiple RTP Streams over Multiple Transports) MRST (Multiple RTP Streams over Single Transport) SRST (Single RTP Stream over Single Transport) [BoB] I have no problem with that, if it can finally remove the confusion a= round this issue. 2. There is no term for referring to a media source or sink. Endpoint comes= to mind, but that is fundamentally different in -taxonomy. Terminal is ano= ther possibility, but is generally not used in RTP (outside H.323). Another= possibility is simply =91media source/sink=92, if the usage is not expecte= d to be very high. This issue came up in drafting text for the BUNDLE RTP m= id, which applies to all RTP streams between a pair of media sources/sinks. [BoB] Endpoint (or End Point) is different in =96taxonomy in that a single = End Point may handle/contain several media sources or sinks, if that is an = important aspect. I currently don=92t have a good name suggestion for a sin= gle =93media source/sink=94, being one part of an End Point. Suggestions ar= e welcome! 3. There is no term for referring to the set of RTP streams between a media= source and sink. Transport comes to mind, but that is fundamentally differ= ent in -taxonomy. Channel is another possibility, but is generally not used= in RTP. Another possibility is simply =91RTP streams between media source/= sink X/Y=92, if the usage is not expected to be very high. This issue came = up in drafting text for the BUNDLE RTP mid, which applies to all RTP stream= s between a pair of media sources/sinks. [BoB] Given that most applicable terms will already have been used somewher= e, I guess we cannot start totally fresh in that choosing a term will poten= tially =93conflict=94 with existing RFCs. I see you don=92t suggest =93RTP = channel=94 because it is not used, so I assume a =93new=94 term is also not= desirable? What about =93RTP flow=94, which I have seen being used as a se= t of RTP streams (one or more)? I checked its use in several RFCs and it is= consistently used that way; probably more often denoting a single RTP stre= am than several, but I think that is manageable by including a note in =96t= axonomy on use of the term in pre-taxonomy RFCs. In that case, I think an R= TP flow would have to be defined as distinctly different from =93transport = flow=94, which is more general and a heavily overloaded term that should pr= obably be avoided in -taxonomy. Mo _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_E9AACA7B1CF94EC5B2822A55B989DEAEvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable I like Mo's suggestions for (1), they appear clear enough.

For (2), maybe the best choice is to avoid a specific term and use the= full "single media source/sink" or "individual media source= /sink". 

For (3), what about distinguishing between "multiple media stream= s between endpoints", vs. "multiple media streams between media s= ources/sinks". If the term "endpoint" can refer to both sing= le and multiple sources/sinks, would both cases of "multimedia media streams" be referred to as flows? 

Part of the problem (in my mind) with the word flow is that it is lack= ing the grouping connotation - it could equally well apply to a single medi= a stream. Could "bundle" work better?

--Alex

On Aug 20, 2014, at 10:45 AM, Bo Burman <bo.burman@ericsson.com> wrote:

Hi Mo, all, see inline.
 
From:<= /span> avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Mo Zanaty = (mzanaty)
Sent: den 23 juli = 2014 07:03
To: a= vtext@ietf.org
Subject: [avtext] = Taxonomy
 
Hi,
In today=92= s AVTEXT session, the following issues related to the taxonomy draft were d= iscussed.
 
1. MST/SST:= I suggest new terminology focused on Single/Multiple Transport (rather tha= n RTP Session) combined with Single/Multiple RTP Stream.<= /div>
MRMT (Multi= ple RTP Streams over Multiple Transports)
MRST (Multi= ple RTP Streams over Single Transport)
SRST (Singl= e RTP Stream over Single Transport)
[BoB] I have no problem with that, if it can finally= remove the confusion around this issue.
 
2. There is= no term for referring to a media source or sink. Endpoint comes to mind, b= ut that is fundamentally different in -taxonomy. Terminal is another possib= ility, but is generally not used in RTP (outside H.323). Another possibility is simply =91media source/sink=92= , if the usage is not expected to be very high. This issue came up in draft= ing text for the BUNDLE RTP mid, which applies to all RTP streams between a= pair of media sources/sinks.
[BoB] Endpoint (or End Point) is different in =96tax= onomy in that a single End Point may handle/contain several media sources o= r sinks, if that is an important aspect. I currently don=92t have a good name suggestion for a single =93media source/sink=94, being one part of an End Point.= Suggestions are welcome!=
 
3. There is= no term for referring to the set of RTP streams between a media source and= sink. Transport comes to mind, but that is fundamentally different in -tax= onomy. Channel is another possibility, but is generally not used in RTP. Another possibility is simply =91RTP str= eams between media source/sink X/Y=92, if the usage is not expected to be v= ery high. This issue came up in drafting text for the BUNDLE RTP mid, which= applies to all RTP streams between a pair of media sources/sinks.
[BoB] Given that most applicable terms will already = have been used somewhere, I guess we cannot start totally fresh in that cho= osing a term will potentially =93conflict=94 with existing RFCs. I see you don=92t suggest =93RTP channel=94 because it= is not used, so I assume a =93new=94 term is also not desirable? What abou= t =93RTP flow=94, which I have seen being used as a set of RTP streams (one= or more)? I checked its use in several RFCs and it is consistently used that way; probably more often denoting a single RT= P stream than several, but I think that is manageable by including a note i= n =96taxonomy on use of the term in pre-taxonomy RFCs. In that case, I thin= k an RTP flow would have to be defined as distinctly different from =93transport flow=94, which is more general a= nd a heavily overloaded term that should probably be avoided in -taxonomy.<= /span>
 
Mo
 
_______________________________________________
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/av= text

--_000_E9AACA7B1CF94EC5B2822A55B989DEAEvidyocom_-- From nobody Thu Aug 21 07:05:46 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 84BE51A0329 for ; Thu, 21 Aug 2014 07:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8tLh8nAa6Vj for ; Thu, 21 Aug 2014 07:05:36 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9221A031A for ; Thu, 21 Aug 2014 07:05:34 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-f7-53f5fc96c533 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B7.55.21432.69CF5F35; Thu, 21 Aug 2014 16:05:10 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.48]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Thu, 21 Aug 2014 16:05:10 +0200 From: Bo Burman To: Alex Eleftheriadis Thread-Topic: [avtext] Taxonomy Thread-Index: AQHPpjNe2+XlKjJ7DkCPUQ4TsxnXHpvYH6jAgAHF/ICAAVA1YA== Date: Thu, 21 Aug 2014 14:05:09 +0000 Message-ID: References: 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.20] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E29135AESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+Jvje60P1+DDf4ftra4vnMti8XHezdY LV48mMPkwOwx5fdGVo8lS34yebQ9u8MewBzFZZOSmpNZllqkb5fAldE74RxbwZvljBUPbjxj b2C8PZGxi5GTQ0LAROLI4X8sELaYxIV769m6GLk4hASOMko8/nOfBcJZzCix8NxxVpAqNgEN ifk77gJ1c3CICKhLdMwvA6lhFuhglPjwdwEbSFxYQE7i1v9ykHIRAXmJRws+sEPYThJrjy5n ArFZBFQlug82sYCU8wr4ShzcLw6xaimjxNr/c8HqOQVsJWa2PmIGsRkFZCXuf78HdiizgLjE rSfzmSCOFpBYsuc8M4QtKvHy8T9WCFtR4up0iF3MAvkSLW8PgM3kFRCUODnzCcsERtFZSEbN QlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxanJSbbmSkl1qUmVxcnJ+n l5dasokRGIcHt/w22MH48rnjIUYBDkYlHt6E31+DhVgTy4orcw8xSnOwKInzLjw3L1hIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QD4/LVOTsdDztJxRdL+kYLhr5xu27zpfm47/GomauW6Ou2 7LggeDlOi+PRu5pp4ddDdO4cdlc+cpC1sbdgghV/xjEBlncmMxZ7fPDIXRw+dRnb1yv/Oj6V /y35M/nH5Bv524TcCtbpWuh+DovZdveglPC771c6p5wOcNnVsuvU1bmf+dalpgXVqSmxFGck GmoxFxUnAgBuSGZypAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/j0b9NAgk8epoEqJ8vgg9Ip0qa3M Cc: "avtext@ietf.org" , Christer Holmberg Subject: Re: [avtext] Taxonomy 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, 21 Aug 2014 14:05:43 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E29135AESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For (3) I agree that "RTP flow" lacks the grouping connotation. The only possible reason for use of multiple RTP streams between a single m= edia source/sink pair is when the media source is encoded with MRMT or MRST= (to use the newly introduced terms below) and/or when making use of redund= ancy streams. The set of those RTP streams, related to a single Media Sourc= e, is the transported representation of a single Source Stream. Since there= is already a name for it, although not on "transport level", can maybe "So= urce Stream" be used without causing confusion and despite also not having = any grouping connotation? To come back to your question below, and if using the term "RTP flow", "mul= tiple media (RTP) streams between media sources/sinks" would constitute sin= gle RTP flows (between each media source/sink pair), while "multiple media = (RTP) streams between endpoints" is unspecific and could consist of one or = more RTP flows, depending on the number of media sources/sinks used in thos= e endpoints. I'm a bit hesitant on using "bundle", or maybe "RTP bundle", to denote the = set of RTP streams between a single media source/sink pair. I think that wo= uld risk being expected to have the same scope as an SDP bundle (as in the = BUNDLE draft), which clearly covers multiple media source/sink pairs. Cheers, Bo From: Alex Eleftheriadis [mailto:alex@vidyo.com] Sent: den 20 augusti 2014 14:06 To: Bo Burman Cc: Mo Zanaty (mzanaty); avtext@ietf.org; Christer Holmberg Subject: Re: [avtext] Taxonomy I like Mo's suggestions for (1), they appear clear enough. For (2), maybe the best choice is to avoid a specific term and use the full= "single media source/sink" or "individual media source/sink". For (3), what about distinguishing between "multiple media streams between = endpoints", vs. "multiple media streams between media sources/sinks". If th= e term "endpoint" can refer to both single and multiple sources/sinks, woul= d both cases of "multimedia media streams" be referred to as flows? Part of the problem (in my mind) with the word flow is that it is lacking t= he grouping connotation - it could equally well apply to a single media str= eam. Could "bundle" work better? --Alex On Aug 20, 2014, at 10:45 AM, Bo Burman > wrote: Hi Mo, all, see inline. From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Mo Zanaty (mzana= ty) Sent: den 23 juli 2014 07:03 To: avtext@ietf.org Subject: [avtext] Taxonomy Hi, In today's AVTEXT session, the following issues related to the taxonomy dra= ft were discussed. 1. MST/SST: I suggest new terminology focused on Single/Multiple Transport = (rather than RTP Session) combined with Single/Multiple RTP Stream. MRMT (Multiple RTP Streams over Multiple Transports) MRST (Multiple RTP Streams over Single Transport) SRST (Single RTP Stream over Single Transport) [BoB] I have no problem with that, if it can finally remove the confusion a= round this issue. 2. There is no term for referring to a media source or sink. Endpoint comes= to mind, but that is fundamentally different in -taxonomy. Terminal is ano= ther possibility, but is generally not used in RTP (outside H.323). Another= possibility is simply 'media source/sink', if the usage is not expected to= be very high. This issue came up in drafting text for the BUNDLE RTP mid, = which applies to all RTP streams between a pair of media sources/sinks. [BoB] Endpoint (or End Point) is different in -taxonomy in that a single En= d Point may handle/contain several media sources or sinks, if that is an im= portant aspect. I currently don't have a good name suggestion for a single = "media source/sink", being one part of an End Point. Suggestions are welcom= e! 3. There is no term for referring to the set of RTP streams between a media= source and sink. Transport comes to mind, but that is fundamentally differ= ent in -taxonomy. Channel is another possibility, but is generally not used= in RTP. Another possibility is simply 'RTP streams between media source/si= nk X/Y', if the usage is not expected to be very high. This issue came up i= n drafting text for the BUNDLE RTP mid, which applies to all RTP streams be= tween a pair of media sources/sinks. [BoB] Given that most applicable terms will already have been used somewher= e, I guess we cannot start totally fresh in that choosing a term will poten= tially "conflict" with existing RFCs. I see you don't suggest "RTP channel"= because it is not used, so I assume a "new" term is also not desirable? Wh= at about "RTP flow", which I have seen being used as a set of RTP streams (= one or more)? I checked its use in several RFCs and it is consistently used= that way; probably more often denoting a single RTP stream than several, b= ut I think that is manageable by including a note in -taxonomy on use of th= e term in pre-taxonomy RFCs. In that case, I think an RTP flow would have t= o be defined as distinctly different from "transport flow", which is more g= eneral and a heavily overloaded term that should probably be avoided in -ta= xonomy. Mo _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_BBE9739C2C302046BD34B42713A1E2A22E29135AESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For (3) I agree that R= 20;RTP flow” lacks the grouping connotation.

 <= /p>

The only possible reason = for use of multiple RTP streams between a single media source/sink pair is = when the media source is encoded with MRMT or MRST (to use the newly introduced terms below) and/or when making use of redundancy str= eams. The set of those RTP streams, related to a single Media Source, is th= e transported representation of a single Source Stream. Since there is alre= ady a name for it, although not on “transport level”, can maybe “Source Stream” be= used without causing confusion and despite also not having any grouping co= nnotation?

 <= /p>

To come back to your ques= tion below, and if using the term “RTP flow”, “multiple m= edia (RTP) streams between media sources/sinks” would constitute sing= le RTP flows (between each media source/sink pair), while “multiple media (= RTP) streams between endpoints” is unspecific and could consist of on= e or more RTP flows, depending on the number of media sources/sinks used in= those endpoints.

 <= /p>

I’m a bit hesitant = on using “bundle”, or maybe “RTP bundle”, to denote= the set of RTP streams between a single media source/sink pair. I think th= at would risk being expected to have the same scope as an SDP bundle (as in the BUNDLE d= raft), which clearly covers multiple media source/sink pairs.

 <= /p>

Cheers,=

Bo

 <= /p>

From: Alex Ele= ftheriadis [mailto:alex@vidyo.com]
Sent: den 20 augusti 2014 14:06
To: Bo Burman
Cc: Mo Zanaty (mzanaty); avtext@ietf.org; Christer Holmberg
Subject: Re: [avtext] Taxonomy

 

I like Mo's suggestions for (1), they appear clear e= nough.

 

For (2), maybe the best choice is to avoid a specifi= c term and use the full "single media source/sink" or "indiv= idual media source/sink". 

 

For (3), what about distinguishing between "mul= tiple media streams between endpoints", vs. "multiple media strea= ms between media sources/sinks". If the term "endpoint" can = refer to both single and multiple sources/sinks, would both cases of "multimedia media streams" be referred to as flows? 

 

Part of the problem (in my mind) with the word flow = is that it is lacking the grouping connotation - it could equally well appl= y to a single media stream. Could "bundle" work better?

 

--Alex

 

On Aug 20, 2014, at 10:45 AM, Bo Burman <bo.burman@ericsson.com> wrote:



Hi Mo, all, see inline.

 <= /p>

From: avtext [m= ailto:avtext-bounces@ietf.org] On Behalf Of = ;Mo Zanaty (mzanaty)
Sent: den 23 juli = 2014 07:03
To: avtext@ietf.org
Subject: [avtext] = Taxonomy

 

Hi,

In today’s AVTEXT session, the follo= wing issues related to the taxonomy draft were discussed.=

 

1. MST/SST: I suggest new terminology focu= sed on Single/Multiple Transport (rather than RTP Session) combined with Si= ngle/Multiple RTP Stream.

MRMT (Multiple RTP Streams over Multiple T= ransports)

MRST (Multiple RTP Streams over Single Tra= nsport)

SRST (Single RTP Stream over Single Transp= ort)

[BoB] I have no pro= blem with that, if it can finally remove the confusion around this issue.

 

2. There is no term for referring to a med= ia source or sink. Endpoint comes to mind, but that is fundamentally differ= ent in -taxonomy. Terminal is another possibility, but is generally not used in RTP (outside H.323). Another possibility is simply &= #8216;media source/sink’, if the usage is not expected to be very hig= h. This issue came up in drafting text for the BUNDLE RTP mid, which applie= s to all RTP streams between a pair of media sources/sinks.

[BoB] Endpoint (or = End Point) is different in –taxonomy in that a single End Point may h= andle/contain several media sources or sinks, if that is an important aspect. I currently don’t have a good name suggestion for a single “media source/sink”, being one p= art of an End Point. Suggestions are welcome!

 

3. There is no term for referring to the s= et of RTP streams between a media source and sink. Transport comes to mind,= but that is fundamentally different in -taxonomy. Channel is another possibility, but is generally not used in RTP. Another possibil= ity is simply ‘RTP streams between media source/sink X/Y’, if t= he usage is not expected to be very high. This issue came up in drafting te= xt for the BUNDLE RTP mid, which applies to all RTP streams between a pair of media sources/sinks.

[BoB] Given that mo= st applicable terms will already have been used somewhere, I guess we canno= t start totally fresh in that choosing a term will potentially “conflict” with existing RFCs. I see you don’t suggest &= #8220;RTP channel” because it is not used, so I assume a “new&#= 8221; term is also not desirable? What about “RTP flow”, which = I have seen being used as a set of RTP streams (one or more)? I checked its= use in several RFCs and it is consistently used that way; probably more often denoting a = single RTP stream than several, but I think that is manageable by including= a note in –taxonomy on use of the term in pre-taxonomy RFCs. In that= case, I think an RTP flow would have to be defined as distinctly different from “transport flow”, w= hich is more general and a heavily overloaded term that should probably be = avoided in -taxonomy.

 

Mo

 

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

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E29135AESESSMB105erics_-- From nobody Thu Aug 21 07:59:37 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 B8E771A03B5 for ; Thu, 21 Aug 2014 07:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e2sRWHb8_4Q for ; Thu, 21 Aug 2014 07:59:27 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016951A0113 for ; Thu, 21 Aug 2014 07:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23466; q=dns/txt; s=iport; t=1408633167; x=1409842767; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DG5Za+uDbHUwZ/FIFxqnRY/ntWk3H9DDUfMk9qwB3gg=; b=dWHtQi/s3agNwmNSShTrrpDPVAvOwX9y8TWtjMCEDk4PSn61fcQBTANp FQYeNmfKU3Ia7jpP2ksXIfeFywwiz5o1W4h3xzZU2O6CH+PHKC3eSd1p4 7b5MwDM65mS2WSCoXemcfrZej96vYFcLNV0U69LiglM744XTXRs9HxRmZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAEsI9lOtJA2M/2dsb2JhbABagkdGU1cEzEIBCYcGUwGBDhZ3hAMBAQEEAQEBKkELEAIBCBEDAQEBIQcHJwsUCQgCBAENBYhCDcJyEwSJf4U8DQQGAYRMBZEliyKVCoNebIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,909,1400025600"; d="scan'208,217";a="349226487" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 21 Aug 2014 14:59:24 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7LExOnR014926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 14:59:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 09:59:24 -0500 From: "Mo Zanaty (mzanaty)" To: Bo Burman , Alex Eleftheriadis Thread-Topic: [avtext] Taxonomy Thread-Index: AQHPvVB+7FIDd68jYEiDXvmM8yf0Yw== Date: Thu, 21 Aug 2014 14:59:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.221.72] Content-Type: multipart/alternative; boundary="_000_D01B7E3B37C46mzanatyciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/Xl6Hk-CmdkueNOWlmopdGPxizTo Cc: "avtext@ietf.org" , Christer Holmberg Subject: Re: [avtext] Taxonomy 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, 21 Aug 2014 14:59:30 -0000 --_000_D01B7E3B37C46mzanatyciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92m inclined to think taxonomy only needs to define terms for 1 but not 2= or 3. 1 is expected to be used quite often in different drafts, while 2 an= d 3 may be concepts that rarely need discussion outside the bundle draft. T= he full descriptions of 2 and 3 are also short enough that new terms may no= t be warranted. Mo From: Bo Burman > Date: Thursday, August 21, 2014 at 10:05 AM To: Alex Eleftheriadis > Cc: mzanaty >, "avtext@ietf.org= " >, Christ= er Holmberg > Subject: RE: [avtext] Taxonomy For (3) I agree that =93RTP flow=94 lacks the grouping connotation. The only possible reason for use of multiple RTP streams between a single m= edia source/sink pair is when the media source is encoded with MRMT or MRST= (to use the newly introduced terms below) and/or when making use of redund= ancy streams. The set of those RTP streams, related to a single Media Sourc= e, is the transported representation of a single Source Stream. Since there= is already a name for it, although not on =93transport level=94, can maybe= =93Source Stream=94 be used without causing confusion and despite also not= having any grouping connotation? To come back to your question below, and if using the term =93RTP flow=94, = =93multiple media (RTP) streams between media sources/sinks=94 would consti= tute single RTP flows (between each media source/sink pair), while =93multi= ple media (RTP) streams between endpoints=94 is unspecific and could consis= t of one or more RTP flows, depending on the number of media sources/sinks = used in those endpoints. I=92m a bit hesitant on using =93bundle=94, or maybe =93RTP bundle=94, to d= enote the set of RTP streams between a single media source/sink pair. I thi= nk that would risk being expected to have the same scope as an SDP bundle (= as in the BUNDLE draft), which clearly covers multiple media source/sink pa= irs. Cheers, Bo From: Alex Eleftheriadis [mailto:alex@vidyo.com] Sent: den 20 augusti 2014 14:06 To: Bo Burman Cc: Mo Zanaty (mzanaty); avtext@ietf.org; Christer = Holmberg Subject: Re: [avtext] Taxonomy I like Mo's suggestions for (1), they appear clear enough. For (2), maybe the best choice is to avoid a specific term and use the full= "single media source/sink" or "individual media source/sink". For (3), what about distinguishing between "multiple media streams between = endpoints", vs. "multiple media streams between media sources/sinks". If th= e term "endpoint" can refer to both single and multiple sources/sinks, woul= d both cases of "multimedia media streams" be referred to as flows? Part of the problem (in my mind) with the word flow is that it is lacking t= he grouping connotation - it could equally well apply to a single media str= eam. Could "bundle" work better? --Alex On Aug 20, 2014, at 10:45 AM, Bo Burman > wrote: Hi Mo, all, see inline. From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Mo Zanaty (mzana= ty) Sent: den 23 juli 2014 07:03 To: avtext@ietf.org Subject: [avtext] Taxonomy Hi, In today=92s AVTEXT session, the following issues related to the taxonomy d= raft were discussed. 1. MST/SST: I suggest new terminology focused on Single/Multiple Transport = (rather than RTP Session) combined with Single/Multiple RTP Stream. MRMT (Multiple RTP Streams over Multiple Transports) MRST (Multiple RTP Streams over Single Transport) SRST (Single RTP Stream over Single Transport) [BoB] I have no problem with that, if it can finally remove the confusion a= round this issue. 2. There is no term for referring to a media source or sink. Endpoint comes= to mind, but that is fundamentally different in -taxonomy. Terminal is ano= ther possibility, but is generally not used in RTP (outside H.323). Another= possibility is simply =91media source/sink=92, if the usage is not expecte= d to be very high. This issue came up in drafting text for the BUNDLE RTP m= id, which applies to all RTP streams between a pair of media sources/sinks. [BoB] Endpoint (or End Point) is different in =96taxonomy in that a single = End Point may handle/contain several media sources or sinks, if that is an = important aspect. I currently don=92t have a good name suggestion for a sin= gle =93media source/sink=94, being one part of an End Point. Suggestions ar= e welcome! 3. There is no term for referring to the set of RTP streams between a media= source and sink. Transport comes to mind, but that is fundamentally differ= ent in -taxonomy. Channel is another possibility, but is generally not used= in RTP. Another possibility is simply =91RTP streams between media source/= sink X/Y=92, if the usage is not expected to be very high. This issue came = up in drafting text for the BUNDLE RTP mid, which applies to all RTP stream= s between a pair of media sources/sinks. [BoB] Given that most applicable terms will already have been used somewher= e, I guess we cannot start totally fresh in that choosing a term will poten= tially =93conflict=94 with existing RFCs. I see you don=92t suggest =93RTP = channel=94 because it is not used, so I assume a =93new=94 term is also not= desirable? What about =93RTP flow=94, which I have seen being used as a se= t of RTP streams (one or more)? I checked its use in several RFCs and it is= consistently used that way; probably more often denoting a single RTP stre= am than several, but I think that is manageable by including a note in =96t= axonomy on use of the term in pre-taxonomy RFCs. In that case, I think an R= TP flow would have to be defined as distinctly different from =93transport = flow=94, which is more general and a heavily overloaded term that should pr= obably be avoided in -taxonomy. Mo _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_D01B7E3B37C46mzanatyciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I=92m inclined to think taxonomy only needs to define terms for 1 but = not 2 or 3. 1 is expected to be used quite often in different drafts, while= 2 and 3 may be concepts that rarely need discussion outside the bundle dra= ft. The full descriptions of 2 and 3 are also short enough that new terms may not be warranted.

Mo

From: Bo Burman <bo.burman@ericsson.com>
Date: Thursday, August 21, 2014 at = 10:05 AM
To: Alex Eleftheriadis <alex@vidyo.com>
Cc: mzanaty <mzanaty@cisco.com>, "avtext@ietf.org" <avtext@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: RE: [avtext] Taxonomy

For (3) I agree that =93RTP flow=94= lacks the grouping connotation.

 

The only possible reason for use of= multiple RTP streams between a single media source/sink pair is when the m= edia source is encoded with MRMT or MRST (to use the newly introduced terms below) and/or when making use of r= edundancy streams. The set of those RTP streams, related to a single Media = Source, is the transported representation of a single Source Stream. Since = there is already a name for it, although not on =93transport level=94, can maybe =93Source Stream=94 be us= ed without causing confusion and despite also not having any grouping conno= tation?

 

To come back to your question below= , and if using the term =93RTP flow=94, =93multiple media (RTP) streams bet= ween media sources/sinks=94 would constitute single RTP flows (between each media source/sink pair), while =93multiple = media (RTP) streams between endpoints=94 is unspecific and could consist of= one or more RTP flows, depending on the number of media sources/sinks used= in those endpoints.

 

I=92m a bit hesitant on using =93bu= ndle=94, or maybe =93RTP bundle=94, to denote the set of RTP streams betwee= n a single media source/sink pair. I think that would risk being expected to have the same scope as an SDP bundle (as in t= he BUNDLE draft), which clearly covers multiple media source/sink pairs.

 

Cheers,

Bo

 

From: Alex Eleftheriadis [mailto:alex@vidyo.com]
Sent: den 20 augusti 2014 14:06
To: Bo Burman
Cc: Mo Zanaty (mzanaty); avtext@i= etf.org; Christer Holmberg
Subject: Re: [avtext] Taxonomy

 

I like Mo's suggestions for (1), they appear clear e= nough.

 

For (2), maybe the best choice is to avoid a specifi= c term and use the full "single media source/sink" or "indiv= idual media source/sink". 

 

For (3), what about distinguishing between "mul= tiple media streams between endpoints", vs. "multiple media strea= ms between media sources/sinks". If the term "endpoint" can = refer to both single and multiple sources/sinks, would both cases of "multimedia media streams" be referred to as flows? 

 

Part of the problem (in my mind) with the word flow = is that it is lacking the grouping connotation - it could equally well appl= y to a single media stream. Could "bundle" work better?

 

--Alex

 

On Aug 20, 2014, at 10:45 AM, Bo Burman <bo.burman@ericsson.com> wrote:



Hi Mo, all, see inline.=

 

From: = av= text [m= ailto:avtext-bounces@ietf.org] On Behalf Of = ;Mo Zanaty (mzanaty)
Sent: den 23 juli = 2014 07:03
To: avtext@ietf.org
Subject: [avtext] = Taxonomy

 

Hi,

In today=92s AVTEXT session, the following issues related to th= e taxonomy draft were discussed.

 

1. MST/SST: I suggest new terminology focused on Single/Multipl= e Transport (rather than RTP Session) combined with Single/Multiple RTP Str= eam.

MRMT (Multiple RTP Streams over Multiple Transports)

MRST (Multiple RTP Streams over Single Transport)

SRST (Single RTP Stream over Single Transport)

[BoB] I have no problem with = that, if it can finally remove the confusion around this issue.<= /b>

 

2. There is no term for referring to a media source or sink. En= dpoint comes to mind, but that is fundamentally different in -taxonomy. Ter= minal is another possibility, but is generally not used in RTP (outside H.323). Another possibility is simply = =91media source/sink=92, if the usage is not expected to be very high. This= issue came up in drafting text for the BUNDLE RTP mid, which applies to al= l RTP streams between a pair of media sources/sinks.

[BoB] Endpoint (or End Point)= is different in =96taxonomy in that a single End Point may handle/contain = several media sources or sinks, if that is an important aspect. I currently don=92t have a good name suggestion fo= r a single =93media source/sink=94, being o= ne part of an End Point. Suggestions are welcome!=

 

3. There is no term for referring to the set of RTP streams bet= ween a media source and sink. Transport comes to mind, but that is fundamen= tally different in -taxonomy. Channel is another possibility, but is generally not used in RTP. Another possibil= ity is simply =91RTP streams between media source/sink X/Y=92, if the usage= is not expected to be very high. This issue came up in drafting text for t= he BUNDLE RTP mid, which applies to all RTP streams between a pair of media sources/sinks.

[BoB] Given that most applica= ble terms will already have been used somewhere, I guess we cannot start to= tally fresh in that choosing a term will potentially =93conflict=94 with existing RFCs. I see you don=92t sugg= est =93RTP channel=94 because it is not used, so I assume a =93new=94 term = is also not desirable? What about =93RTP flow=94, which I have seen being u= sed as a set of RTP streams (one or more)? I checked its use in several RFCs and it is consistently used that way; probably mor= e often denoting a single RTP stream than several, but I think that is mana= geable by including a note in =96taxonomy on use of the term in pre-taxonom= y RFCs. In that case, I think an RTP flow would have to be defined as distinctly different from =93transport fl= ow=94, which is more general and a heavily overloaded term that should prob= ably be avoided in -taxonomy.

 

Mo

 

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

 

 --_000_D01B7E3B37C46mzanatyciscocom_-- From nobody Fri Aug 22 05:35: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 9711D1A0271 for ; Fri, 22 Aug 2014 05:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, 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 MlHwUIPbVbl9 for ; Fri, 22 Aug 2014 05:35:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37A81A0263 for ; Fri, 22 Aug 2014 05:35:14 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-1d-53f73900b0a7 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EB.1A.21432.00937F35; Fri, 22 Aug 2014 14:35:12 +0200 (CEST) Received: from ESESSMB105.ericsson.se ([169.254.5.48]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Fri, 22 Aug 2014 14:35:12 +0200 From: Bo Burman To: Christian Groves , "avtext@ietf.org" Thread-Topic: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 Thread-Index: Ac+oI8943NA5z66dRdGqdkJ2oCY7RQSn2IaAAC2sUTAALZTUgABGai2Q Date: Fri, 22 Aug 2014 12:35:11 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53F1DD5D.6030204@nteczone.com> <53F441C3.5050201@nteczone.com> In-Reply-To: <53F441C3.5050201@nteczone.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+NgFnrELMWRmVeSWpSXmKPExsUyM+JvjS6D5fdgg7bXuhYf791gtfjyvpHF gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mq4cuAjU0FDTkXf/WbGBsaLYV2MnBwSAiYS e19uZIawxSQu3FvP1sXIxSEkcJRR4lvzVyhnMaPEgTk9bCBVbAIaEvN33GUEsUUEoiW29nwG 6xYWcJWY+ugeM0TcTeLXnZ1A9Rxg9oGl4SBhFgFVidalH8BKeAV8JX7sXcgKMf8Ro8ST6bdY QRKcAjoSv570gNmMArIS97/fYwGxmQXEJW49mc8EcamAxJI956GuFpV4+fgfK4StKHF1+nIm iHodiQW7P7FB2NoSyxa+hlosKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLU7KTTcy 0kstykwuLs7P08tLLdnECIyUg1t+G+xgfPnc8RCjAAejEg9vwu+vwUKsiWXFlbmHGKU5WJTE eReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHS8Z+WOkLvOkIf6wdz3NfdkXaI/9Yp e/8Lxb+kIk2X3znredPuxvSGBXlLc275LDj6MW3d3Un6be8mZynXsfjcdc9ke6eS1Tl5m9rW QMc/lpbvnhSaeOQfzT/99r/EufuWhUsu1bN17puxnmshk68Mx/Ic36m2Z382qQgGGB4Teuxm WnpS5IoSS3FGoqEWc1FxIgAnZhG9dQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/uoAqHmiepyXewIwv24pHUg7KBKM 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, 22 Aug 2014 12:35:19 -0000 Hi Christian, Thank you again for comments! See my responses inline, including comments t= o your comments. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: den 20 augusti 2014 08:36 > To: Bo Burman; avtext@ietf.org > Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 >=20 > Hello Bo, >=20 > Thanks for your response. Please see my responses below and some further > comments: >=20 > 1) A minor nit: The headings titles for 4.5 and 12 are the same. Maybe ch= ange 4.5 to "Message acknowledgements". [BoB]: Good suggestion. Will do. >=20 > 2) Clause 9: Use of PAUSE and PAUSED: I must admit I find the distinction= between these two parameters really > confusing. Especially when the draft says that they are different functio= ns but that "pause" > encompasses "paused". It is really necessary to have two parameters? It s= eems that a node can do the following with > respect to the messages: > a) Both send and receive PAUSE, RESUME, PAUSED and REFUSE > b) Send PAUSE, RESUME and receive PAUSED and REFUSE only > c) Receive PAUSE, RESUME and send PAUSED and REFUSE only > d) Do not receive messages but send a PAUSED only. >=20 > The issue seems to come when considering the local PAUSE functionality. > As the draft notes that "pause" contains the full "paused" > functionality", I could assume that a) b) and c) contain the local PAUSE = functionality. d) would also have to contain the > local PAUSE functionality. However I'm not sure b) would be valid because= the node would have to be able to send > PAUSED as a result of clause 5.3. Whilst the intent is that 'pause' and '= paused' are different functions there would appear > to be interactions. e.g. It would be strange to set 'pause=3Drecvonly' an= d 'paused=3Drecvonly'. >=20 > I think the usage at least needs to be clarified as there appears to be s= ome overlap and inconsistencies with other > sections. Preferably it would be good to try to use one parameter. [BoB]: Good catch and good analysis! To go back to the design intent of "paused" and if I remember correctly, I = believe it was to allow for a very restricted implementation that supports/= knows _only_ "local pause" functionality, and additionally (with the dir=3D= parameter) allow for just a) sending the indication, b) just receiving it,= or c) both. This is however not motivated or required by any of the curren= tly included use cases. It seems that some parts of the current text, for e= xample clause 5.1, confuses the use of "paused" with what is actually solve= d by the direction parameter of "pause". I think the following two main options are reasonable ways forward: 1) Remove the "paused" SDP parameter entirely, and with it the possibility = to implement support of only the local pause indication 2) Make the text consistently express that "paused" refers to capability fo= r that limited functionality. For SDP offer/answer, we then have a few more= choices regarding the relation between "pause" and "paused": a) an offer expressing support for this specification MUST contain only o= ne of "pause" or "paused", and an offer with "pause" is possible to restric= t by answering with "paused", but an offer with the limited "paused" cannot= be upgraded to "pause" in the answer. May possibly cause problems with dec= larative use; guidance appreciated. b) "pause" and "paused" are kept separate (what current text mostly does, = except for some confusion that must be corrected throughout if this option = is chosen); the offer MAY contain either or both, while the answer MUST cho= ose one and MUST NOT add anything that was not in the offer >=20 >=20 > 3) Clause 5.1 indicates "/ Capability to understand PAUSED indicatio= n is defined separately from the others to > support partial implementation, which is specifically believed to be feas= ible for the RTP Mixer to Media Sender use case > (Section 3.2)./" I guess the important thing is that its the media sender= that must at least support the PAUSED indication, > the mixer needs to support PAUSE. [BoB]: As said above, signaling for the mixer case is a bit confused in 5.1= , and better dealt with (and covered) by having either dir=3Dsendonly or di= r=3Drecvonly to pause parameter, depending on desired functionality restric= tion. Only supporting local PAUSED, indicated by "paused" SDP parameter, is= a separate issue and should be made clearer, if not removed (see above). >=20 > 4) Clause 10.1 paragraph below the figure. Indicates "/includes the "nowa= it" sub-parameter for both "pause" and > "paused" parameters/" > however the nowait parameter is only specified in the example offer for p= ause + nowait is not defined for paused in the > ABNF syntax.=20 [BoB]: Correct. Only "pause" should be in the sentence above. > The last paragraph in clause 9.1 also indicates that possibility to suppo= rt "nowait" for "paused" i.e. "/The > answerer MUST NOT add "nowait" on the "pause" line in the answer unless i= t is present on the "paused" line in the > offer./" This isn't possible due to the syntax. [BoB]: Correct. Probably a typo; "paused" -> "pause". >=20 > 5) Clause 9.1 paragraph 2: "/In other words, an offer for "paused dir=3Ds= endonly" means that the offerer intends to send > PAUSED indications whenever it pauses RTP stream delivery in any of its s= treams./" Would a pause in one stream require > sending a PAUSED indication in multiple streams? [BoB]: No, only for the actually paused stream; unclear wording. What about= simply "...intends to send PAUSED indications for paused RTP streams"? >=20 > 6) Clause 9.1 para.1 nit: "...functionality if the answer.." [BoB]: OK >=20 > 7) Clause 9.2 first paragraph: The third sentence indicates that it is no= rmally only necessary to include either "pause" or > "paused" however clause 9 indicates "SHOULD" for including both and claus= e 9.1 indicates "is RECOMMENDED" to include > both. It seems the reasoning to use both is the same for O/A and declarat= ive use, i.e. implementations may have > different support levels. [BoB]: I believe 9.2 should be changed to be aligned with 9.1 and RECOMMEND= to include both (as long as option 2b from above is chosen/kept, otherwise= that text has to be re-written accordingly)=20 >=20 >=20 > Regards, Christian >=20 > On 19/08/2014 6:34 PM, Bo Burman wrote: > > Thank you for the review! > > > > Regarding your first question, the assumption was that the scope is rea= l-time streams and thus only (2) makes sense, as > you say. To maybe state the obvious, it does not make much sense to speci= fy for a real-time (live) media source that > pausing should start buffering data at the sender, where a resume would t= hen start to play out data that may be several > minutes old. I also assume that a movie-player type application would not= have the real-time requirements on the > signaling that motivates the use of this draft, but that it rather uses R= TSP or some other media-player protocol that often > has the possibility to explicitly specify resume points. > > > > I think it makes sense to be clear and include a few sentences on pause= / resume point at least in 4.1 "Real-time > Nature", but maybe also point it out again in 5.4 "Requesting to Resume".= Do you agree? > [CNG] I agree with your reasoning. I think it would be good to add some s= entences to clarify this. Perhaps it would also be > worth adding a formal definition for the term "pause"? I think naturally = people assume the media player usage of the > term as to expected behaviour as that's what they are used to. [BoB]: OK. Will change both 4.1, 5.4 and add a definition of "pause". >=20 > > > > Regarding your second question, it sounds reasonable that a media sende= r can have some local considerations (not a > RESUME request from someone else) that makes it decide to resume transmis= sion. This local decision to resume a > stream can be seen as the media sender sending RESUME to itself (internal= ly), similar to that pausing a stream based on a > local decision can be seen as the media sender sending PAUSE to itself (i= nternally). I would however be interested to > know if you have some concrete example scenario as to when this could hap= pen? > [CNG] I don't have a particular scenario in mind. The question was largel= y triggered by the ability in 5.3 to have a local > PAUSE. It seemed that if there were local conditions that triggered a PAU= SE that the clearing of those conditions may > result in a resumption of RTP flow. [BoB]: OK. > > > > I would expect such conditions making a media sender resume a stream ba= sed on local considerations include the ones > described in the next-to-last paragraph of 5.2, where local consideration= s makes a media sender REFUSE to pause a > stream. > [CNG] Not sure. "local conditions" are really enumerated by the draft. > There could be media processing reasons e.g. para 2 clause 5.3. It could = be related to a service e.g. hold etc. > > > > I suggest including a sentence in 5.4 that a media sender MAY resume a = paused stream at any point in time due to local > considerations. It should then be pointed out (in line what is already de= scribed in next-to-last paragraph of 5.2) that for > the case when the *media receiver* paused the stream using TMMBR 0, this = "local resume" is not permitted, since it is > incompatible with the TMMBR semantics! It would however be OK either when= (only) the media sender paused the > stream due to local considerations, or when using PAUSE/RESUME messages d= efined in this draft. OK? > [CNG] Yes this sounds OK. I agree that the resume doesn't apply when TMMB= R 0 is used. [BoB]: OK. Will add a short text for that into 5.4, as suggested. > > > > To elaborate further, for the case of TMMBR/TMMBN signaling and assumin= g that the media sender has paused the > stream due to local considerations, the PAUSED indication would be a TMMB= R 0 containing the media sender itself (SSRC) > as owning the bitrate (0) restriction. A media receiver that does not nee= d to receive the (already paused) RTP stream > could also send a TMMBR 0, and the restriction would then be jointly owne= d by both RTP end points. Assume that the > local restrictions at the media sender that made it pause the stream in t= he first place are lifted, and following CCM [RFC > 5104] rules, a new TMMBR 0 would be sent out where the media sender SSRC = is no longer in the bounding set, only the > media receiver. Even though the media sender is OK with not having the st= ream paused any longer, the media receiver > still desires it to be paused and TMMBR semantics requires the bitrate to= be kept at 0. > > Cheers, > > Bo > > > >> -----Original Message----- > >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Christian > >> Groves > >> Sent: den 18 augusti 2014 13:03 > >> To: avtext@ietf.org > >> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02 > >> > >> On reading the draft I didn't really see a discussion regarding the > >> pause / resume point. E.g. an RTP receiver could request a pause in > >> the transmission of RTP and then at a later point request a > >> resumption of the stream. I assume there would be two options for the > >> sender. (1) Continue sending RTP packets related to media from the > >> time of the pause OR (2) send RTP packets from the time of the > >> resumption. E.g. the RTP stream may relate to a movie, the initial pau= se point is 5min into the movie, a request for > resumption occurs 2min after. The sender could send RTP related to the me= dia from the 5min or 7min point in the movie. > For a real time voice stream probably only (2) makes sense. Is the assump= tion of the draft that only option (2) is > supported? > >> > >> The other question is related to media sender pause/resume. Cl.5.3 of > >> the draft indicates that the RTP sender can choose to pause a stream > >> at any time. However cl.5.4 only mentions that the RTP receiver can re= quest to resume a stream. Is this intentional? I > would have thought the sender could also decide to resume at any time? > >> > >> Regards, Christian > >> > >> On 26/07/2014 2:36 AM, DRAGE, Keith (Keith) wrote: > >>> (As WG cochair) > >>> > >>> This is to announce a Working Group Last Call on > >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ > >>> > >>> draft-ietf-avtext-rtp-stream-pause-02 > >>> > >>> Please comment on the document by August 18th, 2014. > >>> > >>> Comments preferably to the AVTEXT list. > >>> > >>> It is helpful if you categorise your comments into Editorial, Minor t= echnical, Major issue. > >>> > >>> The author has posed some open questions to the list. The chairs do > >>> not believe this should impact the appriateness of > >> starting the WGLC now. However do please respond to those questions. > >>> The chairs realise this is a period when people will be disappearing > >>> on leave - if you intend commenting on the > >> document but such leave means you need more time, please email the > >> chairs with that information and when you think you might complete a W= GLC review. > >>> > >>> > >>> Regards > >>> > >>> Keith > >>> _______________________________________________ > >>> avtext mailing list > >>> avtext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/avtext > >>> > >> _______________________________________________ > >> avtext mailing list > >> avtext@ietf.org > >> https://www.ietf.org/mailman/listinfo/avtext >=20 From nobody Tue Aug 26 23:49:59 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 C4B581A041F for ; Tue, 26 Aug 2014 23:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.6 X-Spam-Level: ** X-Spam-Status: No, score=2.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_38=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id russowxGw4Rm for ; Tue, 26 Aug 2014 23:49:57 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6151A0415 for ; Tue, 26 Aug 2014 23:49:57 -0700 (PDT) Received: from ppp118-209-27-161.lns20.mel4.internode.on.net ([118.209.27.161]:55179 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XMX1e-0006Ui-Kn; Wed, 27 Aug 2014 16:48:10 +1000 Message-ID: <53FD7F8A.6060608@nteczone.com> Date: Wed, 27 Aug 2014 16:49:46 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bo Burman , "avtext@ietf.org" References: <949EF20990823C4C85C18D59AA11AD8B212C0B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <53F1DD5D.6030204@nteczone.com> <53F441C3.5050201@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/7KfKqBNfSbaPQit_Wg8ui07y63Y 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, 27 Aug 2014 06:49:58 -0000 Hello Bo, Please see below. Regards, Christian On 22/08/2014 10:35 PM, Bo Burman wrote: > ..snip.. >> 2) Clause 9: Use of PAUSE and PAUSED: I must admit I find the distinction between these two parameters really >> confusing. Especially when the draft says that they are different functions but that "pause" >> encompasses "paused". It is really necessary to have two parameters? It seems that a node can do the following with >> respect to the messages: >> a) Both send and receive PAUSE, RESUME, PAUSED and REFUSE >> b) Send PAUSE, RESUME and receive PAUSED and REFUSE only >> c) Receive PAUSE, RESUME and send PAUSED and REFUSE only >> d) Do not receive messages but send a PAUSED only. >> >> The issue seems to come when considering the local PAUSE functionality. >> As the draft notes that "pause" contains the full "paused" >> functionality", I could assume that a) b) and c) contain the local PAUSE functionality. d) would also have to contain the >> local PAUSE functionality. However I'm not sure b) would be valid because the node would have to be able to send >> PAUSED as a result of clause 5.3. Whilst the intent is that 'pause' and 'paused' are different functions there would appear >> to be interactions. e.g. It would be strange to set 'pause=recvonly' and 'paused=recvonly'. >> >> I think the usage at least needs to be clarified as there appears to be some overlap and inconsistencies with other >> sections. Preferably it would be good to try to use one parameter. > [BoB]: Good catch and good analysis! > > To go back to the design intent of "paused" and if I remember correctly, I believe it was to allow for a very restricted implementation that supports/knows _only_ "local pause" functionality, and additionally (with the dir= parameter) allow for just a) sending the indication, b) just receiving it, or c) both. This is however not motivated or required by any of the currently included use cases. It seems that some parts of the current text, for example clause 5.1, confuses the use of "paused" with what is actually solved by the direction parameter of "pause". > > I think the following two main options are reasonable ways forward: > > 1) Remove the "paused" SDP parameter entirely, and with it the possibility to implement support of only the local pause indication > > 2) Make the text consistently express that "paused" refers to capability for that limited functionality. For SDP offer/answer, we then have a few more choices regarding the relation between "pause" and "paused": > > a) an offer expressing support for this specification MUST contain only one of "pause" or "paused", and an offer with "pause" is possible to restrict by answering with "paused", but an offer with the limited "paused" cannot be upgraded to "pause" in the answer. May possibly cause problems with declarative use; guidance appreciated. > > b) "pause" and "paused" are kept separate (what current text mostly does, except for some confusion that must be corrected throughout if this option is chosen); the offer MAY contain either or both, while the answer MUST choose one and MUST NOT add anything that was not in the offer [CNG] I wasn't following this closely when 'paused' was added so I'm not sure about removing it. It would simplify things if it was removed. I think what would need to be added if local pause was supported without signalling is that a node supporting this draft must at minimum support the reception of a 'paused' indication and the sending of 'paused' if the node supports a paused state. There would probably need to be an extra value in direction indicating that PAUSE/RESUME is not sent or received. Maybe an option 2c: If local pause is kept and it needs to be supported by signalling there actually appears to be 8 combinations of sent and received messages. I assume a node supporting the sending and/or reception of PAUSE must also support RESUME. A node supporting the reception of PAUSE/RESUME must also support sending PAUSED and REFUSED. The combinations a Node can support are: 1) Send(PAUSE,RESUMED,PAUSED,REFUSE) Receive (PAUSED,RESUMED,PAUSED,REFUSED) 2) Send(PAUSE, RESUME, PAUSED) Receive (PAUSED, REFUSED) 3) Send(PAUSED,REFUSED) Receive (PAUSE, RESUME, PAUSED) 4) Send(PAUSED,REFUSED) Receive (PAUSE, RESUME) 5) Send(PAUSE, RESUME) Receive (PAUSED, REFUSED) 6) Send(PAUSED) Receive(PAUSED) 7) Send() Receive(PAUSED) 8) Send(PAUSED) Receive() Would it be easier to simply signal the messages that are supported rather than two parameters with a direction parameters? e.g. the draft could have the above list of values. If a node supported both the sending and reception of PAUSE/RESUME/PAUSED/REFUSED then it could signal e.g. a=rtcp-fb:98 ccm pause config=1 . Part of the confusion comes from the interaction between the parameters. This would remove the interaction. It might make describing the SDP O/A procedures easier. e.g. On receiving an Offer with: config=1 the answerer may reply with config=1, 2, 3, 4, 5, 6, 7 or 8. config=2 the answerer may reply with config=3, 4, 5, 6, 7 or 8. config=3 the answerer may reply with config=2, 4, 5, 6, 7 or 8. config=4 the answerer may reply with config=5, 6, 7 or 8. config=5 the answerer may reply with config=4, 6, 7 or 8. config=6 the answerer may reply with config=6, 7 or 8. config=7 the answerer may reply with config=8 config=8 the answerer may reply with config=7 In all cases the answerer may reply with a completely removed "pause" parameter. An answerer cannot add extra messages to what is provided in the Offer. For example: If an Offer indicates config=6 an Answer cannot reply with config=3 indicating that it has the capability to receive PAUSE and RESUME. An answerer may remove messages that it does not support. For example: if an Offer indicates config=6 an Answer may reply with config=7 indicating that it can only receive PAUSED. >> 3) Clause 5.1 indicates "/ Capability to understand PAUSED indication is defined separately from the others to >> support partial implementation, which is specifically believed to be feasible for the RTP Mixer to Media Sender use case >> (Section 3.2)./" I guess the important thing is that its the media sender that must at least support the PAUSED indication, >> the mixer needs to support PAUSE. > [BoB]: As said above, signaling for the mixer case is a bit confused in 5.1, and better dealt with (and covered) by having either dir=sendonly or dir=recvonly to pause parameter, depending on desired functionality restriction. Only supporting local PAUSED, indicated by "paused" SDP parameter, is a separate issue and should be made clearer, if not removed (see above). > >> 4) Clause 10.1 paragraph below the figure. Indicates "/includes the "nowait" sub-parameter for both "pause" and >> "paused" parameters/" >> however the nowait parameter is only specified in the example offer for pause + nowait is not defined for paused in the >> ABNF syntax. > [BoB]: Correct. Only "pause" should be in the sentence above. > >> The last paragraph in clause 9.1 also indicates that possibility to support "nowait" for "paused" i.e. "/The >> answerer MUST NOT add "nowait" on the "pause" line in the answer unless it is present on the "paused" line in the >> offer./" This isn't possible due to the syntax. > [BoB]: Correct. Probably a typo; "paused" -> "pause". > >> 5) Clause 9.1 paragraph 2: "/In other words, an offer for "paused dir=sendonly" means that the offerer intends to send >> PAUSED indications whenever it pauses RTP stream delivery in any of its streams./" Would a pause in one stream require >> sending a PAUSED indication in multiple streams? > [BoB]: No, only for the actually paused stream; unclear wording. What about simply "...intends to send PAUSED indications for paused RTP streams"? [CNG] OK > >