[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] retransmission payload format
--> David.Leon@nokia.com writes:
>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.
This is problematic in RTP in general, unless you switch SSRC when changing
to a different rate.
>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 |
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An alternative would be to keep the original payload format, with the OPT
field, and signal different payload types for retransmission at each rate
(this uses one octet per packet, but may simplify the signalling).
>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. How
> ever, 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.
It also becomes difficult to use header compression, if the retransmitted
packets are sent as a separate 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.
You could use the same rate as the original media, and include a delta in
the packet to save a couple of octets?
Cheers,
Colin
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt