Hallo Roni,<= /p>

yes I can con= firm that.

Any Tetra interface definition must describe t= he way the voice payload is transported.

Of course ideally Tetra manufacturers should standardize the comp= lete interface description to control centers.

But having this part well defined offers an excellent first = step and significantly helps to reduce the variety.

= Freundliche = Gr=FC=DFe

J=FCrgen Machui=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0

3D"cid:image0=

Von: Roni Even (A) [mailto:roni= .even@huawei.com]
Gesendet: Donnerstag, 3. Mai 2018 09:46
= An: Juergen Machui; payload@ietf.org
Betreff: RE: Comment on = RTP Payload Format for the TETRA Audio Codec

Jurgen thanks,

Can you also verify that section 4 and 5 of the draft defining t= he payload format and payload header cover your use case

Thanks

Roni Even

<= p class=3DMsoNormal>Payload WG co-chair

From: payload [mailto:payload-bounces@ietf.= org] On Behalf Of Juergen Machui
Sent: Thursday, May 03, 2= 018 9:27 AM
To: payload@ietf.org
Subject: [payload] Com= ment on RTP Payload Format for the TETRA Audio Codec

Dear sir,

please allow me to= comment on the

= Internet-Draft RTP Payload Format for TETRA Audio codec April 2018.<= span lang=3DEN-US>

The internat= ional community strives to establish standards for the interfacing of radio= systems an control centers.

This need is growing as control centers do typically= communicate via more than one radio media. =

In this context we encounter Tetra s= ystems in most control center projects,
unfortunately using different i= nterface definitions for both speech transport and signaling purposes.

This fac= t represents an enormous cost factor to manufacturers and users of control = center technology.

Tetra interfaces move to pure IP definitions and there is a r= eal danger that the variety if interface definitions will grow further.

A well es= tablished standard for voice transport can help to reduce the impact of thi= s trend.

The present draft seems to me a practical way to handle this issue.

I strongl= y recommend to adopt it.

Best regards

J=FCrgen Machui &n= bsp; = ; &n= bsp;

3D"cid:image001.png@01D1B806.B3=

accellonet GmbH, Gesch=E4ftsf=FChrer
Nadistrasse 35, 80809 M=FCnch= en

Tel: &= nbsp; +49 (0) 89 3506 2592<= /span>

Mobil: +49 (0) 175 220 3864

w= ww.accellonet.com

Amtsgericht Memmingen, HRB 12995, Ust-IdNr.: DE253847299=
Gesch=E4ftsf=FChrer: J=FCrgen Machui, Felix Wiederspahn

Der Inhalt die= ser E-Mail ist ausschlie=DFlich f=FCr den bezeichneten Adressaten bestimmt.= Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertrete= r sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Ve= r=F6ffentlichung, Vervielf=E4ltigung oder Weitergabe des Inhalts dieser E-M= ail unzul=E4ssig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender = der E-Mail in Verbindung zu setzen.

This e-mail and any file= s transmitted with it are confidential and intended solely for the use of t= he individual or organization to whom they are addressed. Should you not be= the intended addressee of this e-mail or his or her representative, please= note that publication, replication of the contents by any means or further= communication of the content is not permissible. Should you have received = this e-mail in error, please notify the sender. <= o:p>

