From magnus.westerlund@ericsson.com Tue Nov 1 03:41:43 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E36121F8F48 for ; Tue, 1 Nov 2011 03:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VCxcyH6dl5L for ; Tue, 1 Nov 2011 03:41:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8259A21F8F3C for ; Tue, 1 Nov 2011 03:41:42 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-94-4eafcce53b8a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 36.EB.20773.5ECCFAE4; Tue, 1 Nov 2011 11:41:41 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 1 Nov 2011 11:41:41 +0100 Message-ID: <4EAFCCE4.7070903@ericsson.com> Date: Tue, 1 Nov 2011 11:41:40 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] AVTEXT Agenda IETF 82 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2011 10:41:43 -0000 Wg, We have just posted a WG session agenda for IETF 82. If there is any questions or late requests please contact the chairs. Audio/Video Transport Extensions (avtext) ====================================================================== Chairs: Magnus Westerlund Keith Drage Agenda IETF 82, Taipei 15:10 - 16:10 WEDNESDAY, November 16, 2011. Room: 101C ---------------------------------------------------------------------- 15:10 AVTEXT Status Update (Chairs, 10) 15:20 IEEE 1588/802.1AS Synchronisation for RTP Streams (Williams, 15) draft-williams-avtext-avbsync-02 15:35 RTCP SDES Item SRCNAME to Label Individual Sources (Magnus, 15) draft-westerlund-avtext-rtcp-sdes-srcname-00 15:20 RTP Media Stream Pause and Resume (Magnus, 20) 16:10 End Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Nov 1 03:43:34 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB8821F8F63 for ; Tue, 1 Nov 2011 03:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-sM8apCC1kq for ; Tue, 1 Nov 2011 03:43:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DBF5921F8F42 for ; Tue, 1 Nov 2011 03:43:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-2a-4eafcd531da6 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E2.B0.13753.35DCFAE4; Tue, 1 Nov 2011 11:43:31 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 1 Nov 2011 11:43:31 +0100 Message-ID: <4EAFCD52.6040105@ericsson.com> Date: Tue, 1 Nov 2011 11:43:30 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: avtext@ietf.org References: <4EAFCCE4.7070903@ericsson.com> In-Reply-To: <4EAFCCE4.7070903@ericsson.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [avtext] AVTEXT Agenda IETF 82 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2011 10:43:34 -0000 WG, Corrected version: Audio/Video Transport Extensions (avtext) ====================================================================== Chairs: Magnus Westerlund Keith Drage Agenda IETF 82, Taipei 15:10 - 16:10 WEDNESDAY, November 16, 2011. Room: 101C ---------------------------------------------------------------------- 15:10 AVTEXT Status Update (Chairs, 10) 15:20 IEEE 1588/802.1AS Synchronisation for RTP Streams (Williams, 15) draft-williams-avtext-avbsync-02 15:35 RTCP SDES Item SRCNAME to Label Individual Sources (Magnus, 15) draft-westerlund-avtext-rtcp-sdes-srcname-00 15:20 RTP Media Stream Pause and Resume (Magnus, 20) draft-westerlund-avtext-rtp-stream-pause-00 16:10 End -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Nov 1 03:45:15 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000AC21F8E36 for ; Tue, 1 Nov 2011 03:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjxGq78yf+rd for ; Tue, 1 Nov 2011 03:45:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3731521F8DFB for ; Tue, 1 Nov 2011 03:45:14 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4a-4eafcdb87023 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 01.6C.20773.8BDCFAE4; Tue, 1 Nov 2011 11:45:13 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 1 Nov 2011 11:45:12 +0100 Message-ID: <4EAFCDB8.2030907@ericsson.com> Date: Tue, 1 Nov 2011 11:45:12 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: avtext@ietf.org References: <4EAFCCE4.7070903@ericsson.com> <4EAFCD52.6040105@ericsson.com> In-Reply-To: <4EAFCD52.6040105@ericsson.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [avtext] AVTEXT Agenda IETF 82 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Nov 2011 10:45:15 -0000 Well, The once more corrected and in the future correct version can be retrieved from here: http://www.ietf.org/proceedings/82/agenda/avtext.txt Cheers On 2011-11-01 11:43, Magnus Westerlund wrote: > WG, > > Corrected version: > > Audio/Video Transport Extensions (avtext) > ====================================================================== > > Chairs: Magnus Westerlund > Keith Drage > > > Agenda IETF 82, Taipei > > 15:10 - 16:10 WEDNESDAY, November 16, 2011. Room: 101C > ---------------------------------------------------------------------- > 15:10 AVTEXT Status Update (Chairs, 10) > > 15:20 IEEE 1588/802.1AS Synchronisation for RTP Streams (Williams, 15) > draft-williams-avtext-avbsync-02 > > 15:35 RTCP SDES Item SRCNAME to Label Individual Sources (Magnus, 15) > draft-westerlund-avtext-rtcp-sdes-srcname-00 > > 15:50 RTP Media Stream Pause and Resume (Magnus, 20) > draft-westerlund-avtext-rtp-stream-pause-00 > > 16:10 End > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Nov 3 08:10:40 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FF21F0CB0 for ; Thu, 3 Nov 2011 08:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+XkYWi3T+0L for ; Thu, 3 Nov 2011 08:10:39 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC401F0CA4 for ; Thu, 3 Nov 2011 08:10:38 -0700 (PDT) X-AuditID: c1b4fb39-b7cb2ae000001bd8-94-4eb2aed385e7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 87.D8.07128.3DEA2BE4; Thu, 3 Nov 2011 16:10:11 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 3 Nov 2011 16:10:10 +0100 Message-ID: <4EB2AED2.2070401@ericsson.com> Date: Thu, 3 Nov 2011 16:10:10 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] Pause and Resume CCM extension X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 03 Nov 2011 15:10:40 -0000 Hi, As individual, My colleagues and I have put together a proposal for a functionality for pausing and resuming media streams. This is primarily intended for mixer scenarios where a mixer would send the pause request to media senders that currently don't need to send any media for the mixer isn't using this source. For example video streams when the participant isn't active. Draft: https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/ It does cover a few other usages but that is primarily to ensure that it wouldn't break the whole system if introduced into ASM or transport relay topologies. This proposal is also based on that the system in general may use something like the Media Stream Selection (see link below) to include or exclude media streams they don't want. Thus we have in fact excluded such usages by not allowing the end-points to use this to manipulate the CSRC list of media stream that are mixes or selections. This as it would only provide partial functionality compared to Media Stream Selection. https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection/ Feedback is most appreciated Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Nov 4 03:25:20 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C295321F8C17 for ; Fri, 4 Nov 2011 03:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aazHgCx2j64u for ; Fri, 4 Nov 2011 03:25:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F365B21F8C15 for ; Fri, 4 Nov 2011 03:25:16 -0700 (PDT) X-AuditID: c1b4fb39-b7b3eae00000252a-65-4eb3bd8b54d7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C9.F9.09514.B8DB3BE4; Fri, 4 Nov 2011 11:25:15 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 4 Nov 2011 11:25:15 +0100 Message-ID: <4EB3BD89.7030602@ericsson.com> Date: Fri, 4 Nov 2011 11:25:13 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] Regarding the SDES SRCNAME draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2011 10:25:20 -0000 Hi, (As individual) My colleagues and I have submitted an new Internet draft for the 00 deadline. https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/ So this draft is actually split out of https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and-simulcast/ That was discussed in the AVTCORE WG in Quebec. This proposal we see as a independent building block that becomes highly usable in RTP sessions where end-points starting to have more than one media source being transported in an RTP session and there is reason to have more than one media stream (SSRC) associated with that media source, like retransmission, FEC, duplication, layered encoding, simulcast. We do have agenda time for the upcomming meeting so I hope you have the time to review the draft prior to the meeting. Even more appreciated if you want to provide feedback to the mailing list. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Fri Nov 4 17:09:09 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C9721F8463 for ; Fri, 4 Nov 2011 17:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.169 X-Spam-Level: X-Spam-Status: No, score=-106.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFMEXQsANh2E for ; Fri, 4 Nov 2011 17:09:08 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB4821F8461 for ; Fri, 4 Nov 2011 17:09:07 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA5095f0004144 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 5 Nov 2011 01:09:05 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 5 Nov 2011 01:09:05 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Sat, 5 Nov 2011 01:09:01 +0100 Thread-Topic: Future working group last calls Thread-Index: AcybTx9TFQu4/7eMRCuZpQN9Sc61vw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [avtext] Future working group last calls X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 00:09:09 -0000 (As working group co-chair) It is the intent of the working group chairs to START working group last ca= lls on the following two documents on Wednesday 16th November (strangely en= ough very shortly after the end of the face to face meeting). https://datatracker.ietf.org/doc/draft-ietf-avtext-rams-scenarios/ https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/ This will be a 3 week working group last call when it happens. The chairs and the editors believe these two documents are complete in thei= r current form and ready for WGLC. This is your chance as WG members to ide= ntify any open issues or omissions before we start that WGLC, so that WGLC = can take place on all the final material. So we would urge you all to have a look at these two documents in respect o= f that need. Regards Keith P.S. Just to stress, this is not starting the WGLC now, it is the request f= or you to make sure the documents are ready for that last call.= From mzanaty@cisco.com Fri Nov 4 20:27:37 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8E11E8095 for ; Fri, 4 Nov 2011 20:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tS+h01b3qsW for ; Fri, 4 Nov 2011 20:27:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 92DC811E8093 for ; Fri, 4 Nov 2011 20:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mzanaty@cisco.com; l=2769; q=dns/txt; s=iport; t=1320463656; x=1321673256; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=rrTollEHrExJ4N1Cq1pglFOxLyEvUl9BeMotSJJ3SpA=; b=aBIpN/ttOAVEfXB+Bl5SuEitqje9/itgKViJEV90o4oD4lk7NuS5+W17 itKIPATPHAKP10GY1aihFayQQlUES8zJgD0gTmgIGUCbJsy1cmFlAO5cJ HL/UaJ3/hvpon1081xIYotboZRS406nAWKUsrlOPgmb7hw62sbuPHwOO5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMAAO2rtE6tJV2d/2dsb2JhbABDmhSOVIEggQWBcgEBAQQBAQEJBgEdPhcCAgIBCBEEAQELBhcBBgEaDB8JCAEBBAESCBqHaJc1AZ4hBAKIRmMEh1oxkU2MTw X-IronPort-AV: E=Sophos;i="4.69,459,1315180800"; d="scan'208";a="33573344" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 05 Nov 2011 03:27:36 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pA53Ra3C008276; Sat, 5 Nov 2011 03:27:36 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 22:27:36 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2011 22:24:10 -0500 Message-ID: In-Reply-To: <4EB2AED2.2070401@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [avtext] Pause and Resume CCM extension Thread-Index: AcyaOsDcYzxRxQgUTnCoL0hsoylTeQBKTc6Q References: <4EB2AED2.2070401@ericsson.com> From: "Mo Zanaty (mzanaty)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 05 Nov 2011 03:27:36.0187 (UTC) FILETIME=[DCE70CB0:01CC9B6A] Subject: Re: [avtext] Pause and Resume CCM extension X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 03:27:37 -0000 Magnus, How does the proposed pause differ from tmmbr=3D0? Some implementations = already use tmmbr=3D0 to pause peers. Assuming there is some valuable nuance between pause and tmmbr=3D0, it = may be useful to explicitly allow acks without requests so senders can = notify peers when they pause (and resume) themselves autonomously. This = is not explicitly prohibited in the current draft, just as autonomous = tmmbn (without tmmbr) is not explicitly prohibited in RFC 5104. But it = would be good to explicitly allow and describe this use case. Some = implementations already use tmmbn=3D0 to notify peers they have paused = themselves autonomously (without receiving any tmmbr).=20 Thanks, Mo -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf = Of Magnus Westerlund Sent: Thursday, November 03, 2011 11:10 AM To: avtext@ietf.org Subject: [avtext] Pause and Resume CCM extension Hi, As individual, My colleagues and I have put together a proposal for a functionality for pausing and resuming media streams. This is primarily intended for mixer scenarios where a mixer would send the pause request to media senders that currently don't need to send any media for the mixer isn't using this source. For example video streams when the participant isn't = active. Draft: https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause= / It does cover a few other usages but that is primarily to ensure that it wouldn't break the whole system if introduced into ASM or transport relay topologies. This proposal is also based on that the system in general may use something like the Media Stream Selection (see link below) to include or exclude media streams they don't want. Thus we have in fact excluded such usages by not allowing the end-points to use this to manipulate the CSRC list of media stream that are mixes or selections. This as it would only provide partial functionality compared to Media Stream Selection. https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selecti= on/ Feedback is most appreciated Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From kevin.gross@avanw.com Sun Nov 6 20:12:31 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365E821F8468 for ; Sun, 6 Nov 2011 20:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.017 X-Spam-Level: * X-Spam-Status: No, score=1.017 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap1uZDSi+hmu for ; Sun, 6 Nov 2011 20:12:30 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 3B50921F8467 for ; Sun, 6 Nov 2011 20:12:30 -0800 (PST) Received: (qmail 21075 invoked by uid 0); 7 Nov 2011 04:12:29 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy3.bluehost.com with SMTP; 7 Nov 2011 04:12:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=M9mhTgyyeCfBhxkNmF2/N5LaWRSC8+dESO1Fc52nGTA=; b=mE/fXfephmdhDC2115G0SLR6T+uNYBi7zXQpcF3DznIAt4DAf8RyJdcWXz7Q583Y1f13rK4SZ9MJIaQQcZ+eJRTWDNj8A+7RXaLYO+Xm/28W4wVyWCANiaVPabFh+GNQ; Received: from mail-fx0-f44.google.com ([209.85.161.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RNGZR-0007KV-BB for avtext@ietf.org; Sun, 06 Nov 2011 21:12:29 -0700 Received: by faas12 with SMTP id s12so5625250faa.31 for ; Sun, 06 Nov 2011 20:12:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.7.20 with SMTP id b20mr44060114fab.21.1320639147971; Sun, 06 Nov 2011 20:12:27 -0800 (PST) Received: by 10.223.115.200 with HTTP; Sun, 6 Nov 2011 20:12:27 -0800 (PST) In-Reply-To: <4EAF4255.8010909@audinate.com> References: <4EAF4255.8010909@audinate.com> Date: Sun, 6 Nov 2011 21:12:27 -0700 Message-ID: From: Kevin Gross To: Aidan Williams Content-Type: multipart/alternative; boundary=0015174785d24a966704b11d4367 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.161.44 authed with kevin.gross@avanw.com} Cc: "avtext@ietf.org" Subject: Re: [avtext] draft-williams-avtext-avbsync updated X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2011 04:12:31 -0000 --0015174785d24a966704b11d4367 Content-Type: text/plain; charset=ISO-8859-1 Hi Aidan, Nice to see a new revision. Nice to see acknowledgement of RFC 6051 and IDMS. IDMS defines a "clocksource" SDP attribute to identify the clock domain. The following clock distribution methods are supported by IDMS: NTP, GPS, Galileo, IEEE 1588-2002, IEEE 1588-2008 and IEEE 802.1AS. When IEEE 1588-2002 or IEEE 1588-2008 are used, a domain identifier is also specified. The IEEE 802.1AS PTP profile allows use of the default domain (0) only. You are proposing using the EUI-64 of the grandmaster instead. I also considered this possibility for IDMS but was confounded by the following scenario... For fault tolerance, mission-critical media systems are configured with at least two potential grandmasters all receiving time from a common reference (e.g. house sync reference, GPS). Upon failure of the primary grandmaster, another takes over and, although nothing has functionally changed about the clock domain, the EUI-64 of the grandmaster in the network does change. Until updated SDP advertisements reflecting the new grandmaster are received, senders and receivers will believe they are operating on different time domains and streams will presumably be interrupted. It would be very useful to have a unique identifier for a clock domain. My conclusion after considering the above scenario was that the grandmaster ID was not that identifier and clock distribution protocol, protocol version and domain identifier is currently the best identifier we have. I think there is definitely room for improvement in this. It does not strike me as an easy problem, however. I like your idea of using a traceability indicator to help determine clock compatibility. I am concerned however that while traceable clocks can be assumed to be frequency synchronized (syntonized) I am not aware of any way to gauge the accuracy of their phase synchronization. Nevertheless, adding a traceability indicator to the SDP clock attribute would seem to be a useful improvement. With regards to the proposed T, M and U flags in the header extension. I don't see a need for T if traceability information is to be available via SDP. T is not soemthing that changes dynamically, is it? You do acknowledge that M and U come from IEEE 1722. You should add the minimum toggle period requirement we see in IEEE 1722 section 5.4.1 to your M discussion to be sure these events are not missed if the clock is thrashing. I am not convinced that the information provided by M and U will improve system performance. No specific recommendations for how receivers should respond to these conditions are given in this draft or in IEEE 1722. Perhaps inclusion of such recommendations or a report from someone who has implemented IEEE 1722 would change my opinion. I do support reusing IDMS SDP and RFC 6051 header extensions definitions to meet the requirements of your proposal. I encourage you to review and help improve the IDMS draft. I'm not yet convinced that the header extension defined in RFC 6051 needs improvement but if it does, there are already two header options defined there; Perhaps a third could be added. Kevin Gross On Mon, Oct 31, 2011 at 6:50 PM, Aidan Williams wrote: > Hi All, > > I've updated the draft on avb sync, you can find it at: > > http://tools.ietf.org/html/**draft-williams-avtext-avbsync-**02 > > The main changes are: > > - more discussion about clock domains and traceable time > - additional header timing metadata > - some discussion about signalling with SDP > > Section 8 also describes an alternative approach using the existing RFC > 6051 header extension. I'd appreciate feedback on whether this is more > desirable approach to take. > > regards > aidan > ____ > :wq! > > ______________________________**_________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/**listinfo/avtext > --0015174785d24a966704b11d4367 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Aidan,

