From nobody Wed Nov 4 13:19:54 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A3D1A87E1; Wed, 4 Nov 2015 13:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYnf_YB6MSyH; Wed, 4 Nov 2015 13:19:51 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DF01A8835; Wed, 4 Nov 2015 13:19:51 -0800 (PST) Received: from [133.93.84.114] (dhcp-84-114.meeting.ietf94.jp [133.93.84.114]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tA4LJ9uT058547 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 Nov 2015 15:19:10 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-84-114.meeting.ietf94.jp [133.93.84.114] claimed to be [133.93.84.114] From: "Ben Campbell" To: avtext@ietf.org Date: Thu, 05 Nov 2015 06:19:03 +0900 Message-ID: <1F368FDD-67AA-4906-A895-BABC05E91140@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5164) Archived-At: Cc: avtext-chairs@ietf.org Subject: [avtext] Chair Change X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 21:19:53 -0000 Hi everyone, Rachel Huang (rachel.huang@huawei.com) will replace Keith as co-chair of AVTEXT, effective as soon as the Secretariat makes the change. Keith needs to focus time on some other priorities for a while. Please welcome Rachel in her new role. And many thanks to Keith for all the work he has done to date to keep the working group productive and on track. Thanks! Ben. From nobody Wed Nov 4 15:18:38 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708871B37B2; Wed, 4 Nov 2015 15:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r-7Sdgl4diE; Wed, 4 Nov 2015 15:18:34 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF5F1B37B3; Wed, 4 Nov 2015 15:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=676; q=dns/txt; s=iport; t=1446679115; x=1447888715; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Zn6/D/LmmtNm3wq+5HYnwV34AmPao19D3cIpS+OYT78=; b=Veo0I4hJ1JpJ5haU/8S2XCOr12b78/SkgEcibcoQ7dfeiES+EPYGJFwW MSKCuQxxJi50SUA2Y/714JxzXgpsuK2LFBajLsjVbYQMUbQNDfBX6K51l Ih5ijp0W1UjMkZvfSpwtZNufqwqcYlxY915oLGlg/5X6wQ/9TlKJMRZwv o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaAgCNkTpW/4gNJK1egztTb71zAQ2BXhcKhSdKAoE+OBQBAQEBAQEBgQqENgEBBAEBATc0CxACAQg2ECcLJQIEDgWILg3CGgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhlSCEIJuhFmDS4EUBZJng2EBjSKBWoQ/licBHwEBQoQEcoU0AQEB X-IronPort-AV: E=Sophos;i="5.20,245,1444694400"; d="scan'208";a="205007575" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 04 Nov 2015 23:18:34 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA4NIXcN010599 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 23:18:33 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 17:18:32 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 17:18:32 -0600 From: "Mo Zanaty (mzanaty)" To: Ben Campbell Thread-Topic: [avtext] Chair Change Thread-Index: AQHRF0aQfOwdMj3Yck29QFIxW0MveJ6Mf7Gl Date: Wed, 4 Nov 2015 23:18:32 +0000 Message-ID: <17493C4D-5B50-4993-850B-78337866D62C@cisco.com> References: <1F368FDD-67AA-4906-A895-BABC05E91140@nostrum.com> In-Reply-To: <1F368FDD-67AA-4906-A895-BABC05E91140@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "avtext@ietf.org" , "avtext-chairs@ietf.org" Subject: Re: [avtext] Chair Change X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 23:18:36 -0000 Thanks for all the great work Keith. And welcome Rachel.=20 Mo On Nov 5, 2015, at 6:20 AM, Ben Campbell wrote: Hi everyone, Rachel Huang (rachel.huang@huawei.com) will replace Keith as co-chair of AV= TEXT, effective as soon as the Secretariat makes the change. Keith needs to= focus time on some other priorities for a while. Please welcome Rachel in her new role. And many thanks to Keith for all the= work he has done to date to keep the working group productive and on track= . Thanks! Ben. _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Nov 10 12:45:41 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8E61B3F92 for ; Tue, 10 Nov 2015 12:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuEw8g796tWB for ; Tue, 10 Nov 2015 12:45:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FDC11B3F91 for ; Tue, 10 Nov 2015 12:45:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAE04768; Tue, 10 Nov 2015 20:45:35 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 Nov 2015 20:45:34 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Wed, 11 Nov 2015 04:45:30 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: avtext minutes for IETF94 Thread-Index: AdEb+MXjC5CVInODQ5aqvSI640riBQ== Date: Tue, 10 Nov 2015 20:45:29 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86465D07@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.217.22] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86465D07nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.5642576F.00E9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.75, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7b3ce5aedc8111b25e24a9687410fcc3 Archived-At: Subject: [avtext] avtext minutes for IETF94 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 20:45:40 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86465D07nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Avtext minutes for IETF94 has been uploaded, https://www.ietf.org/proceedin= gs/94/minutes/minutes-94-avtext. Any corrections or additions are welcomed. _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --_000_51E6A56BD6A85142B9D172C87FC3ABBB86465D07nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Avtext minutes for IETF94 has b= een uploaded, h= ttps://www.ietf.org/proceedings/94/minutes/minutes-94-avtext.

Any corrections or additions ar= e welcomed.

 

____________________________= ___________________

avtext mailing list

avtext@ietf.org