= --_000_CEDD4124F5F4AC4F85CFF86AB45D3C3C06E28AE3749Esrvsbs2008_-- --_004_CEDD4124F5F4AC4F85CFF86AB45D3C3C06E28AE3749Esrvsbs2008_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=11290; creation-date="Thu, 03 May 2018 08:51:18 GMT"; modification-date="Thu, 03 May 2018 08:51:18 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAALMAAAA6CAYAAAD7q2jjAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAACuaSURBVHhe 7Z0HeFZF1sfPWxKqdJUiig0WVGzYEVypwuonFkRlwQqrYlkLUgyXmyBFUUQ/G+hiL4CICgqoiKig spa1YAE0CoKKSggtJG/5fv+be8ObkJAAu89+QOZ5bt5bppw5858zZ86ZmURd17XKUMmBinJgmONU I+7mTNdNlJaG7/XyLHp9utmGsNm7ZrGviLumovnvTLzoziSuTLvncGCQk9WF2l4Rt2j7iNkF3L9V Wu0B7h9DnKyX8i05paqFxuRY9LdbnawPq5i9YhadkekOXvGf4lolmP9TnN3N8k2adQOQ58Wo169m t3Z0stoXWOKzt11nWsmqjnQzPr7WcVovtcgjIbNeXN1qWKhbmsVuv8nJfIX7CZluxoJ/N4sqwfzv 5uhukB+StUPCkhdlW/xvz7lugapUxWKjkcrn55jt/bUluzQw67Lawp/yaSswK/59rruBnwvPc9yF ORa64xdLVqEj1CVdX/SUvv2drBn7mo0G1O/9u1hWCeZ/Fyd3g3zQd/fKs7TxcbM+VSwUaW7Rn9s5 Wa+i9/6M+rDsNse9po6Fp1XVC7NkdUsedbLjDm1riQd5t4Y4CPDiYarr3NvHyfqM71Pzzer/bslN ADttrdlfVnL1dTL/cYDFh5KWLHcuVIJ55/i3W6VmlpaoZsnOqAWhXLN1P1nyFlSLIQUW+aCl45wy wnVfHOZkDTnCQiMXWjJW0yzvIAsPC1l4AIxoz/VtaQx5ws2YR7oOSQs9v79Zi41mueQfXm3JdEB9 2T8t0vUMx736Ndd5aWcYWgnmneHebpZWqgETvXFYIsYiNcM/ciFR43uZnQCgx1PdAagFowBm7cMt dCuStmAfAI1ZoyHgHNvBcW5803WXlsYW0v1roOO0C1l0UvVC/XvD3hbatIn0v5s1AtTT2zpZw991 M3bYvFYJ5t0MkDtbnXSLPZxvaf0bWPKg5agTKMwh9OTk/ha65iQnM32sO6wfwByEXp1cbzYIxTiZ ZpYDOM9saJH23ZzMqQdb6NH7Spng3eG6zB2tOx1mGL+3oZPUoOOs3Q9J3chCUfIaXtfJPGaUxS86 vFDn3q5QCebtYtfuFXmwk3UPKsUzWB8+DGqG7rp+kOPeWhPdmAlawSrA3NJCefWIELXQlQBx8Wg3 4x7SDB7oZK0BkGP4FCGfnKYWSgfYl31rycvOd7IWNDSbUtdsJuBfkso50meSdh52aI0Cx2zGbk36 vFqA+igLnXW/RadFHacnIwUCu+KhEswV59VuFRMwjUyz0PUFljzhSse58BsLd5vvOg+okqNd58XB zognDmEiuI4JG7pxAtAmAd1GQHfnzU7WF2PdjDfucDPuYFL4Q9zCE1A16pB0bRMu8k1D3z75e7OT MSqPvMLJWkRnmI3KMg9h/ykdZiNp5xP/WDrHDeR5M6BuQv5oLpZLB+icsOhCaOxHPBwvFQuVYK4Y n3arWAOd23shQQfj2FiPdDzqF4ssqI3e2s5x0wH0Paps3ApuiFraiY3Nmv8CmJm4xQBsAaBOAzTP XelkdZuIRB/hOs8DuiXk8xh5HgEac9GjC+oxh/wJYQ6oq+RYsh16cTu+214WWXaDM+KjmpZcSJqF ZHsfr5+MWbQ3oL6I/FthTYmhtrTElPeOAF3VYo+UZikp2SiVYN6tYFp+ZeSO3mxpIwFKHE9e/Acm eX8AZICWQKLeeYyT9c+PkYbot2vQi/8KMOehO6ejwMaRrAbYMEZYHVSCmec5Wd2nAmikp5wkbWtY 2gNVLHkxEnY9wIw3A9QNLRT7DTXkZ0tG6BRR3h9cxxIH17JQT8Bs1SyyCifK59ieP0A6T+ZVY8o4 EPpq81ud+D3zzObwHlK3HSrBXB6Hdr/vYCP5GQ1/oMxjKywZBdT58uwB1vTjLPlcR8c5DjCvki4N oK9GdZi0ulBayoESAmTrAV5d3r/Wxck6b7ab8Rb6LdlZb1zXq/h2MxJ6E5HzBTAmeDFAHUcBjmFn jtB5wj9YMowEDvG90V6W5Ap1hg5Ls2QOwP4NV/iaGqgsVSw8CalcLpDVTJVg3v3Aus0aabhm6L4H QJ6FNBaYpAsjAM0OsNB6Jn1NNlj0mV6O01nePwD9GIA+EAk9DOtFHKBpgVGIP+sxsdVCr54Zc9xL 30TdUB5j3IxbiP89GaqMdAFfFhF9QxeO1wfUAD20DkCvBdA5ABxRr3t1EoWa0FQLCR/GJEhh8VM7 OJknbrL4wAWuS0csO1SCeQ8Ds6qLWjAPCfoqE7vugHfDd4DuIE8lsDjAXotEPK2BRSYQ9VLFB9AO E8KGtSzZTzqxh8xCQG9A167awsLPGYB/080Y7cd/gA7zdRgTHZK2mdLovSQxl0m9YELoAZsRIYSt OQSgcdQkw3SYMIgNCfCoJQrpjcyuZSUen2xIJZj3QMCWV2WkYAZA6sjwH1pjyXhjdFsBS+kA9Lq6 FrrkUifrp0luxm16N8q9rf8gZ0TNqqzZ4LsHTgEacOYhcWOtiRJxMg+bZPGrmmDeo8PMxUlycoFF 70c96SHzG/ElWT0JHJSlTJDwSVlM9iU7AV4mDQEaPT28AU8j92moIjfhWn9+Ps6XsupWKZnLa/Xd 9Dtg+wTpfD8guhFP3AZJREApE5xCEtVgPZJ6aE8n6/fJbsY4T0RaQR8cKhFUgAtSAU3cOIDMbW2h 3v0s2vo7x7nyK9dlYuhiprZzpHfTS7LQiesBYjSMQlUlYK0euIqeZfWgAyQK6QnpWwHpqiQs9DJe wm94vhtb9aySTVMJ5t0UrKnVGuiMOiBhsebYhl9Pfb/RYm7I0s7cB28fE7y8OikfAXUcdG1k8nZ3 d8ddP9N1JqJvx7GGXMhipM1I6D6S4MTxgKkJpLx5fzJrnWaR+bUdd3gXS4xh80cSNeUBAP06UncM gO5B3ATpBOoiAKfSpQ4VqCTBe9JtjlhyHwC7P+UehtQ/ks6CoWRLqATzHgBmBvVzAdoQgNhklkVb VLPEfqxDflUWCJwWA5CCs9GTQ0jnEJOupL+FRDpxAd82sZhoQgfHzWeS97hv7+2LVF/Dt+vlSIGF npVDACwEdCi9joVGzbPQmUkn6xZUgwUAWl7Ac/AunhdmcRLxjvCdJKjMpYO6BMAF/HypK5TbeLNF HJ6vrQTzHgHgwkoCYCZU0fOQWvUxXt2OilAzYqFzT3acZlgHNjBczwGY4xqY/R0xt04TtBRxKUDn Y1O25hZ+rMBx03CqPKJ8sVrcwCTvJyZzdyBJpeZ6oJS6wLt8JHp+uoXwAibfOdXJZJF+fNR8183G uzgVml7Jt+jVRL0OepoBUHUGpa9ICBF/Q8hCVyDtJ9BJPg8S7daSubvj1ELvqqNZB8sb46eYrQw8 SXxrwLfq/rc8VntpEcxuF/CsHUGljgFtG0DMNUhErYRLZxXcXbz/myrMwnu8gdFT0Z/byPLgO0cC XkiFyNfajJYWnogZrtoC15HXTlaROwc67jIk7UQ6QD2AjCm5ENCS7nvzXB3XNguV+/1kkQvaAz68 eQ/SBni6bRygnkC5VxH9SqwezdUjyEdWi1L3F6Y0Tgzg1ohZaCDv/rpHgBmOXM41WpyhgVYC6MO4 1bCooEXo58lQz7c3+Om+KyIZCbsvIrcr6y6fYtIlwVosJCzRLGrhKoBESy1lKYhyxZDE/a903FkT XWc64NqMlOtDnIVMvqohaUsO/R6gSZNsbeF7w45b713XcQsB7Uy7kUkZnWQS13GBGU7fZLFgYliA 2W8tTpDqf7A+eo1F/tbZyXytjiVll57DyDCW37Gs8TiHddH9uJfbuyYdLwYdeb5OXrJaqgfrRJJn Q/fBSOdlirBbS2bqlwZj0jU5YWiCr1sCjKqib/60WsJolwtdMH0h/V7Ao/Y7QH68tAogNZeA8I00 dAQ+SB9OatEQprcYeu3D7RznUw3/AOKrQc7tV6ZbYjLxNOyX7BgCdAGAXg+gh4edzEZ/xgynCd7d bsaXuLPb485+BLVBpjtJV09jkR4tulA7NmJXDuEar4Y9ueca3Nkf4OU+x8lcUNNCbyQs/CYjxPlA 8mCid0HIdITWltAqLcc3smypIZlKn6/NyHoOb+/c7cGM7pYQkHVt+Sl8gBky2HvjmWbuuxySIRhJ eBJSuSEjztdl0Q9IF6PbLuK71Aht/9f64yTOjo2AYZ8WFn2yv+OcfjHevtHu0CmsiMui12ekmN5S sw6BcpnM1h1pof7zLXLAV47z15+xKjCZlDS/mAnlCvIfSDxpcLIte2CWF1Amt+aUm4tazQKkNHT0 hrTBOSx4OkdmiSoWWYmH8UssJd+inrBeI/QHoG4Txoqh9goQzb2WnFIdL2jX+O4P5l0RoNtDM0Nt jo+WcjpjYlLEwu3lmMBqkZQLW44KgLQWD2Dbly1yL2M+uivjvZsxbKAz4lAA1UvewACMqXRJwtMZ 1rJ9qmvYou81drJ6szhJHYbloxm30nmW0mnG+1JVDhYP0AKjQC06WCO9GdtcgRYgAeQIPUEaX2PK bUwn64QZjrhJvczTB/LTj1SJCJ14Ba73MWy63Q8vIxpWYSimZpztOPQCa0OBWrkUJtEfRPh6BSun mPkGuuZW/GYy1RgmtYO5zaloOmP2Cn4/nO66H2+rcc5znGP5fiLpGlGWevK3VGr+zG1sbmRrTjMk w+mkOchP8zlp3iJN4JXaHjyUGxeetIAHeLLsQEkH7pdS3juUx66i4oH1DOlIyTZqs9muuwi+VEPS dEf6H847Ae6TuZjBcvwdz6UVTppD4WV7mNGMtthEHT/NRqf/EL02iE85adiFj+ZbKzGNtqqHynEK tOXB0I9LLpfcZIkpIYsMkWt5HwsVrMdtLHSRTmrAOoDxt07ova+z6F5lVLWCSzdbtDGStB31LhXQ AiVmvLUtafOllnz7RMe98X3XeUjpmRhOBNBfQv8/oLGF7NG8LnKUBDZk6pk4lLliUwbPnMI9gRGt 2aAh5SUM+VYVj9YggGipjcln3YwRJfnngRmA1EMxeYKH7vQKrwuoF/meGWtMA8Lk/jQgbVE8nOk4 w6j0jVy1lVZBaTXm9HCc6RB2OZYC1LotgfIOqGP2IG/OkLJKg3vBH/LXUNYIyrq7lLJcmHMTaWoE CrCvQiw/w3GGvOa6T5VMs6PP0LgPNI6Dpp6UFy1B43pA/vA81gSnAhNa9qGB3qPxsgFXH3jyJF60 AwIa1NtON/tss+P0on5fpdLGzD7yCQ4K0lzLop6iNQxSXmnsr/dynGvgo8d/yqlLh/5APMBSIP4d 3YzTg7IL2S4d02dLYQmoABuZKN0DuB5Ax86jA4QFRp/nCdp9I4rq3escNxtAakKYh1PiPFzRc0lz eGClKMlLTfAkoVtZqOoPtGdbJ7MdC4NuQPD9CqAXyJ2t3d7pluxNeUXmuyCfANQCISNEXO5sLToq BLS3TkNmOOnqHj98Z4oIr/e041RBNSrq4MrTAzON9SzM6Sy9RYtAkC7er5iljVhw5xAYMK234xzy VIrXpavj3AdzBgipYnpQGIDzntHnzuZ3HyTJacH5C0jjfXk3j0Zvpi4vPUoUpXSguuR5F4DeTIPf H1S8m+OM4/0NQVmBUdIHWVNMR08C6BCAfrIk07f3GRr3gcZ3GA6bixepyFCH47km5d10KtaRGo5z VlA3+JiEvhi8qwddb8jeyjT7Ln5lijqMOl4JUFuvRHCw2/nEVOsDY/QzB9JxWNCeIPK9pHmHsvbi 9yI6RCfSz6aDtQfQC6i7JlgDQcdptFs3Gj/7F6wJvMvhKtWsFbXYJNYxD2AYb85yyzzaNXCQCCgF tFWEBUNPr3WyOn0FEPGurQaMf0la2lysBgfRtmWpHCHqnXcIhhJ2dl+43CJt2zruTVg7ppCHmuuv WCrmgKjR4KIxNBdNDoN2EW4EWD0jEKUCacmo9474HqB1CVNcTGCT4Y8sel1VJ0sSvz51e0bmviig OYGZZmcNV9KoabzbYOA0OBKll1wE2AZJogDo2ph2Tub2ZRWKRO7AMDOA4c6TrKR/S+5KftfxfDEV vFpAQCydnA0IufWUdPIcS4M2U8fRgnCoGQ2BM+hVDWjsEaRrLXBT8f+FthkA+gekXHskwA1BWTTm U8S5S/oT90NJ00P086w0s0ijqDscoPEBaGyuTOh0GiOnwo/nRBZlXA6zOwAeA2Rd+c3kdnBQGC0i J0Mt8vgRGk+hc6GlFQZoWwAvn4TeNpirDkM0f+bzshcdtSdSdhMN2BX656cQ/9hfGAVoo37U9eHj Hedovkvlu5P8fq1TCOalU11XdNjMMmpdKG3d4Vg3JsNLbUbVUF40p6Lt8hiBaxxhyZdiTAiXuO7n gPEHJPoZrImYDaCblQVoSVjqnURdWUsb7kc9JrdzMlFt4kPfdt0l7EZ5ko4xt8DSRpBPH6mwkFmq WpgKbFUFHCThl9zfHtr5LoyL9juUiS6cQhqgHtXwmU2X60VjHQmzYjD/9hR+DIZhfektjXy9pVHw jcyuVkaSrABpGbl1Ra/TUKKwgAY4nM5xJB3gO549AUpeygezTOFYSG3GznDdoUGefF8GsD8mv98o 8zsyg7/2AwAa4NuDNY5++IrrFhnK+X4OHWsxlW6JlKpF3ufyztPddiRAQ2vyOhe6PRqRYBMAT/+U vJ6lvFl05C6+7nQDacan6PnerB0gj0wFstKTZjJ1HocUbMB3tIdCMIuXUtGo972vFgeyVyx8HIDE Pp/R4HB1EF697dNT0xfDKrLcgE14CrrsbDpjF3i7TtJOklAAko6q6h5oIQ4+jLwGoDt877rfYA35 FkB3BdCzsCo0K0vlCEBIpXIxtUVXWvL83yxyxmmOOz7fEuPoGFTBLiWvJwH/cNr0VFAp8iWpywz+ aJ+qNgdxc6V6kE8tcIiWwj09WkLmef+S+zP0LZITxh5NSah4Vlvi3R/OPaZpooM0aKOhXqpIDtI6 BcheYXw7vxW//vZy7x35HY9U0BYcz3MBoc+k1gJALG7vOK1aowpKz/PLSqO2x6ks0UDaN6RfQqM3 u8XUE/sItYXe29LXq9rzeofBTNruGqE0plJuHkS4qTT69RhOQ3SR+kF9qhJXZYqHClqbq7p+XDId tBZA6xqY30Ajn76j0tSlbkdKTFGhL3luynOxxoPXciAsZZQ4jnpqdAzAXLKIcp8p9CboPpV285wn gWhWQgEa2tYxKWuCh/B1c5xOPqC/AYSdAPQrUUv+ifSlqhzKQ7p4HfJFlVmLrlwDM9zQhEUuYW3H /zIRnTiyUO+fi+pxQdLCN0NPG98Us5X6UW5l/AhSx3TrMVSBCU0POHjOpwCOSh3SAAku8Kg7BToj FfXqzjP0esv5vBdcRUNpkJ/cw29uTU1T38yi2UA+DJUALBYYlr5LbSkaEkFmDVSWz8GrAERvHr0G 514k1BYnRC8PzbYutuJvyLS5xIX0fkCZTT1QcYsHOvq3lJNLHEkFhRZBDNJ7uh2MVZ8tGfyR0nvt 8RLgoq1YLR/MT6jsYCKdmjgYUsngkIrXZuuYSNovtTObTiFrwFZDPeVLWq9tYaGmcYu8WdNxun3u up+Rbimr7ziDLvYiaY9HqpeqJqhETw/gl06xgdErzPqMJnSEUekWub6Dk/UU3/+hjbBEeX6Y42Lt CV/H/WnwDDe7N1GU1rg9wYNoFB0sin44DWifKQKEbumzXF9TsQ/heHfEsQClEMweA0x6L/0GLbdw 4hV1Hr8hSxs+Suaj0cCTwurBAKguzEaj2BJUE10+HRKsOxykzwllIoz8is2Wg0wBoDZ3FqQQXzTM S7r50i5V6KXSU6zOJIwKwLpoyA9ItDkQGkEiAYxEMdAjlcBTTXYmsD6CuU20O0w9qTS1QTowo0AO gG6CpXfuXk5WjwVuxjt3uINXMip2ZD3Fk7TB/8CcMqWpKi8pTUMl2LyauwqzGxKvIfbjm8n/+tOd zHkxS06+1xIv5LjOTE5JUiftBU1nkbYldMFij/9q2jJx4reTJxSjKBt9AfOZmuzwQeciMEmwlxjq l8heiRVhaQBmcg2kiXbfypuk3bNqCOm2xQJ65AFUpOka8jnWbLUOpybe78pADUee6XQ/gXJ5akLS nYSEXY84/L4jZSB5JQFEV1WGdD3czc/TMCroQzL+UwybyIjDvT9q7Vhzk8fP6jm+GtQEN20137tV lCFEN6DwOsGIVbIO21nyevihzqHJ7CXozF9vZ/rtjk5bxFAbrqQt3iexBgKBphhgqFsYfuc0B4/f WHLO8Y7b50N0btLKgnA2B8jcRRveSDsorSRpqYALpDQHxGg9SC7tymwtqTI74eXrdLRFxpmT+el8 C72XZol/MSm7o4GFD0VonUA7HAuNdchYa6sDc3EEfqXxXpPChEDA+pMfPTDzspeok9IBIp6HmZ7V YTqXGvJ7pLIaTaUHEgPddh0TvKUUuLdfC5mOSobhfL8EYOYCSDGtC3l8It1XgJb4ZDzpwk+RpGHR TFUq8DrE1jjQ7JdP6FiU9RAd6jvS1vMr1KCkMwZrRw8AtgmxvxhmaQ6ww0EN7EtJ8aTBUtRaMitp 7uvLNxn4PdFEo763owUiNFbAn58Azv7oJeJHqWDG7HgdQifJRPstHDJfpJYHzWWNAmWSJXUD1/WN qHoTQGNgWS0WXwKjDjo03rpqSzwLhTuEJaCjFGmUm3ET6soXYGIrT1/JQgMpreHr4MLjB+I0UuRX pDUYqEHbtsVk2JZlnZ5ay47xP8h3PdipTpumgYkIC5U8ryWdHhNgaBW3km0cm2CsoAt/ozI17Ffx C9MDc5QtIZsF3Qw3dYLpJgV4w70CaZ6nsJN+5R5gtj7Lce5BJN5OI+fSyBwsbRdI9mNyqgXgPb2T EhcfBHiJ01p5UomhWAa+gao5dCTW2dooCK4hwAPcfQGV12iUNYWy2kj9oTIXkeYVLBpT9Y37jpQ/ TT1UlWGkuYWfsSUZWtFn6Jvzndkq6Gikjkp591GGDgeU1StKOb2hc4iAXIcLmmZhtfiyovmXjIek K0AwMLGya+DZ3xmZHqcD56TGA8gdAfL4WoXl9eCnJJgrqukVKx7X9UT29Z3E4iA8fmXbkSl3E/pv HPE3EsfIEThG/oZjJBfHyCQA/S/a6llhZ1sTQ78dPdVDFhT4XKB9h+jUMYEaPHiOHAksLlW1DjRp NJdsgeVJmUk1ms840mKXg4faEYvKchrFzlwIZoAiM9OpMtQR4RQY+56kE9fxSLu2gST1xxBGiqIw Ecb2Q5luBUEC9PVIFo5zsvUQy+ShUJqjvmwgr+FKhZMgcZDj3EJes8V93temAV8CyFI1qgOc+gIJ gJRnayqjxLtKR9yH6BhXAfpmVFrnPEyBzrdJr7w7iUZZVaDjV8osKUW3C2c6CRPwXsuoMlV1gJPy bE6GiT9RVpRy9lV5Glmg5Xe+Xb1dBZQSmXqPRtRcDGAPgF9vAuib4f0i+BKh7qxTsIc0uWWUmHsc /FKvUgA8Mq+JP0cxge/P/XL4NAfLUooGtG3qNljBAI7COhwwHkd91xJ7K3VBqgLoyj8I8KHzXrja okeyNvmKt92MhToABj36NLyFz8OLU+GTtlJtc6QIJLWED/qpHCQxsKNjB7g8YMtZIiB7wQe4Rxd6 9rP+QeZbTbCV3/2Asi8Aai5pWQ/TDw12skQwKsYicviVArsrIsw9G8/VGIFShnuY3p0cXwThR2kK SqeoC2PrighZA/j2B5W7iGHxh4ClpJvTiQ2PAPM+yqmqdDRm0+C7egugfJNyr0hJk0tZZ5HXtDrM 5jUmkn971U7pRRu0L6cxz3250NQYhGpSytWp6BxUbUtDwdC99E200oEkCYoCUv8FpOGldPuxgLa+ X14TRVBDQIPqthi9+mLqBpsKA/SFqVO6OhaoKBrFUvMmvVzR+lcKYpEXMI+uQFU6k3o/RyHHUJe5 gFLNEQHg1ZQR9L8Pby9KXXdBvReQJp84nDNhD6l1qQ8juWfbr1CQCRSHxgUA+l2NhtCncksFNPVK AGjNQ1uBmfmoHXinEiOhaRWA7sRmVxbfe3sDNeUQ20rVowPCAlDrWSoE+IntB7Dho8ybYYQGv8kw +clClEZn+62FJZa2dZyGJIlWtSgbL6KMEIMLdWbAtRagnALzB/LcPgdJROP+gsScSQvfw31TMl4p 6qAsn8lcja8KF44YabOxhug8ssv51p3C2DhpEdL+DMjeIa9HMG15BaWG1133EcrUCHAF8bXQSN4/ 6bzLKOcldOInSqahrM/RqdtQ1mVIis5wvCnpI6TTCTpzQdTDH2/t+fuAxn4EpohvOUg9MdgLvJgO YCRtFbZSE1AdHsN9PIdvf6Vep3Ptp2TQmM39q0jSx0ouvqIc8eVBColyeTPsEkGTVI0yDak3auiW QKd4l/odwxvxpCP1asZ9HPq/Jc0r8/BwlVygBE+WQuPpCIOryLMJ8XKR4KVKRQCrPlQDu/8Kyqm3 P7QGbnjefY+6cD6d5XXiaBDwNb3i1EtCS+/FysHhiMnqay2Uta9F/rK3k3UzgNYo2pcloJ9BxyiI kDVC/NgmoIMSJFS4vLgqA2I5V0OVwWdY+C2fi0VH0Tk8e1olz8i+/D7ce6OxhJpAKXVUYPacJiVW XS3jdb/i1dry5K/meoA3uioc/IU2N5VRZqn5AB4Ng+P8q9yyNAoQSddWAbBO4KWuMoNvYx5DBF3l Bl/XLVPt8PmaUVZGWqDDt5H+VW55igCNmnyWOwEFWeuRYn2xYrx6F52YY68uJ91DQSFaGMRm04vY 7fECYNFgtpWFQ3EFOhAXQofeiJePgxHthDxLzufUoQmcOjRitOvehZntPQTUYwiZFkhZ79y5wmQV CwIvCbzFRakBBAvAdZWRVD4ERg4UzQ3ieGBODRU5bbFiJFU81n+jzIpTt3vE1EQTIM8EIBNuxYL1 KiPaaU7mw/PcYf2DGrLZ9CV2m1wStoTnvCkL0IF6oAkcatg6loBWQ2r3Z3F9z9OdrAfGYMfe7Lp/ us3JGg8AryO+cFmq+rI93FW5ANkbXclX27t0wKMMIF7YCszbk/l/Oy6r+Gqix8eRiBoWiwXUGOnh NZk1/+hPGEolF/NjjTdQd0vbP1eR+kHDXiioBeWdgxbk5S8FiKTSrPXgDKucLGQx3u+UaXFbNGu7 P+rE06xV/qibxY583SJn47x4fK47rO8WQA99CldzBFfzJMAiIVimDVnWB8Cc4PCXjZjTIszi67Jy bujJ7PPjuK5H51hsfFeLvkw+cv+3pYOonTTNqbCULqs+Am7MEs+lft+lwUzjn0FlpJsWDTWqHOCo DuNG03vnZReOjI+WxRR0qFvQH59mHlBMh60IkBUHGs5l4iLbsGzp5Qb0pA7QRR+z+1Min0Yl4rzX 0D693Ex2IgLqxCPsJPkz/wZt8QmWuPYLC036s5OJvTbeJ+iQuJofZ4Udnsjw4wBR5i/NLUsFoNQB fWiGlKZDrsN1rbU09Tl/GbU1cv1cS74IwB9vZZHPAH53FIT6pAlOTtrRmmA4CGWz1uPlXQ7M2jyA zhdCAq4BBQcivZYBWO0f+5Trd60/BrHHApSv0CGzuT+NFlBHnYEoiEj6kvZgZjbNeX7Vt8T8CcWw JWKnARE3+ccSdKMhPmAC+r02EFDmEXz/lTw/TGUalg51Iq2dZrS2twBzrtZpg8TWlC3p+pbiY+KT Wa0K+c0I0vM9XUNkiVZ8D3v8iUx+3/Y7Y0smP60B+Ct6hoaaWuvCKNCEzvMHdW5EBkchGf8lXmh0 IE5X6vY1gMpmzbk3QS8r/MhOkmZsd+JfPTzDZG7Fckucj9t6Pza39mZzq2cJYYXdczhV1jAZexpA 1+fSfKVUQAdqB3yQlN7M0BJfjj4NP9JoB1ZkhnotsuQSvm/EWlOfumqSJ89t4PrfHlDLfYi9Ofkw I26xeu4qkrkltW0HkKfw+yaN14JGvVog5HkBILiICtbj2RVX+G0As+rlYCvnsUk21hkY3g8QLeC5 FekfJf1ggPUVrXO62o7vLmm+pAFuwkw2HhA+qNk9+V7O8yCsDZ5hHtBfQZoDSVsAqDXxbgQRX/Cr JbGYgq0lcX7je3Mk0PH85hKvCcB/WOmJI/tp0dyGvLUdayTXIvIZQyd6kGiacH/CdRNx36dTHcb9 PVg2tK7hceqnidsUaO5JfK0bdwDNT+QxHMRl8a3Y8FsSKVgx8rXwPmZp8+uzWD/OCbPstzuJpZ8L 2zvuVcF/XcWpMhs9+zTKeRY+HF6eDVlSWmU1okM3KPTyxTRJlMmS5aOHyiIGE/NXAGT+IY/c2zoi 11uCqrT6LScoSs089v1tsoLUkc1LtkuAmcb8TDiiYY8EDJuQWJ15XsPz71TAMwGhiA0DcJ6+yft5 NLwk9yKu1qRZzxD32GTXfRagjaTxzySaTIDTtMaa+GeCyr2xIS6uU7ivTv8i92PszWP4fg1lqDN9 g41di5DOAjgPkWcSsXAB778gvU6E/4X4w4h/Ns9teD6FMmdwvw6Q3oIJ89HSnBnk3Y08Zz7Oli/S 3khl1LmaUp+XaehXGd9b8+y1M3lqt7lcvO9Bu3bjZGIx0CiRQ93u4DmfODJzlxuYOP3CKjjWNcdn cdZcC045yuUf6zDChV7AMnE/lokh8vKhZ3+BhetUbMgPsqSzF6NBuTZk6dJCNbbMmLZCYSrj1Pxk HH6F4YdO9wwt4X8AAuoExv+Ejratxa+kNRVNB9iywUvlUqcPMK5fz7WNB/K6klJ5lwGz1oLQUHkA iH+MaFP5vQTiH6JRdYqOd5I7zCtyUtDg1WCMGrWK9FDiyR0dA4yKIybVEMjEAOL+xHd46Z2TdgwA /DIHiY0kOttHhBrAk6RHAloSeSqiL2En8+1wQCejvmbrCml8YwLl2UL3I+84cR7pyq+vq3jHV6Wg jdMtvYWKCrncr+aaz/0QOsFy4s72aVarBiauoKwCvqsu3rPSqvyUvLd5i7MhG0B33syyTtSaYw5D Qn/lLX+wa6pZtNOfHXfQW/yzHiwhsMQuxIYsJ9pd0CEeljkxVKGB6iFm4eEQqGMCs07OR5iEfadI mEmjjh2QXzqOiqTFZD8D7mzSa6tWPRpMHt+iVWUUejMq0GulVWyXkMw+4ZroXQZzzuV3EJdMSrrn 3DFvkpJaF4GpBi8ERIErjd/A4wbPbCFpOqLnLgEw5/LN5Wp6nNnEhTQarVmX9J6E4730Wy9t88LF 9T8ylH9IJ1jNyw4qAyDrhHj6gdc5qqkDcWUjgT7llbbd905lPmlaa3Wg/245tHTjPz59vhKbLd/m U2Zj9Mreuag6fJPN9xDiH0IZR/N9Gs9eWXyrx7vXaexLsJIcB1j6kPap0hq6rHfynjGnOJ3TQCdy mPj5nIeRxyq5Ak6yb85ZcdOQ0i9xDFYmruuPOUbgbkx3Kzlk9h+UiwpcvlNEoJZurPKlU9dmN7ae JZ2pn7dxlTbweEj9Fz1v8Z4h5j2oglX3t+j+xOWkgATsCB9M8m91glJZddllwEyl9H/jatNzP4cJ I1i3sZoGlh4rqSa9LJBWQjVahi3gnc5N+0iTRJ8B4u0iOVPQY1vBQHWK2YB41iLA+z0udgC6inQv g2RJa4VPfIlnsodT5p2gazAI15JN7XjWfOZnMn5XkSn7G9KrnFmUnUncNMTYY4EtHZG8mLx7IGL7 SYTy7NDStfkdzuMb6EkvICWH0mHGkslz0DT7INZNEOca6HiJ/FcRz3OS8J2+Z4t5dx91kWq0Gnok Mbcr+P9vryeS9+/k5SKhq6FybfiRpZrU4X/YQNodULPsNnQPgH4Op8gX3E9nncbBlEtzVCxILw4m C4XALjx/WeAmH1lzCtpb2uAYG1Xx9MmBtA56NMixOSP2qH/ec5mF7TJgRh+Wy1mXghpensu3/OfP U2vo78d70X83K/UbJrin9cyE7J7g/czCm6n+Fbx+1o8nF29RkAufB40KJQNZezR9kPLhqpKR/H/H e2mJ94/wrCsIbgmaB5eI/4Nf1mQmgBppevLncVr/Wu4ZuXcsANRx2KHfR9K/eCC76uugdixDt0VK pAO+vhy6cjGgfuUNC40/1iKn17V4FtuoLgCgBXQ0b9NpRUMqsJWGTq9/y9aGMk4OQFmoN4bQaRIP 06lyyst7lwFzeRXZU7/TOXTOyCcAQRaQd+lM7+8ML7BDL9R+PyTvi/WQvGxOXStTm04ekioAqHpU t2SPf1nBPwHe9FYWnslI0lGjDBJ2h4PmPiTOox6a32hkk4ePswCTg8a4w8ZUJONKMFeES//P4wDg 6ZCo698SdOax/mk7nsInkJgdsA1vYAK3GdWH/+mX1IlDVRgJ2qAitPkM/Rp9LMSubg5jLHKGaIK4 wwGJXBtAY09PXIWOPLmiGVWCuaKc2sPioZ+uxPrT+UyLahvdQFlNAGsu/3lVJpUlTDYXA+qagH2/ Tez6QL/WRC6vEVso/UNjJF01j9FvRYLiVSW/KvSEuQD6GtaKfF2RhEGcSjBvD7f2sLhat85EYBhq xwwAPAKAcdyAFxoyeVuOeoHUjL6aWbjRNcTkJK022xlrW/jsmIX7g84TUD+knmhxkKS1n7wYIwXi KoBYa9tXco3hVP57d4TVlWDeEa7tYWn0n1qpcmcWIJ1VYOFrUW7bA5xOvGNBfjz7VidzBstLX+xq sQVYbWTdeEIXk8kTQbEcSx24DgXYsmF7ujUIlmFDJ3rKorOKi5V6sfHlWSy2xfpKMO9hwNyZ6rIA 6WXSv4ykPgExe75s9UzQjqhq4QHAcwA69mr+P8p83r+FWrKAvXkfAm5vQkqaFgD2JL615mrGpV0t +pfE05MWm8K/pfK8tzsTKsG8M9zbQ9MiqWV+9EyQQxzn4I0WPoIVdkcA0KOYCx6OXbozYjcZt7Tf ADcma/uU4wDeZZXbi9i0H/tPsa0SzP8pzu4h+XLc1jKqqmv6f7vK/wcfBCJK5QJ78QAAAABJRU5E rkJggg== --_004_CEDD4124F5F4AC4F85CFF86AB45D3C3C06E28AE3749Esrvsbs2008_-- From nobody Fri May 4 15:33:46 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BECC12DA1C; Fri, 4 May 2018 15:33:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Elwyn Davies To: Cc: ietf@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-vc2hq.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152547320806.20538.16057278625651659197@ietfa.amsl.com> Date: Fri, 04 May 2018 15:33:28 -0700 Archived-At: Subject: [payload] Genart last call review of draft-ietf-payload-rtp-vc2hq-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 22:33:28 -0000 Reviewer: Elwyn Davies Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-payload-rtp-vc2hq-05 Reviewer: Elwyn Davies Review Date: 2018-05-04 IETF LC End Date: 2018-05-16 IESG Telechat date: Not scheduled for a telechat Summary: Ready. A well written and comprehensible document. Thanks! I spotted a few minor nits noted below. Major issues:\ None Minor issues: None Nits/editorial comments: Abstract, S1 and VC2 reference: Expand SMPTE (Soc of Motion Picture and Television Engineers). s4, para 3: This para would probably be more helpful as a set of six bulleted entries for the six different packet formats, and omitting the 'one which carries' from each. s4.1, Sequecnce Number: s/extneded/extended/ ss4.1, 4.2: The encoding and bit ordering of the numeric fields should be specified (presumably this can be covered by a single statement that they are all unsigned integers encoded in Network Byte Order.). s4.4, third bullet: s/Hight/High/ s6.1, last para: Presumably this is left over from the template and should be removed. s8, para 1: s/This responsibility lays on anyone/This responsibility lies with anyone/ From nobody Tue May 8 09:12:20 2018 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 59A4512D967; Tue, 8 May 2018 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 j6Nj0FL2UlsZ; Tue, 8 May 2018 09:12:16 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 09DFB12DA42; Tue, 8 May 2018 09:12:12 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id f6so19787419wmc.4; Tue, 08 May 2018 09:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language; bh=XW9Lioa3z3izmXc1Vo9k/XbiApvntEzzm7CUS3QRZ88=; b=jUYCp0D7HfPloF6PgHhUHoeoiwEMxfPVAG+3SjSFY0CjOUwkOeByaBmyijK8g5GEHA MGTVwZNhs+kxlShJ80/9FXJKb1FjUZHn2nipN1kGm5Cr6NzKdkdWDtI1NJfdVfx8eaxG KZ1tDMaa1zfJEB5hF4kQbQ9jh24FWyAlRBehxWsfdUrl/Or4x3FDGKf6v2zZNB/MX7uQ D41uAZNgq/A7kZD/SSOZuoAwAIRllGYNX/GTEC4WMhttW8okwRMQfnq4X+sxAHSF22oZ HoOjX6mHMChxC8jJBDd31i5MzIpm8fGWer7to0E9j85LXBupdCd+fTZk2X3fGf5B4Wbs SAkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language; bh=XW9Lioa3z3izmXc1Vo9k/XbiApvntEzzm7CUS3QRZ88=; b=pYPaG3CGIlH+Fhkvl4RtyQnwVgMfuCND3JDXwyk0mRcWj+xVQ3u2JDipQIhWCYdlQE RP3MJdB4mBXj9ssLGjpEWuRYOL9DYKBOYWHlNYs2UqeOKANFRyivZnjvx6r3P7BH86Na vzp4wEebIfQ9oPLTuq3cgmoph+mYnf1TjnxB9OBnrRs8Q41RWCgcGGmNPNKaZwbEEETJ u3Ie932s6TT0VFBg481JY7c1++BAk84r6I8JGeuwONdhfeDRVXPpRdkws2ALnq4+9H3p vn+JNiot5Zuk02vll/K+raaxO/woCuIEd+p6pHb3EEzMYaZSo+I12Cl9BKvVNLoc7hcf PGGw== X-Gm-Message-State: ALQs6tA1WGtD6CFlDHYlIOT8oa6/jeej16iYD2Y7KAT7x79uG+IJzFYY yj3qecjZaBJoXKeOypehC4YWEUBs X-Google-Smtp-Source: AB8JxZq8bEhPqhOUMrasGdXCwO9kdx/GcQv6H2cD9XtNRRE7pv2/N7d2aiUvKqRLyYrrIzhq+lGuQA== X-Received: by 2002:a50:dc02:: with SMTP id q2-v6mr46328959edk.245.1525795930176; Tue, 08 May 2018 09:12:10 -0700 (PDT) Received: from [192.168.0.102] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id b22-v6sm11929622edn.44.2018.05.08.09.12.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 May 2018 09:12:08 -0700 (PDT) To: payload@ietf.org Cc: "draft-ietf-payload-vp9@ietf.org" From: Sergio Garcia Murillo Message-ID: Date: Tue, 8 May 2018 18:12:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------899E69951B8A5E35944AC20C" Content-Language: en-US Archived-At: Subject: [payload] VP9 frame markings: typo and questions X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 08 May 2018 16:12:18 -0000 This is a multi-part message in MIME format. --------------899E69951B8A5E35944AC20C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I have some comments regarding the latest vp9 draft regarding the framemarking header information. I think it is confusing to have two fields on the text named "S" 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=2 | L=2 |S|E|I|D|B| T |0|0|0|0|0| S | TL0PICIDX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IMHO it would be better to rename S/T fields for spatial and temporal ids to TID/SID to be consistent with framemarking draft. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=2 | L=2 |S|E|I|D|B|TID |0|0|0|0|0|SID | TL0PICIDX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Also, I have doubts about how to fill the I/D/B fields of the vp9 framemarking : o I: Independent Frame (1 bit) - MUST be 1 for frames that can be decoded independent of temporally prior frames, e.g. intra-frame, VPX keyframe, H.264 IDR [RFC6184 ], H.265 IDR/CRA/BLA/RAP [RFC7798 ]; otherwise MUST be 0. Note that this bit only signals temporal independence, so it can be 1 in spatial or quality enhancement layers that depend on temporally co-located layers but not temporally prior frames. o D: Discardable Frame (1 bit) - MUST be 1 for frames that can be discarded, and still provide a decodable media stream; otherwise MUST be 0. o B: Base Layer Sync (1 bit) - MUST be 1 if this frame only depends on the base layer; otherwise MUST be 0. If no scalability is used, this MUST be 0. from the information of the VP9 payload description (and viceversa). P: Inter-picture predicted frame. When set to zero, the frame does not utilize inter-picture prediction. In this case, up-switching to a current spatial layer's frame is possible from directly lower spatial layer frame. P SHOULD also be set to zero when encoding a layer synchronization frame in response to an LRR [I-D.ietf-avtext-lrr ] message (seeSection 5.4 ). When P is set to zero, the T field (described below) MUST also be set to 0 (if present). Note that the P bit does not forbid intra-picture, inter-layer prediction from earlier frames of the same picture, if any. U: Switching up point. If this bit is set to 1 for the current picture with temporal layer ID equal to T, then "switch up" to a higher frame rate is possible as subsequent higher temporal layer pictures will not depend on any picture before the current picture (in coding order) with temporal layer ID greater than T. D: Inter-layer dependency used. MUST be set to one if current spatial layer S frame depends on spatial layer S-1 frame of the same picture. MUST only be set to zero if current spatial layer S frame does not depend on spatial layer S-1 frame of the same picture. For the base layer frame (with S equal to 0), this D bit MUST be set to zero. It seems that fm.I = !desc.P but I am not sure if fm.B=!desc.D (the definition doesn't seem to match). I guess that the frame marking B discardable flag could be retrieved from the scalability structure or frame dependencies (although I don't use it at the SFU). Could you confirm if those assumptions are correct, please? If so, couldn't this info be added to the draft for clarity? May main problem is with the description U: witching up point which I can't find a field in the framemarking information that could be usable to provide the information to the SFU. Am I missing something or should we add the U bit also to the vp9 frame marking info on the LID field? Best regards Sergio --------------899E69951B8A5E35944AC20C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I have some comments regarding the latest vp9 draft regarding the framemarking header information.

I think it is confusing to have two fields on the text named "S"

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  ID=2 |  L=2  |S|E|I|D|B|  T  |0|0|0|0|0|  S  |    TL0PICIDX  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IMHO it would be better to rename S/T fields for spatial and temporal ids to TID/SID to be consistent with framemarking draft.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  ID=2 |  L=2  |S|E|I|D|B| TID |0|0|0|0|0| SID |    TL0PICIDX  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Also, I have doubts about how to fill the I/D/B fields of the vp9 framemarking :

   o  I: Independent Frame (1 bit) - MUST be 1 for frames that can be
      decoded independent of temporally prior frames, e.g. intra-frame,
      VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP
      [RFC7798]; otherwise MUST be 0.  Note that this bit only signals
      temporal independence, so it can be 1 in spatial or quality
      enhancement layers that depend on temporally co-located layers but
      not temporally prior frames.
   o  D: Discardable Frame (1 bit) - MUST be 1 for frames that can be
      discarded, and still provide a decodable media stream; otherwise
      MUST be 0.
   o  B: Base Layer Sync (1 bit) - MUST be 1 if this frame only depends
      on the base layer; otherwise MUST be 0.  If no scalability is
      used, this MUST be 0.

from the information of the VP9 payload description (and viceversa).

   P: Inter-picture predicted frame.  When set to zero, the frame does
      not utilize inter-picture prediction.  In this case, up-switching
      to a current spatial layer's frame is possible from directly lower
      spatial layer frame.  P SHOULD also be set to zero when encoding a
      layer synchronization frame in response to an LRR
      [I-D.ietf-avtext-lrr] message (see Section 5.4).  When P is set to
      zero, the T field (described below) MUST also be set to 0 (if
      present).  Note that the P bit does not forbid intra-picture,
      inter-layer prediction from earlier frames of the same picture, if
      any.
   U: Switching up point.  If this bit is set to 1 for the current
      picture with temporal layer ID equal to T, then "switch up" to
      a higher frame rate is possible as subsequent higher temporal
      layer pictures will not depend on any picture before the
      current picture (in coding order) with temporal layer ID
      greater than T.
   D: Inter-layer dependency used.  MUST be set to one if current
      spatial layer S frame depends on spatial layer S-1 frame of the
      same picture.  MUST only be set to zero if current spatial
      layer S frame does not depend on spatial layer S-1 frame of the
      same picture.  For the base layer frame (with S equal to 0),
      this D bit MUST be set to zero.

It seems that fm.I = !desc.P but I am not sure if fm.B=!desc.D (the definition doesn't seem to match). I guess that the frame marking B discardable flag could be retrieved from the scalability structure or frame dependencies (although I don't use it at the SFU). Could you confirm if those assumptions are correct, please? If so, couldn't this info be added to the draft for clarity?

May main problem is with the description U: witching up point which I can't find a field in the framemarking information that could be usable to provide the information to the SFU.

Am I missing something or should we add the U bit also to the vp9 frame marking info on the LID field?

Best regards
Sergio

--------------899E69951B8A5E35944AC20C-- From nobody Fri May 11 19:55:24 2018 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 D1D0112E042; Fri, 11 May 2018 19:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 MZm_5vg44a1a; Fri, 11 May 2018 19:55:04 -0700 (PDT) Received: from mx3-int.auckland.ac.nz (mx3-int.auckland.ac.nz [130.216.125.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4CA12D7F2; Fri, 11 May 2018 19:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1526093704; x=1557629704; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=gnrjBHKfwv7sLki9AqU9eCTFifC4tMl17F231f7b1t0=; b=cRmEhdDJrFYyJrgEYw4r4HZ6rhapSqnvmKBsK0Sps2gd5Xx31fZE45Sb 0lJzQJdD4iReCxuRrm1DGyiFxYnHRJ4F/QvOG3CtY7xYkuYKgt5VlOTZm mVjUnH58qPuPNZ9r++65vfry6PgfPGC4a/xg11utKopdLQY3tqcg0RpJI hYB+bZLj0xatbTajBpWGmSMVKfF5hAbceW3lozjigicavWzAZYH7tqLFQ oftcAiV5TjUYXJC9SDACRrfzcYqusRfCPobVnwrnaUeTxSKZfFjNLUC1n WcpSR5kMkF1kyCsPVbdkvsSPN4P6KzYqrIpiU7g0LBhNeD7dJOy7uoSUA g==; X-IronPort-AV: E=Sophos;i="5.49,390,1520852400"; d="scan'208";a="25811106" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 121.98.244.177 - Outgoing - Outgoing-SSL Received: from dynamic-cpe-pool.orcon.net.nz (HELO [192.168.20.4]) ([121.98.244.177]) by mx3-int.auckland.ac.nz with ESMTP; 12 May 2018 14:54:59 +1200 To: "ops-dir@ietf.org" , draft-ietf-payload-rtp-vc2hq.all@ietf.org, payload@ietf.org From: Nevil Brownlee Message-ID: <88bea593-3697-9626-4f20-953f8f428f41@auckland.ac.nz> Date: Sat, 12 May 2018 14:54:34 +1200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [payload] Pos-Dir last call review for draft-ietf-payload-rtp-vc2hq-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 12 May 2018 02:55:10 -0000 Reviewer: Nevil Brownlee Review Result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. "This memo describes an RTP Payload format for the High Quality (HQ) profile of SMPTE Standard ST 2042-1 known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video." This draft simply describes in detail the way in which a stream of VC-2 information must be carried ina stream of RTP packets. It's well-written, with sufficient detail to allow for inter-operating implementations. It's Security Considerations are clear. As with all documents of this kind, operators will need to be sure that the implementations of this kind of RTP stream do conform to this draft's eventual RFC. I noticed a few slightly puzzling things: Section 4.1 Payload Type says that the PT is "A dynamically allocated payload type field that designates the payload as VC-2 coded video." Given that it's dynamically allocated, how does a VC-2 receiver know what value has been allocated for PT? Section 4.4 has two lists of acceptable Parse Code values. but those sentences end with 'and'. Should that really be 'or', indicating that any of the listed values of allowed? Cheers, Nevil -- -------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From nobody Fri May 11 22:22:27 2018 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 9734012D86F; Fri, 11 May 2018 22:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 05JJtji1oXe9; Fri, 11 May 2018 22:22:17 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 6E64E12D86D; Fri, 11 May 2018 22:22:17 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id o4-v6so7158231wrm.0; Fri, 11 May 2018 22:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=Q9H7Ro52NQHh2ySmN6+Pfi5/DIQSbyP8k5lfwNgB8vY=; b=WcNI+Iar37fqgLANDKCo+TibHE/F+aYX7Za7ITtghALash5SutRH4zze7mXqn8LNbd tmOAOJ/qeg9Sxm0X15guxFv/D5kuzDxhSei+6jbj/c5Lh0MZUQ62GpNusYnVdiUYAv3H sXWDh+MmrOe4gN96l0ckIZR6l5IKKFSqlSD2vP5ggqcDaCNRtpJMJ4RYMbiJRtD7Feq5 APLu9m8+2nbRih16+ZXkzpzQMYhzgjNhGkAG6Q0Ap7e/yvnIaW+K2f0iWgU4l1wunGWf UzLHvgOXFvTw2bHizyGEz4FzISZFh6nYyzpW60e4Wifcu1Hb1MMziWgfJU2d8czI0jCJ C3ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=Q9H7Ro52NQHh2ySmN6+Pfi5/DIQSbyP8k5lfwNgB8vY=; b=D+C1cif89kXSUTaJ1i9um2Gzwau7zIghUC1Yv1FgsUCCEfypWCeDBm9QAingwAnMjA xSkLPDymQBcxcLK3XguFhJ8xENleObtiHWxgLqFPio230JW0ZAOr9L8hWuyRiAI3mn7P 91pDqwQ8UhLo0yeRUADggoUR/e/KoqFph2bEh2aCACUAUcgEMhZNxH1TYODsrwBVsJk0 QxKrcbaCH0R9Ml/esF+2tBgfRPAfP02Z2W4w6J7Zoylw4KxahEotxnOcwfZPQjTSk5M8 60zorJIRlpAs8/Rn8U7baKrKLfqkk4mqzkuhzSVfKDzy8hu9wRUuWvXYKbFuZS6S0JQg rzMA== X-Gm-Message-State: ALKqPwcbzIOSG4ij3d27Yc03heNdW3mk3vozFQInrIAIR7tnVNiPG2Bj mWrLHOBJCuPuswBsWespJdUF9Q== X-Google-Smtp-Source: AB8JxZql+czIvqo8ld2MToE1Ery2K0na9ehE9kX2/E6DVVTZ5BpwwHPrZmEcGAk+zpuy01yMUJIesQ== X-Received: by 2002:adf:b979:: with SMTP id b54-v6mr1166002wrg.265.1526102535826; Fri, 11 May 2018 22:22:15 -0700 (PDT) Received: from RoniPC (bzq-79-177-57-250.red.bezeqint.net. [79.177.57.250]) by smtp.gmail.com with ESMTPSA id m134-v6sm4402008wmg.13.2018.05.11.22.22.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 May 2018 22:22:14 -0700 (PDT) From: "Roni Even" To: "'Nevil Brownlee'" , , , References: <88bea593-3697-9626-4f20-953f8f428f41@auckland.ac.nz> In-Reply-To: <88bea593-3697-9626-4f20-953f8f428f41@auckland.ac.nz> Date: Sat, 12 May 2018 08:19:52 +0300 Message-ID: <02f801d3e9b0$dc018780$94049680$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: he Thread-Index: AQFYyCsWpNYasGf9eD1RsJwTGPgXKKUh0JQQ Archived-At: Subject: Re: [payload] Pos-Dir last call review for draft-ietf-payload-rtp-vc2hq-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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: Sat, 12 May 2018 05:22:20 -0000 Hi, Thanks for the review About section 4.1. The pt number is negotiated in the signaling , for example using SDP see section 6.2. This is how it works for all payload type numbers who are dynamically allocated m=video 30000 RTP/AVP 112 a=rtpmap:112 vc2/90000 a=fmtp:112 profile=HQ;version=3;level=0 the pt = 122 and it is mapped to vc2 Roni Even > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Nevil Brownlee > Sent: Saturday, May 12, 2018 5:55 AM > To: ops-dir@ietf.org; draft-ietf-payload-rtp-vc2hq.all@ietf.org; > payload@ietf.org > Subject: [payload] Pos-Dir last call review for draft-ietf-payload-rtp-vc2hq-05 > > > Reviewer: Nevil Brownlee > Review Result: Ready > > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. > These comments were written with the intent of improving the operational > aspects of the IETF drafts. Comments that are not addressed in last call may be > included in AD reviews during the IESG review. Document editors and WG > chairs should treat these comments just like any other last call comments. > > "This memo describes an RTP Payload format for the High Quality (HQ) > profile of SMPTE Standard ST 2042-1 known as VC-2. This document > describes the transport of HQ Profile VC-2 in RTP packets and has > applications for low-complexity, high-bandwidth streaming of both > lossless and lossy compressed video." > > This draft simply describes in detail the way in which a stream of VC-2 > information must be carried ina stream of RTP packets. It's well-written, with > sufficient detail to allow for inter-operating implementations. > It's Security Considerations are clear. As with all documents of this kind, > operators will need to be sure that the implementations of this kind of RTP > stream do conform to this draft's eventual RFC. > > I noticed a few slightly puzzling things: > > Section 4.1 Payload Type says that the PT is "A dynamically allocated > payload type field that designates the payload as VC-2 coded video." > Given that it's dynamically allocated, how does a VC-2 receiver know > what value has been allocated for PT? > > Section 4.4 has two lists of acceptable Parse Code values. but those > sentences end with 'and'. Should that really be 'or', indicating > that any of the listed values of allowed? > > Cheers, Nevil > > -- > -------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Sun May 13 20:48:53 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A8C12946D; Sun, 13 May 2018 20:48:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: Cc: iesg@ietf.org, payload@ietf.org, draft-ietf-payload-rtp-vc2hq.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152626973155.10254.510935141360676360@ietfa.amsl.com> Date: Sun, 13 May 2018 20:48:51 -0700 Archived-At: Subject: [payload] Secdir last call review of draft-ietf-payload-rtp-vc2hq-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 14 May 2018 03:48:52 -0000 Reviewer: Joseph Salowey Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is the document is ready. The security considerations seem well thought out and are follow the guidelines of RFC7202 for RTP payload definitions. I like the fact that it includes some information on possible implementation pitfalls. Cheers, Joe From nobody Tue May 22 21:32:20 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1261241F3; Tue, 22 May 2018 21:32:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: even.roni@gmail.com, ben@nostrum.com, payload-chairs@ietf.org, payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152704993816.27125.11658127511653755912.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2018 21:32:18 -0700 Archived-At: Subject: [payload] payload - Not having a session at IETF 102 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 04:32:18 -0000 Roni Even, a chair of the payload working group, indicated that the payload working group does not plan to hold a session at IETF 102. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed May 23 03:55:53 2018 Return-Path: X-Original-To: payload@ietf.org Delivered-To: payload@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 871FC126CF9; Wed, 23 May 2018 03:55:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: payload@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152707295152.26880.10791566315733955550@ietfa.amsl.com> Date: Wed, 23 May 2018 03:55:51 -0700 Archived-At: Subject: [payload] I-D Action: draft-ietf-payload-rtp-vc2hq-06.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 23 May 2018 10:55:52 -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 Payloads WG of the IETF. Title : RTP Payload Format for VC-2 HQ Profile Video Author : James P. Weaver Filename : draft-ietf-payload-rtp-vc2hq-06.txt Pages : 21 Date : 2018-05-23 Abstract: This memo describes an RTP Payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1 known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video. The HQ profile of VC-2 is intended for low latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-vc2hq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-vc2hq-06 https://datatracker.ietf.org/doc/html/draft-ietf-payload-rtp-vc2hq-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-vc2hq-06 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 Fri May 25 06:43:19 2018 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 D4A34126D45 for ; Fri, 25 May 2018 06:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 g72wDm8cl1Nz for ; Fri, 25 May 2018 06:43:17 -0700 (PDT) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE92126D05 for ; Fri, 25 May 2018 06:43:16 -0700 (PDT) Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w4PDhFBd025809 for ; Fri, 25 May 2018 14:43:15 +0100 (BST) Received: from BGB01XUD1011.national.core.bbc.co.uk ([10.161.14.9]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0361.001; Fri, 25 May 2018 14:43:14 +0100 From: John Fletcher To: "payload@ietf.org" Thread-Topic: Non-media type parameters in SDP a=fmtp line Thread-Index: AQHT9C5UG5M6Ad5eWEmih+77VAPw0w== Date: Fri, 25 May 2018 13:43:14 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23866.006 x-tm-as-result: No--0.441900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [payload] Non-media type parameters in SDP a=fmtp line X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 25 May 2018 13:43:18 -0000 Is it permissible to include additional parameters, beyond those specified = for the Media Type, in the SDP a=3Dfmtp line?=0A= =0A= Thanks,=0A= John Fletcher=0A= =0A= =0A= From nobody Fri May 25 07:03:29 2018 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 3C1EF126CE8 for ; Fri, 25 May 2018 07:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.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 GsjRPF6sB4YT for ; Fri, 25 May 2018 07:03:27 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 3A611126CB6 for ; Fri, 25 May 2018 07:03:27 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id o78-v6so14990976wmg.0 for ; Fri, 25 May 2018 07:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jUvNPBI9pUy5bxagV1X+iICpunvRGemVi3OUHKmeLyA=; b=k9b/uWXM0DjMVI5PBJN6Es56HW3zA6sP6K7TmN3jIxy1o1ZcawLEk7vALKBPk40+CC YFAStFheDLtH0TaKTmorG7BwBfjgaiscVj08aCKw7RGsENo56kz1bYPIGEbDrIqpuumy mH1i6UIle0dTj0/kw3bab2jcTqc46k6SUW+jHXqQ+oBY2eUZ1EtlPEl16YyOvumGR/lY CQ55wITneD+3XsWODoVCbI91X/BeeSy5ncaNmPGE28rODmJH3L5gIx+gzHLThikYLlIg SLWncbR8oC6R6l6F2CJ/DNH6SArChu14aMPoQR5V6j8EvjnJoiTflrHtrKPo7aG36zLH oUSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jUvNPBI9pUy5bxagV1X+iICpunvRGemVi3OUHKmeLyA=; b=IdCuuSE6eF/G1kvbtVDTuBWqtKMs1fxNtKZJnTe9d9Z/Q+J9mt+H8Ndewy/xACbsIs CTVnwzZ4vEQryIeQWg0oXGqVOfG/6lRpvFIHOdYbCXQO28PmbF5Nof9x9wvWXTqTRW4I YtsFl9vK8IyeEYcBap0Wa6idA6eALEiPpqHRXupEouhW6YKpE9ZxkUaEezpBXhz4KS9r NOYTI3oEeFBmXFxw8x9F7z8EIvjYgAnWTiZaOFbyDG/O6XWWHC7qRunA2jOafU/Vv9Od MGjj7AsDGOD9MiF4PLyGhSDTfSh0uM1Zh2sUDA7DiZJeGPPTA2h38GB1yKUmewmO9sC8 jRdQ== X-Gm-Message-State: ALKqPwfBNt4e8WPThsifbH6i5Qdw1lOFxZCa8f+PY5+3EO7yd8Xp6Azi NHsj1/EgbuV78ryyhMoF45RtCQ== X-Google-Smtp-Source: ADUXVKKBeBTTtQC52CVeWqAwQhMONPvQjt7zVao6JKzRGFBc5r/UejcNKYPA/Xe0HuXK3jhpboIWWg== X-Received: by 2002:a1c:c702:: with SMTP id x2-v6mr2142259wmf.57.1527257005709; Fri, 25 May 2018 07:03:25 -0700 (PDT) Received: from [192.168.1.159] ([85.105.47.236]) by smtp.gmail.com with ESMTPSA id m64-v6sm12744033wmb.12.2018.05.25.07.03.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 May 2018 07:03:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 $3445.6.18$) From: "Ali C. Begen" In-Reply-To: Date: Fri, 25 May 2018 17:03:23 +0300 Cc: "payload@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7865002F-3582-4ED8-AC32-89A123BDDDD9@networked.media> References: To: John Fletcher X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [payload] Non-media type parameters in SDP a=fmtp line X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 25 May 2018 14:03:29 -0000 I think so, but anything the receiver does not understand in SDP will be = ignored. > On May 25, 2018, at 4:43 PM, John Fletcher = wrote: >=20 > Is it permissible to include additional parameters, beyond those = specified for the Media Type, in the SDP a=3Dfmtp line? >=20 > Thanks, > John Fletcher >=20 >=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Fri May 25 08:01:42 2018 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 EF53E12E870 for ; Fri, 25 May 2018 08:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 wkkBJLqaonD6 for ; Fri, 25 May 2018 08:01:38 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0515B127136 for ; Fri, 25 May 2018 08:01:38 -0700 (PDT) Received: from [130.209.157.48] (port=30402 helo=[172.30.192.35]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fMEDj-0007UO-82; Fri, 25 May 2018 16:01:36 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 $3273$) From: Colin Perkins In-Reply-To: <7865002F-3582-4ED8-AC32-89A123BDDDD9@networked.media> Date: Fri, 25 May 2018 16:01:28 +0100 Cc: John Fletcher , "payload@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <921089B6-1571-4B5A-B86C-AC677CA6C679@csperkins.org> References: <7865002F-3582-4ED8-AC32-89A123BDDDD9@networked.media> To: "Ali C. Begen" X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [payload] Non-media type parameters in SDP a=fmtp line X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 25 May 2018 15:01:40 -0000 No-one can stop you putting whatever you like in that line, but the = specification says that the a=3Dfmtp: line carries the media type = parameters only. Colin > On 25 May 2018, at 15:03, Ali C. Begen = wrote: >=20 > I think so, but anything the receiver does not understand in SDP will = be ignored. >=20 >> On May 25, 2018, at 4:43 PM, John Fletcher = wrote: >>=20 >> Is it permissible to include additional parameters, beyond those = specified for the Media Type, in the SDP a=3Dfmtp line? >>=20 >> Thanks, >> John Fletcher --=20 Colin Perkins https://csperkins.org/ From Ralf.Dux@t-systems.com Mon May 28 12:40:40 2018 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 AFA9612DA21 for ; Mon, 28 May 2018 12:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=t-systems.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 o_riq1rg5HFx for ; Mon, 28 May 2018 12:40:37 -0700 (PDT) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 362E512DA69 for ; Mon, 28 May 2018 12:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=t-systems.com; i=@t-systems.com; q=dns/txt; s=mail; t=1527536437; x=1559072437; h=from:to:subject:date:message-id:mime-version; bh=SeGM3rqVgNFxe46r42rikfxOxxtmf6THU4P3DPSkDsc=; b=HA+tyPoaPa4iqDYwVNw7XJalNmWbiLke16yh6gezlY5vVdIwOdP2sHtN aw6jJIzs2N91visweQm5LKcBBrENIy21asyL84aNtavPszjgTQvHGGA82 Jk4/ShOy0JHlVY42HvbFqyvO9xL0LIQ0Rku8LUi2DaTWbFQY74qKdmkO0 fI6W90hppNDuqwmkJeam856QrJ3VhN4AVRcPnAoM6ftiVZuCm4B+AiQ6o gd+IMFthjfG6h3uZdQdZXF3dlYSVmmQNt4jUu0khKMUOLNbSM68ef4rOp FYm+rV2aXq9tn7mArw0j7nwXCDo1RGffsPenfIzGAxmIj1IOGzwXdsZpT g==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 May 2018 21:40:34 +0200 X-IronPort-AV: E=Sophos;i="5.48,405,1517871600"; d="scan'208,217";a="253740280" Received: from he105667.emea1.cds.t-internal.com ([10.169.118.63]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 28 May 2018 21:40:34 +0200 Received: from HE105667.EMEA1.cds.t-internal.com (10.169.118.63) by HE105667.emea1.cds.t-internal.com (10.169.118.63) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 28 May 2018 21:40:33 +0200 Received: from HE105667.EMEA1.cds.t-internal.com ([fe80::fdf1:7b5a:94a8:421a]) by HE105667.emea1.cds.t-internal.com ([fe80::fdf1:7b5a:94a8:421a%26]) with mapi id 15.00.1367.000; Mon, 28 May 2018 21:40:33 +0200 From: To: Thread-Topic: Review Comments for RTP Payload Format for the TETRA Audio Codec Thread-Index: AdP2u75ssD9Xj2elQ3ufCYEY1v5M1g== Date: Mon, 28 May 2018 19:40:33 +0000 Message-ID: <27ac31c683224cbfb995cb2338bc4bd5@HE105667.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.213.67.48] Content-Type: multipart/alternative; boundary="_000_27ac31c683224cbfb995cb2338bc4bd5HE105667emea1cdstintern_" MIME-Version: 1.0 Archived-At: Subject: [payload] Review Comments for RTP Payload Format for the TETRA Audio Codec X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 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, 31 May 2018 14:18:00 -0000 --_000_27ac31c683224cbfb995cb2338bc4bd5HE105667emea1cdstintern_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review Comments for RTP Payload Format for the TETRA Audio Codec draft-ietf-payload-tetra-00 2018-05-23 by Ralf Dux ralf.dux@t-systems.com General Comment: >From my point of view the draft-ietf-payload-tetra-00 document describes th= e payload format and used protocols correctly and completely. With this information a= developer should be able to implement the payload protocol. But one important point needs clarification. If the content of RTP packets are not going to be restricted to one or two = TETRA frames (30ms or 60ms speech content) the meaning of the control bits and the relationship to resulting or origin= ating FSTE/OSTE packets on the E1 line must be described for cases where more than two TETRA records are in an RTP= frame. Review Comments: 4.3.3. CTRL: Control bit(5 bits) Wording line 285: "document" should be added General: Clarification needed for cases where more than two TETRA frames ar= e in the RTP packet. 285 NOTE: The meaning of C4 and C5 is outside the scope of the present d= ocument 286 287 4.3.4. C bit: Failed Crypto operation indication 5. Payload example Wording line 358: "of" should be replaced by "the" 356 The following example shows how a first and a consecutive 30 ms fram= e 357 is combined into a single 60ms RTP packet. Note: This example shows 358 the usage of OSTE mapping. 359 360 0 1 2 3 6. Congestion Control Considerations Clarification needed line 415: What is acceptable and what shall be done if= the current loss rate is not?? 414 used is: users of this payload format MUST monitor packet loss to 415 ensure that the packet loss rate is within acceptable parameters. 416 417 7. Payload Format Parameters 7.1. Media Type Definition Line 455: Clarification needed for cases where more than two TETRA frames a= re in the RTP packet. 454 size. If this parameter is not present, the sender MAY 455 encapsulate any number of speech frames into one RTP packet. 456 ptime: 457 see RFC 4566 [RFC4566]. 8.1. Offer/Answer Considerations Line 535: Clarification needed for cases where more than two TETRA frames a= re in the RTP packet. o Integer multiples of 30ms SHALL be used for ptime. It is recommended to use packet size of 60ms. Even if there is no good reason why not doing so, there is no need that ptime and maxptime parameters are negotiated symmetrically. Kind regards Ralf Dux DEUTSCHE TELEKOM HEALTHCARE AND SECURITY SOLUTIONS GMBH Ralf Dux System Engineer Security Hausanschrift: =DCberseering 2, 22297 Hamburg Postanschrift: 22297 Hamburg mailto: Ralf.Dux@t-systems.com www.t-systems.de/dths DEUTSCHE TELEKOM HEALTHCARE AND SECURITY SOLUTIONS GMBH Gesch=E4ftsf=FChrung: Peter B=F6ttcher, Holger Lesch, Arndt Lorenz Handelsregister: Amtsgericht Bonn HRB 20695 Sitz der Gesellschaft: Bonn WEEE-Reg.-Nr. DE50335567 GROSSE VER=C4NDERUNGEN FANGEN KLEIN AN - RESSOURCEN SCHONEN UND NICHT JEDE = E-MAIL DRUCKEN. Hinweis: Diese E-Mail und/oder die Anh=E4nge sind vertraulich und ausschlie= =DFlich f=FCr den bezeichneten Adressaten bestimmt. Die Weitergabe oder Kop= ieren dieser E-Mail ist strengstens verboten. Wenn Sie diese E-Mail irrt=FC= mlich erhalten haben, informieren Sie bitte unverz=FCglich den Absender und= vernichten Sie die Nachricht und alle Anh=E4nge. Vielen Dank --_000_27ac31c683224cbfb995cb2338bc4bd5HE105667emea1cdstintern_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Review Comments for

RTP= Payload Format for the TETRA Audio Codec

&nbs= p; draft-ietf-payload= -tetra-00

2018-05-23 by

Ralf Dux

ralf.dux@t-systems.com

General Comment:

From my point of view the draft-ietf-payload-tetra-00 document describ= es the payload

format and used protocols correctly and completely. With this informat= ion a developer

should be able to implement the payload protocol.

But one important point needs clarification.

If the content of RTP packets are not going to be restricted to one or= two TETRA frames (30ms or 60ms speech content)

the meaning of the control bits and the relationship to resulting or o= riginating FSTE/OSTE packets on the E1 line

must be described for cases where more than two TETRA records are in a= n RTP frame.

Review Comments:

4.3.3. CTRL: Control bit(5 bits)

Wording line 285: "document" should be added

General: Clarification needed for cases where more than two TETRA fram= es are in the RTP packet.

285 NOTE: The meaning of C4 and C5 is outside the sc= ope of the present document

286

287 4.3.4. C bit: Failed Crypto operation indication

5. Payload example

Wording line 358: "of" should be replaced by "the"=

356 The following example shows how a first and a co= nsecutive 30 ms frame

357 is combined into a single 60ms RTP packet. = Note: This example shows

358 the usage of OSTE mapping.

359

360 0 = ; &n= bsp; 1 &nb= sp; 2 &nbs= p; = 3

6. Congestion Control Considerations

Clarification needed line 415: What is acceptable and what shall be do= ne if the current loss rate is not??

414 used is: users of this payload format MUST monit= or packet loss to

415 ensure that the packet loss rate is within accep= table parameters.

416

417 7. Payload Format Parameters

7.1. Media Type Definition

Line 455: Clarification needed for cases where more than two TETRA fra= mes are in the RTP packet.

454 size. If this parameter = is not present, the sender MAY

455 encapsulate any number of spee= ch frames into one RTP packet.

456 ptime:

457 see RFC 4566 [RFC4566].

8.1. Offer/Answer Considerations

Line 535: Clarification needed for cases where more than two TETRA fra= mes are in the RTP packet.

o Integer multiples of 30ms SHALL be used for ptime= . It is

recommended to use packet size of 60ms.= Even if there is no good

reason why not doing so, there is no ne= ed that ptime and maxptime

parameters are negotiated symmetrically= .

Kind regards

Ralf Dux

DEUTSC= HE TELEKOM HEALTHCARE AND SECURITY SOLUTIONS GMBH

Ralf D= ux

System= Engineer

Securi= ty

Hausan= schrift: =DCberseering 2, 22297 Hamburg

Postan= schrift: 22297 Hamburg

mailto= : Ralf.Dux@t-systems.com

www.t-systems= .de/dths

DEUTSCHE TELEKOM HEALTHCARE AND SECURITY SOLUTIONS GMBH
Gesch=E4ftsf=FChrung: Peter B=F6ttcher, Holger Lesch, Arndt Lorenz

Handelsregister: Amtsgericht Bonn HRB 20695
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr. DE50335567

GROSSE VER=C4NDERUNGEN FANGEN KLEIN AN – RESSOURCEN SCH= ONEN UND NICHT JEDE E-MAIL DRUCKEN.

Hinweis: Diese E-Mail und/oder die Anh=E4nge sind vertraulich un= d ausschlie=DFlich f=FCr den bezeichneten Adressaten bestimmt. Die Weiterga= be oder Kopieren dieser E-Mail ist strengstens verboten. Wenn Sie diese E-Mail irrt=FCmlich erhalten haben, informieren Si= e bitte unverz=FCglich den Absender und vernichten Sie die Nachricht und al= le Anh=E4nge. Vielen Dank

--_000_27ac31c683224cbfb995cb2338bc4bd5HE105667emea1cdstintern_--