From nobody Wed Apr 6 13:08:38 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4845112D5AB; Wed, 6 Apr 2016 13:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVG3toTh4jnC; Wed, 6 Apr 2016 13:08:33 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F6C12D1D2; Wed, 6 Apr 2016 13:08:32 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-99-57056cbe1b3e Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0B.BA.22880.EBC65075; Wed, 6 Apr 2016 22:08:30 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Wed, 6 Apr 2016 22:07:40 +0200 To: , , , References: <20150427154444.78210180092@rfc-editor.org> <5702A612.4090802@ericsson.com> From: Magnus Westerlund Message-ID: <57056C85.5050106@ericsson.com> Date: Wed, 6 Apr 2016 17:07:33 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5702A612.4090802@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM2K7ru6+HNZwg5kbVSymn/nLaPGyZyW7 xfzO0+wWTxvPMlpcuniWyeJJyw9mi5NfdrA4sHu0PtvL6vHlyUsmjyVLfjJ57Nj8gNXj7q1L TB6zdj5hCWCL4rJJSc3JLEst0rdL4MqY+PU6U8Ft84quJa2MDYxt2l2MHBwSAiYSZ+/kdTFy ApliEhfurWfrYuTiEBI4wiixaspjRghnGaPEu6NX2ECqhAUcJc419bCD2CICuRK9x7+BxYUE IiUWbL8BZjMLhEs8m/uQBcRmE7CQuPmjkQ1kGa+AtsTtmSUgYRYBFYkr02aClYsKxEgcf3eO EcTmFRCUODnzCQtIOaeAjsS2m44gJrOAvcSDrWUQw+UlmrfOZoZYqi3R0NTBOoFRcBaS5lkI HbOQdCxgZF7FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERgBB7f81t3BuPq14yFGAQ5GJR7e Bbks4UKsiWXFlbmHGCU4mJVEeMOyWcOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8+ZE/gsTEkhP LEnNTk0tSC2CyTJxcEo1MJpZFt1Id/5b8Cb4Wqilc8hl1z42Q7+ybsXln4ylW8XzPZiMDlcV K+vvmeknpP5ykQbP8tOFomlcmfzxn2T1Ze9k9JoFF1mwOZ7TvbPj5RruLsO4k3JCyXealYwn e5Z2Sl+c0Sr6RKahv3valtae7qwJ52x+n7yz2KCTlbtm5xnbb9eS/I4psRRnJBpqMRcVJwIA AflOjnwCAAA= Archived-At: Cc: Thomas.Belling@nokia.com, avt@ietf.org, "payload@ietf.org" Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC4867 (4347) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:08:35 -0000 Payload, I should have included you from start. Please provide any input on this Errata as its relate to an RTP Payload format. Cheers Magnus Westerlund (AVTCORE WG chair) Den 2016-04-04 kl. 14:36, skrev Magnus Westerlund: > WG, > > I am co-author of this document. If there are any controversy around the > consensus here I will let my co-chair or the AD judge that. > > However, the WG should progress this Errata. It has been created due to > actual interoperability issues that has been discussed in 3GPP SA4. From > my perspective the errata also represents the intention of the document. > Thus I propose that this errata is verified. Please provide any feedback > by the 18th of April. > > Cheers > > Magnus Westerlund > > > > > Den 2015-04-27 kl. 12:44, skrev RFC Errata System: >> The following errata report has been submitted for RFC4867, >> "RTP Payload Format and File Storage Format for the Adaptive >> Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4347 >> >> -------------------------------------- >> Type: Technical >> Reported by: Thomas Belling >> >> Section: 4.3.1 >> >> Original Text >> ------------- >> CMR (4 bits): Indicates a codec mode request sent to the speech >> encoder at the site of the receiver of this payload. The value of >> the CMR field is set to the frame type index of the corresponding >> speech mode being requested. The frame type index may be 0-7 for >> AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined >> in Table 1a in [4]. CMR value 15 indicates that no mode request >> is present, and other values are for future use. >> >> The codec mode request received in the CMR field is valid until the >> next codec mode request is received, i.e., a newly received CMR value >> corresponding to a speech mode, or NO_DATA overrides the previously >> received CMR value corresponding to a speech mode or NO_DATA. >> Therefore, if a terminal continuously wishes to receive frames in the >> same mode X, it needs to set CMR=X for all its outbound payloads, and >> if a terminal has no preference in which mode to receive, it SHOULD >> set CMR=15 in all its outbound payloads. >> >> If receiving a payload with a CMR value that is not a speech mode or >> NO_DATA, the CMR MUST be ignored by the receiver. >> >> >> Corrected Text >> -------------- >> CMR (4 bits): Indicates a codec mode request sent to the speech >> encoder at the site of the receiver of this payload. The value of >> the CMR field is set to the frame type index of the corresponding >> speech mode being requested. The frame type index may be 0-7 for >> AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined >> in Table 1a in [4]. CMR value 15 indicates that the receiver has >> no preference in which mode within the negotiated mode set to >> receive, and other values are for future use. >> >> The codec mode request received in the CMR field is valid until the >> next codec mode request is received, i.e., a newly received CMR value >> corresponding to a speech mode, or CMR=15 overrides the previously >> received CMR value corresponding to a speech mode or CMR=15. >> Therefore, if a terminal continuously wishes to receive frames not >> higher than mode X, it needs to set CMR=X for all its outbound >> payloads, and if a terminal has no preference in which mode within >> the negotiated mode set to receive, it SHOULD set CMR=15 in all its >> outbound payloads. >> >> If receiving a payload with a CMR value that is not a speech mode or >> CMR=15, the CMR MUST be ignored by the receiver. >> >> >> Notes >> ----- >> The definition of CMR 15 as "no mode request is present", could be > understood to suggest that other previously received CMR values remain > applicable. However, this contradicts text in the subsequent paragraphs > suggesting CMR=15 should be used when the "terminal has no preference in > which mode to receive", and stating that any previously received CMR > value is overridden by CMR=15. >> >> It is thus unclear for a receiving entity that has previously >> received > a CMR value requesting a lower AMR mode and then receives a CMR value 15 > if it should continue to send using the lower AMR mode or if it can > select a higher mode within the negotiated mode set based on own > preferences. >> >> CMR 15 is referred to as "NO_DATA" in subsequent text, but "NO_DATA" > is not well defined. This value appears in the quoted references, but > these references are only quoted for CMR values 0 to 7/8. >> >> It is also not perfectly clear if CMR=15 allows for any mode, or >> only > modes within the negotiated mode set. However, the definition of the > mode-set parameter in Clause 8.1 suggests that only modes within the > negotiated mode-set can be sent when a mode-set has been negotiated. >> >> The text "if a terminal continuously wishes to receive frames in the > same mode X, it needs to set CMR=X for all its outbound payloads" seems > to suggest that the receiver will always follow the request, although it > may also choose to send lower modes, as explained in text further below. >> >> This erratum has been discussed and endorsed by the 3GPP SA4 group > before submission to IETF. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4867 (draft-ietf-avt-rtp-amr-bis-06) >> -------------------------------------- >> Title : RTP Payload Format and File Storage Format for >> the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband >> (AMR-WB) Audio Codecs >> Publication Date : April 2007 >> Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Apr 6 13:08:52 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC67C12D79D; Wed, 6 Apr 2016 13:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2VH63XOYp8k; Wed, 6 Apr 2016 13:08:35 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CADF12D135; Wed, 6 Apr 2016 13:08:35 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-90-57056cc1a39d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 11.BE.23401.1CC65075; Wed, 6 Apr 2016 22:08:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.248.2; Wed, 6 Apr 2016 22:08:31 +0200 To: , , , References: <20150427154813.ECA28180092@rfc-editor.org> <5702A648.4010502@ericsson.com> From: Magnus Westerlund Message-ID: <57056C9E.3040605@ericsson.com> Date: Wed, 6 Apr 2016 17:07:58 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5702A648.4010502@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM2K7q+7BHNZwg+9rZCymn/nLaPGyZyW7 xfzO0+wWTxvPMlpcuniWyeJJyw9mi5NfdrA4sHu0PtvL6vHlyUsmjyVLfjJ57Nj8gNXj7q1L TB6zdj5hCWCL4rJJSc3JLEst0rdL4Mq40X+dpWCVbMXKhfuZGhh7xbsYOTkkBEwkZv67wwhh i0lcuLeerYuRi0NI4AijxKNnq9hAEkICyxgltvwNB7GFBRwldr9cxwJiiwjkSvQe/wZVEykx 6fVudhCbWSBc4tnch2A1bAIWEjd/NALVcHDwCmhL7J6QCxJmEVCRmDxjBSuILSoQI3H83Tmw G3gFBCVOznwC1sopoCNx6OhUFpBWZgF7iQdbyyCmy0s0b53NDLFVW6KhqYN1AqPgLCTdsxA6 ZiHpWMDIvIpRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMAYObvlttYPx4HPHQ4wCHIxKPLwL clnChVgTy4orcw8xSnAwK4nwLk5jDRfiTUmsrEotyo8vKs1JLT7EKM3BoiTOmxP5L0xIID2x JDU7NbUgtQgmy8TBKdXAGNVksfrppWyH+7uzNS/eWHyqfOmKnB1b4xbIXfvC57C9VFrRe9Xm shQdjn1PnoVIMS3a+G7i6pP+k1RydgSv0mG6wr3H9SmPr9j5qhDnV1tnvE6L5Cv7/PbuYxX1 vXdi9YRW33tie/aKl8Eb6UzNz3dYpryIb5z0Sun7hCdFC9qEfh85McVv1nMlluKMREMt5qLi RAA8SWmIfQIAAA== Archived-At: Cc: Thomas.Belling@nokia.com, avt@ietf.org, "payload@ietf.org" Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC4867 (4348) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:08:38 -0000 Payload, I should have included you from start. Please provide any input on this Errata as its relate to an RTP Payload format. Cheers Magnus Westerlund (AVTCORE WG chair) Den 2016-04-04 kl. 14:37, skrev Magnus Westerlund: > WG, > > I am co-author of this document. If there are any controversy around the > consensus here I will let my co-chair or the AD judge that. > > However, the WG should progress this Errata. It has been created due to > actual interoperability issues that has been discussed in 3GPP SA4. From > my perspective the errata also represents the intention of the document. > Thus I propose that this errata is verified. Please provide any feedback > by the 18th of April. > > Cheers > > Magnus Westerlund > > Den 2015-04-27 kl. 12:48, skrev RFC Errata System: >> The following errata report has been submitted for RFC4867, >> "RTP Payload Format and File Storage Format for the Adaptive >> Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4348 >> >> -------------------------------------- >> Type: Technical >> Reported by: Thomas Belling >> >> Section: 4.3.1 >> >> Original Text >> ------------- >> The encoder SHOULD follow a received codec mode request, but MAY >> change to a lower-numbered mode if it so chooses, for example, to >> control congestion. >> >> >> Corrected Text >> -------------- >> The encoder MUST follow a received codec mode request as soon as >> possible. It SHOULD use the requested mode, but MAY change to a >> lower-numbered mode if it so chooses, for example, to >> control congestion. However, the encoder MUST NOT use a >> higher-numbered mode than the received codec mode request. >> >> >> Notes >> ----- >> This seems to be the intention of the existing text, but is not > explicitly stated. It is essential for the end-to-end mode control and > interoperability with 3GPP CS networks that a peer does not send higher > modes than requested. >> >> This erratum has been discussed and endorsed by the 3GPP SA4 group > before submission to IETF. > >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4867 (draft-ietf-avt-rtp-amr-bis-06) >> -------------------------------------- >> Title : RTP Payload Format and File Storage Format for >> the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband >> (AMR-WB) Audio Codecs >> Publication Date : April 2007 >> Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Apr 6 13:09:04 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A06D12D1DD; Wed, 6 Apr 2016 13:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuQM-CSOqeVO; Wed, 6 Apr 2016 13:08:49 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4DC12D135; Wed, 6 Apr 2016 13:08:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-a5-57056cc628d0 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A4.BE.23401.6CC65075; Wed, 6 Apr 2016 22:08:38 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Wed, 6 Apr 2016 22:08:35 +0200 To: , , , References: <20150427155709.23479180092@rfc-editor.org> <5702A6BB.3080402@ericsson.com> From: Magnus Westerlund Message-ID: <57056CBD.1080500@ericsson.com> Date: Wed, 6 Apr 2016 17:08:29 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5702A6BB.3080402@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM2K7je6xHNZwgy+/FS2mn/nLaPGyZyW7 xfzO0+wWTxvPMlpcuniWyeJJyw9mi5NfdrA4sHu0PtvL6vHlyUsmjyVLfjJ57Nj8gNXj7q1L TB6zdj5hCWCL4rJJSc3JLEst0rdL4Mq4v28me8F09YqbS5tYGhjvy3QxcnJICJhITNl/lRXC FpO4cG89WxcjF4eQwBFGickzZrKBJIQEljFKHFiYD2ILCzhK3D3RBNYgIpAr0Xv8G1RNpMTl zkNgNrNAuMSzuQ9ZQGw2AQuJmz8aweK8AtoSz+e0g9ksAioSLx7MYgexRQViJI6/O8cIUSMo cXLmE7BeTgEdiaXXtzF1MXIAzbSXeLC1DGK8vETz1tnMEGu1JRqaOlgnMArOQtI9C6FjFpKO BYzMqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECo+Dglt9WOxgPPnc8xCjAwajEw7sglyVc iDWxrLgy9xCjBAezkgjv4jTWcCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8OZH/woQE0hNLUrNT UwtSi2CyTBycUg2M4oe7j3i+DQ/dz7+DTzxx5qwKiz+fp27cn7Prmal12bQse+trsVejKydJ 6vmYvOczXSVvuujFZil+rbpJJ1xTv67cVq/qU3JI2cXj3gsb4073tCATHRUblg8Pt/qvd/a0 2rHpdnkI+/LofaYn7za6b+p/v/Ly3ZJdB5x9Dtsxz7i3R9hQtp5JiaU4I9FQi7moOBEAm6SV rH4CAAA= Archived-At: Cc: Thomas.Belling@nokia.com, avt@ietf.org, "payload@ietf.org" Subject: Re: [payload] [AVTCORE] [Technical Errata Reported] RFC4867 (4349) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:08:52 -0000 Payload, I should have included you from start. Please provide any input on this Errata as its relate to an RTP Payload format. Cheers Magnus Westerlund (AVTCORE WG chair) Den 2016-04-04 kl. 14:39, skrev Magnus Westerlund: > WG, > > I am co-author of this document. If there are any controversy around the > consensus here I will let my co-chair or the AD judge that. > > However, the WG should progress this Errata. It has been created due to > actual interoperability issues that has been discussed in 3GPP SA4. From > my perspective the errata also represents the intention of the document. > Thus I propose that this errata is verified. Please provide any feedback > by the 18th of April. > > Cheers > > Magnus Westerlund > > > Den 2015-04-27 kl. 12:57, skrev RFC Errata System: >> The following errata report has been submitted for RFC4867, >> "RTP Payload Format and File Storage Format for the Adaptive >> Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4867&eid=4349 >> >> -------------------------------------- >> Type: Technical >> Reported by: Thomas Belling >> >> Section: 8.1 >> >> Original Text >> ------------- >> mode-set: Restricts the active codec mode set to a subset of all >> modes, for example, to be able to support transport >> channels such as GSM networks in gateway use cases. >> Possible values are a comma separated list of modes from >> the set: 0,...,7 (see Table 1a [2]). The SID frame type >> 8 and NO_DATA (frame type 15) are never included in the >> mode set, but can always be used. If mode-set is >> specified, it MUST be abided, and frames encoded with >> modes outside of the subset MUST NOT be sent in any RTP >> payload or used in codec mode requests. If not present, >> all codec modes are allowed for the payload type. >> >> >> Corrected Text >> -------------- >> mode-set: Restricts the active codec mode set to a subset of all >> modes, for example, to be able to support transport >> channels such as GSM networks in gateway use cases. >> Possible values are a comma separated list of modes from >> the set: 0,...,7 (see Table 1a [2]). The SID frame type >> 8 and NO_DATA (frame type 15) are never included in the >> mode set, but can always be used. If mode-set is >> specified, it MUST be abided, i.e. frames encoded with >> modes outside of the subset MUST NOT be sent in any RTP >> payload and codec mode requests MUST only use modes >> within the mode-set or CMR=15. If the mode-set parameter >> is not present, then all codec modes are allowed for the >> payload type. >> >> >> Notes >> ----- >> The existing text rules out that CMR=15 is used when a mode-set has > been negotiated. However, this contradicts a statement in .clause 4.3.1 > that if a terminal has no preference in which mode to receive, it SHOULD > set CMR=15 in all its outbound payloads. >> >> This erratum has been discussed and endorsed by the 3GPP SA4 group > before submission to IETF. > >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4867 (draft-ietf-avt-rtp-amr-bis-06) >> -------------------------------------- >> Title : RTP Payload Format and File Storage Format for >> the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband >> (AMR-WB) Audio Codecs >> Publication Date : April 2007 >> Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Apr 18 03:23:13 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C27812DC48 for ; Mon, 18 Apr 2016 03:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 T-bpoffXJPFj for ; Mon, 18 Apr 2016 03:23:10 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 0AE5912DBEA for ; Mon, 18 Apr 2016 03:23:10 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id p188so183236870oih.2 for ; Mon, 18 Apr 2016 03:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=mq9xBHLAhlHkZLDZZGRR8wEAkHZpIiPwr5FVNGwwozA=; b=TOaOPqEGjhZBNBzWB7WByoC+l5rY1etbsGfru2aAKCeFooAR2DrdJRSzRNg3C8/DMR yaNsfBRUZrxLXaeSqzfuBbFP8TO3sf3odRcHSIZ6SX3KB8yvdzQJ9TAusB0syjZv9gY2 RT7Ai2GFLbPf6Kjcl52CfumZLCus1WfBA+ZY6GG5IgU0T6s/LWW29EeGTSRsis5UwTN7 JqQUjqjfjkvZPZ6J/cP1ZGtLqgl+JB2liJm5SJN0x9+8m6ZSx2Vso1ZC4S9cOTXNG1hJ lDJp32YembcDs5DYUfP3/INfOwBnQ5Y0s6m4xUCQ+KDFYtZuJVYSD4nrsRy5m+SuoipP MgMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=mq9xBHLAhlHkZLDZZGRR8wEAkHZpIiPwr5FVNGwwozA=; b=ZWu763AM5zhPNVmMhtJSjq7IQ+1rwszAqo9rTrZSgUIgb27PCCzI41b7WrfsdK/yGj Bqul5fbd5fI6DVi/1Cn/sMeoDOBpfQFOmG9zQXTmvDaDKWWFtd586J7GXVCvRG7iBe5L YaLtqxGLDFYRvBqrCEJI7hTonCGMqTwG4tDMpXYB19wS1eXy8OduCjNPxUoHfvpubi2K ARImtu/a2Hp3IvaV8Di1z22q8NogpHbKZNtteJs0dOa76+RiQhCFGu1779t+sas/M6XG Q93gJS6ZEhumLA3XpBQ/k+xXJbHvTbB1DB211m/Qd6zZQhbuZUHPFFmVkiCQQcE/lvX+ 34EA== X-Gm-Message-State: AOPr4FVWIjOJzG9145qeNeleTfoe3seTiB7IArALVoedRUmSyr364QDDD7dJ/MC/AzDhP1bSc2ebwEn8F030gQ== MIME-Version: 1.0 X-Received: by 10.157.34.14 with SMTP id o14mr341960ota.63.1460974989442; Mon, 18 Apr 2016 03:23:09 -0700 (PDT) Received: by 10.202.180.2 with HTTP; Mon, 18 Apr 2016 03:23:09 -0700 (PDT) Date: Mon, 18 Apr 2016 13:23:09 +0300 Message-ID: From: "Ali C. Begen" To: payload@ietf.org Content-Type: multipart/alternative; boundary=001a113c2b42458b8a0530bfbf3e Archived-At: Subject: [payload] WGLC: draft-ietf-payload-rtp-ancillary-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 10:23:11 -0000 --001a113c2b42458b8a0530bfbf3e Content-Type: text/plain; charset=UTF-8 Hi everyone I am starting a WGLC on the following draft: https://www.ietf.org/id/draft-ietf-payload-rtp-ancillary-03.txt It is a short document. Please review and send any comments to the list by May 2nd. -acbegen (as a co-chair) --001a113c2b42458b8a0530bfbf3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone

I am starting a WGLC on the= following draft:

It is a short document. = Please review and send any comments to the list by May 2nd.

<= /div>
-acbegen (as a co-chair)
--001a113c2b42458b8a0530bfbf3e-- From nobody Mon Apr 18 08:59:36 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CEE12E1AD for ; Mon, 18 Apr 2016 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byyr-RuRyohN for ; Mon, 18 Apr 2016 08:59:32 -0700 (PDT) Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B59012E1AC for ; Mon, 18 Apr 2016 08:59:32 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u3IFpI1S030733; Mon, 18 Apr 2016 11:59:31 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 22agff1vkg-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Apr 2016 11:59:31 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 18 Apr 2016 10:59:30 -0500 From: Jonathan Lennox To: "Ali C. Begen" Thread-Topic: [payload] WGLC: draft-ietf-payload-rtp-ancillary-03 Thread-Index: AQHRmX9DVBDtL4Dc2kakGfKBjIdZLZ+QN2aA Date: Mon, 18 Apr 2016 15:59:29 +0000 Message-ID: <11F2C0D4-36AF-4543-87AE-8819D1C739C8@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_11F2C0D436AF454387AE8819D1C739C8vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-18_12:2016-04-15,2016-04-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1604180199 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] WGLC: draft-ietf-payload-rtp-ancillary-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 15:59:34 -0000 --_000_11F2C0D436AF454387AE8819D1C739C8vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBcHIgMTgsIDIwMTYsIGF0IDY6MjMgQU0sIEFsaSBDLiBCZWdlbiA8YWNiZWdlbkBnbWFp bC5jb208bWFpbHRvOmFjYmVnZW5AZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIGV2ZXJ5b25lDQoN CkkgYW0gc3RhcnRpbmcgYSBXR0xDIG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQ6DQpodHRwczovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeS0wMy50eHQNCg0K SXQgaXMgYSBzaG9ydCBkb2N1bWVudC4gUGxlYXNlIHJldmlldyBhbmQgc2VuZCBhbnkgY29tbWVu dHMgdG8gdGhlIGxpc3QgYnkgTWF5IDJuZC4NCg0KSSBkb27igJl0IGhhdmUgdGhlIGV4cGVydGlz ZSB0byByZXZpZXcgdGhlIHBheWxvYWQgZm9ybWF0IGl0c2VsZi4gIEhvd2V2ZXIsIEkgaGF2ZSBz ZXZlcmFsIGNvbW1lbnRzIGFib3V0IGl0cyBzaWduYWxpbmcuDQoNClRoZSBvZmZlci9hbnN3ZXIg c2VjdGlvbiBpcyB2ZXJ5IHZhZ3VlIGFuZCBuZWVkcyB3b3JrLCBhc3N1bWluZyBhbnlvbmUgY2Fy ZXMgYWJvdXQgdXNpbmcgdGhpcyBmb3JtYXQgd2l0aCBvZmZlci9hbnN3ZXIuIChJZiBubyBvbmUg ZG9lcywgcHJlc3VtYWJseSBpdCBzaG91bGQgc2F5IHRoYXQgdXNlIHdpdGggb2ZmZXIvYW5zd2Vy IGlzIHVuZGVmaW5lZCwgYnV0IHRoYXQgd291bGQgYmUgdW5mb3J0dW5hdGUuKQ0KDQpObyBtZWNo YW5pc20gaXMgZ2l2ZW4gdG8gYXNzb2NpYXRlIHRoZSB2aWRlby9zbXB0ZTI5MSBzdHJlYW1zIHdp dGggdGhlaXIgYXNzb2NpYXRlZCB2aWRlby9yYXcgb3IgdmlkZW8vanBlZzIwMDAgc3RyZWFtcy4g IEluIGNvbXBsaWNhdGVkIHNjZW5hcmlvcyAobXVsdGlwbGUgdmlkZW8gc3RyZWFtcywgZS5nLikg c29tZSBTRFAgZ3JvdXBpbmcgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHByb3ZpZGUgdGhpcyBhc3Nv Y2lhdGlvbi4NCg0KVGhlIFJUUCBjbG9jayByYXRlIGlzbuKAmXQgc3BlY2lmaWVkLiAgUHJlc3Vt YWJseSBpdCBzaG91bGQgYmUgdGhlIHNhbWUgYXMgdGhlIGFzc29jaWF0ZWQgdmlkZW8gc3RyZWFt czsgaS5lLiwgbm9ybWFsbHkgOTAwMDAsIGJ1dCB2YXJpYWJsZSBmb3IgSlBFRzIwMDAuDQoNCkNo YWlyczogaGF2ZSB5b3Ugc2VudCB0aGlzIGRvY3VtZW50IGZvciBhbiBTRFAgZGlyZWN0b3JhdGUg cmV2aWV3Pw0K --_000_11F2C0D436AF454387AE8819D1C739C8vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8A94F2FC1520D34E9D9693955F2423C8@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIg MTgsIDIwMTYsIGF0IDY6MjMgQU0sIEFsaSBDLiBCZWdlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFj YmVnZW5AZ21haWwuY29tIiBjbGFzcz0iIj5hY2JlZ2VuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5IaSBldmVyeW9uZQ0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBhbSBzdGFydGluZyBhIFdH TEMgb24gdGhlIGZvbGxvd2luZyBkcmFmdDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1hbmNpbGxhcnkt MDMudHh0IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXBheWxv YWQtcnRwLWFuY2lsbGFyeS0wMy50eHQ8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JdCBpcyBhIHNob3J0 IGRvY3VtZW50LiBQbGVhc2UgcmV2aWV3IGFuZCBzZW5kIGFueSBjb21tZW50cyB0byB0aGUgbGlz dCBieSBNYXkgMm5kLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIGRvbuKAmXQgaGF2ZSB0aGUgZXhwZXJ0aXNlIHRvIHJl dmlldyB0aGUgcGF5bG9hZCBmb3JtYXQgaXRzZWxmLiAmbmJzcDtIb3dldmVyLCBJIGhhdmUgc2V2 ZXJhbCBjb21tZW50cyBhYm91dCBpdHMgc2lnbmFsaW5nLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+VGhlIG9mZmVyL2Fuc3dlciBzZWN0aW9uIGlzIHZlcnkgdmFndWUg YW5kIG5lZWRzIHdvcmssIGFzc3VtaW5nIGFueW9uZSBjYXJlcyBhYm91dCB1c2luZyB0aGlzIGZv cm1hdCB3aXRoIG9mZmVyL2Fuc3dlci4gKElmIG5vIG9uZSBkb2VzLCBwcmVzdW1hYmx5IGl0IHNo b3VsZCBzYXkgdGhhdCB1c2Ugd2l0aCBvZmZlci9hbnN3ZXIgaXMgdW5kZWZpbmVkLCBidXQgdGhh dCB3b3VsZCBiZSB1bmZvcnR1bmF0ZS4pPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPk5vIG1lY2hhbmlzbSBpcyBnaXZlbiB0byBhc3NvY2lhdGUgdGhlIHZpZGVvL3NtcHRlMjkx IHN0cmVhbXMgd2l0aCB0aGVpciBhc3NvY2lhdGVkIHZpZGVvL3JhdyBvciB2aWRlby9qcGVnMjAw MCBzdHJlYW1zLiAmbmJzcDtJbiBjb21wbGljYXRlZCBzY2VuYXJpb3MgKG11bHRpcGxlIHZpZGVv IHN0cmVhbXMsIGUuZy4pIHNvbWUgU0RQIGdyb3VwaW5nIG1pZ2h0IGJlIG5lY2Vzc2FyeSB0byBw cm92aWRlIHRoaXMgYXNzb2NpYXRpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgUlRQIGNsb2NrIHJhdGUgaXNu4oCZdCBzcGVj aWZpZWQuICZuYnNwO1ByZXN1bWFibHkgaXQgc2hvdWxkIGJlIHRoZSBzYW1lIGFzIHRoZSBhc3Nv Y2lhdGVkIHZpZGVvIHN0cmVhbXM7IGkuZS4sIG5vcm1hbGx5IDkwMDAwLCBidXQgdmFyaWFibGUg Zm9yIEpQRUcyMDAwLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Q2hhaXJzOiBoYXZlIHlvdSBzZW50IHRoaXMgZG9jdW1lbnQgZm9yIGFu IFNEUCBkaXJlY3RvcmF0ZSByZXZpZXc/PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_11F2C0D436AF454387AE8819D1C739C8vidyocom_-- From nobody Tue Apr 19 03:28:48 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF9512D861 for ; Tue, 19 Apr 2016 03:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2PQrpz_McTJJ for ; Tue, 19 Apr 2016 03:28:44 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 C0FD812D516 for ; Tue, 19 Apr 2016 03:28:44 -0700 (PDT) Received: by mail-ob0-x234.google.com with SMTP id j9so10302764obd.3 for ; Tue, 19 Apr 2016 03:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PQ2OYv0SG569w7XZw1w+R9bjMKenGLxxN1xAI8mbXQY=; b=yoYTm5zZqkrJPkwzunxB0horJwgmHPWoyjAtC7olsBcttyo9Q309w5CsDLDQRMJRUm 53Z1RsRZUY/nUluV0WoUmSm6vKm0NW9btamMn0uw1mcgLbHsHLznF5SPwl4wXwLxFIY6 wr7SnJOvZHdFxqFJA5UelJ4qpRt7IUoL+LzCN7C2lrS6V+G7wXqSYg/GAIVQB8/tcPv+ walT6nYbVREAJDegotCZNwRwbSpZdOeMHg5CrYt9Vyn8gFdy34zbZHPx/nJ3hWDh0B+0 UjCFs/iEXvq08svOl6Y9hOPMWu5D/nmcd+DGNuMf7/pGlWmwyLI96xkZGA2fg+nMroLr RPPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PQ2OYv0SG569w7XZw1w+R9bjMKenGLxxN1xAI8mbXQY=; b=ltxBbGMMHeAqYKQPJR/CnTTupgXFVKg8XVIoeJs57EJCUletA7K5FlnH6GhuMb0qWu BtyECrSrxcw/2/X8CjmyCaFeMlBlAZscRYgBOq4RBtZiLruNNZIdIN4mCyF6wDKGbC1o eefDtCACd5+zQH20hwaOssLs1kVfx/AgR3ROD0Zc7RvtVBpdKbFIkVZzRl8Q/XTJfMzR tCsy5D9ax/ZOhvqoJb2DbDUJc/6dx7PYrtu8RAg9N6ZW/kTU/kyBRjHdP/qh0rrR+qEk QT8yZrte/zzkyD6gVlEqZv2JWH1uvt47xw5CMCeAygGeGWKQpmOBdrdVCUraEdbbkpNP 2XPg== X-Gm-Message-State: AOPr4FWNgFknYbQppcAaU8nOXDIuIT1ZdFmjRNhMEFXkLrEEVrKd9M0bjgSDxflKMhrZ2gvp7n2OaqQVhl2ghg== MIME-Version: 1.0 X-Received: by 10.157.48.87 with SMTP id w23mr699016otd.138.1461061724234; Tue, 19 Apr 2016 03:28:44 -0700 (PDT) Received: by 10.202.180.2 with HTTP; Tue, 19 Apr 2016 03:28:44 -0700 (PDT) In-Reply-To: <11F2C0D4-36AF-4543-87AE-8819D1C739C8@vidyo.com> References: <11F2C0D4-36AF-4543-87AE-8819D1C739C8@vidyo.com> Date: Tue, 19 Apr 2016 13:28:44 +0300 Message-ID: From: "Ali C. Begen" To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a113e29be116d090530d3f1cf Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] WGLC: draft-ietf-payload-rtp-ancillary-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 10:28:47 -0000 --001a113e29be116d090530d3f1cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 18, 2016 at 6:59 PM, Jonathan Lennox wrote= : > > On Apr 18, 2016, at 6:23 AM, Ali C. Begen wrote: > > Hi everyone > > I am starting a WGLC on the following draft: > https://www.ietf.org/id/draft-ietf-payload-rtp-ancillary-03.txt > > It is a short document. Please review and send any comments to the list b= y > May 2nd. > > > I don=E2=80=99t have the expertise to review the payload format itself. = However, > I have several comments about its signaling. > > The offer/answer section is very vague and needs work, assuming anyone > cares about using this format with offer/answer. (If no one does, > presumably it should say that use with offer/answer is undefined, but tha= t > would be unfortunate.) > > No mechanism is given to associate the video/smpte291 streams with their > associated video/raw or video/jpeg2000 streams. In complicated scenarios > (multiple video streams, e.g.) some SDP grouping might be necessary to > provide this association. > > The RTP clock rate isn=E2=80=99t specified. Presumably it should be the = same as > the associated video streams; i.e., normally 90000, but variable for > JPEG2000. > > I will let the author respond to these questions. My assumption is that these cases won't be necessary for this payload but I will let the author confirm. > Chairs: have you sent this document for an SDP directorate review? > I just did. Thanks. -acbegen --001a113e29be116d090530d3f1cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 18, 2016 at 6:59 PM, Jonathan Lennox <= jonathan@vidyo.com<= /a>> wrote:


Hi everyone

I am starting a WGLC on the following draft:

It is a short document. Please review and send any comments to the lis= t by May 2nd.

I don=E2=80=99t have the expertise to review the payload format= itself.=C2=A0 However, I have several comments about its signaling.

The offer/answer section is very vague and needs work, assuming anyone= cares about using this format with offer/answer. (If no one does, presumab= ly it should say that use with offer/answer is undefined, but that would be= unfortunate.)

No mechanism is given to associate the video/smpte291 streams with the= ir associated video/raw or video/jpeg2000 streams.=C2=A0 In complicated sce= narios (multiple video streams, e.g.) some SDP grouping might be necessary = to provide this association.

The RTP clock rate isn=E2=80=99t specified.=C2=A0 Presumably it should= be the same as the associated video streams; i.e., normally 90000, but var= iable for JPEG2000.

I will let the author respond to the= se questions. My assumption is that these cases won't be necessary for = this payload but I will let the author confirm.
=C2=A0
Chairs: have you sent this document for an SDP directorate review?

I just did. Thanks.

=
-acbegen


=C2=A0

--001a113e29be116d090530d3f1cf-- From nobody Tue Apr 19 06:11:30 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ADE12EAE3 for ; Tue, 19 Apr 2016 06:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPXkQr1oO6_7 for ; Tue, 19 Apr 2016 06:11:23 -0700 (PDT) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AECB12EA6D for ; Tue, 19 Apr 2016 06:11:23 -0700 (PDT) Received: from BGB01XI1010.national.core.bbc.co.uk (bgb01xi1010.national.core.bbc.co.uk [10.161.14.14]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.14.3) with ESMTP id u3JDBLIE006566; Tue, 19 Apr 2016 14:11:21 +0100 (BST) Received: from BGB01XUD1007.national.core.bbc.co.uk ([10.161.14.5]) by BGB01XI1010.national.core.bbc.co.uk ([10.161.14.14]) with mapi id 14.03.0195.001; Tue, 19 Apr 2016 14:11:21 +0100 From: James Barrett To: "Ali C. Begen" Thread-Topic: [payload] WGLC: draft-ietf-payload-rtp-ancillary-03 Thread-Index: AQHRmVxTzwev5NwolUiGTj6dJhBjm5+P0xeAgAE17ACAAC1tgA== Date: Tue, 19 Apr 2016 13:11:20 +0000 Message-ID: <0EB4F1FC-DF6C-4EA0-9E61-3212B1C88B41@bbc.co.uk> References: <11F2C0D4-36AF-4543-87AE-8819D1C739C8@vidyo.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.48.249] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22270.007 x-tm-as-result: No--51.949500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-ID: <15982DE2FFF27F43AF6280130387A997@bbc.co.uk> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] WGLC: draft-ietf-payload-rtp-ancillary-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 13:11:28 -0000 SSB0aGluayB0aGF0IHRoZSBtaW1lLXR5cGUgc2hvdWxkIHByb2JhYmx5IG5vdCBiZSB2aWRlby9z bXB0ZTI5MSwgYnV0IHJhdGhlciBhcHBsaWNhdGlvbi9zbXB0ZTI5MS4gVGhlIGRhdGEgY2Fycmll ZCBoZXJlIGlzbuKAmXQgdmlkZW8gZGF0YSwgc28gaXQgc2VlbXMgaW5jb3JyZWN0IHRvIHVzZSB2 aWRlbyBhcyB0aGUgdHlwZS4NCg0KLS0NCkphbWVzIFAuIFdlYXZlciAobsOpIEJhcnJldHQpDQpS ZXNlYXJjaCBFbmdpbmVlcg0KQkJDIFImRCBOb3J0aCBMYWIsDQpGbG9vciA1IERvY2sgSG91c2Us IE1lZGlhQ2l0eSwNCk01MCAyTEgNClRlbDogKzQ0KDApMzAgMzA0MC05NTIxDQplLW1haWw6IGph bWVzLmJhcnJldHRAYmJjLmNvLnVrDQoNCj4gT24gMTkgQXByIDIwMTYsIGF0IDExOjI4LCBBbGkg Qy4gQmVnZW4gPGFjYmVnZW5AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IA0KPiANCj4gT24gTW9u LCBBcHIgMTgsIDIwMTYgYXQgNjo1OSBQTSwgSm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5 by5jb20+IHdyb3RlOg0KPiANCj4+IE9uIEFwciAxOCwgMjAxNiwgYXQgNjoyMyBBTSwgQWxpIEMu IEJlZ2VuIDxhY2JlZ2VuQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpIGV2ZXJ5b25lDQo+ PiANCj4+IEkgYW0gc3RhcnRpbmcgYSBXR0xDIG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQ6DQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXBheWxvYWQtcnRwLWFuY2lsbGFyeS0w My50eHQNCj4+IA0KPj4gSXQgaXMgYSBzaG9ydCBkb2N1bWVudC4gUGxlYXNlIHJldmlldyBhbmQg c2VuZCBhbnkgY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgTWF5IDJuZC4NCj4gDQo+IEkgZG9u4oCZ dCBoYXZlIHRoZSBleHBlcnRpc2UgdG8gcmV2aWV3IHRoZSBwYXlsb2FkIGZvcm1hdCBpdHNlbGYu ICBIb3dldmVyLCBJIGhhdmUgc2V2ZXJhbCBjb21tZW50cyBhYm91dCBpdHMgc2lnbmFsaW5nLg0K PiANCj4gVGhlIG9mZmVyL2Fuc3dlciBzZWN0aW9uIGlzIHZlcnkgdmFndWUgYW5kIG5lZWRzIHdv cmssIGFzc3VtaW5nIGFueW9uZSBjYXJlcyBhYm91dCB1c2luZyB0aGlzIGZvcm1hdCB3aXRoIG9m ZmVyL2Fuc3dlci4gKElmIG5vIG9uZSBkb2VzLCBwcmVzdW1hYmx5IGl0IHNob3VsZCBzYXkgdGhh dCB1c2Ugd2l0aCBvZmZlci9hbnN3ZXIgaXMgdW5kZWZpbmVkLCBidXQgdGhhdCB3b3VsZCBiZSB1 bmZvcnR1bmF0ZS4pDQo+IA0KPiBObyBtZWNoYW5pc20gaXMgZ2l2ZW4gdG8gYXNzb2NpYXRlIHRo ZSB2aWRlby9zbXB0ZTI5MSBzdHJlYW1zIHdpdGggdGhlaXIgYXNzb2NpYXRlZCB2aWRlby9yYXcg b3IgdmlkZW8vanBlZzIwMDAgc3RyZWFtcy4gIEluIGNvbXBsaWNhdGVkIHNjZW5hcmlvcyAobXVs dGlwbGUgdmlkZW8gc3RyZWFtcywgZS5nLikgc29tZSBTRFAgZ3JvdXBpbmcgbWlnaHQgYmUgbmVj ZXNzYXJ5IHRvIHByb3ZpZGUgdGhpcyBhc3NvY2lhdGlvbi4NCj4gDQo+IFRoZSBSVFAgY2xvY2sg cmF0ZSBpc27igJl0IHNwZWNpZmllZC4gIFByZXN1bWFibHkgaXQgc2hvdWxkIGJlIHRoZSBzYW1l IGFzIHRoZSBhc3NvY2lhdGVkIHZpZGVvIHN0cmVhbXM7IGkuZS4sIG5vcm1hbGx5IDkwMDAwLCBi dXQgdmFyaWFibGUgZm9yIEpQRUcyMDAwLg0KPiANCj4gSSB3aWxsIGxldCB0aGUgYXV0aG9yIHJl c3BvbmQgdG8gdGhlc2UgcXVlc3Rpb25zLiBNeSBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlc2UgY2Fz ZXMgd29uJ3QgYmUgbmVjZXNzYXJ5IGZvciB0aGlzIHBheWxvYWQgYnV0IEkgd2lsbCBsZXQgdGhl IGF1dGhvciBjb25maXJtLg0KPiAgDQo+IENoYWlyczogaGF2ZSB5b3Ugc2VudCB0aGlzIGRvY3Vt ZW50IGZvciBhbiBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3Pw0KPiANCj4gSSBqdXN0IGRpZC4gVGhh bmtzLg0KPiANCj4gLWFjYmVnZW4NCj4gDQo+IA0KPiAgDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwYXlsb2FkIG1haWxpbmcgbGlzdA0K PiBwYXlsb2FkQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGF5bG9hZA0KDQo= From nobody Tue Apr 19 06:40:13 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E3612D86C for ; Tue, 19 Apr 2016 06:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iWwMlgJpz695 for ; Tue, 19 Apr 2016 06:40:09 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 D1FAF12D663 for ; Tue, 19 Apr 2016 06:40:08 -0700 (PDT) Received: by mail-ob0-x233.google.com with SMTP id tz8so14521462obc.0 for ; Tue, 19 Apr 2016 06:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OqUBwcFaux4Og3Vti+iel58XTN/bhIrx6WjhhrUGrFY=; b=LH6qYtXwGUnbmNS3sJEq5p3nkAE400RVXdaoRRUBnA9o+Dk78sjqSeaRG3zxZgnykp bu51r3rLK3R5FGDGvJ1eecZgPc6lo4E2SVy1buwnBIpvvXG4FBbix3O+h/b5JBjn+p1C FSG7HSUMbYxX1Cve8wbiGIxbHvo/BAzHDZ2wr5yh9+tuqYLadAMpuGeY6I4OJ3rvo7K/ upEQBHc2qvNIYYNnRKR81KMjBFpN3fjM3qidYXky4QScf+U7AsjGIoVjDlY/S9LfXU2d A79/DCXYyiKU686sXQF5p3ekoKE02FP95ery5UTM4dHUyIY4ig6eZLBbQdscK5dh7hla /Kdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OqUBwcFaux4Og3Vti+iel58XTN/bhIrx6WjhhrUGrFY=; b=Nyyb5naRRiUwGVKykTrj6hILVrIJjq7IhJXkJz2tsFL/Kyny7iz9KTr9aKhCC3WI7v t0+7ZruokyyDbRQ486FS3l0+jK8o/y+4Z/OlQSZSuEioJuq/RRNSZsXcLWE7lqVIMS3e JZxL7/n+YHnDuiqOY4IFKC0DK3LKI/qLkMmoVww+gPbIvsHx1cxsUxXdlKfjRcfJllF6 2Jcx7Grme0zx9n/nJ4qp/Qcg92Dlche7aKwSSP86Z5Sf1rsXtAQ+hKw9dUvYH12N/CLo drw8588xo0wn2jJcf2WxmL19YLzaDhDNNq2MS3eW0KyGPrxGOYCuGDcs3kda1CbL6vly +7Og== X-Gm-Message-State: AOPr4FVtntkSTCRH66emFzoaYSzmAZ7p2z93HF0WmrLHNbR9kD1LCfoW+QhBiXxlAB6Cbe8WB7lOr1gMJzhADA== MIME-Version: 1.0 X-Received: by 10.182.159.69 with SMTP id xa5mr1234169obb.75.1461073208099; Tue, 19 Apr 2016 06:40:08 -0700 (PDT) Received: by 10.202.180.2 with HTTP; Tue, 19 Apr 2016 06:40:08 -0700 (PDT) In-Reply-To: <0EB4F1FC-DF6C-4EA0-9E61-3212B1C88B41@bbc.co.uk> References: <11F2C0D4-36AF-4543-87AE-8819D1C739C8@vidyo.com> <0EB4F1FC-DF6C-4EA0-9E61-3212B1C88B41@bbc.co.uk> Date: Tue, 19 Apr 2016 16:40:08 +0300 Message-ID: From: "Ali C. Begen" To: James Barrett Content-Type: multipart/alternative; boundary=14dae939976d8f4cdc0530d69d88 Archived-At: Cc: "payload@ietf.org" Subject: Re: [payload] WGLC: draft-ietf-payload-rtp-ancillary-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 13:40:11 -0000 --14dae939976d8f4cdc0530d69d88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe this was discussed in the session during Thomas' first presentation. The room was somewhat split IIRC. I personally prefer application/smpte291 as well but someone had an argument for the video mime-type, which I cannot recall right now. On Tue, Apr 19, 2016 at 4:11 PM, James Barrett wrote: > I think that the mime-type should probably not be video/smpte291, but > rather application/smpte291. The data carried here isn=E2=80=99t video da= ta, so it > seems incorrect to use video as the type. > > -- > James P. Weaver (n=C3=A9 Barrett) > Research Engineer > BBC R&D North Lab, > Floor 5 Dock House, MediaCity, > M50 2LH > Tel: +44(0)30 3040-9521 > e-mail: james.barrett@bbc.co.uk > > > On 19 Apr 2016, at 11:28, Ali C. Begen wrote: > > > > > > > > On Mon, Apr 18, 2016 at 6:59 PM, Jonathan Lennox > wrote: > > > >> On Apr 18, 2016, at 6:23 AM, Ali C. Begen wrote: > >> > >> Hi everyone > >> > >> I am starting a WGLC on the following draft: > >> https://www.ietf.org/id/draft-ietf-payload-rtp-ancillary-03.txt > >> > >> It is a short document. Please review and send any comments to the lis= t > by May 2nd. > > > > I don=E2=80=99t have the expertise to review the payload format itself. > However, I have several comments about its signaling. > > > > The offer/answer section is very vague and needs work, assuming anyone > cares about using this format with offer/answer. (If no one does, > presumably it should say that use with offer/answer is undefined, but tha= t > would be unfortunate.) > > > > No mechanism is given to associate the video/smpte291 streams with thei= r > associated video/raw or video/jpeg2000 streams. In complicated scenarios > (multiple video streams, e.g.) some SDP grouping might be necessary to > provide this association. > > > > The RTP clock rate isn=E2=80=99t specified. Presumably it should be th= e same as > the associated video streams; i.e., normally 90000, but variable for > JPEG2000. > > > > I will let the author respond to these questions. My assumption is that > these cases won't be necessary for this payload but I will let the author > confirm. > > > > Chairs: have you sent this document for an SDP directorate review? > > > > I just did. Thanks. > > > > -acbegen > > > > > > > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > --14dae939976d8f4cdc0530d69d88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe this was discussed in the session during Thomas&= #39; first presentation. The room was somewhat split IIRC. I personally pre= fer application/smpte291 as well but someone had an argument for the video = mime-type, which I cannot recall right now.

On Tue, Apr 19, 2016 at 4:11 PM, James Barr= ett <James.Barrett@bbc.co.uk> wrote:
I think that the mime-type should probably not be video/sm= pte291, but rather application/smpte291. The data carried here isn=E2=80=99= t video data, so it seems incorrect to use video as the type.

--
James P. Weaver (n=C3=A9 Barrett)
Research Engineer
BBC R&D North Lab,
Floor 5 Dock House, MediaCity,
M50 2LH
Tel: +44= (0)30 3040-9521
e-mail: james.barrett@bbc.co.uk<= /a>

> On 19 Apr 2016, at 11:28, Ali C. Begen <acbegen@gmail.com> wrote:
>
>
>
> On Mon, Apr 18, 2016 at 6:59 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
>> On Apr 18, 2016, at 6:23 AM, Ali C. Begen <acbegen@gmail.com> wrote:
>>
>> Hi everyone
>>
>> I am starting a WGLC on the following draft:
>> https://www.ietf.org/id/draf= t-ietf-payload-rtp-ancillary-03.txt
>>
>> It is a short document. Please review and send any comments to the= list by May 2nd.
>
> I don=E2=80=99t have the expertise to review the payload format itself= .=C2=A0 However, I have several comments about its signaling.
>
> The offer/answer section is very vague and needs work, assuming anyone= cares about using this format with offer/answer. (If no one does, presumab= ly it should say that use with offer/answer is undefined, but that would be= unfortunate.)
>
> No mechanism is given to associate the video/smpte291 streams with the= ir associated video/raw or video/jpeg2000 streams.=C2=A0 In complicated sce= narios (multiple video streams, e.g.) some SDP grouping might be necessary = to provide this association.
>
> The RTP clock rate isn=E2=80=99t specified.=C2=A0 Presumably it should= be the same as the associated video streams; i.e., normally 90000, but var= iable for JPEG2000.
>
> I will let the author respond to these questions. My assumption is tha= t these cases won't be necessary for this payload but I will let the au= thor confirm.
>
> Chairs: have you sent this document for an SDP directorate review?
>
> I just did. Thanks.
>
> -acbegen
>
>
>
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload<= br>

