<?xml version="1.0" encoding="utf-8"?>
<!-- 
     draft-rfcxml-general-template-standard-00
  
     This template includes examples of the most commonly used features of RFCXML with comments 
     explaining how to customise them. This template can be quickly turned into an I-D by editing 
     the examples provided. Look for [REPLACE], [REPLACE/DELETE], [CHECK] and edit accordingly.
     Note - 'DELETE' means delete the element or attribute, not just the contents.
     
     Documentation is at https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="info"
  docName="draft-majali-avtcore-rtcp-fb-timing-cfg-00"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">
<!-- [REPLACE] 
       * docName with name of your draft
     [CHECK] 
       * category should be one of std, bcp, info, exp, historic
       * ipr should be one of trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
       * updates can be an RFC number as NNNN
       * obsoletes can be an RFC number as NNNN 
-->

  <front>
    <title abbrev="RTCP feedback Message Timing Config">RTCP feedback Message Timing Configuration</title>
    <!--  [REPLACE/DELETE] abbrev. The abbreviated title is required if the full title is longer than 39 characters -->

    <seriesInfo name="INTERNET-DRAFT" value="draft-majali-avtcore-rtcp-fb-timing-cfg-00"/>
   
    <author fullname="Shridhar Majali" initials="S" surname="Majali">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <organization>Nvidia</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>2788 San Tomas Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95051</code>
          <country>United States of America</country>
          <!-- Uses two letter country code -->
        </postal>        
        <phone></phone>
        <email>smajali@nvidia.com</email>  
        <!-- Can have more than one <email> element -->
      </address>
    </author>
   
    <date year="2024"/>
    <!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not the current one, it is necessary to specify at least a month and day="1" will be used.
    -->

    <area>General</area>
    <workgroup>AVTCORE Working Group</workgroup>
    <!-- "Internet Engineering Task Force" is fine for individual submissions.  If this element is 
          not present, the default is "Network Working Group", which is used by the RFC Editor as 
          a nod to the history of the RFC Series. -->

    <keyword>RTCP</keyword>
    <!-- [REPLACE/DELETE]. Multiple allowed.  Keywords are incorporated into HTML output files for 
         use by search engines. -->

    <abstract>
      <t>This specification describes configuring the Real-time Transport Control Protocol (RTCP) message feedback send time.</t>
    </abstract>
 
  </front>

  <middle>
    
    <section>
      <name>Introduction</name>
      <t>This document proposes controlling specific RTCP message feedback send time. This proposal help sender negotiate RTCP feedback send time, better flexibility in defining application behavior. This document defines a new Session Description Protocol (SDP) parameter to negotiate the timing configuration.</t>
      
      <section>
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
          RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
          interpreted as described in BCP 14 <xref target="RFC2119"/>
          <xref target="RFC8174"/> when, and only when, they appear in
          all capitals, as shown here.</t>
      </section>
      <!-- [CHECK] The 'Requirements Language' section is optional -->

    </section>
    
    <section>
      <name>SDP Definitions</name>
      <t>This section defines optional SDP parameters that are used to negotiate RTCP feedback message send time. Time defined is applicable to specific RTCP feedback message only.</t>
      
      <t>An OPTIONAL RTCP feedback specific parameter, "fb-min-time", indicates the minimum period T_fb_min_time in milliseconds between two same RTCP feedback or wait time before sending feedback message.</t>
      
      <t>The syntax is as follows:</t>
      
      <t>a=rtcp-fb:&lt;rtcp-fb-pt&gt; &lt;rtcp-fb-param&gt;;fb-min-time=&lt;fb-min-time-val&gt;</t>

      <t>where above parameters are explained in <xref target="RFC4585" sectionFormat="of" section="4"/></t>


      <dl newline="false" spacing="normal" indent="24">
        <!-- Omit newline="true" if you want each definition to start on the same line as the corresponding term -->
        <dt>rtcp-fb-pt</dt>
        <dd>= /fmt  ; as defined in SDP</dd>

        <dt>rtcp-fb-param</dt>
        <dd>=  SP "app" [SP byte-string]</dd>
        <dt></dt>
        <dd>/ SP token [SP byte-string]</dd>
        <dt></dt>
        <dd>/ ; empty</dd>

        <dt>fb-min-time-val</dt>
        <dd>= feedback message minimum time value in milliseconds</dd>        
      </dl>

      <t>“fb-min-time” may have an OPTIONAL parameter “sync-counter”, indicates synchronization counter SYNC-CONTER helps synchronize RTCP feedback with RTP timestamp change.</t>
      <t>If T0 is start of time, receiver keeps count of change in RTP timestamp as COUNT. Once COUNT is equal to parameter SYNC-CONTER or time elapsed is greater than or equal to T_fb_min_time, receiver sends the RTCP feedback. Receiver resets the counter and time, to determine when the next feedback is to be sent.</t>

      <section>
        <name>SDP description for RTCP feedback timing configuration</name>
        <ul>
          <li>
            <t>Payload specific RTCP feedback PLI (Picture Loss Indication) with minimum interval of 50 milliseconds. Configuration can be used by the receiver to trigger PLI when no decodable unit is available to decode for 50ms.</t>
            <t>a=rtcp-fb:96 nack pli;fb-min-time=50</t>
          </li>

          <li>
            <t>RTCP feedback Generic NACK with minimum time of 1 milliseconds. Receiver to wait for 1 milliseconds before NACK RTCP feedback message is sent on packet loss.</t>
            <t>a=rtcp-fb:96 nack;fb-min-time=1</t>
          </li>

          <li>
            <t>RTCP feedback transport-cc with minimum time of 50 milliseconds and synchronization counter set to 3. Receiver to send transport-cc feedback on every 3rd change in RTP timestamp change or 50 milliseconds elapsed, whichever happens earliest.</t>
            <t>a=rtcp-fb:96 transport-cc ;fb-min-time=50;sync-counter=3</t>
          </li>
        </ul>
      </section>

    </section>   
    
    <section anchor="IANA">
    <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>
      <t>An OPTIONAL parameters, "fb-min-time", “sync-counter” are defined.  See Section 3 for details.</t>
    </section>
    
    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP <xref target="RFC3550" sectionFormat="of" section="9"/></t>
    </section>
    
    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <!-- The recommended and simplest way to include a well known reference -->
      </references>
    </references>
    
 </back>
</rfc>
