One document matched: draft-even-mmusic-video-media-control-00.txt

                                                               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> 
  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 
  "<integer>.<fraction>" 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 do not have an access to the RTCP channel of the media. 
   
  The media level attributes to support this are: 
   
  a=video-frame:<request> 
   
  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