--14dae939976d8f4cdc0530d69d88-- From nobody Thu Apr 21 00:38:33 2016 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEDE12D796; Thu, 21 Apr 2016 00:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMce3TDjcV8Q; Thu, 21 Apr 2016 00:38:30 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15B012E3AD; Thu, 21 Apr 2016 00:38:28 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-fd-571883729328 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.25.12926.27388175; Thu, 21 Apr 2016 09:38:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.248.2; Thu, 21 Apr 2016 09:38:21 +0200 To: Ben Campbell From: Magnus Westerlund Message-ID: <5718836A.8040906@ericsson.com> Date: Thu, 21 Apr 2016 09:38:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2K7t25Rs0S4QfMaEYuXPSvZLeZ3nma3 uHTxLJMDs8eSJT+ZPGbtfMISwBTFZZOSmpNZllqkb5fAlfFpOUvBHe6KzyemMjcwfuHsYuTk kBAwkWh+sZ0dwhaTuHBvPVsXIxeHkMARRolJ21ewQzjLGSUO3FjGBFIlIqAk8bx5KwuIzSzg KbG0dz8biM0mYCFx80cjkM3BISwgL7F0cxhImFdAW+LehJdg5SwCqhLNMxcwgtiiAjESjQ9O MUHUCEqcnPmEBaSVWcBe4sHWMojp8hLNW2czg9hCQGMamjpYJzDyz0LSMQuhYxaSjgWMzKsY RYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAkPw4JbfqjsYL79xPMQowMGoxMOrYCIRLsSaWFZc mXuIUYKDWUmE90AjUIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvduS/MCGB9MSS1OzU1ILUIpgs EwenVAOj9K2E/geVO9L5LCb8M/r92VraWOtNeVef0HX9/lNlLDVvlm20Debt+ZQdPP9ZvEj0 U/5tS/uuhX7IqnsoMX1yae2Ki8fL723fa5rlE94qfv7nkoesLqc6btiYxm6WDDKfqybMVXbl dt68wsVabTeYvWX40+fwr/Y2d2V59fqsg9SnV1mPAsWUWIozEg21mIuKEwFcfbmQPQIAAA== Archived-At: Cc: IETF AVTCore WG , "payload@ietf.org" Subject: [payload] Result of errata calls X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 07:38:32 -0000 Hi Ben (cc AVTCORE and Payload WG) Here is a summary of the WG's proposal for how to handle the outstanding Erratas for AVT and AVTCORE WG's RFCs. RFC 3611: Errata 4597: https://www.rfc-editor.org/errata_search.php?eid=4597 Recommendation: Verified RFC 4867: Errata 4347: https://www.rfc-editor.org/errata_search.php?eid=4347 Recommendation: Verified Errata 4348: https://www.rfc-editor.org/errata_search.php?eid=4348 Recommendation: Verified Errata 4349: https://www.rfc-editor.org/errata_search.php?eid=4349 Recommendation: Verified RFC 7273: Errata 4450: https://www.rfc-editor.org/errata_search.php?eid=4450 Recommendation: Verified Note: I have looked at the edits, and it appears to match what was proposed to put in. Errata 4548: https://www.rfc-editor.org/errata_search.php?eid=4548 Recommendation: Verified Note to WG: Errata 4425 on RFC 3711: http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=4425 Was already put in held for document update. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------