draft-barbato-avt-rtp-theora-01.txt

mediastreamer2是开源的网络传输媒体流的库

6.1.  Mapping MIME Parameters into SDP

   The information carried in the MIME media type specification has a
   specific mapping to fields in the Session Description Protocol (SDP)
   [6], which is commonly used to describe RTP sessions.  When SDP is



Barbato                 Expires December 18, 2006              [Page 19]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


   used to specify sessions the mapping are as follows:

   o  The MIME type ("video") goes in SDP "m=" as the media name.

   o  The MIME subtype ("theora") goes in SDP "a=rtpmap" as the encoding
      name.

   o  The clock rate in the "a=rtpmap" line MUST be 90000

   o  The mandated parameters "delivery-method" and "configuration" MUST
      be included in the SDP "a=fmpt" attribute.

   o  The optional parameter "configuration-uri", when present, MUST be
      included in the SDP "a=fmpt" attribute and MUST follow the
      delivery-method that applies.

   If the stream uses multiple decoder setup configurations and all of
   them are known in advance, the Configuration Packet for each file
   SHOULD be packaged together and passed to the client using the
   configuration attribute.

   The URI specified in the configuration-uri attribute MUST point to a
   location where all of the Configuration Packets needed for the life
   of the session reside.

6.1.1.  SDP Example

   The following example shows a basic SDP for a single stream.  The
   first configuration packet is inlined in the sdp, other
   configurations could be fetched at any time from the first provided
   uri using or all the known configuration could be downloaded using
   the second uri.  The inline base16 [11] configuration string is
   omitted because of the lenght.
      c=IN IP4 192.0.0.1
      m=video RTP/AVP 98
      a=rtpmap:98 theora/90000
      a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720; delivery-
      method=inline; configuration=base16string1; delivery-
      method=out_band/rtsp; delivery-method=out_band/rtsp;
      configuration-uri=rtsp://path/to/resource/; delivery-
      method=out_band/http; configuration-uri=http://another/path/to/
      resource/aggregate.bz2!sha1hash;

6.2.  Usage with the SDP Offer/Answer Model

   The offer, as described in An Offer/Answer Model Session Description
   Protocol [5], may contain a large number of delivery methods per
   single fmtp attribute, the answerer MUST remove every delivery-method



Barbato                 Expires December 18, 2006              [Page 20]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


   and configuration-uri not supported.  All the parameters MUST not be
   altered on answer otherwise.


7.  Examples

   The following examples are common usage patterns that MAY be applied
   in such situations, the main scope of this section is to explain
   better usage of the transmission vectors.

7.1.  Stream Video

   This is one of the most common situation: one single server streaming
   content in multicast, the clients may start a session at random time.
   The content itself could be a mix of live stream, as the wj's voice
   or studio scenes, and stored streams, as the music she plays.

   In this situation we don't know in advance how many codebooks we will
   use.  The clients can join anytime and users expect to start the
   fruition of the content in a short time.

   On join the client will receive the current Configuration necessary
   to decode the current streams inlined in the SDP so that the decoding
   will start immediately after.

   When the streamed content changes the new Configuration is sent in-
   band before the actual stream, and the Configuration that has to be
   sent inline in the SDP updated.  Since the inline method is
   unreliable, an out of band fallback is provided.

   The client could choose to fetch the Configuration from the alternate
   source as soon it discovers a Configuration packet got lost inline or
   use selective retransmission [17], if the server supports the
   feature.

   A serverside optimization would be to keep an hash list of the
   Configurations per session to avoid packing all of them and send the
   same Configuration with different Ident tags

   A clientside optimization would be to keep a tag list of the
   Configurations per session and don't process configuration packets
   already known.


8.  Security Considerations

   RTP packets using this payload format are subject to the security
   considerations discussed in the RTP specification [3].  This implies



Barbato                 Expires December 18, 2006              [Page 21]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


   that the confidentiality of the media stream is achieved by using
   encryption.  Because the data compression used with this payload
   format is applied end-to-end, encryption may be performed on the
   compressed data.  Where the size of a data block is set care MUST be
   taken to prevent buffer overflows in the client applications.


9.  Acknowledgments

   This document is a continuation of draft-kerr-avt-theora-rtp-00.txt

   Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph
   Giles, Mike Smith, Phil Kerr, Timothy Terriberry, Stefan Ehmann,
   Alessandro Salvatori, Politecnico di Torino (LS)^3/IMG Group in
   particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini,
   Juan Carlos De Martin.


10.  References

10.1.  Normative References

   [1]   Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
         RFC 3533.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119.

   [3]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for real-time applications",
         RFC 3550.

   [4]   Schulzrinne, H. and S. Casner, "RTP Profile for video and Video
         Conferences with Minimal Control.", RFC 3551.

   [5]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264.

   [6]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327.

   [7]   Mogul et al., J., "Path MTU Discovery", RFC 1063.

   [8]   McCann et al., J., "Path MTU Discovery for IP version 6",
         RFC 1981.

   [9]   Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
         "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",



Barbato                 Expires December 18, 2006              [Page 22]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


         Internet Draft (draft-ietf-avt-rtcp-feedback-11: Work in
         progress).

   [10]  Barbato, L., "RTP Payload Format for Vorbis Encoded Audio -
         draft-ietf-avt-vorbis-rtp-00", Internet Draft (Work in
         progress).

   [11]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
         RFC 3548.

   [12]  Deutsch, P., "GZIP file format specification version 4.3",
         RFC 1952.

   [13]  National Institute of Standards and Technology, "Secure Hash
         Standard", May 1993.

   [14]  Seward, J., "libbz2 and bzip2".

10.2.  Informative References

   [15]  "libTheora: Available from the Xiph website,
         http://www.xiph.org".

   [16]  "Theora I specification:  Codec setup and packet decode.
         http://www.xiph.org/theora/doc/Theora_I_spec.pdf".

   [17]  Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
         Extended Reports (RTCP XR)", RFC 3611, November 2003.

   [18]  "ITU-T Recommendation V.42, 1994, Rev. 1. Error-correcting
         Procedures for DCEs Using Asynchronous-to-Synchronous
         Conversion. International Telecommunications Union. Available
         from the ITU website, http://www.itu.int".

   [19]  "ISO 3309, October 1984, 3rd Edition. Information Processing
         Systems--Data Communication High-Level Data Link Control
         Procedure--Frame Structure. International Organization for
         Standardization.".













Barbato                 Expires December 18, 2006              [Page 23]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


Author's Address

   Luca Barbato
   Xiph.Org

   Email: [e-mail]
   URI:   http://www.xiph.org/












































Barbato                 Expires December 18, 2006              [Page 24]

Internet-Draft       draft-barbato-avt-rtp-theora-01           June 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Barbato                 Expires December 18, 2006              [Page 25]