Subject: Re: [AVT] Header formats for RTP profile for TFRC

From: Colin Perkins <[email-masked]>
Date: Sun, 4 Sep 2005 13:00:14 +0100

Ladan,

Before proposing new header formats, I'd like to see some more  
requirements discussion, so we have a good rationale for adding the  
new features.  Do we have a reasonable use case? Or is this a "might  
be nice" type of feature?

Colin

On 2 Aug 2005, at 12:40, Ladan Gharai wrote:
> Following the discussion of the RTP profile for TFRC today, I would  
> be interested in your feedback on the following two possible header  
> formats for AVPCC?
>
> Header I is the current header in the draft, whereas header II  
> incorporates some of the comments made in the AVT session today.
>
>
> Header I (current):
> -------------------------
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>       |V=2|P|X|  CC   |M|R|    PT             |              
> sequence number            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>       |                                                   
> timestamp                                                |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>       |                      synchronization source (SSRC)  
> identifier                     |
>       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>       |                                              send  
> timestamp                                          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>       |                                                         
> RTT                                                     |
>       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>
> pros:
>   - RTP header is extended by 4 octets and occasionally by 8 (if the R
>         bit is set and RTT field in present).
>   - the RTT timestamp field is a full 32 bit field
>
> cons:
>    - the RTT cannot be used for other time measurements
>    - header compression is not fully optimum
>    - payload type is a 6 bit fields
>
>
> Header II (possible alternative):
> --------------------------------------------
>      In this alternative a 30 bit general "time" field is added,  
> where the
>      first two bits, "tt", indicate the type of time measurement   
> i.e, RTT, decode
>      timestamp, etc.,
>     Therefore when the TFRC algorithm is not conveying RTT  
> measurements
>      it is possible to use this field for conveying a different  
> type of time
>      measurement.
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>       |V=2|P|X|  CC   |M|  PT             |             sequence  
> number                  |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>       |                                                   
> timestamp                                                |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>       |                      synchronization source (SSRC)  
> identifier                     |
>       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>       |                                              send  
> timestamp                                          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+
>       |   tt  |                                                    
> time                                                  |
>       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>
>
> pros:
>    - payload field remains at 7 bits
>    - works seamlessly with header compression
>    - allows the RTT field to be used for other types of time  
> measurements
>
> cons:
>    - RTP header is always extended by 8 octets
>     - the extra time field is a 30 bit field

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt