R. Even Internet Draft Polycom Document: draft-even-mmusic-video-media- O. Levin control-00.txt RADVISION P. Koskelainen Columbia University Expires: December 2002 June 2002 SDP attributes for Video media Media Control 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. Abstract This document defines the syntax and the semantics for the new SDP attributes required for handling of video. These attributes are not CODEC specific. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................2 2. Conventions used in this document...............................2 3. Video Resolution Attribute......................................2 4. Video Request Attribute.........................................3 5. IANA Considerations.............................................4 6. Security Considerations.........................................5 7. References......................................................6 8. Author's Addresses..............................................6 Even et al. Expires December 2002 1 1. Introduction Internet multimedia conferencing based on SIP is picking up with point-to-point and multipoint video conferencing implementation. Video media has some characteristics that are common to all video codecs. Video streams can build pictures for different display resolutions each in a different supported frame rate. Compressed Video information is typically composed of full picture frames and frames that reflect changes from previous frames, this requires some special handling to enable smooth switching of video source and resynchronization on full pictures. In order to have better support for video media this draft specifies the SDP syntax to be used for the described video media properties. These attributes can be delivered by some signalling protocol (e.g. SIP or SAP). For example, the defined attributes help to control video streams belonging to SIP dialogs in a point-to-point call as well as in a multipoint call. The attributes are especially useful in SIP but may be used in SAP. 2. Conventions used in this document 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 RFC-2119 [1]. 3. Video Resolution Attribute The SDP draft [1] has an attribute of frame rate. Video CODECs can support different frame rates that are dependent on the frame resolution. Therefore we need a new attribute that will specify the frame rate per resolution. a=video-resolution: size=öSQCIFö ô=ö mpi | ôQCIFö ô=ö mpi | ôCIFö ô=ö mpi | ô4CIFö ô=ö mpi | ô16CIFö ô=ö mpi | ôXMAXö ô=ö xmax SP ôYMAXö ô=ö ymax SP ôMPIö ô=ö mpi mpi=1*3DIGIT xmax=1*3DIGIT ymax=1*3DIGIT ôvideo-resolutionö is a media level attribute that enables definition of supported resolutions for a video CODEC for described media. MPI gives the maximum video frame rate in frames/sec. Decimal representations of fractional values using the notation "." are allowed. If a resolution is not specified then the decoder will support the frame rate of the next highest resolution specified. Even et al. Expires December 2002 2 SQIF: Sub-QCIF picture size and its MPI value. QCIF: QCIF picture size and its MPI value CIF: CIF picture size and it MPI value 4CIF: is 4xCIF picture size and its MPI value 16CIF: is 16xCIF picture size and its MPI value. Arbitrary picture size (XMAX, YMAX, MPI): the maximum X and Y values in pixels for an arbitrary picture size and it MPI value. The X and Y value must be dividable by 4. 4. Video Request Attribute Output of a video CODEC is a frame. The frame can carry complete (in time) information about a picture or about a picture segment. These frames are known as ôintraö frames. In order to save bandwidth, other frames can carry only changes relative to previously sent frames. Frames carrying relative information are known as ôinterö frames. Some CODECs (such as H.261 and H.263), in addition to a ôfullö picture, have a notion of picture slices: MB (Macro Block) and GOB (Group Of Blocks) or arbitrary slices. The decoder has an ability to recognize synchronization problem and MUST have an ability to explicitly request from an encoder for complete (in-time) information of a ôfullö picture or of a specific slice of the picture. In addition, when an application needs to start presenting a new video source, it MUST have the ability to explicitly request from an encoder for a complete information about the picture. In case the encoder is aware of the upcoming changes in the transmitted stream (that would result in synchronization lost by the decoder), the encoder MUST be able to request the decoding side to freeze the picture, i.e. to stop presenting the changes, until a new stable image is encoded and transmitted. A smooth video switch in a multipoint conference starts when the conference host decides to switch to a new video source. It sends a freeze picture request to all the decoders that will receive the new stream. Afterwards, the conferencing host sends a request to the new encoder to send an Intra frame with the complete information for the new picture. The new Intra frame, from the encoder, releases the decoders from the video freeze state and a new complete picture is presented. The AVT RTCP feedback draft [3] provides a mechanism for an immediate feedback using RTCP. In order to be in line with the RTCP role (as described in RTP [4]), the feedback mechanism is allowed for notifications only. Moreover, the RTCP feedback provides a Even et al. Expires December 2002 3 notification channel from decoder to encoder only. For our purposes, a means of sending requests in both directions are required. Using SDP (instead of RTCP) has a clear advantage for applications that donÆt have an access to the RTCP channel of the media. The media level attributes to support this are: a=video-frame: Permitted values for request are: ôINTRA-PICTUREö û instructing the encoder to send an intra frame ôFREEZE-PICTUREö û instructing the decoder to stop decoding. ôINTRA-GOBö ô=ö fgb ô,ö ngb û instruct the encoder to send ngb gobs starting from gob fgb. ôINTRA-MBö ô=ö fgb ô,ö fmb ô,ö nmb û instruct the encoder to send nmb macro blocks starting from gob fgb and first macro block fmb. fmb=1*2DIGIT nmb=1*2DIGIT fgb=1*2DIGIT ngb=1*2DIGIT 5. IANA Considerations This document defines the following new SDP parameters of type "att- field" (attribute names): Attribute name: video-resolution Long form name: video resolution . Type of attribute: media-level. Subject to charset: No. Purpose: define supported frame rate per resolution. Appropriate values: See Section 3. Attribute name: video-frame Long form name: video frame request. Type of attribute: media-level. Subject to charset: No. Purpose: define video frame requests. Appropriate values: See Section 4. Even et al. Expires December 2002 4 6. Security Considerations The new SDP attributes do not introduce additional security pitfalls. The security considerations are the same as for the SDP [1]. Even et al. Expires December 2002 5 7. References [1] M. Handley and V. Jacobson, "SDP: session description protocol", Request for Comments 2327, Internet Engineering Task Force, Apr. 1998. [2] P. Koskelainen et al. ôSDP syntax for H.263 optionsö, INTERNET-DRAFT, Internet Engineering Task Force, 1998. [3] Ott, Wenger et al. ôExtended RTP Profile for RTCP-based Feedback (RTP/AVPF)ö, INTERNET-DRAFT, Internet Engineering Task Force, 2002 [4] AVT WG, Schulzrinne/Casner/Frederick/Jacobson, ôRTP: A Transport Protocol for Real-Time Applicationsö, RFC 1889, Proposed Standard, Jan 1996. 8. Author's Addresses Roni Even Polycom Network Systems 94 Derech Em Hamoshavot Phone: +972-3-9251200 Petach Tikva, Israel Email: roni.even@polycom.co.il Orit Levin RADVISION Inc. 575 Corporate Drive Mahwah, NJ 07430 Phone: +1-210-529-4300 x230 USA Email: orit@radvision.com Petri Koskelainen Dept. of Computer Science Columbia University 1214 Amsterdam Avenue Phone: MC 0401 New York Email: petkos@cs.columbia.edu NY 10027 USA Even et al. Expires December 2002 6