Subject: [AVT] Concatenation of RTP streams

From: "Yuval Nissan" <[email-masked]>
Date: Sun, 18 Feb 2007 15:43:31 +0200

Hi, 

There can be different scenarios in a unicast session that the incoming
stream is changed\restart without signaling it to the receiver.

Examples:

1.	The remote side is reset because of some problem - In this case
the remote side usually keeps the same SSRC, but the sequence number and
timestamp usually start from new random value. 
2.	When few RTP streams from different sources are aggregated (in
real time) one after another to create one stream (for example: adding
announcements, advertising, etc).
3.	Video Conference Server that does only RTP switching.

RFC 3550 appendix A describes algorithm to handle these cases, and the
tradeoff between fast transit and validity check. As I understand from
the code there (update_seq() function) - at least 1 packet is dropped
during the stream transit. This can be problematic in video application
where the first packet is Intra and can cause freeze of long duration.

I would like to get your feedback how this issue is implemented today in
RTP stacks (In devices such as video conferencing endpoints and
streaming clients)?

I think it would be better to define a standard way to notify the
receiver (should be inband) before the RTP switch, so no packet is
getting lost. What do you think?

Regards,

Yuval 

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 18 Feb 2007 14:34:28 +0000

On 18 Feb 2007, at 13:43, Yuval Nissan wrote:
> There can be different scenarios in a unicast session that the  
> incoming stream is changed\restart without signaling it to the  
> receiver.
>
>
> Examples:
>
> The remote side is reset because of some problem - In this case the  
> remote side usually keeps the same SSRC, but the sequence number  
> and timestamp usually start from new random value.

The SSRC should change in this case.

> When few RTP streams from different sources are aggregated (in real  
> time) one after another to create one stream (for example: adding  

In this case, the aggregator is supposed to ensure the sequence  
numbers and timestamps are maintained. Alternatively, the inserts  
should use different SSRC values.

> Video Conference Server that does only RTP switching.

Again, the SSRC should change when the switch occurs.

> RFC 3550 appendix A describes algorithm to handle these cases, and  
> the tradeoff between fast transit and validity check. As I  
> understand from the code there (update_seq() function) – at least 1  
> packet is dropped during the stream transit. This can be  
> problematic in video application where the first packet is Intra  
> and can cause freeze of long duration.

An implementation can buffer packets with unexpected RTP sequence  
numbers, if it suspects those packets will shortly be shown to be  
valid, which would avoid the problems you highlight.

> I would like to get your feedback how this issue is implemented  
> today in RTP stacks (In devices such as video conferencing  
> endpoints and streaming clients)?
>
>

I'm not sure any such notification is needed, beyond the expected  
SSRC change. This seems to be a quality of implementation issue,  
rather than a standards problem.

-- 
Colin Perkins
http://csperkins.org/