[even more inline] Colin Perkins wrote:
I guess this depends on the compression type. In the case of the ROHC RTP profile it will only mean that each packets header becomes up to 2 bytes bigger compared to a optimal performance. But maybe some of the other standards has worse performance.[inline] --> Magnus Westerlund writes:Colin Perkins wrote:--> David.Leon@nokia.com writes:...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.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 was what I meant: the compression is likely to be seriously impacted. We may not care, since retransmission packets will hopefully be rare.
I agree that doubling the number of payload types is not a problem with the normal small number of payload types we have seen so far. However I don't see how this helps the synchronization problem. If the original stream switches rate by changing payload type, any retransmitted packet must after reconstructing have its correct timestamp.I don't see a problem with using many payload types. That seems cleanerYes, 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.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?
My view is that the later solution is a cleaner and nicer, but its cost is rather high.
than having to deal with synchronisation problems if the retransmission format chooses a different clock rate to the original media.