Nice to see a new revision. Nice to see acknow= ledgement of RFC 6051 and IDMS.

IDMS defines a &qu= ot;clocksource" SDP attribute to identify the clock domain.=A0The foll= owing clock distribution methods are supported by IDMS: NTP, GPS,=A0Galileo= , IEEE 1588-2002, IEEE 1588-2008 and IEEE 802.1AS.=A0When IEEE 1588-2002 or= IEEE 1588-2008 are used, a domain identifier is also specified. The IEEE 8= 02.1AS PTP profile allows use of the default domain (0) only.=A0You are pro= posing using the EUI-64 of the grandmaster=A0instead. I also considered thi= s possibility for IDMS but was confounded by the following scenario...

For fault tolerance, mission-critical media systems are= configured with at least two potential grandmasters all receiving time fro= m a common reference (e.g. house sync reference, GPS). Upon failure of the = primary grandmaster, another takes over and, although nothing has functiona= lly changed about the clock domain, the EUI-64 of the grandmaster in the ne= twork does change. Until updated SDP advertisements reflecting the new gran= dmaster are received, senders and receivers will believe they are operating= on different time domains and streams will presumably be interrupted.

It would be very useful to have a unique identifier for= a clock domain. My conclusion after considering the above scenario was tha= t the grandmaster ID was not that identifier and clock distribution protoco= l, protocol version and domain identifier is currently the best identifier = we have. I think there is definitely room for improvement in this. It does = not strike me as an easy problem, however.

I like your idea of using a traceability=A0indicator to= help determine clock compatibility. I am concerned however that while trac= eable clocks can be assumed to be frequency synchronized (syntonized) I am = not aware of any way to gauge the accuracy of their phase synchronization. = Nevertheless, adding a traceability indicator to the SDP clock attribute wo= uld seem to be a useful improvement.

With regards to the proposed T, M and U flags in the he= ader extension. I don't see a need for T if traceability information is= to be available via SDP. T is not soemthing that changes dynamically, is i= t? You do acknowledge that M and U come from IEEE 1722. You should add the = minimum toggle period requirement we see in IEEE 1722 section 5.4.1 to your= M discussion to be sure these events are not missed if the clock is thrash= ing.

I am not=A0convinced=A0that the information provided by= M and U will improve system=A0performance. No specific recommendations for= how receivers should respond to these=A0conditions=A0are given in this dra= ft or in IEEE 1722. Perhaps inclusion of such recommendations or a report f= rom someone who has implemented IEEE 1722 would change my opinion.

I do support reusing IDMS SDP and RFC 6051 header exten= sions definitions to meet the requirements of your proposal.=A0I encourage = you to review and help improve the IDMS draft.=A0I'm not yet convinced = that the header extension defined in RFC 6051 needs improvement but if it d= oes, there are already two header options defined there; Perhaps a third co= uld be added.

Kevin Gross

On= Mon, Oct 31, 2011 at 6:50 PM, Aidan Williams <aidan.williams@audinate.com>= wrote:
Hi All,

I've updated the draft on avb sync, you can find it at:

=A0http://tools.ietf.org/html/draft-williams-avtext-= avbsync-02

The main changes are:

=A0- more discussion about clock domains and traceable time
=A0- additional header timing metadata
=A0- some discussion about signalling with SDP

Section 8 also describes an alternative approach using the existing RFC 605= 1 header extension. =A0I'd appreciate feedback on whether this is more = desirable approach to take.

regards
=A0 =A0 =A0 =A0 =A0 =A0aidan
____
:wq!

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


--0015174785d24a966704b11d4367-- From Even.roni@huawei.com Mon Nov 7 03:58:42 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772BE21F8B26 for ; Mon, 7 Nov 2011 03:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odakK9UfeKH2 for ; Mon, 7 Nov 2011 03:58:42 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C692C21F8B15 for ; Mon, 7 Nov 2011 03:58:41 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA00H4IH97N4@szxga03-in.huawei.com> for avtext@ietf.org; Mon, 07 Nov 2011 19:58:19 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA00M2VH8ZLL@szxga03-in.huawei.com> for avtext@ietf.org; Mon, 07 Nov 2011 19:58:19 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEU62400; Mon, 07 Nov 2011 19:58:19 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 19:58:16 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.4]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 19:58:10 +0800 Date: Mon, 07 Nov 2011 11:58:09 +0000 From: Roni even In-reply-to: X-Originating-IP: [172.24.2.41] To: "Mo Zanaty (mzanaty)" , Magnus Westerlund , "avtext@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [avtext] Pause and Resume CCM extension Thread-index: AQHMmjrMGJWD2VSoMEuRr/T8Wfx9cZWdGjIAgAQ5RE4= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EB2AED2.2070401@ericsson.com> Subject: Re: [avtext] Pause and Resume CCM extension X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2011 11:58:42 -0000 Hi, I agree with Mo, the tmmbr=3D0 is probably used by video conferencing appli= cations to temporary stop video flows. So why use a new method. Roni ________________________________________ From: avtext-bounces@ietf.org [avtext-bounces@ietf.org] on behalf of Mo Zan= aty (mzanaty) [mzanaty@cisco.com] Sent: Saturday, November 05, 2011 5:24 To: Magnus Westerlund; avtext@ietf.org Subject: Re: [avtext] Pause and Resume CCM extension Magnus, How does the proposed pause differ from tmmbr=3D0? Some implementations alr= eady use tmmbr=3D0 to pause peers. Assuming there is some valuable nuance between pause and tmmbr=3D0, it may = be useful to explicitly allow acks without requests so senders can notify p= eers when they pause (and resume) themselves autonomously. This is not expl= icitly prohibited in the current draft, just as autonomous tmmbn (without t= mmbr) is not explicitly prohibited in RFC 5104. But it would be good to exp= licitly allow and describe this use case. Some implementations already use = tmmbn=3D0 to notify peers they have paused themselves autonomously (without= receiving any tmmbr). Thanks, Mo -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Magnus Westerlund Sent: Thursday, November 03, 2011 11:10 AM To: avtext@ietf.org Subject: [avtext] Pause and Resume CCM extension Hi, As individual, My colleagues and I have put together a proposal for a functionality for pausing and resuming media streams. This is primarily intended for mixer scenarios where a mixer would send the pause request to media senders that currently don't need to send any media for the mixer isn't using this source. For example video streams when the participant isn't active. Draft: https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/ It does cover a few other usages but that is primarily to ensure that it wouldn't break the whole system if introduced into ASM or transport relay topologies. This proposal is also based on that the system in general may use something like the Media Stream Selection (see link below) to include or exclude media streams they don't want. Thus we have in fact excluded such usages by not allowing the end-points to use this to manipulate the CSRC list of media stream that are mixes or selections. This as it would only provide partial functionality compared to Media Stream Selection. https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection= / Feedback is most appreciated Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ 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 mzanaty@cisco.com Mon Nov 7 12:38:15 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40E311E80D8 for ; Mon, 7 Nov 2011 12:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrmiQkRb5Y8X for ; Mon, 7 Nov 2011 12:38:14 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5491911E80D2 for ; Mon, 7 Nov 2011 12:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mzanaty@cisco.com; l=3989; q=dns/txt; s=iport; t=1320698294; x=1321907894; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=pEptAA8mhLdwa0no6v4+GW8+yuWy0/vNa3Lh2Qj//kg=; b=URc+llRZxJdANLid7KyckAlWsJJ5pO1Xp130RspxbVytRarYMWl9jwy/ KpH2OQeV4tQ9XAGOPAwXfb3vbC/WB0+3IRR46w1+rTw5ewA7OM1wkV1pn zTRMqE2MTjYDUajqMyxVyDayQRk7fAWWXmaDPRvutdywUPaCAYPYUonS0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAMZAuE6tJV2b/2dsb2JhbABEmgiOR4EjgQWBcgEBAQQBAQEJBgEdPhcCAgIBCBEEAQELBhcBBgEaDB8JCAIEARIIGodomU8Bnm4EAohGYwSHWjGRUIxR X-IronPort-AV: E=Sophos;i="4.69,471,1315180800"; d="scan'208";a="34026118" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 07 Nov 2011 20:38:14 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA7KcOCp020786; Mon, 7 Nov 2011 20:38:24 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 14:38:13 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2011 14:38:12 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [avtext] Pause and Resume CCM extension Thread-Index: AQHMmjrMGJWD2VSoMEuRr/T8Wfx9cZWdGjIAgAQ5RE6AAHXdMA== References: <4EB2AED2.2070401@ericsson.com> From: "Mo Zanaty (mzanaty)" To: "Roni even" , "Magnus Westerlund" , X-OriginalArrivalTime: 07 Nov 2011 20:38:13.0822 (UTC) FILETIME=[2BD4D5E0:01CC9D8D] Subject: Re: [avtext] Pause and Resume CCM extension X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2011 20:38:15 -0000 Perhaps this should be reworked into an Informational RFC on how to use = TMMBR/TMMBN for such functionality, since it is not obvious whether or = not RFC 5104 allows this. Or, if IETF prefers to focus on standards, = then perhaps other forums which focus on interoperability and = implementation guidelines (like IMTC, UCIF, etc.) can codify this usage = in their recommendations. Thanks, Mo -----Original Message----- From: Roni even [mailto:Even.roni@huawei.com]=20 Sent: Monday, November 07, 2011 6:58 AM To: Mo Zanaty (mzanaty); Magnus Westerlund; avtext@ietf.org Subject: RE: [avtext] Pause and Resume CCM extension Hi, I agree with Mo, the tmmbr=3D0 is probably used by video conferencing = applications to temporary stop video flows. So why use a new method. Roni ________________________________________ From: avtext-bounces@ietf.org [avtext-bounces@ietf.org] on behalf of Mo = Zanaty (mzanaty) [mzanaty@cisco.com] Sent: Saturday, November 05, 2011 5:24 To: Magnus Westerlund; avtext@ietf.org Subject: Re: [avtext] Pause and Resume CCM extension Magnus, How does the proposed pause differ from tmmbr=3D0? Some implementations = already use tmmbr=3D0 to pause peers. Assuming there is some valuable nuance between pause and tmmbr=3D0, it = may be useful to explicitly allow acks without requests so senders can = notify peers when they pause (and resume) themselves autonomously. This = is not explicitly prohibited in the current draft, just as autonomous = tmmbn (without tmmbr) is not explicitly prohibited in RFC 5104. But it = would be good to explicitly allow and describe this use case. Some = implementations already use tmmbn=3D0 to notify peers they have paused = themselves autonomously (without receiving any tmmbr). Thanks, Mo -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf = Of Magnus Westerlund Sent: Thursday, November 03, 2011 11:10 AM To: avtext@ietf.org Subject: [avtext] Pause and Resume CCM extension Hi, As individual, My colleagues and I have put together a proposal for a functionality for pausing and resuming media streams. This is primarily intended for mixer scenarios where a mixer would send the pause request to media senders that currently don't need to send any media for the mixer isn't using this source. For example video streams when the participant isn't = active. Draft: https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause= / It does cover a few other usages but that is primarily to ensure that it wouldn't break the whole system if introduced into ASM or transport relay topologies. This proposal is also based on that the system in general may use something like the Media Stream Selection (see link below) to include or exclude media streams they don't want. Thus we have in fact excluded such usages by not allowing the end-points to use this to manipulate the CSRC list of media stream that are mixes or selections. This as it would only provide partial functionality compared to Media Stream Selection. https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selecti= on/ Feedback is most appreciated Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ 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 magnus.westerlund@ericsson.com Tue Nov 8 04:51:01 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7364721F8B44 for ; Tue, 8 Nov 2011 04:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neDDjCBQDUVh for ; Tue, 8 Nov 2011 04:51:01 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 75C9721F8B39 for ; Tue, 8 Nov 2011 04:51:00 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-47-4eb925b3fd06 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6A.31.13753.3B529BE4; Tue, 8 Nov 2011 13:50:59 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 8 Nov 2011 13:50:59 +0100 Message-ID: <4EB925B1.5010605@ericsson.com> Date: Tue, 8 Nov 2011 13:50:57 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <4EB2AED2.2070401@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Pause and Resume CCM extension X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 12:51:01 -0000 On 2011-11-07 21:38, Mo Zanaty (mzanaty) wrote: > Perhaps this should be reworked into an Informational RFC on how to > use TMMBR/TMMBN for such functionality, since it is not obvious > whether or not RFC 5104 allows this. Or, if IETF prefers to focus on > standards, then perhaps other forums which focus on interoperability > and implementation guidelines (like IMTC, UCIF, etc.) can codify this > usage in their recommendations. Hi, We had considered this but think there are a few issues with using TMMBR=0. First, the semantics of TMMBR in that it cuts the bit-rate immediately and only the increase allows other receivers to reconsider the change. This is problematic in any scenario where you have a shared media, like ASM or Transport Translators instead of RTP mixer topologies. If you contrast our the PAUSE proposal with this, it takes the safer but more complicated way of requiring all known receivers to send pause before it occurs. secondly, when resuming the TMMBR semantics is to not increase the bit-rate until all participants has had the possibility to inject a new limiation. That is not suitable at all for resume, that needs to happen immediately. So we think there is significant semantics issues with TMMBR/TMMBN for pause and resume. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Tue Nov 8 08:06:56 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DDA21F8922 for ; Tue, 8 Nov 2011 08:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofJ0DsVGwizp for ; Tue, 8 Nov 2011 08:06:56 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6F4F21F8B3E for ; Tue, 8 Nov 2011 08:06:55 -0800 (PST) Received: by faas12 with SMTP id s12so839780faa.31 for ; Tue, 08 Nov 2011 08:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=Fe7mchYWrpceZLOO1XrTwq8CFD332CuG2t47N+Nrk1A=; b=G4Xzm7uAVU3W1l3LyyOXcIOkkHAFcmyMksmpyUaEf5vgckOJ9dybIJ+WL40WbNgj2+ B/lN6ZUXqCSYTEJCsbaupRJZhsePMUt52jYm8cTD7bf3G0IVvBmPuJ1eM5IBy8xdWP58 XeUTy+uq1dq2P2Z1LhoPJoiiEpoQm5Jwa0/Z8= Received: by 10.223.14.197 with SMTP id h5mr17341232faa.2.1320768414792; Tue, 08 Nov 2011 08:06:54 -0800 (PST) Received: from windows8d787f9 ([109.66.64.90]) by mx.google.com with ESMTPS id n25sm2625765fah.15.2011.11.08.08.06.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 08:06:53 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" , "'Mo Zanaty \(mzanaty\)'" References: <4EB2AED2.2070401@ericsson.com> <4EB925B1.5010605@ericsson.com> In-Reply-To: <4EB925B1.5010605@ericsson.com> Date: Tue, 8 Nov 2011 18:03:57 +0200 Message-ID: <4eb9539d.193cdf0a.0b4e.4699@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyeFRWNXJGexqvOSQ6fvvaRN0slRAAGbjuA Content-Language: en-us Cc: avtext@ietf.org, "'Botzko, Stephen'" Subject: Re: [avtext] Pause and Resume CCM extension X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 16:06:56 -0000 Hi Magnus, The document does not discuss the TMMBR (RFC 5104) option and section 1 = says that "No currently existing RTCP feedback message supports pausing and resuming an incoming data stream."=20 The use cases in sections 3.1 and 3.2 can be addressed by TMMBR and this = is what is being used today by shipping products. Section 4.4 is the only section about multicast and describes the = behavior of a sender in a multicast group saying that it shall not pause until = all the receivers that the sender knows of have requested it to be paused. = I am not sure that real use cases will cause this to happen. So the question is why add a new way to do something that is being done today by TMMBR in the common cases. Regards Roni > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Tuesday, November 08, 2011 2:51 PM > To: Mo Zanaty (mzanaty) > Cc: avtext@ietf.org > Subject: Re: [avtext] Pause and Resume CCM extension >=20 > On 2011-11-07 21:38, Mo Zanaty (mzanaty) wrote: > > Perhaps this should be reworked into an Informational RFC on how to > > use TMMBR/TMMBN for such functionality, since it is not obvious > > whether or not RFC 5104 allows this. Or, if IETF prefers to focus on > > standards, then perhaps other forums which focus on interoperability > > and implementation guidelines (like IMTC, UCIF, etc.) can codify = this > > usage in their recommendations. >=20 > Hi, >=20 > We had considered this but think there are a few issues with using > TMMBR=3D0. >=20 > First, the semantics of TMMBR in that it cuts the bit-rate immediately > and only the increase allows other receivers to reconsider the change. > This is problematic in any scenario where you have a shared media, = like > ASM or Transport Translators instead of RTP mixer topologies. >=20 > If you contrast our the PAUSE proposal with this, it takes the safer > but > more complicated way of requiring all known receivers to send pause > before it occurs. >=20 > secondly, when resuming the TMMBR semantics is to not increase the > bit-rate until all participants has had the possibility to inject a = new > limiation. That is not suitable at all for resume, that needs to = happen > immediately. >=20 > So we think there is significant semantics issues with TMMBR/TMMBN for > pause and resume. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From magnus.westerlund@ericsson.com Wed Nov 9 01:57:13 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D4921F858C for ; Wed, 9 Nov 2011 01:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.26 X-Spam-Level: X-Spam-Status: No, score=-106.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE3emcOIiest for ; Wed, 9 Nov 2011 01:57:13 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DA84021F84C1 for ; Wed, 9 Nov 2011 01:57:12 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-95-4eba4e774bcb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BF.8C.09514.77E4ABE4; Wed, 9 Nov 2011 10:57:12 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 9 Nov 2011 10:57:11 +0100 Message-ID: <4EBA4E76.9070505@ericsson.com> Date: Wed, 9 Nov 2011 10:57:10 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Roni Even References: <4EB2AED2.2070401@ericsson.com> <4EB925B1.5010605@ericsson.com> <4eb9539d.193cdf0a.0b4e.4699@mx.google.com> In-Reply-To: <4eb9539d.193cdf0a.0b4e.4699@mx.google.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" , "'Botzko, Stephen'" Subject: Re: [avtext] Pause and Resume CCM extension X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 09 Nov 2011 09:57:13 -0000 On 2011-11-08 17:03, Roni Even wrote: > Hi Magnus, > The document does not discuss the TMMBR (RFC 5104) option and section 1 says > that "No currently existing RTCP feedback message supports pausing and > resuming an incoming data stream." Yes, we should have discussed TMMBR and its shortcomming. We will address this in a future revision. > > The use cases in sections 3.1 and 3.2 can be addressed by TMMBR and this is > what is being used today by shipping products. > Section 4.4 is the only section about multicast and describes the behavior > of a sender in a multicast group saying that it shall not pause until all > the receivers that the sender knows of have requested it to be paused. I am > not sure that real use cases will cause this to happen. > So the question is why add a new way to do something that is being done > today by TMMBR in the common cases. Still the TMMBR semantics do create two issues, even in Point to Point and RTP Mixer to Media sender use case. The biggest issue is the resume semantics. TMMBR says the following: "If the media sender concludes that it can increase the maximum total media bit rate value, it SHALL wait before actually doing so, for a period long enough to allow a media receiver to respond to the TMMBN if it determines that its tuple belongs in the bounding set. This delay period is estimated by the formula: 2 * RTT + T_Dither_Max, where RTT is the longest round trip time known to the media sender and T_Dither_Max is defined in section 3.4 of [RFC4585]. Even in point-to-point sessions, a media sender MUST obey the aforementioned rule, as it is not guaranteed that a participant is able to determine correctly whether all the sources are co-located in a single node, and are coordinated." Based on this a media receiver or mixer sending TMMBR>0 to the media sender will not get media until two*RTT + T_Dither_Max. That is highly problematic from our point of view. And if the above behavior should not be done in the case of TMMBR=0 then it needs to be specified. In most cases, the session topology a end-point is present in is hard to determine. For example how does a end-point determine if it is in a point to point session or a Transport Translator multi-point session (relay) that currently only has two participants in it. Thus it becomes hard to determine if it acceptable for the end-point to send a TMMBR=0 as it is the sole receiver, or if other end-points that was interested of the media still needs it. If it is a relay based topology a new participant can join at any time. And if there is an existing TMMBR=0 limitation in place the then the new participant will not know that this media sender is in fact paused by another receiver. So we think these issues with TMMBR semantics that a alternative should be seriously considered. Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stephen.botzko@gmail.com Mon Nov 14 19:59:21 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48661F0CC0 for ; Mon, 14 Nov 2011 19:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrAvCxh92xF5 for ; Mon, 14 Nov 2011 19:59:20 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD27C1F0C69 for ; Mon, 14 Nov 2011 19:59:20 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so6845917vcb.31 for ; Mon, 14 Nov 2011 19:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kppDibBI3Ji0A/mpcPYBWf3KqQkjOsKHY5Qms9TiJzA=; b=lIRfwGk4yNarKqSftLfz0ajyqtxi/iiQgO2x6Mdn3XEo+/RBK+rYohnbxUtiM/vPoA Z2A4zxSk8D+UzE6axUsjKmPIeB/CKP5FnIRALvwXBrI4NQ8ViR7IFrH6ycXIe72W3Ff+ +jZ6zJnjUKR1rKoaloTUKopUppUFj2vddKdeA= MIME-Version: 1.0 Received: by 10.52.35.70 with SMTP id f6mr39519822vdj.84.1321329560113; Mon, 14 Nov 2011 19:59:20 -0800 (PST) Received: by 10.52.183.33 with HTTP; Mon, 14 Nov 2011 19:59:20 -0800 (PST) In-Reply-To: References: <4EB2AED2.2070401@ericsson.com> Date: Tue, 15 Nov 2011 11:59:20 +0800 Message-ID: From: Stephen Botzko To: Roni even Content-Type: multipart/alternative; boundary=20cf307d000a0fd1d704b1be03a4 Cc: "avtext@ietf.org" Subject: Re: [avtext] Pause and Resume CCM extension X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 03:59:21 -0000 --20cf307d000a0fd1d704b1be03a4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Our products support tmmbr; we would rather not see yet-another-mechanism for pause/resume. While perhaps the semantics are not perfect, providing a competing mechanism will not help interoperability. Stephen Botzko On Mon, Nov 7, 2011 at 7:58 PM, Roni even wrote: > Hi, > I agree with Mo, the tmmbr=3D0 is probably used by video conferencing > applications to temporary stop video flows. So why use a new method. > > Roni > > ________________________________________ > From: avtext-bounces@ietf.org [avtext-bounces@ietf.org] on behalf of Mo > Zanaty (mzanaty) [mzanaty@cisco.com] > Sent: Saturday, November 05, 2011 5:24 > To: Magnus Westerlund; avtext@ietf.org > Subject: Re: [avtext] Pause and Resume CCM extension > > Magnus, > How does the proposed pause differ from tmmbr=3D0? Some implementations > already use tmmbr=3D0 to pause peers. > > Assuming there is some valuable nuance between pause and tmmbr=3D0, it ma= y > be useful to explicitly allow acks without requests so senders can notify > peers when they pause (and resume) themselves autonomously. This is not > explicitly prohibited in the current draft, just as autonomous tmmbn > (without tmmbr) is not explicitly prohibited in RFC 5104. But it would be > good to explicitly allow and describe this use case. Some implementations > already use tmmbn=3D0 to notify peers they have paused themselves > autonomously (without receiving any tmmbr). > > Thanks, > Mo > > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of Magnus Westerlund > Sent: Thursday, November 03, 2011 11:10 AM > To: avtext@ietf.org > Subject: [avtext] Pause and Resume CCM extension > > Hi, > > As individual, > > My colleagues and I have put together a proposal for a functionality for > pausing and resuming media streams. This is primarily intended for mixer > scenarios where a mixer would send the pause request to media senders > that currently don't need to send any media for the mixer isn't using > this source. For example video streams when the participant isn't active. > > Draft: > https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause= / > > > It does cover a few other usages but that is primarily to ensure that it > wouldn't break the whole system if introduced into ASM or transport > relay topologies. > > This proposal is also based on that the system in general may use > something like the Media Stream Selection (see link below) to include or > exclude media streams they don't want. Thus we have in fact excluded > such usages by not allowing the end-points to use this to manipulate the > CSRC list of media stream that are mixes or selections. This as it would > only provide partial functionality compared to Media Stream Selection. > > > https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selecti= on/ > > Feedback is most appreciated > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > 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 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --20cf307d000a0fd1d704b1be03a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Our products support tmmbr; we would rather not see yet-another-mechanism f= or pause/resume.=A0

While perhaps the semantics are not perfect, pr= oviding a competing mechanism will not help interoperability.

Stephe= n Botzko

On Mon, Nov 7, 2011 at 7:58 PM, Roni even <Even.roni@huawe= i.com> wrote:
Hi,
I agree with Mo, the tmmbr=3D0 is probably used by video conferencing appli= cations to temporary stop video flows. So why use a new method.

Roni

________________________________________
From: avtext-bounces@ietf.org [avtext-bounces@ietf.org] = on behalf of Mo Zanaty (mzanaty) [mzan= aty@cisco.com]
Sent: Saturday, November 05, 2011 5:24
To: Magnus Westerlund; avtext@ietf.org
Subject: Re: [avtext] Pause and Resume CCM extension

Magnus,
How does the proposed pause differ from tmmbr=3D0? Some implementations alr= eady use tmmbr=3D0 to pause peers.

Assuming there is some valuable nuance between pause and tmmbr=3D0, it may = be useful to explicitly allow acks without requests so senders can notify p= eers when they pause (and resume) themselves autonomously. This is not expl= icitly prohibited in the current draft, just as autonomous tmmbn (without t= mmbr) is not explicitly prohibited in RFC 5104. But it would be good to exp= licitly allow and describe this use case. Some implementations already use = tmmbn=3D0 to notify peers they have paused themselves autonomously (without= receiving any tmmbr).

Thanks,
Mo

-----Original Message-----
From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.or= g] On Behalf Of Magnus Westerlund
Sent: Thursday, November 03, 2011 11:10 AM
To: avtext@ietf.org
Subject: [avtext] Pause and Resume CCM extension

Hi,

As individual,

My colleagues and I have put together a proposal for a functionality for pausing and resuming media streams. This is primarily intended for mixer scenarios where a mixer would send the pause request to media senders
that currently don't need to send any media for the mixer isn't usi= ng
this source. For example video streams when the participant isn't activ= e.

Draft:
https://datatracker.ietf.org/doc/draft-wester= lund-avtext-rtp-stream-pause/


It does cover a few other usages but that is primarily to ensure that it wouldn't break the whole system if introduced into ASM or transport
relay topologies.

This proposal is also based on that the system in general may use
something like the Media Stream Selection (see link below) to include or exclude media streams they don't want. Thus we have in fact excluded such usages by not allowing the end-points to use this to manipulate the CSRC list of media stream that are mixes or selections. This as it would only provide partial functionality compared to Media Stream Selection.

https://datatracker.ietf.org/doc/draft-west= erlund-dispatch-stream-selection/

Feedback is most appreciated


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
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
_______________________________________________
avtext mailing list
avtext@ietf.org
= https://www.ietf.org/mailman/listinfo/avtext

