MMUSIC WG N. Ismail Internet-Draft J. Restrick Expires: March 31, 2004 Cisco Systems, Inc. Oct 2003 SDP General Purpose Media Descriptors for H.261 and H.263 draft-nismail-mmusic-sdp-video-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines new SDP parameters using general purpose media descriptors to describe video codecs used in interactive multimedia applications. Currently this document covers H.261 and H.263 but more codecs are expected to leverage the SDP syntax defined by this document. These parameters aid in negotiating parameters for video sessions. Examples of using the SDP video syntax to setup a video call using the SDP offer answer model are included. Ismail & Restrick Expires March 31, 2004 [Page 1] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. SDP syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 The Video Format gpmd Parameter . . . . . . . . . . . . . . . 4 4.2 Custom picture clock gpmd parameter . . . . . . . . . . . . . 5 4.3 H.261 annex gpmd parameter . . . . . . . . . . . . . . . . . . 5 4.4 H.263 simple annex gpmd parameter . . . . . . . . . . . . . . 6 4.5 H.263 parameterized annex parameters . . . . . . . . . . . . . 7 5. Support in SDP offer answer . . . . . . . . . . . . . . . . . 7 5.1 Video format gpmd parameter . . . . . . . . . . . . . . . . . 7 5.2 Custom clock picture gpmd parameter . . . . . . . . . . . . . 8 5.3 simple261Annex gpmd parameter . . . . . . . . . . . . . . . . 9 5.4 simple263Annex gpmd parameter . . . . . . . . . . . . . . . . 9 5.5 h263AnnexD gpmd parameter . . . . . . . . . . . . . . . . . . 9 5.6 h263AnnexK gpmd parameter . . . . . . . . . . . . . . . . . . 9 5.7 h263AnnexL gpmd parameter . . . . . . . . . . . . . . . . . . 9 5.8 h263AnnexN gpmd parameter . . . . . . . . . . . . . . . . . . 9 5.9 h263AnnexO gpmd parameter . . . . . . . . . . . . . . . . . . 9 6. ABNF grammar for gpmd video parameters . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 A. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Ismail & Restrick Expires March 31, 2004 [Page 2] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 1. Conventions 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 [1]. 2. Introduction IP-based real time interactive communication in the form of IP telephony and audio conferencing are already in common use. As the industry moves forward video is being used more frequently. IETF protocols such as SIP [2] are used by these applications to initiate media sessions. SDP [3] is the IETF's chosen mechanism through which media sessions are described. SDP already has the flexibility to describe multiple media lines per session, one or more of which can be video. SDP in conjunction with the RTP audiovisual profile [4] and the SDP offer answer mechanism [5] provide enough syntax and semantics for negotiating the video encoding types (video codecs) and the network transport information between the sender and receiver. This is sufficient to provide basic video sessions where senders and receivers limit themselves to the use of default video options that are commonly supported. However to support extra video options applications need to negotiate more video parameters between the sender and the receiver. Some of these parameters are generic and apply to several codecs commonly used in interactive real time video communication such as H.261, H.263 and H.264. Other parameters are specific to a particular video codec. This document defines new gpmd [6] parameters. Examples of using these parameters and the video attributes in the SDP offer answer model are given. As with the SDP specification, the syntax is described in an augmented Backus-Naur form (ABNF) described in detail in [7]. 3. Requirements 1- It must be possible for applications to associate multiple standard video picture formats with each of the H.263 and H.261 video encodings included in the video media line. 2- It must be possible for applications to associate custom picture formats with H.263 video encodings. 3- It must be possible for applications to associate the Minimum Picture Interval with each pair of video encoding and video picture format. 4- It should be possible for applications to associate a maximum sustainable video bitrate with each pair of video encoding and video picture format. Ismail & Restrick Expires March 31, 2004 [Page 3] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 5- It must be possible for applications to declare support for H.261 and H.263 annexes. It should be possible for applications to declare this per video picture format. 4. SDP syntax 4.1 The Video Format gpmd Parameter This section defines a new gpmd parameter called Video Format ("vf"). It is a bilateral parameter used to detail support for a given video picture format and its associated minimum picture interval and maximum bitrate. No SDP attributes or parameters are currently defined to specify video picture formats or minimum picture interval. SDP has a media line bandwidth attribute. SDP also has a frame rate attribute which is similar in purpose to MPI. However these attributes are associated with a media line rather than a specific encoding and a specific video picture format. The Video Format (vf) parameter has the following syntax: vf=id/format/mpi/bitrate Editor Note: Formal BNF specifications will be added later Where: - id is a two digit sequence number that uniquely identify this video format within the SDP session. - format is the video picture format For H.261 payload types the valid values are: QCIF | CIF For H.263 payload types the valid values are: X:Y | SQCIF | QCIF | CIF | 4CIF | 16CIF Where X and Y are a 4 digit number each that define the maximum custom picture resolution. The X and Y values should follow the rules defined in the H.263 standard. - mpi is a 1 digit number that has a value between 1 and 4 representing the minimum picture interval. When using the default 29.97 picture clock value an mpi value of 1 specifies a maximum of 30 Ismail & Restrick Expires March 31, 2004 [Page 4] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 frames per second whereas a value of 2 specifies a maximum of 15 frames per second. - bitrate is a number that specifies the maximum sustainable video bitrate in kbps. This number does not include any protocol overhead. Open Issue: Should the H261 and H263 RTP headers be excluded or included?. Each gpmd attribute can have multiple "vf" parameters. This defines the ability to support each of the included video formats when using the specified video encoding. The below SDP syntax specifies the ability to support the H.263 codec with QCIF format at 30 frames per second at up to 320 kbps as well as with CIF format at 15 frames per second at up to 320 kbps. m=video 4002 RTP/AVP 98 a=rtpmap:98 H263/90000 a=gpmd:98 vf=1/QCIF/1/320; vf=2/CIF/2/320 4.2 Custom picture clock gpmd parameter This section defines a new gpmd parameter called Custom Picture Clock (cpc). This parameter has a float number value that specifies the custom picture clock. If this parameter is not present applications MUST use the default value of 30000/1001 (29.97). Optionally the parameter value MAY contain a list of video format ids to which this cpc applies. If no video format id is present then the cpc value applies to all vf parameters defined for that gpmd format. If no other gpmd parameters are defined for this gpmd line then the cpc parameter applies to the default vf parameters the application decides to use. cpc=float number *(SP id) Below is an example where the application specifies a picture clock value of 25 for QCIF while using the standard 29.97 clock for CIF. m=video 4002 RTP/AVP 31 a=gpmd:vf=1/QCIF/1/320; vf=2/CIF/2/320; cpc=25 1 4.3 H.261 annex gpmd parameter This section defines a new gpmd parameter for H.261 annexes called "261Annex". This parameter applies to the H.261 encoding. The only Ismail & Restrick Expires March 31, 2004 [Page 5] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 current value defined for this parameter is D which specifies the ability of the application to support H.261 annex D. The parameter value MAY contain a list of video format ids in which case annex D can only be supported when these formats are used. If no video format ids are present then annex D is supported by all H.261 video formats specified in the gpmd line. If no other parameters are present on the gpmd line then the parameter specifies support for annex D for the default video formats the application decides to use. 261Annex=D *(SP id) Below is an example of an SDP syntax for which the application will only support H.261 annex D when using the CIF format. m=video 4002 RTP/AVP 31 a=gpmd:31 vf=1/QCIF/1/320; vf=2/CIF/2/320; 261Annex=D 2 4.4 H.263 simple annex gpmd parameter This section defines a new gpmd parameter for simple to declare H.263 annexes called "simple263Annex". The attribute value is a list of alphabetic characters each specifying the ability of the application to support the H.263 annex corresponding to that character. The attribute value MAY contain a list of video format ids, in which case the specified H.263 annex(es) can only be supported when these formats are used. If no video format ids are present as part of the simple263annex parameter then the annex is supported by all H.263 video formats specified in the gpmd line. If no video format parameters are present on the gpmd line then the parameter specifies support for the annex by the default video formats the application decides to use. simple261Annex=1*(annex) *(SP id) annex= E | F | G | I | J | M | P | Q | R | S | T Below is an example of an SDP syntax for which the application will only support annex I and J when using CIF at 128 Kbps while T is supported with all video formats m= video 4002 RTP/AVP 98 a=rtpmap:98 H261/90000 a=gpmd:98 vf=1/CIF/1/128; vf=2/CIF/2/320; simple263Annex=I J 1; simple263Annex=T Ismail & Restrick Expires March 31, 2004 [Page 6] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 4.5 H.263 parameterized annex parameters This section defines new gpmd parameters used to specify H.263 annexes that take parameters. Each parameter value specifies one or more parameters needed by the annex. The parameter value MAY contain a list of video format ids, specified by the gpmd vf attribute, in which case the specified H.263 annex can only be supported when these formats are used. If no video format ids are present then the annex is supported by all H.263 video formats specified by the gpmd parameter. If no video format parameters are present on the gpmd line then the parameter specifies support for the annex by the default video formats the application decides to use. 263AnnexD= 1 | 2 / *(SP id) 263AnnexK= 263AnnexL= 263AnnexN= 263AnnexO= Editor Note: The rest of the 263 annexes specifications will be provided in the next draft. Editor Note: Need to deal with the H.263 levels and profiles in the next draft 5. Support in SDP offer answer 5.1 Video format gpmd parameter An offer containing a video m line MAY or MAY NOT include a gpmd attribute with "vf" parameters. - If the answerer receives an offer without a vf parameter specified in any of the gpmd attributes (or with no gpmd attributes) it SHOULD assume that the offerer only support default video format parameters. Defining such defaults is outside the scope of this document. The answerer MUST NOT include a gpmd attribute with vf parameters in its answer. - An answerer that does not support the gpmd attribute or the vf parameter should ignore them if received in an offer and MUST behave as specified in above. - An answerer receiving an offer that contains one more gpmd Ismail & Restrick Expires March 31, 2004 [Page 7] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 attributes with one or more vf parameters should: 1- Examine each of the vf parameters and determine the ones it supports. The VF is supported if the answerer supports the video picture format specified in the vf parameter. 2- If the answerer wants to use ANY of the supported vf parameters included in the offer, the answerer MUST return a gpmd attribute that includes these vf parameters with their id and video picture format intact. The answerer MAY use a higher mpi or a lower bit rate value to the one specified in the vf parameter. The answerer MUST NOT return a lower mpi or a higher bit rate value. - An offerer receiving an answer with no gpmd attribute in the video media line specifying vf parameters SHOULD assume that the answerer support default video format parameters. Defining such defaults is outside the scope of this document. - Both offerer and answerer MUST be prepared to receive video streams with any of the video format parameters they specified in the offer or the answer respectively. - If an answerer excludes a specific video encoding from the media line it MUST exclude its gpmd attribute as well. Offer: m=video 4002 rtp/avp 98 31 rtpmap: 98 h263/90000 a=gpmd:98 vf=1/QCIF/2/128 vf=2/QCIF/1/320 vf=3/CIF/1/768 a=gpmd:31 vf=4/CIF/1/768 Answer: m=video 4003 rtp/avp 98 rtpmap: 98 h263/avp 98 a=gpmd:98 vf=3/CIF/2/768 5.2 Custom clock picture gpmd parameter - If the offer does not include a cpc parameter in the gpmd attribute the answerer MUST use the default cpc for all vf parameters specified with the gpmd attribute or with the default vf parameters. Ismail & Restrick Expires March 31, 2004 [Page 8] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 - If the offerer does not include a valid cpc value or a value that is not supported by the answerer, the answerer MUST NOT return the cpc parameter in its answer. - If an answer is received with no cpc parameter while the offer contained one the offerer MUST use the default cpc value. - If the offer contains a cpc parameter associated with a video format ID that the answerer does not support the answerer MUST NOT associate the video format id with the cpc parameter in its answer. Other associated and supported video format ID MAY be included. 5.3 simple261Annex gpmd parameter TBD 5.4 simple263Annex gpmd parameter TBD 5.5 h263AnnexD gpmd parameter TBD 5.6 h263AnnexK gpmd parameter TBD 5.7 h263AnnexL gpmd parameter TBD 5.8 h263AnnexN gpmd parameter TBD 5.9 h263AnnexO gpmd parameter TBD 6. ABNF grammar for gpmd video parameters TBD 7. Security Considerations Though applications should work without the existence of the gpmd parameters specified in this document, an attacker altering, deleting Ismail & Restrick Expires March 31, 2004 [Page 9] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 or creating one of these parameter could cause erroneous application behavior. It is possible to protect against such attacks by employing integrity protection mechanism on the protocol(s) used to exchange the session description or by use of integrity protection mechanism on the session description itself. Editor Note: More work is needed on this Section 8. IANA Considerations There are 5 IANA actions in this draft: 1- Registration of the "vf" gpmd parameter 2- Registration the "cpc" gpmd parameter 3- Registration of the "261simpleAnnex" gpmd parameter 4- Registration of the "263simpleAnnex" parameter. 5- Registration of the 263AnnexD, 263AnnexK,.... Editor Note: More work is needed in this section 9. Acknowledgments We would like to acknowledge Flemming Andreasen, Cullen Jennings, Scott Firestone, Tripti Agarwal and Yun-Chung Chen for their constructive comments on this draft. Authors' Addresses Nermeen Ismail Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA EMail: nismail@cisco.com Ismail & Restrick Expires March 31, 2004 [Page 10] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 John Restrick Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA EMail: restrick@cisco.com Appendix A. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [4] H. Schulzrinne and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. [5] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [6] R. Kumar and F. Andreasen, "SDP attribute for Qualifying Media Formats with Generic Parameters", IETF draft, Work In Progress. [7] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [8] International Telecommunications Union, "Video codec for audiovisual services at p x 64 kbit/s", ITU-T Recommendation H.261, March 1993. [9] International Telecommunications Union, "Video coding for low bit rate communication", ITU-T Recommendation H.263, February 1998. Ismail & Restrick Expires March 31, 2004 [Page 11] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Ismail & Restrick Expires March 31, 2004 [Page 12] Internet-Draft SDP General Purpose Media Descriptors for H.261 and H.263 Oct 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ismail & Restrick Expires March 31, 2004 [Page 13]