https://www.ietf.org/mailman/listinfo/avtext

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB86465D07nkgeml501mbschi_-- From nobody Tue Nov 10 19:57:49 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0011B2FB1; Tue, 10 Nov 2015 19:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BIW1PUMvpdU; Tue, 10 Nov 2015 19:57:45 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079FA1B2FAF; Tue, 10 Nov 2015 19:57:40 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tAB3vcdT078142 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 10 Nov 2015 21:57:39 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: draft-ietf-avtext-splicing-notification.all@ietf.org, avtext@ietf.org Date: Tue, 10 Nov 2015 21:57:38 -0600 Message-ID: <5FFEFB3F-B495-4D09-AA1D-E4411DFFB4E2@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5164) Archived-At: Subject: [avtext] AD Evaluation of draft-ietf-avtext-splicing-notification-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 03:57:46 -0000 Hi, Here is my AD Evaluation of draft-ietf-avtext-splicing-notification-02. I think a number of these issues need to be handled prior to the IETF last call, so I'm holding off on that until we've at least had a chance to discuss them. Thanks! Ben. ----------- Substantive Comments: ===================== - RFC 6828 informational. This draft depends heavily on behavior from that RFC (which needs to be a normative reference as things are currently written). I suspect this draft needs to be PS due to the SDP group semantics registration, but I think it really should be informational, or it should be written in a way to not depend on or assume behaviors from RFC 6828. (Especially for the security considerations) - section 1, first paragraph: "the splicing duration MUST be inside of the specific, pre-designated time slot" That sounds more like a statement of fact than a 2119 MUST. - 2, 2nd paragraph: "When a new splicing is forthcoming, the main RTP sender MUST send the Splicing Interval to the mixer." I don't think that needs to be a 2119 MUST. The sender does this, or it doesn't. In the latter case, this draft does not come into play. -2, paragraph 3: If I understand correctly, this mechanisms doesn't work unless the substitutive source knows the splice interval. Furthermore, it needs to know it in time to act on it. I'm not sure this mechanism is useful without at least some mechanism to share the SI. Do you assume they have a proprietary mechanism (i.e. they are from the same vendor) or perhaps the substitutive source is colocated with the main source or the mixer? If so, please mention that. Is there a minimum required resolution and skew for the shared reference clock? -2, paragraph 5: Any guidance on how much ahead the substitutive packets should be sent? -2, paragraph 6: How. By selecting the correct packet? By adjusting the time stamp? Do we assume a main stream packet exists that starts at that exact timestamp? -3.1, paragraph after figure 1: This is at least partially redundant with previous guidance. - 3.2, last paragraph: Are there receivers that are not down-stream receivers? If so, there the SHOULD and MUST seem to conflict. Or does the MUST only apply if you want undetectable splicing? - 4, last paragraph: "Either the main RTP sender or the substitutive sender SHOULD send..." Assuming "either" means that exactly one SHOULD send, how do they coordinate? Or does it matter if both do it? -5, 3rd paragraph: What if the mixer uses a separate closed RCTP loop for senders and receivers? I think 6828 can be interpreted to allow that. (And see previous comment about assuming 6828 behavior.) Also, please describe the process by which the RTP sender infers that splicing failed from the downstream sender reports. ( I think I know, but don't assume everyone will.) -5, last paragraph: What do you mean by "check the path"? Wouldn't it be up to the mixer to fall back to a payload specific mechanism? -7, first paragraph: If you depend on the security considerations in RFC 6828, that reference needs to be normative. -7, 2nd paragraph: "authenticate the main and substitutive content sources? I thought the paragraph was talking about SRTP on the main source but not on the substitutive source? If neither are protected, there’s a lot easier attacks than the one described. -7, last paragraph: The last two sentences conflict with slightly different normative statements earlier in the draft. - 10.2: The references for RFCs 3711, 5506, 6904, and 6828 need to be normative the way the draft is currently formulated. (See previous comments about 6828). Editorial Comments: =================== - 1, first paragraph: "refers to this information as Splicing Interval." Missing article ("... the Splicing Interval") - 1, last paragraph: Do you mean to say you designed it in a complementary fashion, or it carries the SI in a complementary fashion? - 2, 2nd paragraph: "Usually, the Splicing Interval SHOULD be sent more than once" "Usually" is redundant to the SHOULD, and only serves to weaken it. If there are known circumstances where it does not make sense to send more than once, please mention them. - 3.1, paragraph 2: I think this would be easier to understand if you described how to calculate the absolute (64bit NTP) splicing out time by concatenating the first octet of the splice-in time with the 7 octets of the splice-out time. also, s/referred/infer - 3.1, 2nd to last paragraph: Consider stating this in the positive, i.e. SHOULD strip the RTP extension from forwarded packets. - 3.1, last paragraph: This seems to belong with the following section. It needs a "the" before "RTCP splicing notification message". Also, please consider restating "MUST be sent to provide robustness " in the active voice. (That is, what MUST send it?) -3.2, 2nd paragraph: s/fix/fixed - 3.2, definition of Timestamp: s/"RTCP Sender Report" / "the RTCP Sender Report - 4, 1st paragraph: I don't understand the phrase "... provide the Reference Information align with its multimedia content ...". - 5, 1st paragraph: "... other failure case..." "... other failure cases..." or "... the other failure case..." - 5, 2nd paragraph: "... splicing un-aware middlebox ..." "... a splicing un-aware middlebox ..." or "... splicing un-aware middleboxes ..." "one heuristics" -> "one heuristic" What uses the heuristic? (consider active voice). - 6, paragraph 2: Please expand SDP on first mention in the body text. -6, paragraph 3: "multiple media": Does that mean multiple media streams? Multiple m-lines? s / "This semantics" / "This semantic" ; or "These semantics" -7, 3rd paragraph: "To protect from different substitutive contents are inserted, the splicer MUST have some mechanisms to authenticate the substitutive stream source." I don't understand the sentence. -9: Acknowledgement section says "TBD" Also, s/Acknowledges/Acknowledgement From nobody Fri Nov 13 05:18:21 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EEE1A6FD1; Fri, 13 Nov 2015 05:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eSnAh_E7dMM; Fri, 13 Nov 2015 05:18:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A581A6FD6; Fri, 13 Nov 2015 05:18:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEB10961; Fri, 13 Nov 2015 13:18:08 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 13 Nov 2015 13:17:58 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Fri, 13 Nov 2015 21:17:51 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell , "draft-ietf-avtext-splicing-notification.all@ietf.org" , "avtext@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-avtext-splicing-notification-02 Thread-Index: AQHRHDUljrdMBNpfFEWHVW24J+eXXp6YgQYg Date: Fri, 13 Nov 2015 13:17:50 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB864663EE@nkgeml501-mbs.china.huawei.com> References: <5FFEFB3F-B495-4D09-AA1D-E4411DFFB4E2@nostrum.com> In-Reply-To: <5FFEFB3F-B495-4D09-AA1D-E4411DFFB4E2@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.216.236] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5645E311.01C7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.75, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dd7c07e1e22ebdc85acb082f254630fa Archived-At: Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-splicing-notification-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 13:18:20 -0000 SGkgQmVuLA0KDQpTb3JyeSBmb3IgbXkgbGF0ZSByZXNwb25zZS4gSSdtIG9uIG15IGJ1c2luZXNz IHRyaXAgdGhpcyB3ZWVrLiBQbGVhc2Ugc2VlIG15IHJlcGxpZXMgaW5saW5lLiBJJ2xsIG1vZGlm eSB0aGUgZHJhZnQgYWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMgYW5kIHByb3Bvc2FscyB0aGF0 IHlvdSBhZ3JlZS4NCg0KQlIsDQpSYWNoZWwNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R 5Lu25Lq6OiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5jb21dIA0K5Y+R6YCB5pe2 6Ze0OiAyMDE15bm0MTHmnIgxMeaXpSAxMTo1OA0K5pS25Lu25Lq6OiBkcmFmdC1pZXRmLWF2dGV4 dC1zcGxpY2luZy1ub3RpZmljYXRpb24uYWxsQGlldGYub3JnOyBhdnRleHRAaWV0Zi5vcmcNCuS4 u+mimDogQUQgRXZhbHVhdGlvbiBvZiBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmlj YXRpb24tMDINCg0KSGksDQoNCkhlcmUgaXMgbXkgQUQgRXZhbHVhdGlvbiBvZiBkcmFmdC1pZXRm LWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24tMDIuIA0KSSB0aGluayBhIG51bWJlciBvZiB0 aGVzZSBpc3N1ZXMgbmVlZCB0byBiZSBoYW5kbGVkIHByaW9yIHRvIHRoZSBJRVRGIGxhc3QgY2Fs bCwgc28gSSdtIGhvbGRpbmcgb2ZmIG9uIHRoYXQgdW50aWwgd2UndmUgYXQgbGVhc3QgaGFkIGEg Y2hhbmNlIHRvIGRpc2N1c3MgdGhlbS4NCg0KVGhhbmtzIQ0KDQpCZW4uDQoNCi0tLS0tLS0tLS0t DQoNClN1YnN0YW50aXZlIENvbW1lbnRzOg0KPT09PT09PT09PT09PT09PT09PT09DQoNCi0gUkZD IDY4MjggaW5mb3JtYXRpb25hbC4gVGhpcyBkcmFmdCBkZXBlbmRzIGhlYXZpbHkgb24gYmVoYXZp b3IgZnJvbSB0aGF0IFJGQyAod2hpY2ggbmVlZHMgdG8gYmUgYSBub3JtYXRpdmUgcmVmZXJlbmNl IGFzIHRoaW5ncyBhcmUgY3VycmVudGx5IHdyaXR0ZW4pLiBJIHN1c3BlY3QgdGhpcyBkcmFmdCBu ZWVkcyB0byBiZSBQUyBkdWUgdG8gIHRoZSBTRFAgZ3JvdXAgc2VtYW50aWNzIHJlZ2lzdHJhdGlv biwgIGJ1dCBJIHRoaW5rIGl0IHJlYWxseSBzaG91bGQgYmUgaW5mb3JtYXRpb25hbCwgb3IgaXQg c2hvdWxkIGJlIHdyaXR0ZW4gaW4gYSB3YXkgdG8gbm90IGRlcGVuZCBvbiBvciBhc3N1bWUgYmVo YXZpb3JzIGZyb20gUkZDIDY4MjguIChFc3BlY2lhbGx5IGZvciB0aGUgc2VjdXJpdHkNCmNvbnNp ZGVyYXRpb25zKQ0KIA0KW1JhY2hlbF06IE1ha2Ugc2Vuc2UgdG8gbWUuIFNpbmNlIHdlIGV4cGVj dCB0aGlzIGRyYWZ0IGdvZXMgZm9yIGEgc3RhbmRhcmRzIHRyYWNrLCBJJ2xsIG1vZGlmeSB0aGUg ZHJhZnQgdG8ganVzdCB1c2UgUkZDNjgyOCBhcyBhbiBleGFtcGxlIG9mIHNwbGljaW5nIG1lY2hh bmlzbXMuIFdoYXQgZG8geW91IHRoaW5rPw0KDQotIHNlY3Rpb24gMSwgZmlyc3QgcGFyYWdyYXBo OiAidGhlIHNwbGljaW5nIGR1cmF0aW9uIE1VU1QgYmUgaW5zaWRlIG9mIHRoZSBzcGVjaWZpYywg cHJlLWRlc2lnbmF0ZWQgdGltZSBzbG90Ig0KDQpUaGF0IHNvdW5kcyBtb3JlIGxpa2UgYSBzdGF0 ZW1lbnQgb2YgZmFjdCB0aGFuIGEgMjExOSBNVVNULg0KDQpbUmFjaGVsXTogSG93IGFib3V0IGNo YW5naW5nIHRvICJuZWVkcyB0byI/DQoNCi0gMiwgMm5kIHBhcmFncmFwaDogIldoZW4gYSBuZXcg c3BsaWNpbmcgaXMgZm9ydGhjb21pbmcsIHRoZSBtYWluIFJUUCBzZW5kZXIgTVVTVCBzZW5kIHRo ZQ0KICAgIFNwbGljaW5nIEludGVydmFsIHRvIHRoZSBtaXhlci4iDQoNCkkgZG9uJ3QgdGhpbmsg dGhhdCBuZWVkcyB0byBiZSBhIDIxMTkgTVVTVC4gVGhlIHNlbmRlciBkb2VzIHRoaXMsIG9yIGl0 IGRvZXNuJ3QuIEluIHRoZSBsYXR0ZXIgY2FzZSwgdGhpcyBkcmFmdCBkb2VzIG5vdCBjb21lIGlu dG8gcGxheS4NCg0KW1JhY2hlbF06IEFncmVlLiBBbHNvIGNhbiBiZSBjaGFuZ2VkIHRvICJuZWVk cyB0byIuDQoNCi0yLCBwYXJhZ3JhcGggMzoNCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwg dGhpcyBtZWNoYW5pc21zIGRvZXNuJ3Qgd29yayB1bmxlc3MgdGhlIHN1YnN0aXR1dGl2ZSBzb3Vy Y2Uga25vd3MgdGhlIHNwbGljZSBpbnRlcnZhbC4gRnVydGhlcm1vcmUsIGl0IG5lZWRzIHRvIGtu b3cgaXQgaW4gdGltZSB0byBhY3Qgb24gaXQuIEknbSBub3Qgc3VyZSB0aGlzIG1lY2hhbmlzbSBp cyB1c2VmdWwgd2l0aG91dCBhdCBsZWFzdCBzb21lIG1lY2hhbmlzbSB0byBzaGFyZSB0aGUgU0ku IERvIHlvdSBhc3N1bWUgdGhleSBoYXZlIGEgcHJvcHJpZXRhcnkgbWVjaGFuaXNtIChpLmUuIHRo ZXkgYXJlIGZyb20gdGhlIHNhbWUgdmVuZG9yKSBvciBwZXJoYXBzIHRoZSBzdWJzdGl0dXRpdmUg c291cmNlIGlzIGNvbG9jYXRlZCB3aXRoIHRoZSBtYWluIHNvdXJjZSBvciB0aGUgbWl4ZXI/IA0K SWYgc28sIHBsZWFzZSBtZW50aW9uIHRoYXQuDQoNCltSYWNoZWxdOiBZZXMuIEJvdGggYXNzdW1w dGlvbnMgYXJlIHBvc3NpYmxlIGluIGRlcGxveW1lbnRzLiBTbyBJJ2xsIGFkZCBzb21lIHRleHQg aW4gU2VjdGlvbiAzIHRvIGNsYXJpZnkgdGhpcy4NCg0KSXMgdGhlcmUgYSBtaW5pbXVtIHJlcXVp cmVkIHJlc29sdXRpb24gYW5kIHNrZXcgZm9yIHRoZSBzaGFyZWQgcmVmZXJlbmNlIGNsb2NrPw0K DQpbUmFjaGVsXTogSXQgZGVwZW5kcyBvbiB0aGUgY29kZWMgdGhhdCdzIHVzZWQuIEkgY2FuIGNs YXJpZnkgaXQgaW4gdGhlIGRyYWZ0Lg0KDQotMiwgcGFyYWdyYXBoIDU6DQoNCkFueSBndWlkYW5j ZSBvbiBob3cgbXVjaCBhaGVhZCB0aGUgc3Vic3RpdHV0aXZlIHBhY2tldHMgc2hvdWxkIGJlIHNl bnQ/DQoNCltSYWNoZWxdOiBXZSBoYXZlIHNvbWUgc3VnZ2VzdGlvbnMgaW4gMnJkIHBhcmFncmFw aCBvZiBzZWN0aW9uIDMuIEl0IGlzIGNvcGllZCBhcyBmb2xsb3dpbmc6DQoNCiINCldoZW4gYSBu ZXcgc3BsaWNpbmcgaXMgZm9ydGhjb21pbmcsIHRoZSBtYWluIFJUUCBzZW5kZXIgTVVTVCBzZW5k IHRoZQ0KICAgU3BsaWNpbmcgSW50ZXJ2YWwgdG8gdGhlIG1peGVyLiBVc3VhbGx5LCB0aGUgU3Bs aWNpbmcgSW50ZXJ2YWwgU0hPVUxEDQogICBiZSBzZW50IG1vcmUgdGhhbiBvbmNlIHRvIG1pdGln YXRlIHRoZSBwb3NzaWJsZSBwYWNrZXQgbG9zcy4gVG8NCiAgIGVuYWJsZSB0aGUgbWl4ZXIgdG8g Z2V0IHRoZSBzdWJzdGl0dXRpdmUgY29udGVudCBiZWZvcmUgdGhlIHNwbGljaW5nDQogICBzdGFy dHMsIHRoZSBtYWluIFJUUCBzZW5kZXIgTVVTVCBzZW5kIHRoZSBTcGxpY2luZyBJbnRlcnZhbCBm YXINCiAgIGFoZWFkLiBGb3IgZXhhbXBsZSwgdGhlIG1haW4gUlRQIHNlbmRlciBjYW4gZXN0aW1h dGUgd2hlbiB0byBzZW5kIHRoZQ0KICAgU3BsaWNpbmcgSW50ZXJ2YWwgYmFzZWQgb24gdGhlIHJv dW5kLXRyaXAgdGltZSAoUlRUKSBmb2xsb3dpbmcgdGhlDQogICBtZWNoYW5pc21zIGluIHNlY3Rp b24gNi40LjEgb2YgW1JGQzM1NTBdIHdoZW4gdGhlIG1peGVyIHNlbmRzIFJUQ1AgUlINCiAgIHRv IHRoZSBtYWluIHNlbmRlci4NCiINCg0KLTIsIHBhcmFncmFwaCA2Og0KDQpIb3cuIEJ5IHNlbGVj dGluZyB0aGUgY29ycmVjdCBwYWNrZXQ/IEJ5IGFkanVzdGluZyB0aGUgdGltZSBzdGFtcD8gRG8g d2UgYXNzdW1lIGEgbWFpbiBzdHJlYW0gcGFja2V0IGV4aXN0cyB0aGF0IHN0YXJ0cyBhdCB0aGF0 IGV4YWN0IHRpbWVzdGFtcD8NCg0KW1JhY2hlbF06IFRoZSBtaXhlciBjYW5ub3QgZW5zdXJlIHRo ZSBleGFjdCBzYW1lIHRpbWUgaW5zdGFuY2UuIFNvIGhvdyBhYm91dCBmaXhpbmcgaXQgbGlrZSB0 aGlzPw0KDQoiDQpXaGVuIHRoZSBzcGxpY2luZyB3aWxsIGVuZCwgdGhlIG1peGVyIE1VU1QgZW5z dXJlIHRoZSBTcGxpY2luZyBPdXQgTlRQIHRpbWVzdGFtcCBpbiB0aGUgU3BsaWNpbmcgSW50ZXJ2 YWwgaXMgaW4gdGhlIGJldHdlZW4gb2YgdGhlIHRpbWUgaW5zdGFuY2Ugb2YgdGhlIGxhc3Qgc3Vi c3RpdHV0aXZlIFJUUCBwYWNrZXQncyB0aW1lc3RhbXAgYW5kIHRoZSB0aW1lIGluc3RhbmNlIG9m IHRoZSBmaXJzdCBtYWluIFJUUCBwYWNrZXQncyB0aW1lc3RhbXAgdGhhdCB3b3VsZCBiZSBwcmVz ZW50ZWQgb24gdGhlIHJlY2VpdmVycy4NCiINCg0KLTMuMSwgcGFyYWdyYXBoIGFmdGVyIGZpZ3Vy ZSAxOg0KDQpUaGlzIGlzIGF0IGxlYXN0IHBhcnRpYWxseSByZWR1bmRhbnQgd2l0aCBwcmV2aW91 cyBndWlkYW5jZS4NCg0KW1JhY2hlbF06IE9rYXkuIFdpbGwgYmUgZml4ZWQuDQoNCi0gMy4yLCBs YXN0IHBhcmFncmFwaDoNCg0KQXJlIHRoZXJlIHJlY2VpdmVycyB0aGF0IGFyZSBub3QgZG93bi1z dHJlYW0gcmVjZWl2ZXJzPw0KDQpbUmFjaGVsXTogSSdsbCBjaGFuZ2UgInJlY2VpdmVycyIgaW4g dGhlIGZpcnN0IHNlbnRlbmNlIGludG8gImRvd24tc3RyZWFtIHJlY2VpdmVycyIgdG8gYXZvaWQg YW55IGNvbmZ1c2lvbnMuDQogDQogSWYgc28sIHRoZXJlIHRoZSBTSE9VTEQgYW5kIE1VU1Qgc2Vl bSB0byBjb25mbGljdC4gT3IgZG9lcyB0aGUgTVVTVCBvbmx5IGFwcGx5IGlmIHlvdSB3YW50IHVu ZGV0ZWN0YWJsZSBzcGxpY2luZz8NCg0KW1JhY2hlbF06IFRoZSBzZWNvbmQgc2VudGVuY2Ugc2hv dWxkIGJlIGNoYW5nZWQgZnJvbQ0KDQoiDQpBbmQgaXQgTVVTVCBOT1QgZm9yd2FyZCB0aGUgbWVz c2FnZSB0bw0KICAgdGhlIGRvd25zdHJlYW0gcmVjZWl2ZXJzIHRvIGF2b2lkIHRoZW0gZnJvbSBk ZXRlY3Rpbmcgc3BsaWNpbmcNCiAgIGRlZmluZWQgaW4gU2VjdGlvbiA0LjUgaW4gW1JGQzY4Mjhd Lg0KIg0KVG8NCg0KIg0KQW5kIGlmIHRoZSBtaXhlciB3aXNoZXMgdG8gcHJldmVudCB0aGUgZG93 bnN0cmVhbSByZWNlaXZlcnMgZnJvbSBkZXRlY3Rpbmcgc3BsaWNpbmcsIGl0IE1VU1QgTk9UIGZv cndhcmQgdGhlIG1lc3NhZ2UuDQoiDQoNCg0KLSA0LCBsYXN0IHBhcmFncmFwaDogIkVpdGhlciB0 aGUgbWFpbiBSVFAgc2VuZGVyIG9yIHRoZSBzdWJzdGl0dXRpdmUgc2VuZGVyIFNIT1VMRCBzZW5k Li4uIg0KDQpBc3N1bWluZyAiZWl0aGVyIiBtZWFucyB0aGF0IGV4YWN0bHkgb25lIFNIT1VMRCBz ZW5kLCBob3cgZG8gdGhleSBjb29yZGluYXRlPyBPciBkb2VzIGl0IG1hdHRlciBpZiBib3RoIGRv IGl0Pw0KDQpbUmFjaGVsXTogWWVzLiBUaGV5IGNhbiBiZSBjb29yZGluYXRlZCBieSBzb21lIHBy b3ByaWV0YXJ5IG91dC1vZi1iYW5kIG1lY2hhbmlzbXMuIEknbGwgY2xhcmlmeSBpdCBpbiB0aGUg ZHJhZnQuDQoNCi01LCAzcmQgcGFyYWdyYXBoOg0KDQpXaGF0IGlmIHRoZSBtaXhlciB1c2VzIGEg c2VwYXJhdGUgY2xvc2VkIFJDVFAgbG9vcCBmb3Igc2VuZGVycyBhbmQgcmVjZWl2ZXJzPyBJIHRo aW5rIDY4MjggY2FuIGJlIGludGVycHJldGVkIHRvIGFsbG93IHRoYXQuIChBbmQgc2VlIHByZXZp b3VzIGNvbW1lbnQgYWJvdXQgYXNzdW1pbmcgNjgyOCBiZWhhdmlvci4pDQoNCltSYWNoZWxdOiBJ biBvdGhlciB0b3BvbG9naWVzIHdoZXJlIHNlbmRlcnMgYW5kIHJlY2VpdmVycyBhcmUgaW4gZGlm ZmVyZW50IFJUQ1AgZG9tYWlucywgd2UgYXNzdW1lIHRoYXQgc3BsaWNpbmcgZmFpbHVyZSBpcyBu b3RpZmllZCBieSBvdXQtb2YtYmFuZCBtZWNoYW5pc21zLg0KDQpBbHNvLCBwbGVhc2UgZGVzY3Jp YmUgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhlIFJUUCBzZW5kZXIgaW5mZXJzIHRoYXQgc3BsaWNp bmcgZmFpbGVkIGZyb20gdGhlIGRvd25zdHJlYW0gc2VuZGVyIHJlcG9ydHMuICggSSB0aGluayBJ IGtub3csIGJ1dCBkb24ndCBhc3N1bWUgZXZlcnlvbmUgd2lsbC4pDQoNCltSYWNoZWxdOiBPay4N Cg0KLTUsIGxhc3QgcGFyYWdyYXBoOg0KDQpXaGF0IGRvIHlvdSBtZWFuIGJ5ICJjaGVjayB0aGUg cGF0aCI/IFdvdWxkbid0IGl0IGJlIHVwIHRvIHRoZSBtaXhlciB0byBmYWxsIGJhY2sgdG8gYSBw YXlsb2FkIHNwZWNpZmljIG1lY2hhbmlzbT8NCg0KW1JhY2hlbF06IElmIGEgZmFpbHVyZSBpcyBk ZXRlY3RlZCwgaXQgaXMgcG9zc2libGUgdGhhdCB0aGVyZSdzIGEgc3BsaWNpbmcgdW4tYXdhcmUg bWlkZGxlYm94IGluIHRoZSBwYXRoIGJldHdlZW4gdGhlIHNlbmRlciBhbmQgbWl4ZXIsIGFuZCBS VENQIG1lc3NhZ2VzIGhhdmVuJ3QgYXJyaXZlZCBpbiB0aW1lLiBTbyB0aGUgYmVzdCB3YXkgaXMg dG8gdXNlIFtTQ1RFMzVdIGluc3RlYWQsIHdoaWNoIGVuY2Fwc3VsYXRlcyB0aGUgc3BsaWNpbmcg aW50ZXJ2YWwgaW5zaWRlIHRoZSBwYXlsb2FkLiBCdXQgeW91J3JlIHJpZ2h0LiBUaGUgbWl4ZXIg aW4gdGhpcyBjYXNlIG11c3Qgc3VwcG9ydCBkZXRlY3RpbmcgdGhlIHBheWxvYWQgYW5kIGFncmVl IHRvIGZhbGwgYmFjayB0byB0aGlzIG1ldGhvZC4gVGh1cywgY2FuIEkgY2hhbmdlIHRoZSBsYXN0 IHBhcmFncmFwaCBhcyBmb2xsb3dpbmc/DQoNCk9MRA0KIg0KVXBvbiB0aGUgZGV0ZWN0aW9uIG9m IGEgZmFpbHVyZSwgdGhlIG1haW4gUlRQIHNlbmRlciBvciB0aGUNCiAgIHN1YnN0aXR1dGl2ZSBz ZW5kZXIgU0hPVUxEIGNoZWNrIHRoZSBwYXRoIHRvIHRoZSBmYWlsZWQgbWl4ZXIsIG9yDQogICBm YWxsYmFjayB0byB0aGUgcGF5bG9hZCBzcGVjaWZpYyBtZWNoYW5pc21zLCBlLmcuLCBNUEVHLVRT IHNwbGljaW5nDQogICBzb2x1dGlvbiBkZWZpbmVkIGluIFtTQ1RFMzVdLg0KIg0KDQpORVcNCiIN ClVwb24gdGhlIGRldGVjdGlvbiBvZiBhIGZhaWx1cmUsIHRoZSBtaXhlciBjYW4gY29tbXVuaWNh dGUgd2l0aCB0aGUgbWFpbiBzZW5kZXIgYW5kIHRoZSBzdWJzdGl0dXRpdmUgc2VuZGVyIGluIHNv bWUgb3V0IG9mIGJhbmQgc2lnbmFsaW5nIHRvIGZhbGwgYmFjayB0byB0aGUgcGF5bG9hZCBzcGVj aWZpYyBtZWNoYW5pc21zIGl0IHN1cHBvcnRzLCBlLmcuLCBNUEVHLVRTIHNwbGljaW5nIHNvbHV0 aW9uIGRlZmluZWQgaW4gW1NDVEUzNV0uDQoiDQoNCi03LCBmaXJzdCBwYXJhZ3JhcGg6DQoNCklm IHlvdSBkZXBlbmQgb24gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIFJGQyA2ODI4LCB0 aGF0IHJlZmVyZW5jZSBuZWVkcyB0byBiZSBub3JtYXRpdmUuDQoNCltSYWNoZWxdOiBBZ3JlZS4g V2lsbCBkZWxldGUgdGhlIHJlZmVyZW5jZSBhbmQgcmVwaHJhc2Ugc29tZSB0ZXh0cy4NCg0KLTcs IDJuZCBwYXJhZ3JhcGg6ICJhdXRoZW50aWNhdGUgdGhlIG1haW4gYW5kIHN1YnN0aXR1dGl2ZSBj b250ZW50IHNvdXJjZXM/DQoNCkkgdGhvdWdodCB0aGUgcGFyYWdyYXBoIHdhcyB0YWxraW5nIGFi b3V0IFNSVFAgb24gdGhlIG1haW4gc291cmNlIGJ1dCBub3Qgb24gdGhlIHN1YnN0aXR1dGl2ZSBz b3VyY2U/IElmIG5laXRoZXIgYXJlIHByb3RlY3RlZCwgdGhlcmXigJlzIGEgbG90IGVhc2llciBh dHRhY2tzIHRoYW4gdGhlIG9uZSBkZXNjcmliZWQuDQoNCltSYWNoZWxdOiBZZXMuIFlvdSdyZSBy aWdodC4gU1JUUCBzaG91bGQgYmUgYWxzbyB1c2VkIG9uIHRoZSBzdWJzdGl0dXRpdmUgc291cmNl LiANCg0KLTcsIGxhc3QgcGFyYWdyYXBoOg0KDQpUaGUgbGFzdCB0d28gc2VudGVuY2VzIGNvbmZs aWN0IHdpdGggc2xpZ2h0bHkgZGlmZmVyZW50IG5vcm1hdGl2ZSBzdGF0ZW1lbnRzIGVhcmxpZXIg aW4gdGhlIGRyYWZ0Lg0KDQpbUmFjaGVsXTogQXJlIHlvdSByZWZlcnJpbmcgdG8gdGhlIGxhc3Qg cGFyYWdyYXBoIG9mIFNlY3Rpb24gMy4yLiBUaGV5IGRvbid0IGNvbmZsaWN0LiBTZWN0aW9uIDMu MiBpcyB0YWxraW5nIGFib3V0IFJUQ1AgbWVzc2FnZS4gSGVyZSBpcyB0YWxraW5nIGFib3V0IFJU UCBoZWFkZXIgZXh0ZW5zaW9ucy4NCg0KLSAxMC4yOg0KDQpUaGUgcmVmZXJlbmNlcyBmb3IgUkZD cyAzNzExLCA1NTA2LCA2OTA0LCBhbmQgNjgyOCBuZWVkIHRvIGJlIG5vcm1hdGl2ZSB0aGUgd2F5 IHRoZSBkcmFmdCBpcyBjdXJyZW50bHkgZm9ybXVsYXRlZC4gKFNlZSBwcmV2aW91cyBjb21tZW50 cyBhYm91dCA2ODI4KS4NCg0KW1JhY2hlbF06IEFncmVlLiBXaWxsIGJlIGZpeGVkLg0KDQpFZGl0 b3JpYWwgQ29tbWVudHM6DQo9PT09PT09PT09PT09PT09PT09DQoNCi0gMSwgZmlyc3QgcGFyYWdy YXBoOiAicmVmZXJzIHRvIHRoaXMgaW5mb3JtYXRpb24gYXMgU3BsaWNpbmcgSW50ZXJ2YWwuIg0K DQpNaXNzaW5nIGFydGljbGUgKCIuLi4gdGhlIFNwbGljaW5nIEludGVydmFsIikNCg0KW1JhY2hl bF06IE9rLg0KDQotIDEsIGxhc3QgcGFyYWdyYXBoOg0KDQpEbyB5b3UgbWVhbiB0byBzYXkgeW91 IGRlc2lnbmVkIGl0IGluIGEgY29tcGxlbWVudGFyeSBmYXNoaW9uLCBvciBpdCBjYXJyaWVzIHRo ZSBTSSBpbiBhIGNvbXBsZW1lbnRhcnkgZmFzaGlvbj8NCg0KW1JhY2hlbF06IEknbSBub3QgcXVp dGUgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UuIFRoZSByZWFzb24gd2Ugd2FudCB0 byBoYXZlIGEgUlRDUCBtZXNzYWdlIGhlcmUgaXMgdG8gaGF2ZSBhbm90aGVyIHdheSB0byBjb252 ZXkgU0kgaW5mb3JtYXRpb24gaW4gY2FzZSB0aGUgUlRQIGhlYWRlciBpbmZvcm1hdGlvbiBpcyBz dHJpcHBlZCBieSBzb21lIHNwbGljaW5nIHVuYXdhcmUgbWlkZGxlYm94LiBUaGUgUlRDUCBtZXNz YWdlcyBjYW4gYmUgc2VudCBpbiBwYXJhbGxlbCB3aXRoIFJUUCBoZWFkZXIgaW5mb3JtYXRpb24g dG8gaW1wcm92ZSByb2J1c3RuZXNzLg0KDQotIDIsIDJuZCBwYXJhZ3JhcGg6ICJVc3VhbGx5LCB0 aGUgU3BsaWNpbmcgSW50ZXJ2YWwgU0hPVUxEDQogICAgYmUgc2VudCBtb3JlIHRoYW4gb25jZSIN Cg0KIlVzdWFsbHkiIGlzIHJlZHVuZGFudCB0byB0aGUgU0hPVUxELCBhbmQgb25seSBzZXJ2ZXMg dG8gd2Vha2VuIGl0LiBJZiB0aGVyZSBhcmUga25vd24gY2lyY3Vtc3RhbmNlcyB3aGVyZSBpdCBk b2VzIG5vdCBtYWtlIHNlbnNlIHRvIHNlbmQgbW9yZSB0aGFuIG9uY2UsIHBsZWFzZSBtZW50aW9u IHRoZW0uDQoNCltSYWNoZWxdOiBXaWxsIGRlbGV0ZSB1c3VhbGx5Lg0KDQotIDMuMSwgcGFyYWdy YXBoIDI6DQoNCkkgdGhpbmsgdGhpcyB3b3VsZCBiZSBlYXNpZXIgdG8gdW5kZXJzdGFuZCBpZiB5 b3UgZGVzY3JpYmVkIGhvdyB0byBjYWxjdWxhdGUgdGhlIGFic29sdXRlICg2NGJpdCBOVFApIHNw bGljaW5nIG91dCB0aW1lIGJ5IGNvbmNhdGVuYXRpbmcgdGhlIGZpcnN0IG9jdGV0IG9mIHRoZSBz cGxpY2UtaW4gdGltZSB3aXRoIHRoZSA3IG9jdGV0cyBvZiB0aGUgc3BsaWNlLW91dCB0aW1lLg0K DQpbUmFjaGVsXTogT2suDQoNCmFsc28sIHMvcmVmZXJyZWQvaW5mZXINCg0KW1JhY2hlbF06IE9r Lg0KDQotIDMuMSwgMm5kIHRvIGxhc3QgcGFyYWdyYXBoOg0KDQpDb25zaWRlciBzdGF0aW5nIHRo aXMgaW4gdGhlIHBvc2l0aXZlLCBpLmUuIFNIT1VMRCBzdHJpcCB0aGUgUlRQIGV4dGVuc2lvbiBm cm9tIGZvcndhcmRlZCBwYWNrZXRzLg0KDQpbUmFjaGVsXTogT2suDQoNCi0gMy4xLCBsYXN0IHBh cmFncmFwaDoNCg0KVGhpcyBzZWVtcyB0byBiZWxvbmcgd2l0aCB0aGUgZm9sbG93aW5nIHNlY3Rp b24uIEl0IG5lZWRzIGEgInRoZSIgYmVmb3JlICJSVENQIHNwbGljaW5nIG5vdGlmaWNhdGlvbiBt ZXNzYWdlIi4gQWxzbywgcGxlYXNlIGNvbnNpZGVyIHJlc3RhdGluZyAiTVVTVCBiZSBzZW50IHRv IHByb3ZpZGUgcm9idXN0bmVzcyAiIGluIHRoZSBhY3RpdmUgdm9pY2UuIChUaGF0IGlzLCB3aGF0 IE1VU1Qgc2VuZCBpdD8pDQoNCltSYWNoZWxdOiBPay4NCg0KLTMuMiwgMm5kIHBhcmFncmFwaDoN Cg0Kcy9maXgvZml4ZWQNCg0KLSAzLjIsIGRlZmluaXRpb24gb2YgVGltZXN0YW1wOg0KDQpzLyJS VENQIFNlbmRlciBSZXBvcnQiIC8gInRoZSBSVENQIFNlbmRlciBSZXBvcnQNCg0KW1JhY2hlbF06 IEFncmVlLg0KDQotIDQsIDFzdCBwYXJhZ3JhcGg6DQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUg cGhyYXNlICIuLi4gcHJvdmlkZSB0aGUgUmVmZXJlbmNlIEluZm9ybWF0aW9uIGFsaWduIHdpdGgg aXRzIG11bHRpbWVkaWEgY29udGVudCAuLi4iLg0KDQpbUmFjaGVsXTogImFsaWduIiBjYW4gYmUg Y2hhbmdlZCB0byAidG9nZXRoZXIiLg0KDQotIDUsIDFzdCBwYXJhZ3JhcGg6ICIuLi4gb3RoZXIg ZmFpbHVyZSBjYXNlLi4uIg0KDQoiLi4uIG90aGVyIGZhaWx1cmUgY2FzZXMuLi4iIG9yICIuLi4g dGhlIG90aGVyIGZhaWx1cmUgY2FzZS4uLiINCg0KLSA1LCAybmQgcGFyYWdyYXBoOiAiLi4uIHNw bGljaW5nIHVuLWF3YXJlIG1pZGRsZWJveCAuLi4iDQoNCiIuLi4gYSBzcGxpY2luZyB1bi1hd2Fy ZSBtaWRkbGVib3ggLi4uIiBvciAiLi4uIHNwbGljaW5nIHVuLWF3YXJlIG1pZGRsZWJveGVzIC4u LiINCg0KW1JhY2hlbF06IEFncmVlLg0KDQoib25lIGhldXJpc3RpY3MiIC0+ICJvbmUgaGV1cmlz dGljIg0KDQpXaGF0IHVzZXMgdGhlIGhldXJpc3RpYz8gKGNvbnNpZGVyIGFjdGl2ZSB2b2ljZSku DQoNCltSYWNoZWxdOiBUaGUgbWFpbiBSVFAgc2VuZGVyIGFuZCB0aGUgc3Vic3RpdHV0aXZlIHNl bmRlci4NCg0KLSA2LCBwYXJhZ3JhcGggMjoNCg0KUGxlYXNlIGV4cGFuZCBTRFAgb24gZmlyc3Qg bWVudGlvbiBpbiB0aGUgYm9keSB0ZXh0Lg0KDQpbUmFjaGVsXTogUmlnaHQuDQoNCi02LCBwYXJh Z3JhcGggMzoNCg0KIm11bHRpcGxlIG1lZGlhIjogRG9lcyB0aGF0IG1lYW4gbXVsdGlwbGUgbWVk aWEgc3RyZWFtcz8gTXVsdGlwbGUgbS1saW5lcz8NCg0KW1JhY2hlbF06IEhlcmUgaXMgbXVsdGlw bGUgbS1saW5lcy4NCg0KcyAvICJUaGlzIHNlbWFudGljcyIgLyAiVGhpcyBzZW1hbnRpYyIgIDsg b3IgIlRoZXNlIHNlbWFudGljcyINCg0KLTcsIDNyZCBwYXJhZ3JhcGg6ICJUbyBwcm90ZWN0IGZy b20gZGlmZmVyZW50IHN1YnN0aXR1dGl2ZSBjb250ZW50cyBhcmUgaW5zZXJ0ZWQsDQogICAgdGhl IHNwbGljZXIgTVVTVCBoYXZlIHNvbWUgbWVjaGFuaXNtcyB0byBhdXRoZW50aWNhdGUgdGhlDQog ICAgc3Vic3RpdHV0aXZlIHN0cmVhbSBzb3VyY2UuIg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhl IHNlbnRlbmNlLg0KDQpbUmFjaGVsXTogSSB0aGluayBpdCBjb3VsZCBiZSByZXdvcmRlZCBsaWtl IHRoaXMNCg0KIg0KVG8gYXZvaWQgaW52YWxpZCBzdWJzdGl0dXRpdmUgY29udGVudHMgYXJlIGlu c2VydGVkLCB0aGUgc3BsaWNlciBNVVNUIGhhdmUgc29tZSBtZWNoYW5pc21zIHRvIGF1dGhlbnRp Y2F0ZSB0aGUgc3Vic3RpdHV0aXZlIHN0cmVhbSBzb3VyY2UuDQoiDQoNCi05OiBBY2tub3dsZWRn ZW1lbnQgc2VjdGlvbiBzYXlzICJUQkQiIEFsc28sIHMvQWNrbm93bGVkZ2VzL0Fja25vd2xlZGdl bWVudA0KDQpbUmFjaGVsXTogV2lsbCBjaGFuZ2UgaXQuDQoNCg0KDQoNCg== From nobody Mon Nov 16 07:39:59 2015 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AC41A1BF3; Mon, 16 Nov 2015 07:37:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Jonathan Lennox" , "Keith Drage" X-Test-IDTracker: no X-IETF-IDTracker: 6.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151116153738.22557.39259.idtracker@ietfa.amsl.com> Date: Mon, 16 Nov 2015 07:37:38 -0800 Archived-At: X-Mailman-Approved-At: Mon, 16 Nov 2015 07:39:54 -0800 Cc: Jonathan Lennox , Audio/Video Transport Extensions Discussion List , 3GPPLiaison@etsi.org, georg.mayer.huawei@gmx.com, Barry Leiba Subject: [avtext] New Liaison Statement, "LS to IETF AVTEXT on Video Region-of-Interest (ROI)" X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 15:37:39 -0000 Title: LS to IETF AVTEXT on Video Region-of-Interest (ROI) Submission Date: 2015-11-16 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1440/ From: (Ozgur Oyman ) To: (Keith Drage , Jonathan Lennox ) Cc: Response Contacts: georg.mayer.huawei@gmx.com,3GPPLiaison@etsi.org Technical Contacts: Purpose: For information Body: 1. Overall Description: In an earlier liaison statement, 3GPP SA4 informed IETF AVTEXT regarding the Video Region-of-Interest (ROI) signaling framework adopted in 3GPP TS 26.114. Since then, we have recently updated the ROI specification in TS 26.114 with the following: •Clarification of the requirements on ‘Sent ROI’ signaling mandating its offer when ‘Arbitrary ROI’ and/or ‘Pre-defined ROI’ are negotiated, and recommendation of its offer when ‘FECC’ is negotiated. •Definition of separate URNs for RTP header extensions corresponding to arbitrary ROI and predefined ROI signaling for the ‘Sent ROI’ mode. •Clarification of the SDP offer-answer procedures for the ‘a=predefined_ROI’ parameter. •Description of guidelines on the handling of concurrent ROI requests, e.g., during multi-party conferences •Clarification of the definition of ROI information parameters and ROI usage in transcoding scenarios. •Inclusion of SDP examples demonstrating the offer-answer procedures for FECC, ‘Arbitrary ROI’, ‘Pre-defined ROI’ and ‘Sent ROI’ The latest version of 3GPP TS 26.114 v13.1.0 containing these updates can be found in the attached. 2. Actions: To IETF AVTEXT: 3GPP SA4 kindly requests IETF AVTEXT to take the information above into account, and maintain coordination with SA4 during the course of the development of draft-huang-avtext-feedback-image-control-00 toward ensuring the alignment between 3GPP and IETF specifications. 3. Date of Upcoming TSG-SA WG4 Meetings: TSG SA WG4 Meeting #87 25 - 29 Jan 2016 Venue: Sophia Antipolis, France TSG SA WG4 Meeting #88 18 - 22 Apr 2016 Venue: USA Attachments: S4-151302 https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-11-16-3gpp-tsgsa-sa4-avtext-ls-to-ietf-avtext-on-video-region-of-interest-roi-attachment-1.zip From nobody Wed Nov 18 17:12:04 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CF51B3A82; Wed, 18 Nov 2015 17:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a938rI9ds72Y; Wed, 18 Nov 2015 17:11:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 62EB41B3A81; Wed, 18 Nov 2015 17:11:57 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D77AC180005; Wed, 18 Nov 2015 17:10:37 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151119011037.D77AC180005@rfc-editor.org> Date: Wed, 18 Nov 2015 17:10:37 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, avtext@ietf.org, rfc-editor@rfc-editor.org Subject: [avtext] RFC 7656 on A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 01:11:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7656 Title: A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources Author: J. Lennox, K. Gross, S. Nandakumar, G. Salgueiro, B. Burman, Ed. Status: Informational Stream: IETF Date: November 2015 Mailbox: jonathan@vidyo.com, kevin.gross@avanw.com, snandaku@cisco.com, gsalguei@cisco.com, bo.burman@ericsson.com Pages: 46 Characters: 101759 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avtext-rtp-grouping-taxonomy-08.txt URL: https://www.rfc-editor.org/info/rfc7656 DOI: http://dx.doi.org/10.17487/RFC7656 The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships. This document is a product of the Audio/Video Transport Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Nov 23 13:16:16 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A161B344F; Mon, 23 Nov 2015 13:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3M-jfaNJV6y; Mon, 23 Nov 2015 13:16:12 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B051B344A; Mon, 23 Nov 2015 13:16:12 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tANLFrDE098480 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 23 Nov 2015 15:15:55 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: Huangyihong Date: Mon, 23 Nov 2015 15:15:53 -0600 Message-ID: <4E26B75C-DCEF-4861-9BC4-C80CAF9A63FD@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB864663EE@nkgeml501-mbs.china.huawei.com> References: <5FFEFB3F-B495-4D09-AA1D-E4411DFFB4E2@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB864663EE@nkgeml501-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5180) Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-splicing-notification.all@ietf.org" Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-splicing-notification-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 21:16:15 -0000 Hi, Thanks for the response. Please see comments below. I removed sections that don't seem to need further discussion. Thanks! Ben. On 13 Nov 2015, at 7:17, Huangyihong (Rachel) wrote: [...] > > - RFC 6828 informational. This draft depends heavily on behavior from > that RFC (which needs to be a normative reference as things are > currently written). I suspect this draft needs to be PS due to the > SDP group semantics registration, but I think it really should be > informational, or it should be written in a way to not depend on or > assume behaviors from RFC 6828. (Especially for the security > considerations) > > [Rachel]: Make sense to me. Since we expect this draft goes for a > standards track, I'll modify the draft to just use RFC6828 as an > example of splicing mechanisms. What do you think? That would help. But keep in mind that would mean this draft could not depend on 6828. That is, it could not assume 6828 behaviors, security considerations, etc. The other option would be to make this draft informational, but that would mean either removing the group semantic registration, or convincing people to relax the group semantic registration policy. > > - section 1, first paragraph: "the splicing duration MUST be inside of > the specific, pre-designated time slot" > > That sounds more like a statement of fact than a 2119 MUST. > > [Rachel]: How about changing to "needs to"? That would work for me . > > - 2, 2nd paragraph: "When a new splicing is forthcoming, the main RTP > sender MUST send the > Splicing Interval to the mixer." > > I don't think that needs to be a 2119 MUST. The sender does this, or > it doesn't. In the latter case, this draft does not come into play. > > [Rachel]: Agree. Also can be changed to "needs to". Works for me. > > -2, paragraph 3: > > If I understand correctly, this mechanisms doesn't work unless the > substitutive source knows the splice interval. Furthermore, it needs > to know it in time to act on it. I'm not sure this mechanism is useful > without at least some mechanism to share the SI. Do you assume they > have a proprietary mechanism (i.e. they are from the same vendor) or > perhaps the substitutive source is colocated with the main source or > the mixer? > If so, please mention that. > > [Rachel]: Yes. Both assumptions are possible in deployments. So I'll > add some text in Section 3 to clarify this. > Okay. That likely works for me--depending on the text. :-) But I'm a little bit nervous that too many dependencies on proprietary or otherwise unspecified mechanisms will make it very hard to create interoperable implementations. [...] > > -2, paragraph 5: > > Any guidance on how much ahead the substitutive packets should be > sent? > > [Rachel]: We have some suggestions in 2rd paragraph of section 3. It > is copied as following: > > " > When a new splicing is forthcoming, the main RTP sender MUST send the > Splicing Interval to the mixer. Usually, the Splicing Interval SHOULD > be sent more than once to mitigate the possible packet loss. To > enable the mixer to get the substitutive content before the splicing > starts, the main RTP sender MUST send the Splicing Interval far > ahead. For example, the main RTP sender can estimate when to send the > Splicing Interval based on the round-trip time (RTT) following the > mechanisms in section 6.4.1 of [RFC3550] when the mixer sends RTCP RR > to the main sender. Ah, right. Nevermind. > " > > -2, paragraph 6: > > How. By selecting the correct packet? By adjusting the time stamp? Do > we assume a main stream packet exists that starts at that exact > timestamp? > > [Rachel]: The mixer cannot ensure the exact same time instance. So how > about fixing it like this? > > " > When the splicing will end, the mixer MUST ensure the Splicing Out NTP > timestamp in the Splicing Interval is in the between of the time > instance of the last substitutive RTP packet's timestamp and the time > instance of the first main RTP packet's timestamp that would be > presented on the receivers. > " > Works for me, thanks. [...] > > - 3.2, last paragraph: > > Are there receivers that are not down-stream receivers? > > [Rachel]: I'll change "receivers" in the first sentence into > "down-stream receivers" to avoid any confusions. > > If so, there the SHOULD and MUST seem to conflict. Or does the MUST > only apply if you want undetectable splicing? > > [Rachel]: The second sentence should be changed from > > " > And it MUST NOT forward the message to > the downstream receivers to avoid them from detecting splicing > defined in Section 4.5 in [RFC6828]. > " > To > > " > And if the mixer wishes to prevent the downstream receivers from > detecting splicing, it MUST NOT forward the message. > " > Okay, all taken together that helps. > > - 4, last paragraph: "Either the main RTP sender or the substitutive > sender SHOULD send..." > > Assuming "either" means that exactly one SHOULD send, how do they > coordinate? Or does it matter if both do it? > > [Rachel]: Yes. They can be coordinated by some proprietary out-of-band > mechanisms. I'll clarify it in the draft. Okay (depending on the clarification text. In particular, does it do harm if both do it?) > > -5, 3rd paragraph: > > What if the mixer uses a separate closed RCTP loop for senders and > receivers? I think 6828 can be interpreted to allow that. (And see > previous comment about assuming 6828 behavior.) > > [Rachel]: In other topologies where senders and receivers are in > different RTCP domains, we assume that splicing failure is notified by > out-of-band mechanisms. It would help to mention that (unless you already did and I missed it.) [...] > -5, last paragraph: > > What do you mean by "check the path"? Wouldn't it be up to the mixer > to fall back to a payload specific mechanism? > > [Rachel]: If a failure is detected, it is possible that there's a > splicing un-aware middlebox in the path between the sender and mixer, > and RTCP messages haven't arrived in time. So the best way is to use > [SCTE35] instead, which encapsulates the splicing interval inside the > payload. But you're right. The mixer in this case must support > detecting the payload and agree to fall back to this method. Thus, can > I change the last paragraph as following? > > OLD > " > Upon the detection of a failure, the main RTP sender or the > substitutive sender SHOULD check the path to the failed mixer, or > fallback to the payload specific mechanisms, e.g., MPEG-TS splicing > solution defined in [SCTE35]. > " > > NEW > " > Upon the detection of a failure, the mixer can communicate with the > main sender and the substitutive sender in some out of band signaling > to fall back to the payload specific mechanisms it supports, e.g., > MPEG-TS splicing solution defined in [SCTE35]. We seem to be creating a lot of dependencies on unspecified mechanisms. In this case, what happens if no such mechanism is available? Do things just fail? [...] > > -7, last paragraph: > > The last two sentences conflict with slightly different normative > statements earlier in the draft. > > [Rachel]: Are you referring to the last paragraph of Section 3.2. They > don't conflict. Section 3.2 is talking about RTCP message. Here is > talking about RTP header extensions. Oops, you are correct that I missed the distinction. [...] > > Editorial Comments: > =================== [...] > - 1, last paragraph: > > Do you mean to say you designed it in a complementary fashion, or it > carries the SI in a complementary fashion? > > [Rachel]: I'm not quite sure I understand the difference. The reason > we want to have a RTCP message here is to have another way to convey > SI information in case the RTP header information is stripped by some > splicing unaware middlebox. The RTCP messages can be sent in parallel > with RTP header information to improve robustness. As written, it says "defined in a complementary fashion" which describes the act of defining, not the thing being defined. I think you mean something like "... defines a complementary RTCP packet type ..." (so that "complementary" refers to the RTCP packet type". [...] > > s / "This semantics" / "This semantic" ; or "These semantics" > > -7, 3rd paragraph: "To protect from different substitutive contents > are inserted, > the splicer MUST have some mechanisms to authenticate the > substitutive stream source." > > I don't understand the sentence. > > [Rachel]: I think it could be reworded like this > > " > To avoid invalid substitutive contents are inserted, the splicer MUST > have some mechanisms to authenticate the substitutive stream source. > > " That helps, but consider "To avoid the insertion of invalid..." [...] From nobody Mon Nov 23 22:50:55 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B4B1A00A7; Mon, 23 Nov 2015 22:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNL0VS3ZDDY7; Mon, 23 Nov 2015 22:50:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98671A00A1; Mon, 23 Nov 2015 22:50:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAS49604; Tue, 24 Nov 2015 06:50:46 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 24 Nov 2015 06:50:45 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.12]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Tue, 24 Nov 2015 14:50:38 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: AD Evaluation of draft-ietf-avtext-splicing-notification-02 Thread-Index: AQHRHDUljrdMBNpfFEWHVW24J+eXXp6YgQYggBEouICAANFsoA== Date: Tue, 24 Nov 2015 06:50:37 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB8649D012@nkgeml501-mbs.china.huawei.com> References: <5FFEFB3F-B495-4D09-AA1D-E4411DFFB4E2@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB864663EE@nkgeml501-mbs.china.huawei.com> <4E26B75C-DCEF-4861-9BC4-C80CAF9A63FD@nostrum.com> In-Reply-To: <4E26B75C-DCEF-4861-9BC4-C80CAF9A63FD@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.565408C7.0059, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.12, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a0ab0e19f1fe0f5b9e99dc9df0ce004a Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-splicing-notification.all@ietf.org" Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-splicing-notification-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 06:50:54 -0000 Dear Ben, Please see further replies inline. BR, Rachel > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, November 24, 2015 5:16 AM > To: Huangyihong (Rachel) > Cc: draft-ietf-avtext-splicing-notification.all@ietf.org; avtext@ietf.org > Subject: Re: AD Evaluation of draft-ietf-avtext-splicing-notification-02 >=20 > Hi, >=20 > Thanks for the response. Please see comments below. I removed sections th= at > don't seem to need further discussion. >=20 > Thanks! >=20 > Ben. >=20 >=20 > On 13 Nov 2015, at 7:17, Huangyihong (Rachel) wrote: >=20 > [...] >=20 > > > > - RFC 6828 informational. This draft depends heavily on behavior from > > that RFC (which needs to be a normative reference as things are > > currently written). I suspect this draft needs to be PS due to the > > SDP group semantics registration, but I think it really should be > > informational, or it should be written in a way to not depend on or > > assume behaviors from RFC 6828. (Especially for the security > > considerations) > > > > [Rachel]: Make sense to me. Since we expect this draft goes for a > > standards track, I'll modify the draft to just use RFC6828 as an > > example of splicing mechanisms. What do you think? >=20 > That would help. But keep in mind that would mean this draft could not de= pend > on 6828. That is, it could not assume 6828 behaviors, security considerat= ions, > etc. [Rachel]: Yes. That's what I'm going to do. Because this draft just specifi= es 2 timing extension on the splicing. It doesn't have to require any RFC68= 28 method. To do that, I'll rephrase the texts referring to RFC6828, and mo= dify anything that depends on splicing being implemented as an RTP mixer.=20 > The other option would be to make this draft informational, but that woul= d > mean either removing the group semantic registration, or convincing peopl= e to > relax the group semantic registration policy. [Rachel]: Thanks for the suggestion. But I'll try option 1. > > -2, paragraph 3: > > > > If I understand correctly, this mechanisms doesn't work unless the > > substitutive source knows the splice interval. Furthermore, it needs > > to know it in time to act on it. I'm not sure this mechanism is useful > > without at least some mechanism to share the SI. Do you assume they > > have a proprietary mechanism (i.e. they are from the same vendor) or > > perhaps the substitutive source is colocated with the main source or > > the mixer? > > If so, please mention that. > > > > [Rachel]: Yes. Both assumptions are possible in deployments. So I'll > > add some text in Section 3 to clarify this. > > >=20 > Okay. That likely works for me--depending on the text. :-) But I'm a litt= le bit > nervous that too many dependencies on proprietary or otherwise unspecifie= d > mechanisms will make it very hard to create interoperable implementations= . [Rachel]: I think it is common that substitutive source and media sender ar= e provided by the same operators so that security risks can be reduced. Th= e propriety mechanisms between the main media sender and the substitutive s= ource sender don't affect interoperability between media source and middleb= ox (splicer), and end users.=20 Here's the suggested text: OLD " The Splicing Interval could be transmitted from the main RTP sender to the substitutive content using some out-of-band mechanisms, the details how to achieve that are beyond the scope of this memo.=20 " NEW " The Splicing Interval could be transmitted from the main RTP sender to t= he substitutive content using some out-of-band mechanisms, for example, a p= roprietary mechanism to exchange the Splicing Interval, or the substitutive= sender is implemented together with the main RTP sender in a single device= . However, the details how to achieve that are beyond the scope of this mem= o. " >=20 > > > > - 4, last paragraph: "Either the main RTP sender or the substitutive > > sender SHOULD send..." > > > > Assuming "either" means that exactly one SHOULD send, how do they > > coordinate? Or does it matter if both do it? > > > > [Rachel]: Yes. They can be coordinated by some proprietary out-of-band > > mechanisms. I'll clarify it in the draft. >=20 > Okay (depending on the clarification text. In particular, does it do harm= if both > do it?) >=20 [Rachel]: How about the following suggested text? OLD " Another latency element is synchronization caused delay. The receivers must receive enough synchronization metadata prior to synchronizing the separate components of the multimedia streams when splicing starts or ends. Either the main RTP sender or the substitutive sender SHOULD send the synchronization metadata early enough so that the receivers can play out the multimedia in a synchronized fashion. The mechanisms defined in [RFC6051] are RECOMMENDED to be adopted to reduce the possible synchronization delay. " NEW " Another latency element is synchronization caused delay. The=20 receivers must receive enough synchronization metadata prior to=20 synchronizing the separate components of the multimedia streams when splicing starts or ends. Either the main RTP sender or the=20 substitutive sender SHOULD send the synchronization metadata early=20 enough so that the receivers can play out the multimedia in a synchroniz= ed fashion. The main RTP sender and the substitutive sender can be coordinated by some proprietary out-o= f-band mechanisms to decide when and whom to send the metadata. If both sen= d the information, the splicer SHOULD pick one based on the current situati= on, e.g., choosing media sender when synchronizing the main media content w= hile choosing the information from the substitutive sender when synchronizi= ng the spliced content. The mechanisms defined in [RFC6051] are RECOMMENDED to be adopted to reduce the possible synchronization delay. " > > > > -5, 3rd paragraph: > > > > What if the mixer uses a separate closed RCTP loop for senders and > > receivers? I think 6828 can be interpreted to allow that. (And see > > previous comment about assuming 6828 behavior.) > > > > [Rachel]: In other topologies where senders and receivers are in > > different RTCP domains, we assume that splicing failure is notified by > > out-of-band mechanisms. >=20 > It would help to mention that (unless you already did and I missed it.) [Rachel]: Please see following suggested modifications: OLD " If the mixer does not get the Splicing Interval when the splicing starts, it will still output the main content to the downstream receivers and forward the RTCP RR packets sent from downstream receivers to the main RTP sender (see section 4.2 of [RFC6828]). In such case, the main RTP sender can learn that splicing failed. " NEW " If a mixer works as the splicer and it follows [RFC3550], the main RTP send= er can learn that splicing failed: The splicer will still output the main c= ontent to the downstream receivers and forward the RTCP RR packets sent fro= m downstream receivers to the main RTP sender (see section 4.2 of [RFC6828]= ), if it does not get the Splicing Interval when the splicing starts. Other= cases where senders and receivers are in different RTCP domains may requir= e translation of RTCP reports, or additional reporting, if the senders want= to detect splicing problems. " >=20 > [...] >=20 > > -5, last paragraph: > > > > What do you mean by "check the path"? Wouldn't it be up to the mixer > > to fall back to a payload specific mechanism? > > > > [Rachel]: If a failure is detected, it is possible that there's a > > splicing un-aware middlebox in the path between the sender and mixer, > > and RTCP messages haven't arrived in time. So the best way is to use > > [SCTE35] instead, which encapsulates the splicing interval inside the > > payload. But you're right. The mixer in this case must support > > detecting the payload and agree to fall back to this method. Thus, can > > I change the last paragraph as following? > > > > OLD > > " > > Upon the detection of a failure, the main RTP sender or the > > substitutive sender SHOULD check the path to the failed mixer, or > > fallback to the payload specific mechanisms, e.g., MPEG-TS splicing > > solution defined in [SCTE35]. > > " > > > > NEW > > " > > Upon the detection of a failure, the mixer can communicate with the > > main sender and the substitutive sender in some out of band signaling > > to fall back to the payload specific mechanisms it supports, e.g., > > MPEG-TS splicing solution defined in [SCTE35]. >=20 > We seem to be creating a lot of dependencies on unspecified mechanisms. > In this case, what happens if no such mechanism is available? Do things j= ust > fail? [Rachel]: If no such mechanism, splicing will never happen. I think it does= no harm to the original RTP session. So how about following suggestion? NEW " Upon the detection of a failure, the mixer can communicate with the main sender and the substitutive sender in some out of band signaling to fall back to the payload specific mechanisms it supports, e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon the splicing= . " >=20 >=20 > > - 1, last paragraph: > > > > Do you mean to say you designed it in a complementary fashion, or it > > carries the SI in a complementary fashion? > > > > [Rachel]: I'm not quite sure I understand the difference. The reason > > we want to have a RTCP message here is to have another way to convey > > SI information in case the RTP header information is stripped by some > > splicing unaware middlebox. The RTCP messages can be sent in parallel > > with RTP header information to improve robustness. >=20 > As written, it says "defined in a complementary fashion" which describes = the > act of defining, not the thing being defined. I think you mean something = like "... > defines a complementary RTCP packet type ..." (so that "complementary" > refers to the RTCP packet type". [Rachel]: Oh, I get it. Will modify it as you suggested. >=20 > [...] > > > > s / "This semantics" / "This semantic" ; or "These semantics" > > > > -7, 3rd paragraph: "To protect from different substitutive contents > > are inserted, the splicer MUST have some mechanisms to authenticate > > the substitutive stream source." > > > > I don't understand the sentence. > > > > [Rachel]: I think it could be reworded like this > > > > " > > To avoid invalid substitutive contents are inserted, the splicer MUST > > have some mechanisms to authenticate the substitutive stream source. > > > > " >=20 > That helps, but consider "To avoid the insertion of invalid..." [Rachel]: Right. Good suggestion. >=20 > [...] From nobody Tue Nov 24 14:00:56 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A051A905E; Tue, 24 Nov 2015 14:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFbNJdRnPp80; Tue, 24 Nov 2015 14:00:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961C81A905C; Tue, 24 Nov 2015 14:00:53 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tAOM0neH052994 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 Nov 2015 16:00:50 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: Huangyihong Date: Tue, 24 Nov 2015 16:00:49 -0600 Message-ID: <85B3209B-2F55-4D78-9699-5646A40261B7@nostrum.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB8649D012@nkgeml501-mbs.china.huawei.com> References: <5FFEFB3F-B495-4D09-AA1D-E4411DFFB4E2@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB864663EE@nkgeml501-mbs.china.huawei.com> <4E26B75C-DCEF-4861-9BC4-C80CAF9A63FD@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB8649D012@nkgeml501-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5184) Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-splicing-notification.all@ietf.org" Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-splicing-notification-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 22:00:55 -0000 Thanks Rachel, Do you plan to submit a new version? I think doing so might give us a smoother IETF last call. Thanks! Ben. On 24 Nov 2015, at 0:50, Huangyihong (Rachel) wrote: > Dear Ben, > > Please see further replies inline. > > BR, > Rachel > > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Tuesday, November 24, 2015 5:16 AM >> To: Huangyihong (Rachel) >> Cc: draft-ietf-avtext-splicing-notification.all@ietf.org; >> avtext@ietf.org >> Subject: Re: AD Evaluation of >> draft-ietf-avtext-splicing-notification-02 >> >> Hi, >> >> Thanks for the response. Please see comments below. I removed >> sections that >> don't seem to need further discussion. >> >> Thanks! >> >> Ben. >> >> >> On 13 Nov 2015, at 7:17, Huangyihong (Rachel) wrote: >> >> [...] >> >>> >>> - RFC 6828 informational. This draft depends heavily on behavior >>> from >>> that RFC (which needs to be a normative reference as things are >>> currently written). I suspect this draft needs to be PS due to the >>> SDP group semantics registration, but I think it really should be >>> informational, or it should be written in a way to not depend on or >>> assume behaviors from RFC 6828. (Especially for the security >>> considerations) >>> >>> [Rachel]: Make sense to me. Since we expect this draft goes for a >>> standards track, I'll modify the draft to just use RFC6828 as an >>> example of splicing mechanisms. What do you think? >> >> That would help. But keep in mind that would mean this draft could >> not depend >> on 6828. That is, it could not assume 6828 behaviors, security >> considerations, >> etc. > > [Rachel]: Yes. That's what I'm going to do. Because this draft just > specifies 2 timing extension on the splicing. It doesn't have to > require any RFC6828 method. To do that, I'll rephrase the texts > referring to RFC6828, and modify anything that depends on splicing > being implemented as an RTP mixer. > >> The other option would be to make this draft informational, but that >> would >> mean either removing the group semantic registration, or convincing >> people to >> relax the group semantic registration policy. > > [Rachel]: Thanks for the suggestion. But I'll try option 1. > >>> -2, paragraph 3: >>> >>> If I understand correctly, this mechanisms doesn't work unless the >>> substitutive source knows the splice interval. Furthermore, it needs >>> to know it in time to act on it. I'm not sure this mechanism is >>> useful >>> without at least some mechanism to share the SI. Do you assume they >>> have a proprietary mechanism (i.e. they are from the same vendor) or >>> perhaps the substitutive source is colocated with the main source or >>> the mixer? >>> If so, please mention that. >>> >>> [Rachel]: Yes. Both assumptions are possible in deployments. So I'll >>> add some text in Section 3 to clarify this. >>> >> >> Okay. That likely works for me--depending on the text. :-) But I'm a >> little bit >> nervous that too many dependencies on proprietary or otherwise >> unspecified >> mechanisms will make it very hard to create interoperable >> implementations From nobody Tue Nov 24 19:39:51 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08601ACE97; Tue, 24 Nov 2015 19:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM2amdWxzi3J; Tue, 24 Nov 2015 19:39:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249F71ACE95; Tue, 24 Nov 2015 19:39:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEO41209; Wed, 25 Nov 2015 03:39:44 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 25 Nov 2015 03:39:42 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.12]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Wed, 25 Nov 2015 11:39:35 +0800 From: "Huangyihong (Rachel)" To: Ben Campbell Thread-Topic: AD Evaluation of draft-ietf-avtext-splicing-notification-02 Thread-Index: AQHRHDUljrdMBNpfFEWHVW24J+eXXp6YgQYggBEouICAANFsoIAAzXeAgADkhPA= Date: Wed, 25 Nov 2015 03:39:34 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB8649E21D@nkgeml501-mbs.china.huawei.com> References: <5FFEFB3F-B495-4D09-AA1D-E4411DFFB4E2@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB864663EE@nkgeml501-mbs.china.huawei.com> <4E26B75C-DCEF-4861-9BC4-C80CAF9A63FD@nostrum.com> <51E6A56BD6A85142B9D172C87FC3ABBB8649D012@nkgeml501-mbs.china.huawei.com> <85B3209B-2F55-4D78-9699-5646A40261B7@nostrum.com> In-Reply-To: <85B3209B-2F55-4D78-9699-5646A40261B7@nostrum.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56552D80.013D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.12, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dd7c07e1e22ebdc85acb082f254630fa Archived-At: Cc: "avtext@ietf.org" , "draft-ietf-avtext-splicing-notification.all@ietf.org" Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-splicing-notification-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 03:39:50 -0000 Hi Ben, I'll submit a new version in these two days to reflect all the comments we = discussed. BR, Rachel > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, November 25, 2015 6:01 AM > To: Huangyihong (Rachel) > Cc: draft-ietf-avtext-splicing-notification.all@ietf.org; avtext@ietf.org > Subject: Re: AD Evaluation of draft-ietf-avtext-splicing-notification-02 >=20 > Thanks Rachel, >=20 > Do you plan to submit a new version? I think doing so might give us a smo= other > IETF last call. >=20 > Thanks! >=20 > Ben. >=20 >=20 > On 24 Nov 2015, at 0:50, Huangyihong (Rachel) wrote: >=20 > > Dear Ben, > > > > Please see further replies inline. > > > > BR, > > Rachel > > > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: Tuesday, November 24, 2015 5:16 AM > >> To: Huangyihong (Rachel) > >> Cc: draft-ietf-avtext-splicing-notification.all@ietf.org; > >> avtext@ietf.org > >> Subject: Re: AD Evaluation of > >> draft-ietf-avtext-splicing-notification-02 > >> > >> Hi, > >> > >> Thanks for the response. Please see comments below. I removed > >> sections that don't seem to need further discussion. > >> > >> Thanks! > >> > >> Ben. > >> > >> > >> On 13 Nov 2015, at 7:17, Huangyihong (Rachel) wrote: > >> > >> [...] > >> > >>> > >>> - RFC 6828 informational. This draft depends heavily on behavior > >>> from that RFC (which needs to be a normative reference as things are > >>> currently written). I suspect this draft needs to be PS due to the > >>> SDP group semantics registration, but I think it really should be > >>> informational, or it should be written in a way to not depend on or > >>> assume behaviors from RFC 6828. (Especially for the security > >>> considerations) > >>> > >>> [Rachel]: Make sense to me. Since we expect this draft goes for a > >>> standards track, I'll modify the draft to just use RFC6828 as an > >>> example of splicing mechanisms. What do you think? > >> > >> That would help. But keep in mind that would mean this draft could > >> not depend on 6828. That is, it could not assume 6828 behaviors, > >> security considerations, etc. > > > > [Rachel]: Yes. That's what I'm going to do. Because this draft just > > specifies 2 timing extension on the splicing. It doesn't have to > > require any RFC6828 method. To do that, I'll rephrase the texts > > referring to RFC6828, and modify anything that depends on splicing > > being implemented as an RTP mixer. > > > >> The other option would be to make this draft informational, but that > >> would mean either removing the group semantic registration, or > >> convincing people to relax the group semantic registration policy. > > > > [Rachel]: Thanks for the suggestion. But I'll try option 1. > > > >>> -2, paragraph 3: > >>> > >>> If I understand correctly, this mechanisms doesn't work unless the > >>> substitutive source knows the splice interval. Furthermore, it needs > >>> to know it in time to act on it. I'm not sure this mechanism is > >>> useful without at least some mechanism to share the SI. Do you > >>> assume they have a proprietary mechanism (i.e. they are from the > >>> same vendor) or perhaps the substitutive source is colocated with > >>> the main source or the mixer? > >>> If so, please mention that. > >>> > >>> [Rachel]: Yes. Both assumptions are possible in deployments. So I'll > >>> add some text in Section 3 to clarify this. > >>> > >> > >> Okay. That likely works for me--depending on the text. :-) But I'm a > >> little bit nervous that too many dependencies on proprietary or > >> otherwise unspecified mechanisms will make it very hard to create > >> interoperable implementations From nobody Thu Nov 26 18:59:46 2015 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 674A01A88FF; Thu, 26 Nov 2015 18:59:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151127025945.11717.84080.idtracker@ietfa.amsl.com> Date: Thu, 26 Nov 2015 18:59:45 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 02:59:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF. Title : RTP/RTCP extension for RTP Splicing Notification Authors : Jinwei Xia Roni Even Rachel Huang Lingli Deng Filename : draft-ietf-avtext-splicing-notification-03.txt Pages : 18 Date : 2015-11-26 Abstract: Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 26 19:10:33 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754AC1A897E for ; Thu, 26 Nov 2015 19:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGPzfwmUyFZj for ; Thu, 26 Nov 2015 19:10:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3357D1A8978 for ; Thu, 26 Nov 2015 19:10:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CER39724; Fri, 27 Nov 2015 03:10:23 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 27 Nov 2015 03:10:20 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.12]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Fri, 27 Nov 2015 11:10:13 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext] FW: New Version Notification for draft-ietf-avtext-splicing-notification-03.txt Thread-Index: AQHRKMEhB9+h6Ci1O0qhToIfqez5Fw== Date: Fri, 27 Nov 2015 03:10:12 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB8649E7A2@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.29] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5657C99F.00E7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.12, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: faf95406eed9094d0853610628012e72 Archived-At: Subject: [avtext] FW: New Version Notification for draft-ietf-avtext-splicing-notification-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 03:10:31 -0000 RGVhciBhbGwsDQoNClRoaXMgbmV3IHZlcnNpb24gYWltcyB0byBzb2x2ZSB0aGUgY29tbWVudHMg ZHVyaW5nIHRoZSBBRCByZXZpZXcuDQoNCkJSLA0KUmFjaGVsDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDI3LCAyMDE1IDEx OjAwIEFNDQpUbzogRGVuZyBMaW5nbGk7IFJvbmkgRXZlbjsgWGlhamlud2VpOyBIdWFuZ3lpaG9u ZyAoUmFjaGVsKTsgTGluZ2xpIERlbmcNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTAzLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmlj YXRpb24tMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJhY2hlbCBI dWFuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1p ZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24NClJldmlzaW9uOgkwMw0KVGl0bGU6CQlS VFAvUlRDUCBleHRlbnNpb24gZm9yIFJUUCBTcGxpY2luZyBOb3RpZmljYXRpb24NCkRvY3VtZW50 IGRhdGU6CTIwMTUtMTEtMjcNCkdyb3VwOgkJYXZ0ZXh0DQpQYWdlczoJCTE4DQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0 ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3Rp ZmljYXRpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wMw0KRGlmZjogICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWF2dGV4dC1zcGxp Y2luZy1ub3RpZmljYXRpb24tMDMNCg0KQWJzdHJhY3Q6DQogICBDb250ZW50IHNwbGljaW5nIGlz IGEgcHJvY2VzcyB0aGF0IHJlcGxhY2VzIHRoZSBjb250ZW50IG9mIGEgbWFpbg0KICAgbXVsdGlt ZWRpYSBzdHJlYW0gd2l0aCBvdGhlciBtdWx0aW1lZGlhIGNvbnRlbnQsIGFuZCBkZWxpdmVycyB0 aGUNCiAgIHN1YnN0aXR1dGl2ZSBtdWx0aW1lZGlhIGNvbnRlbnQgdG8gdGhlIHJlY2VpdmVycyBm b3IgYSBwZXJpb2Qgb2YNCiAgIHRpbWUuIFRoZSBzcGxpY2VyIGlzIGRlc2lnbmVkIHRvIGhhbmRs ZSBSVFAgc3BsaWNpbmcgYW5kIG5lZWRzIHRvDQogICBrbm93IHdoZW4gdG8gc3RhcnQgYW5kIGVu ZCB0aGUgc3BsaWNpbmcuDQoNCiAgIFRoaXMgbWVtbyBkZWZpbmVzIHR3byBSVFAvUlRDUCBleHRl bnNpb25zIHRvIGluZGljYXRlIHRoZSBzcGxpY2luZw0KICAgcmVsYXRlZCBpbmZvcm1hdGlvbiB0 byB0aGUgc3BsaWNlcjogYW4gUlRQIGhlYWRlciBleHRlbnNpb24gdGhhdA0KICAgY29udmV5cyB0 aGUgaW5mb3JtYXRpb24gaW4tYmFuZCBhbmQgYW4gUlRDUCBwYWNrZXQgdGhhdCBjb252ZXlzIHRo ZQ0KICAgaW5mb3JtYXRpb24gb3V0LW9mLWJhbmQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From nobody Mon Nov 30 11:30:58 2015 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2697D1A8AE1 for ; Mon, 30 Nov 2015 10:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHJe7EgTLo7I for ; Mon, 30 Nov 2015 10:57:23 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86A31A8AC8 for ; Mon, 30 Nov 2015 10:57:23 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tAUIvMRw054823 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 30 Nov 2015 12:57:23 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local References: <20151130183802.21578.17213.idtracker@ietfa.amsl.com> To: avtext@ietf.org From: Adam Roach X-Forwarded-Message-Id: <20151130183802.21578.17213.idtracker@ietfa.amsl.com> Message-ID: <565C9C12.80004@nostrum.com> Date: Mon, 30 Nov 2015 12:57:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151130183802.21578.17213.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 30 Nov 2015 11:30:58 -0800 Subject: [avtext] Fwd: New Version Notification for draft-roach-avtext-rid-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 18:57:25 -0000 A we discussed in Yokohama, here's the AVTEXT version of a RID document. I tried to take into account all of the suggestions that were made at the microphone -- please look this over and let me know whether it matches what you expected. /a -------- Forwarded Message -------- Subject: New Version Notification for draft-roach-avtext-rid-00.txt Date: Mon, 30 Nov 2015 10:38:02 -0800 From: internet-drafts@ietf.org To: Suhas Nandakumar , Peter Thatcher , Adam Roach A new version of I-D, draft-roach-avtext-rid-00.txt has been successfully submitted by Adam Roach and posted to the IETF repository. Name: draft-roach-avtext-rid Revision: 00 Title: RTP Payload Format Constraints Document date: 2015-11-30 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-roach-avtext-rid-00.txt Status: https://datatracker.ietf.org/doc/draft-roach-avtext-rid/ Htmlized: https://tools.ietf.org/html/draft-roach-avtext-rid-00 Abstract: This document defines and registers an RTCP SDES item, RID, for identification of RTP streams associated with encoded and dependent streams. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Nov 30 13:09:21 2015 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2044C1B3163 for ; Mon, 30 Nov 2015 13:00:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151130210045.14935.44284.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 13:00:45 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Mon, 30 Nov 2015 13:09:19 -0800 Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 21:00:45 -0000 Changed milestone "Submit Mechanism for Indication of Content Splicing Times in Multimedia Content for Proposed Standard", resolved as "Done". Changed milestone "Submit RTP header extension for SDES items for Proposed Standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/avtext/charter/