--20cf307d000a0fd1d704b1be03a4-- From internet-drafts@ietf.org Tue Nov 15 01:06:21 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F7F21F8FD6; Tue, 15 Nov 2011 01:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rd7gth8-Wkp; Tue, 15 Nov 2011 01:06:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4CE21F8FC4; Tue, 15 Nov 2011 01:06:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111115090619.6131.51139.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2011 01:06:19 -0800 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-splicing-for-rtp-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 09:06:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : Content Splicing for RTP Sessions Author(s) : Jinwei Xia Filename : draft-ietf-avtext-splicing-for-rtp-02.txt Pages : 16 Date : 2011-11-15 This memo outlines RTP splicing. Splicing is a process that replaces the content of the main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to receiver for a period of time. This memo provides some RTP splicing use cases, then we enumerate a set of requirements and analyze whether an existing RTP level middlebox can meet these requirements, at last we provide concrete guidelines for how the chosen middlebox works to handle RTP splicing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-for-rtp-02.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-splicing-for-rtp-02.txt From xiajinwei@huawei.com Tue Nov 15 17:43:06 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC05411E813A for ; Tue, 15 Nov 2011 17:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.347 X-Spam-Level: X-Spam-Status: No, score=-4.347 tagged_above=-999 required=5 tests=[AWL=2.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmGnKOcSx8SB for ; Tue, 15 Nov 2011 17:43:02 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 24F3111E8107 for ; Tue, 15 Nov 2011 17:43:02 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00ESFCRPJG@szxga04-in.huawei.com> for avtext@ietf.org; Wed, 16 Nov 2011 09:43:01 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ009VWCRPI2@szxga04-in.huawei.com> for avtext@ietf.org; Wed, 16 Nov 2011 09:43:01 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB63118; Wed, 16 Nov 2011 09:43:00 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 09:42:54 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.249]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 09:42:52 +0800 Date: Wed, 16 Nov 2011 01:42:51 +0000 From: Xiajinwei X-Originating-IP: [10.138.41.52] To: "avtext@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-ietf-avtext-splicing-for-rtp-02.txt Thread-index: AQHMo3YZ/3XJ4thUlkiXhMjeaQFc+ZWuuU3Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [avtext] FW: New Version Notification for draft-ietf-avtext-splicing-for-rtp-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 01:43:06 -0000 SGksDQoNCkkgZG8gc29tZSB1cGRhdGVzIHRvIGFkZHJlc3Mgc29tZSBlZGl0b3JpYWwgaXNzdWVz IGluIG5ldyB2ZXJzaW9uIHByaW9yIHRvIHRoZSBXR0xDLg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1mb3ItcnRwLTAyDQoNClRoZSBjaGFu Z2VzIGNhbiBiZSByZWZlcnJlZCBhdA0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj9k aWZmdHlwZT0tLWh3ZGlmZiZ1cmwyPWRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLWZvci1ydHAt MDIudHh0DQoNCg0KQlINCkppbndlaQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bk uro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTHlubQxMeaciDE15pelIDE3OjA2DQrmlLbku7bkuro6 IFhpYWppbndlaQ0K5oqE6YCBOiBYaWFqaW53ZWkNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1mb3ItcnRwLTAyLnR4dA0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctZm9yLXJ0cC0w Mi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaW53ZWkgWGlhIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1pZXRmLWF2 dGV4dC1zcGxpY2luZy1mb3ItcnRwDQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBDb250ZW50IFNw bGljaW5nIGZvciBSVFAgU2Vzc2lvbnMNCkNyZWF0aW9uIGRhdGU6CSAyMDExLTExLTE1DQpXRyBJ RDoJCSBhdnRleHQNCk51bWJlciBvZiBwYWdlczogMTYNCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1l bW8gb3V0bGluZXMgUlRQIHNwbGljaW5nLiAgU3BsaWNpbmcgaXMgYSBwcm9jZXNzIHRoYXQgcmVw bGFjZXMNCiAgIHRoZSBjb250ZW50IG9mIHRoZSBtYWluIG11bHRpbWVkaWEgc3RyZWFtIHdpdGgg b3RoZXIgbXVsdGltZWRpYQ0KICAgY29udGVudCwgYW5kIGRlbGl2ZXJzIHRoZSBzdWJzdGl0dXRp dmUgbXVsdGltZWRpYSBjb250ZW50IHRvIHJlY2VpdmVyDQogICBmb3IgYSBwZXJpb2Qgb2YgdGlt ZS4gIFRoaXMgbWVtbyBwcm92aWRlcyBzb21lIFJUUCBzcGxpY2luZyB1c2UNCiAgIGNhc2VzLCB0 aGVuIHdlIGVudW1lcmF0ZSBhIHNldCBvZiByZXF1aXJlbWVudHMgYW5kIGFuYWx5emUgd2hldGhl ciBhbg0KICAgZXhpc3RpbmcgUlRQIGxldmVsIG1pZGRsZWJveCBjYW4gbWVldCB0aGVzZSByZXF1 aXJlbWVudHMsIGF0IGxhc3Qgd2UNCiAgIHByb3ZpZGUgY29uY3JldGUgZ3VpZGVsaW5lcyBmb3Ig aG93IHRoZSBjaG9zZW4gbWlkZGxlYm94IHdvcmtzIHRvDQogICBoYW5kbGUgUlRQIHNwbGljaW5n Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg== From Even.roni@huawei.com Tue Nov 15 21:51:27 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66F21F9226 for ; Tue, 15 Nov 2011 21:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.472 X-Spam-Level: X-Spam-Status: No, score=-105.472 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dg8wVj5FS4e for ; Tue, 15 Nov 2011 21:51:26 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3818F21F9230 for ; Tue, 15 Nov 2011 21:51:26 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00C34O6XTT@szxga03-in.huawei.com> for avtext@ietf.org; Wed, 16 Nov 2011 13:49:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00AZ5O6XQ5@szxga03-in.huawei.com> for avtext@ietf.org; Wed, 16 Nov 2011 13:49:45 +0800 (CST) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LUQ003I2O6WF5@szxml12-in.huawei.com> for avtext@ietf.org; Wed, 16 Nov 2011 13:49:44 +0800 (CST) Date: Wed, 16 Nov 2011 07:47:08 +0200 From: Roni Even To: avtext@ietf.org Message-id: <00f701cca423$2e4d4bd0$8ae7e370$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_LGaf4V1kkmX+5TMZq7CD/A)" Content-language: en-us Thread-index: AcykIy2O1Q9++27pTo+G7fbbA61w7g== Subject: [avtext] qusetions on draft-westerlund-avtext-rtcp-sdes-srcname-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 05:51:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_LGaf4V1kkmX+5TMZq7CD/A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I read the draft and I am not sure I fully understand the mechanism so there are clarification questions Looking at the examples in section 5.1 through 5.4 it looks to me that the offer has one RTP payload type number that is being used to send two video streams with the same parameters. I was expecting to see two payload type numbers that will allow separate a=fmtp lines for each of the streams. Having both with the same functionality is limiting. Looking at 5.1 I see for example two streams (SSRCs 192392452 and 834753488)having mid=2 with the same capability so I assume that they may come from two cameras for example. How do you know which is from which camera, will there be another a:ssrc parameter. It is also limited since it assumes that both have the same video capabilities I am also not sure how does it work without the SDP. If a receiver receives two SDES for two SSRCs with the same srcname how does he know which one is each without getting the mapping from the SDP, like in 5.1 how does a receiver know if this is the mid=2 or 3 stream, is it based on RTP session multiplexing. From the current text I get it this is intended for SSRC multiplexing but to associate streams that can be identified either by the RTP session or by the payload like in 5.3. Roni --Boundary_(ID_LGaf4V1kkmX+5TMZq7CD/A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I read the draft and I am not sure I fully understand the mechanism so there are clarification questions

 

Looking at the examples in section 5.1 through 5.4 it looks to me that the offer has one RTP payload type number that is being used to send two video streams with the same parameters. I was expecting to see two payload type numbers that will allow separate a=fmtp lines for each of the streams. Having both with the same functionality is limiting. Looking at 5.1 I see for example two streams (SSRCs 192392452 and 834753488)having mid=2 with the same capability so I assume that they may come from two cameras for example. How do you know which is from which camera, will there be another a:ss rc param since it assumes that both have the same video capabilities

 

I am also not sure how does it work without the SDP.  If a receiver receives two SDES for two SSRCs with the same srcname how does he know which one is each without getting the mapping from the SDP, like in 5.1 how does a receiver know if this is the mid=2 or 3 stream, is it based on RTP session multiplexing. From the current text I get it this is intended for SSRC multiplexing but to associate streams that can be identified either by the RTP session or by the payload like in 5.3.

 

Roni

--Boundary_(ID_LGaf4V1kkmX+5TMZq7CD/A)-- From magnus.westerlund@ericsson.com Wed Nov 16 01:11:43 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2AB21F9592 for ; Wed, 16 Nov 2011 01:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye7x7M96CKIJ for ; Wed, 16 Nov 2011 01:11:42 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7115821F958F for ; Wed, 16 Nov 2011 01:11:39 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-b2-4ec37e4956c9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CB.06.13753.94E73CE4; Wed, 16 Nov 2011 10:11:37 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 16 Nov 2011 10:11:36 +0100 Message-ID: <4EC37E43.7080609@ericsson.com> Date: Wed, 16 Nov 2011 17:11:31 +0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] WG last call: draft-ietf-avtext-splicing-for-rtp-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 09:11:43 -0000 WG, In todays WG meeting I announced the start of a 3 week WG last call that ends on the 7th of December. The WG last call is for "Content Splicing for RTP Sessions" https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/ with the intended status of Informational RFC Please review and provide comments, even if it is just to say I read it and I found no issues with the document. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Wed Nov 16 03:04:26 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67421F9628; Wed, 16 Nov 2011 03:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLayNJCwDrGE; Wed, 16 Nov 2011 03:04:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F3E21F94D1; Wed, 16 Nov 2011 03:04:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111116110426.13162.76266.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2011 03:04:26 -0800 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 11:04:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : A Real-Time Transport Protocol (RTP) Header Extension fo= r Client-to- Mixer Audio Level Indication Author(s) : Jonathan Lennox Emil Ivov Enrico Marocco Filename : draft-ietf-avtext-client-to-mixer-audio-level-06.txt Pages : 11 Date : 2011-11-16 This document defines a mechanism by which packets of Real-Time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox which wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio= -level-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio-= level-06.txt From internet-drafts@ietf.org Wed Nov 16 03:04:31 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402CC21F9643; Wed, 16 Nov 2011 03:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjsjgzBF-r7D; Wed, 16 Nov 2011 03:04:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DF821F963A; Wed, 16 Nov 2011 03:04:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111116110430.13163.81688.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2011 03:04:30 -0800 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 11:04:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : A Real-Time Transport Protocol (RTP) Header Extension fo= r Mixer-to- Client Audio Level Indication Author(s) : Emil Ivov Enrico Marocco Jonathan Lennox Filename : draft-ietf-avtext-mixer-to-client-audio-level-06.txt Pages : 17 Date : 2011-11-16 This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-audio= -level-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-audio-= level-06.txt From jonathan@vidyo.com Wed Nov 16 03:31:30 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94DE21F9509; Wed, 16 Nov 2011 03:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAHkNCP6yKzW; Wed, 16 Nov 2011 03:31:30 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 246E521F9502; Wed, 16 Nov 2011 03:31:30 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1B9B67B4404; Wed, 16 Nov 2011 06:31:26 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id ADF487B4467; Wed, 16 Nov 2011 06:31:25 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 16 Nov 2011 06:31:25 -0500 From: Jonathan Lennox To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Date: Wed, 16 Nov 2011 06:31:24 -0500 Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level-06.txt Thread-Index: AcykUHKF5M9aYfsjTKqxauIugBoC/QAADaDA Message-ID: References: <20111116110426.13162.76266.idtracker@ietfa.amsl.com> In-Reply-To: <20111116110426.13162.76266.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 11:31:30 -0000 I've just submitted new revisions of the two audio-levels drafts. These sh= ould address all comments received during IETF Last Call and IESG review (i= ncluding one comment received privately). See the drafts' changes sections for what's changed, or the diff2 available= here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-client-to-mixer-audi= o-level-06.txt http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-mixer-to-client-audi= o-level-06.txt -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, November 16, 2011 7:04 PM To: i-d-announce@ietf.org Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level= -06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : A Real-Time Transport Protocol (RTP) Header Extension fo= r Client-to- Mixer Audio Level Indication Author(s) : Jonathan Lennox Emil Ivov Enrico Marocco Filename : draft-ietf-avtext-client-to-mixer-audio-level-06.txt Pages : 11 Date : 2011-11-16 This document defines a mechanism by which packets of Real-Time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox which wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio= -level-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer-audio-= level-06.txt _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From keith.drage@alcatel-lucent.com Wed Nov 16 08:54:02 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB72311E80C7; Wed, 16 Nov 2011 08:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.172 X-Spam-Level: X-Spam-Status: No, score=-106.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko07Jqj5BeU7; Wed, 16 Nov 2011 08:54:02 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCB811E8095; Wed, 16 Nov 2011 08:54:01 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pAGGrxnI004856 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 Nov 2011 17:53:59 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 16 Nov 2011 17:53:37 +0100 From: "DRAGE, Keith (Keith)" To: Jonathan Lennox , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Date: Wed, 16 Nov 2011 17:53:36 +0100 Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level-06.txt Thread-Index: AcykUHKF5M9aYfsjTKqxauIugBoC/QAADaDAAAu1oVA= Message-ID: References: <20111116110426.13162.76266.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 16:54:02 -0000 (as WG co chair) The intention of the editors is that this completes all the open discusses = and comments from the IESG. You can find these discusses and comments at: https://datatracker.ietf.org/doc/draft-ietf-avtext-client-to-mixer-audio-le= vel/ballot/ https://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to-client-audio-le= vel/ballot/ The situation at them moment is that one IESG member on each document has t= o identify if their discusses are resolved, and out Area Director (Gonzalo)= will verify if all the comments have been handled in his view. That could happen very quickly or may take a few days. If members of the working group want to express anything on the document or= the comments, you have a small window for doing this, but it is very small= . My assumption is that none of the changes require further working group c= onsensus and that the AD will assume likewise. Regards Keith > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf > Of Jonathan Lennox > Sent: 16 November 2011 11:31 > To: internet-drafts@ietf.org; i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: Re: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio= - > level-06.txt >=20 > I've just submitted new revisions of the two audio-levels drafts. These > should address all comments received during IETF Last Call and IESG revie= w > (including one comment received privately). >=20 > See the drafts' changes sections for what's changed, or the diff2 > available here: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-client-to-mixer- > audio-level-06.txt > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-mixer-to-client- > audio-level-06.txt >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, November 16, 2011 7:04 PM > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio- > level-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Audio/Video Transport > Extensions Working Group of the IETF. >=20 > Title : A Real-Time Transport Protocol (RTP) Header > Extension for Client-to- Mixer Audio Level Indication > Author(s) : Jonathan Lennox > Emil Ivov > Enrico Marocco > Filename : draft-ietf-avtext-client-to-mixer-audio-level- > 06.txt > Pages : 11 > Date : 2011-11-16 >=20 > This document defines a mechanism by which packets of Real-Time > Transport Protocol (RTP) audio streams can indicate, in an RTP header > extension, the audio level of the audio sample carried in the RTP > packet. In large conferences, this can reduce the load on an audio > mixer or other middlebox which wants to forward only a few of the > loudest audio streams, without requiring it to decode and measure > every stream that is received. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer- > audio-level-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-client-to-mixer- > audio-level-06.txt >=20 > _______________________________________________ > 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 magnus.westerlund@ericsson.com Wed Nov 16 18:30:55 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497071F0C74 for ; Wed, 16 Nov 2011 18:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bgf-e7ICjHzV for ; Wed, 16 Nov 2011 18:30:54 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 565DB1F0C3D for ; Wed, 16 Nov 2011 18:30:53 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-8e-4ec471dc56f6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 57.77.09514.CD174CE4; Thu, 17 Nov 2011 03:30:53 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 17 Nov 2011 03:30:51 +0100 Message-ID: <4EC471D8.4050602@ericsson.com> Date: Thu, 17 Nov 2011 10:30:48 +0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: avtext@ietf.org References: <20111116110426.13162.76266.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [avtext] I-D Action: draft-ietf-avtext-client-to-mixer-audio-level-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 02:30:55 -0000 On 2011-11-17 00:53, DRAGE, Keith (Keith) wrote: > https://datatracker.ietf.org/doc/draft-ietf-avtext-client-to-mixer-audio-level/ballot/ > > If members of the working group want to express anything on the > document or the comments, you have a small window for doing this, but > it is very small. My assumption is that none of the changes require > further working group consensus and that the AD will assume > likewise. WG, I would like to point out that in client to mixer document there has been a change of SHOULD to MUST on encrypting the header extension when confidentiality is required. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From iesg-secretary@ietf.org Wed Nov 16 23:15:26 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515A111E80E9; Wed, 16 Nov 2011 23:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJxVHoCNekwa; Wed, 16 Nov 2011 23:15:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9DB11E80F3; Wed, 16 Nov 2011 23:15:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111117071525.24240.24716.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2011 23:15:25 -0800 Cc: avtext mailing list , avtext chair , RFC Editor Subject: [avtext] Protocol Action: 'A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication' to Proposed Standard (draft-ietf-avtext-client-to-mixer-audio-level-06.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 07:15:26 -0000 The IESG has approved the following document: - 'A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication' (draft-ietf-avtext-client-to-mixer-audio-level-06.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtext-client-to-mixer-audio-level/ Technical Summary This document defines a mechanism by which packets of Real-Time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox which wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. Working Group Summary The document is a product of the AVTEXT working group. Document Quality Vidyo has a working implementation of this internet-draft. Personnel Keith Drage is the document's shepherd. Gonzalo Camarillo is the responsible AD. RFC Editor Note In the Security Considerations Section: s/relys/relies/ From iesg-secretary@ietf.org Wed Nov 16 23:16:52 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EFA11E810C; Wed, 16 Nov 2011 23:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy1LFNjjFinr; Wed, 16 Nov 2011 23:16:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE0C11E8111; Wed, 16 Nov 2011 23:16:51 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111117071651.25239.73963.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2011 23:16:51 -0800 Cc: avtext mailing list , avtext chair , RFC Editor Subject: [avtext] Protocol Action: 'A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication' to Proposed Standard (draft-ietf-avtext-mixer-to-client-audio-level-06.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 07:16:52 -0000 The IESG has approved the following document: - 'A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication' (draft-ietf-avtext-mixer-to-client-audio-level-06.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to-client-audio-level/ Technical Summary This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. Working Group Summary The document is a product of the AVTEXT working group. Document Quality Jitsu has a working and deployed implementation of this internet- draft. Personnel Keith Drage is the document's shepherd. Gonzalo Camarillo is the responsible AD. From magnus.westerlund@ericsson.com Thu Nov 17 18:37:05 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5554E11E8098 for ; Thu, 17 Nov 2011 18:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcFhEoyBWGka for ; Thu, 17 Nov 2011 18:37:04 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 60FA521F9474 for ; Thu, 17 Nov 2011 18:37:04 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-60-4ec5c4ce76f1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CB.85.13753.EC4C5CE4; Fri, 18 Nov 2011 03:37:03 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 18 Nov 2011 03:37:02 +0100 Message-ID: <4EC5C4CA.3050605@ericsson.com> Date: Fri, 18 Nov 2011 10:36:58 +0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] IPR disclosures on draft-westerlund-avtext-rtcp-sdes-srcname-00 and draft-westerlund-avtext-rtp-stream-pause-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 18 Nov 2011 02:37:05 -0000 WG, I have realized that I forgot to be explicit about the IPR disclosures on the drafts in the presentations. I am sorry about this, please review these disclosures. RTP Media Stream Pause and Resume draft-westerlund-avtext-rtp-stream-pause-00 IPR Disclosure: https://datatracker.ietf.org/ipr/1641/ RTCP SDES Item SRCNAME to Label Individual Sources draft-westerlund-avtext-rtcp-sdes-srcname-00 IPR Disclosure https://datatracker.ietf.org/ipr/1638/ Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Tue Nov 22 09:50:53 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B961F0C35 for ; Tue, 22 Nov 2011 09:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.177 X-Spam-Level: X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF6mzyE9Kl5W for ; Tue, 22 Nov 2011 09:50:52 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8E23E1F0C3E for ; Tue, 22 Nov 2011 09:50:52 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pAMHohwx011212 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 22 Nov 2011 18:50:44 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 22 Nov 2011 18:50:43 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Date: Tue, 22 Nov 2011 18:50:42 +0100 Thread-Topic: WGLC for draft-ietf-avtext-rams-scenarios-01 Thread-Index: AcypP0Dc31PKaJcUTCS5YCyjX9GRWw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [avtext] WGLC for draft-ietf-avtext-rams-scenarios-01 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 22 Nov 2011 17:50:53 -0000 (As WG cochair) This is to announce a working group last call for draft-ietf-avtext-rams-sc= enarios-01 https://datatracker.ietf.org/doc/draft-ietf-avtext-rams-scenarios/ Please respond to the list by December 13th 2011 (i.e. 3 weeks time) with a= ny comments. This is intended as an informational RFC. It is helpful to attempt to categorise the type of your comment (including = severity) and also to assist to provide any replacement text you feel is ne= cessary. If you review the document and have no comments, please tell the chairs tha= t you have reviewed it. This is always useful information in assessing the = degree of WG review and consensus behind the document. Regards Keith From kevin.gross@avanw.com Tue Nov 29 14:07:21 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18AD11E811D for ; Tue, 29 Nov 2011 14:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2eh5h+xIJ2a for ; Tue, 29 Nov 2011 14:07:21 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 17B9011E8120 for ; Tue, 29 Nov 2011 14:07:12 -0800 (PST) Received: (qmail 9474 invoked by uid 0); 29 Nov 2011 22:07:12 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy2.bluehost.com with SMTP; 29 Nov 2011 22:07:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=BF2yXQdrQqBh3YBNdqMZHxp/nfAmyinoKVT8QfetzKY=; b=Fx0IpWIFId0SjGc1c41zZzszQ8+nVlfNn9EhUlo5Mcg3XCZM7NT5vzTXiQpSUhXuzs/3Ipk2U6Do80SlukwoCa+JqpSMcG+oQT58x6KYZnwPWS9AzcdhII07hhuhgcaw; Received: from mail-fx0-f44.google.com ([209.85.161.44]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1RVVpY-0006hK-5D; Tue, 29 Nov 2011 15:07:12 -0700 Received: by faap14 with SMTP id p14so187145faa.31 for ; Tue, 29 Nov 2011 14:07:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.154.151 with SMTP id o23mr51484464bkw.62.1322604430485; Tue, 29 Nov 2011 14:07:10 -0800 (PST) Received: by 10.223.93.197 with HTTP; Tue, 29 Nov 2011 14:07:10 -0800 (PST) In-Reply-To: References: <4EAF4255.8010909@audinate.com> Date: Tue, 29 Nov 2011 15:07:10 -0700 Message-ID: From: Kevin Gross To: Aidan Williams , avtext@ietf.org, avt@ietf.org Content-Type: multipart/alternative; boundary=0015175d039441e9bc04b2e6d76a X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.161.44 authed with kevin.gross@avanw.com} Subject: Re: [avtext] draft-williams-avtext-avbsync updated X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 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, 29 Nov 2011 22:07:22 -0000 --0015175d039441e9bc04b2e6d76a Content-Type: text/plain; charset=ISO-8859-1 Aidan and I ended up at the same conference in San Diego last weekend and found time to discuss clock domain identification. We believe it is desirable to use the same clock identification scheme for IDMS and Aidan's work. Here's a proposal I've fleshed out based on our discussion. The "clocksource" parameter should be improved to allow optional specification of clock identifiers. Clock identifiers are derived from an EUI-48 or EUI-64 as specified by IEEE 1588 (IEEE 1588-2008 7.5.2.2.2, IEEE 1588-2002 D.2). The listed identifiers would be for the current grandmaster and other high-quality clocks on the IEEE 1288 domain, members of a grandmaster cluster (IEEE 1588-2008 17.3) or an alternate master (IEEE 1588-2008 17.4). If no clock identifiers are supplied, implementations may assume that a match of the supplied attributes (e.g. PTP, version and domain identifier) specifies the same clock. If one or more clock identifiers are supplied, these should be compared to the available clock identifiers for the specified domain. If there is at least one match, there is assumed to be a clock match. We both believe a traceability indication should be included in the "clocksource" attribute for IEEE 1588-2002, IEEE 1588-2008, IEEE 802.1AS and NTP. Galileo and GPS are implied traceable and local is presumably never traceable. Aidan argues that you shouldn't have to second guess a traceable clock and therefore, no domain or clock identifiers are required for traceable clocks. > Kevin Gross > On Sun, Nov 6, 2011 at 9:12 PM, Kevin Gross wrote: > > IDMS defines a "clocksource" SDP attribute to identify the clock > domain. The following clock distribution methods are supported by IDMS: > NTP, GPS, Galileo, IEEE 1588-2002, IEEE 1588-2008 and IEEE 802.1AS. When > IEEE 1588-2002 or IEEE 1588-2008 are used, a domain identifier is also > specified. The IEEE 802.1AS PTP profile allows use of the default domain > (0) only. You are proposing using the EUI-64 of the grandmaster instead. I > also considered this possibility for IDMS but was confounded by the > following scenario... > > For fault tolerance, mission-critical media systems are configured with at > least two potential grandmasters all receiving time from a common reference > (e.g. house sync reference, GPS). Upon failure of the primary grandmaster, > another takes over and, although nothing has functionally changed about the > clock domain, the EUI-64 of the grandmaster in the network does change. > Until updated SDP advertisements reflecting the new grandmaster are > received, senders and receivers will believe they are operating on > different time domains and streams will presumably be interrupted. > > It would be very useful to have a unique identifier for a clock domain. My > conclusion after considering the above scenario was that the grandmaster ID > was not that identifier and clock distribution protocol, protocol version > and domain identifier is currently the best identifier we have. I think > there is definitely room for improvement in this. It does not strike me as > an easy problem, however. > > I like your idea of using a traceability indicator to help determine clock > compatibility. I am concerned however that while traceable clocks can be > assumed to be frequency synchronized (syntonized) I am not aware of any way > to gauge the accuracy of their phase synchronization. Nevertheless, adding > a traceability indicator to the SDP clock attribute would seem to be a > useful improvement. > > --0015175d039441e9bc04b2e6d76a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Aidan and I ended up at the same conference in San Diego last weekend and f= ound time to discuss clock domain identification. We=A0believe=A0it is=A0de= sirable=A0to use the same clock identification scheme for IDMS and Aidan= 9;s work. Here's a proposal I've fleshed out based on our discussio= n.

The "clocksource" parameter should be improved to allow = optional specification of clock identifiers. Clock identifiers are derived = from an EUI-48 or EUI-64 as specified by IEEE 1588 (IEEE 1588-2008 7.5.2.2.= 2, IEEE 1588-2002 D.2). The listed identifiers would be for the current gra= ndmaster and other high-quality clocks on the IEEE 1288 domain, members of = a grandmaster cluster (IEEE 1588-2008 17.3) or an alternate master (IEEE 15= 88-2008 17.4).

If no clock identifiers are supplied, implementations m= ay assume that a match of the supplied attributes (e.g. PTP, version and do= main identifier) specifies the same clock. If one or more clock identifiers= are supplied, these should be compared to the available clock identifiers = for the specified domain. If there is at least one match, there is assumed = to be a clock match.

We both=A0believe=A0a traceability indication shou= ld be included in the "clocksource" attribute for IEEE 1588-2002,= IEEE 1588-2008, IEEE 802.1AS and NTP. Galileo=A0and GPS are implied=A0trac= eable=A0and local is presumably never traceable.=A0Aidan argues that =A0you= shouldn't have to second guess a=A0traceable=A0clock and=A0therefore, = no domain or clock identifiers are required for traceable clocks.

Kevin Gross

=A0
On Sun, Nov 6, 2011 at 9:12 PM, Kev= in Gross <kevin.gross@avanw.com> wrote:

IDMS defines a "clo= cksource" SDP attribute to identify the clock domain.=A0The following = clock distribution methods are supported by IDMS: NTP, GPS,=A0Galileo, IEEE= 1588-2002, IEEE 1588-2008 and IEEE 802.1AS.=A0When IEEE 1588-2002 or IEEE = 1588-2008 are used, a domain identifier is also specified. The IEEE 802.1AS= PTP profile allows use of the default domain (0) only.=A0You are proposing= using the EUI-64 of the grandmaster=A0instead. I also considered this poss= ibility for IDMS but was confounded by the following scenario...

For fault tolerance, mission-critical media systems are= configured with at least two potential grandmasters all receiving time fro= m a common reference (e.g. house sync reference, GPS). Upon failure of the = primary grandmaster, another takes over and, although nothing has functiona= lly changed about the clock domain, the EUI-64 of the grandmaster in the ne= twork does change. Until updated SDP advertisements reflecting the new gran= dmaster are received, senders and receivers will believe they are operating= on different time domains and streams will presumably be interrupted.

It would be very useful to have a unique identifier for= a clock domain. My conclusion after considering the above scenario was tha= t the grandmaster ID was not that identifier and clock distribution protoco= l, protocol version and domain identifier is currently the best identifier = we have. I think there is definitely room for improvement in this. It does = not strike me as an easy problem, however.

I like your= idea of using a traceability=A0indicator to help determine clock compatibi= lity. I am concerned however that while traceable clocks can be assumed to = be frequency synchronized (syntonized) I am not aware of any way to gauge t= he accuracy of their phase synchronization. Nevertheless, adding a traceabi= lity indicator to the SDP clock attribute would seem to be a useful improve= ment.

=A0
--0015175d039441e9bc04b2e6d76a--