[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] retransmission payload format
Hi Colin,
See comments inline:
Colin Perkins wrote:
--> 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.
I would just like to clarify, that switching SSRC does not remove the
requirement that each payload type can only have a single TS rate.
However I do agree that switching SSRC when changing RTP TS rate has
some advantages. It does avoid the unclarity for the receiver to exactly
know when the switch point was. This unclarity can really be problematic
if you would switch rate rapidly several times. However if the switch
does not happen often it can be decently enough handled.
When doing retransmission according to the current proposal (SSRC
multiplexing) one will be required to follow the original stream and how
it is handled. If the original stream switch SSRC when switching rate,
each rate will have its own retransmission SSRC. If the original stream
switch rate and keeps the rate the retransmission stream needs to do the
same.
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).
I don't think it will simplify the signaling at all. You will still need
one RTX payload format for each rate existing in the original stream.
Then having the original PT signaled in the RTX payload format seems
redundant. Making a simple 1-1 mapping of the original PTs and the RTX
PTs seems straightforward enough.
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.
I would not say it becomes difficult to use header compression. The
efficiency will simple be less as the RTP TS must be sent using more
bits or uncompressed. But as the retransmitted stream uses much less
bandwidth than the original stream I would think it is a minor problem.
This approach also obviously implies that more PT values need to be used
for the retransmission stream.
Another solution to the retransmission TS clock rate 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?
Yes, but then you would still require to have as many RTX payload types
as you have original rates. By including the full field you don't care
about the original rate. Also having a delta requires a more advanced
mechanism for reconstructing the TS.
My view is that the later solution is a cleaner and nicer, but its cost
is rather high.
Regards
Magnus Westerlund
Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt