[AVT] retransmission payload format

[David.Leon@nokia.com]

We are in the process of merging the two retransmission payload format as outlined at the last group meeting. We have one open issue on which we would like to get the group feedback before submitting the draft.

We had first planned to use the payload format as described in Section 5 of http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-02.txt and reproduced below:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|   OPT       |            OSN                |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                  Original RTP Packet Payload                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

If this format were used, the PT field of the RTP header would map to the retransmission payload format, the OPT would map to the original PT of the media being retransmitted and the RTP TS would be set to the media TS of the original RTP packet.

However, an issue was brought up with regards to the TS clockrate to be used with the retransmission payload format in scenarios where the original RTP stream would be switching between media types with different TS clockrate. One example would be an audio stream which may switch between AMR, AMR-WB and AAC codecs which all have different TS clockrate. This can't be handled with the above payload format as there cannot be multiple clockrate for any payload format.

The solution that we propose in order to solve this problem, is to use multiple PT values in the retransmission stream if multiple payload formats are used in the original stream. In other words, instead of using the RTP header to signal the retransmission payload format and signal in the payload format (OPT) the original media payload, the RTP header PT would map directly to the retransmission/media type couple. In the above example, this would mean that retransmitted AMR, AMR-WB and AAC map to 3 different payload types. 

Note that as a consequence, there's no use of the OPT field and the payload format header could be reduced to 2 bytes as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            OSN                |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                  Original RTP Packet Payload                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Adopting this payload format has further implications on the random TS offset requirement and the RTCP jitter:
*The initial RTP TS SHOULD be random because of known plain text attacks. This payload format does not follow this recommendation as the initial TS will be the media TS of the first retransmitted packet. However, since the initial TS of the orignal stream is itself random, if the original stream is encrypted, the initial retransmitted TS would also be random to an attacker. Therefore, security requirements would be met. 
*The RTCP jitter value for the retransmission stream does not reflect the actual network jitter since there could be little correlation between the time a packet is retransmitted and its original media TS. There would thus be very little use of this jitter value computation to RTP senders. However, since the original packets and the retransmission packets are sent into separate streams, the RTCP jitter of the original stream is computed as usual and senders can estimate the network jitter using the RTCP jitter value of the original stream.

This approach also obviously implies that more PT values need to be used for the retransmission stream.  

Another solution to the retransmission TS clockrate problem would be to use an independent TS for the retransmission stream, such as the time instant the packet is retranmsitted and send the original media TS in the payload. 

With such a solution, the payload format would be as shown below:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           OTS                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|   OPT       |            OSN                |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                  Original RTP Packet Payload                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

where OTS is the orginal media TS of the retransmitted packet. Compared to the previous approach, this payload format adds 5 bytes of overhead.
The advantage of this payload format is to allow the computation of the network jitter since an sending time TS is used.
The RTP timestamp frequency for this payload format should be chosen so as to yield an RTCP jitter measurement with the desired precision. For example, a 10khz timestamp would yield a precision of 0.1 ms. 

To conclude, two approaches (media TS with multiple PT, sending time TS with unique PT) could solve the TS clockrate issue when multiple clockrates are used in the original stream. We favour the media TS approach which has lower overhead but we would like to hear from others' point of views.

David. 
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt