Subject: RE: [AVT] FWD: I-D ACTION:draft-even-mmusic-video-media-control-0 0.txt

From: "Even, Roni" <[email-masked]>
Date: Wed, 12 Jun 2002 16:43:43 +0300

Hi,
I have seen that too.
This is the text file I submitted
Roni

> -----Original Message-----
> From: Lior Sion [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 3:41 PM
> To: 'Even, Roni'
> Subject: RE: [AVT] FWD: I-D
> ACTION:draft-even-mmusic-video-media-control-0 0.txt
> 
> 
> Hi Roni,
> 
> the link you gave brings me some garbage in the draft, can 
> you please send
> me a text file with it?
> 
> thanks,
> lior
> 
> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 11:50 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] FWD: I-D
> ACTION:draft-even-mmusic-video-media-control-00.txt
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. 
> 	Title : SDP attributes for Video media Media Control 
> 	Author(s) : R. Even, O. Levin, P. Koskelainen 
> 	Filename : draft-even-mmusic-video-media-control-00.txt 
> 	Pages : 6 
> 	Date : 10-Jun-02 
> This document defines the syntax and the semantics for the new SDP
> attributes required for handling of video. These attributes 
> are not CODEC
> specific. 
> 
> A URL for this Internet-Draft is:
> <http://www.ietf.org/internet-drafts/draft-even-mmusic-video-m
edia-control-0
0.txt> 
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message. 

Internet-Drafts are also available by anonymous FTP. Login with the username

"anonymous" and a password of your e-mail address. After logging in, 
type "cd internet-drafts" and then "get
draft-even-mmusic-video-media-control-00.txt". 

A list of Internet-Drafts directories can be found in
<http://www.ietf.org/shadow.html> or
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt
****************************************************************************
**********************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or
the 
sender immediately and do not disclose the contents to any one or make
copies.

** eSafe scanned this email for viruses, vandals and malicious content **
****************************************************************************
**********************

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Jun 2002 16:02:22 +0200

Hi,

The garbage is a result of using illegal characters (Non ascii) in the 
draft. The use of smart quotations (“ & ”) should be avoided, use only 
the standard strait ones ("). Also please remove all the 15 extra left 
columns before submission the next time. Please read the draft 
guidelines, "http://www.ietf.org/ietf/1id-guidelines.txt", for other 
things to consider.

Regards

Magnus

Even, Roni wrote:

>------------------------------------------------------------------------
>
>
>                                                                               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 
>                   
>                  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 don’t 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:  [email-masked] 
>                   
>                  Orit Levin 
>                  RADVISION Inc. 
>                  575 Corporate Drive 
>                  Mahwah, NJ 07430                  Phone:  +1-210-529-4300 x230 
>                  USA                               Email:  [email-masked] 
>                   
>                  Petri Koskelainen 
>                  Dept. of Computer Science 
>                  Columbia University 
>                  1214 Amsterdam Avenue            Phone: 
>                  MC 0401 New York                 Email: [email-masked] 
>                  NY 10027 
>                  USA 
>                   
>                   
>
>
>
>
>
>
>
>
>
>
>                    
>                  Even et al.           Expires December 2002                       6 
>
>

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]