<?xml version='1.0'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rtph264 SYSTEM 
      'reference.RFC.3984.xml'>
    <!ENTITY rfc2119 SYSTEM 
      'reference.RFC.2119.xml'>
    <!ENTITY rtp SYSTEM 
      'reference.RFC.3550.xml'>
    <!ENTITY rtpsvc SYSTEM 
      'reference.I-D.ietf-avt-rtp-svc.xml'>
    <!ENTITY sdp SYSTEM 
      'reference.RFC.4566.xml'>
    <!ENTITY offeranswer SYSTEM 
      'reference.RFC.3264.xml'>
    <!ENTITY sdpssrc SYSTEM 
      'reference.I-D.lennox-mmusic-sdp-source-attributes.xml'>
]>

<?rfc toc="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>

<rfc category='std' ipr='full3978'
docName='draft-lennox-avt-h264-source-fmtp-00' updates='3984'>
    <front>
        <title abbrev='H.264 Source-Specific Format Parameters'>
		Source-Specific Media Format Parameters for H.264 and H.264 SVC
        </title>

        <author initials='J.' surname='Lennox'
                fullname='Jonathan Lennox'>
            <organization abbrev='Vidyo'>
               Vidyo, Inc.
            </organization>
            <address>
               <postal>
                   <street>433 Hackensack Avenue</street>
                   <street>Sixth Floor</street>
                   <city>Hackensack</city> <region>NJ</region>
                   <code>07601</code>
                   <country>US</country>
               </postal>
               <email>jonathan@vidyo.com</email>
            </address>
        </author>

        <date />
        <area>RAI</area>
        <workgroup>AVT</workgroup>

        <keyword>I-D</keyword>
        <keyword>Internet-Draft</keyword>
		<!-- TODO: more keywords -->

        <abstract>
		<t>When used in the Session Description Protocol Offer/Answer
		  model, several of the media format parameters for the H.264 video
		  format, and for its Scalabile Video Codec (SVC) extension,
		  describe characterics of the stream an endpoint is prepared
		  to send, not of streams it is prepared to receive.  If an
		  endpoint wishes to send multiple streams, these parameters
		  may be incompatible.  This document defines how such media
		  format parameters may be given on a per-source basis, using
		  SDP source-specific fmtp attributes.</t>
        </abstract>

    </front>

<middle>

<section title='Introduction' anchor='introduction'>

<t>Unlike many media packetization formats for
the <xref target='RFC3550'>Real-Time Transport Protocol (RTP)</xref>,
the the RTP packetization specifications
for <xref target='RFC3984'>H.264</xref> and
for <xref target='I-D.ietf-avt-rtp-svc'>H.264's
Scalable Video Coding extension</xref> define a number of MIME media type
parameters that, when
encoded in <xref target='RFC4566'>SDP</xref>, define characteristics of
the media stream an endpoint is prepared to send, not of the streams it
is prepared to receive.  Most notably, streams' parameter sets
(initial data required to correctly initialize a decoder) are encoded
in SDP messages and sent out-of-band, to ensure that they are
reliably received by a decoder before decoding begins.</t>

<t>Because RTP is fundamentally a group communication protocol,
however, an RTP session may contain many different media streams.  In
this case, different H.264 and H.264 SVC streams in an RTP session may
need to be described by different and incompatible values for these
MIME media type parameters.  For example, an endpoint may be switching
between video streams encoded by separate video encoders.  In this
case, it is not possible, using only the mechanisms of
<xref target='RFC3984' />, to describe all the sources and to send
their parameter sets out-of-band.  An endpoint must instead fall back
to sending parameter sets in-band, and retransmitting them with high
enough frequency that there is a reasonably high likelihood of their
being receceived successfully.</t>

<t>To solve this difficulty, this document uses the framework
introduced by <xref target='I-D.lennox-mmusic-sdp-source-attributes' />
to describe MIME media format parameters of individual H.264 sources in
SDP.  This enables all the benefits of out-of-band H.264 source
description in the case when multiple H.264 sources will be sent in an
RTP session.</t>

</section>

<section title='Terminology'>

<t>The key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" in this document
are to be interpreted as described in <xref
target='RFC2119'>RFC 2119</xref> and indicate requirement levels for
compliant implementations.</t>

</section>

<section title='Overview' anchor='overview'>

<t>When used with the <xref target='RFC4566'>SDP</xref>
<xref target='RFC3264'>offer/answer model</xref>, several of the media
format parameters of <xref target='RFC3984'>H.264</xref>
and <xref target='I-D.ietf-avt-rtp-svc'>H.264 SVC</xref> define
characteristics of an RTP stream (media source) to be sent, not of a
session receiver's capabilities.  When multiple media sources are in
use, it is sometimes useful to describe source characteristics
individually for each source.</t>

<t>Per-source media format parameters are defined using the
<xref target='I-D.lennox-mmusic-sdp-source-attributes'>fmtp source
parameter</xref>.  This document updates the MIME type registration of
video/H264 in <xref target='RFC3984' /> and of video/H264-SVC
in <xref target='I-D.ietf-avt-rtp-svc' /> to specify the encoding of
the MIME media format parameters into the fmtp source attribute.</t>

</section>

<section title='Mapping of MIME parameters to SDP source attributes'>

<t>H.264 MIME media format parmaeters applicable to a specific source
are are encoded into an "fmtp" source attribute for the H.264 payload
type and the source being described.  These parameters are expressed
in the form of a semicolon-separated list of parameter=value pairs,
the same syntax as the media-level fmtp value.   For the purposes of
discussion in this document, MIME media format parameters encoded into a
source-specific fmtp attribute are called "source-specific
parameters", while MIME media format parameters encoded into a
media-level format attribute are called "media parameters".</t>

<t>Source-specific parameters only describe characteristics of a
specific source might send, while media parameters describe all
sources of a stream.  Source-specific parameters do not override media
parameters, though they do in some cases further constrain them or
provide additional information.</t>

<section title='Parameter Sets'>

<t>The "sprop-parameter-sets" parameter encodes H.264 sequence parameter
set (SPS) and picture parameter set (PPS) Network Adaptation Layer
NAL) units.  These parameter sets provide essential information
necessary to decode an H.264 bitstream; encoding them in SDP ensures
that they are delivered reliably.</t>

<t>The "sprop-parameter-sets" parameter MAY be encoded as a source
parameter.  However, if the sprop-parameter-sets parameter is also
present as a media parameter, the H.264 parameter sets described for
each source MUST include all the H.264 parameter set described for the
media.</t>

<t>In an SDP answer, the "sprop-parameter-sets" for a source MUST follow
the same constraints as for the media.  I.e., the parameter sets for a
source described in an answer MUST be a superset of the parameter
sets for the media in the offer, and if an offer indicates
"parameter-add=0" (false) for the media, the corresponding answer MUST
NOT add additonal parameter sets for any source.</t>

</section>

<section title='Packetization Mode 2 Parameters'>

<t>The "sprop-deint-buf-req", "sprop-interleaving-depth",
"sprop-max-don-diff", and "sprop-init-buf-time" parameters describe
characteristics of H.264 media streams using packetization mode 2
(interleaved mode).  According to <xref target='RFC3984' />, the first
two are mandatory for packetization mode 2 streams; the other two
are optional.  They specify the maximum size and time of the
debuffering needed to deinterleave streams sent in interleaved mode.</t> 

<t>These parameters MAY be included as source parameters, overriding
any corresponding values at the media level for the source.  However,
if they are, they MUST be less than or equal to the value specified
for the parameter (if any) at the media level.  All constraints for
these values specified by <xref target='RFC3984' /> still apply.</t>

</section>

<section title='Capability Parameters'>

<t>As defined in <xref target='RFC3984' />, the meaning of the
capability parameters ("max-mbps", "max-fs", "max-cpb", "max-dpb",
"max-br", "redundant-pic-cap", and "max-rcmd-nalu-size") at the media
level depends on a media stream's "direction" attribute.  When the
"direction" attribute is "sendonly", then the parameters describe the
limits of media sources that the sender is capable of producing.  When
the "direction" attribute is "sendrecv" or "recvonly", then the
parameters describe the limitations of what the receiver accepts.</t>

<t>When encoded as source parameters, these parameters always describe
the limits of the source being described.  In media streams whose
"direction" is "sendonly", these parameters MUST be less than or equal
to the values (if any) in the media parameters.  In media streams
whose "direction" is "sendrecv", source parameters for these values
are unconstrained by stream's media parameters (which describe what
the endpoint is willing to receive).  However, in offer/answer mode,
the values of these source parameters MUST be less than or equal to
the values given in media parameters in the most recent (accepted)
offer or answer for the stream.</t>

<t>(Media streams whose "direction" is "recvonly" do not encode any
sources.)</t>

</section>

<section title='H264 SVC Parameters'>

<t>The H.264 SVC parameters "sprop-scalability-info" and
"sprop-layer-ids" are defined in <xref target='I-D.ietf-avt-rtp-svc' />.
They describe the scalability structure of an H.264 Scalable Video
Codec stream.</t>

<t>These parameters MUST NOT be given both as source parameters and
media parameters.  They MUST be specified at one level at most.</t>

</section>

<section title='Other Parameters'>

<t>The parameters "profile-level-id", "packetization-mode", and
"parameter-add" MUST NOT be used as a source parameters.</t>

</section>

</section>

<section anchor="examples" title='Examples'>

<t>This section gives examples of SDP descriptions of media
sessions containing H.264 source parameters.  For brevity, only the media
sections of the descriptions are given.</t>

<figure anchor="simple_example" title="Example: declaration of two
sources with different parameter sets">
<artwork>
m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1
a=ssrc:12345 cname:cif-stream@example.com
a=ssrc:12345 fmtp:96 sprop-parameter-sets=J0LgDZWWFglk,KM4Ecg==
a=ssrc:67890 cname:vga-stream@example.com
a=ssrc:67890 fmtp:96 sprop-parameter-sets=J0LgDZWWCgPZ,KM4Ecg==
</artwork>
</figure>

<t>The example in <xref target='simple_example' /> shows two H.264
streams with different, incompatbile parameter sets.   (Specifically,
the two streams encode different image sizes.)</t>

<t>(TODO: add more examples.)</t>

</section>

<section title='Backward Compatibility' anchor='backward'>

<t>Unless a sender knows via some mechanism (not specified here or in
<xref target='I-D.lennox-mmusic-sdp-source-attributes' />) that a receiver
definitely understands source parameters, it MUST send any parameter
sets specified in sprop-parameter-sets source attributes in-band in
the media stream as well.  These parameter sets SHOULD be transmitted
frequently enough that a receiver has a high probability of receiving
them even in the presence of packet loss.</t>

<t>For H.264 SVC streams, the scalability information Supplemental
Encoder Information (SEI) message encoded in an sprop-scalability-info
parameter set SHOULD be similarly transmitted in-band as well.</t>

</section>

<section title='Security Considerations' anchor='security'>

<t>Source-specific encoding of media format parameters does not add
any additional security considerations beyond those of
<xref target='RFC3984' /> and <xref target='I-D.ietf-avt-rtp-svc' />.</t>

</section>

<section title='IANA Considerations' anchor='iana'>

<t>This document updates the SDP encoding of the video/H264 MIME media
type specified in <xref target='RFC3984' />, and of the video/H264-SVC
MIME media type specified in <xref target='I-D.ietf-avt-rtp-svc' />.</t>

</section>

</middle>

<back>

<references title='Normative References'>

&rfc2119;

&sdp;

&sdpssrc;

&offeranswer;

&rtph264;

&rtpsvc;

&rtp;

</references>

<!-- <references title='Informative References'>

</references> -->

<!-- <section title='Open issues'>

<t><list style='symbols'>
<t></t>

</list></t>

</section> -->


<!--
 <section title='Changes From Earlier Versions'>

<t>Note to the RFC-Editor: please remove this section prior to publication
as an RFC.</t>

<section title='Changes From Draft -00'>

<t><list style='symbols'>

<t>.</t>

</list></t>

</section>

</section>

-->

</back>

</rfc>
