Re: [AVT] Fwd: Retransmission and fast channel change with usage ofRTP/RTCP

[Colin Perkins <csp at csperkins.org>]

Jose,

On 25 Mar 2008, at 15:53, Jose Rey wrote:
> thanks for your feedback. Inline...
>
> [...]
>>
>>> Now, since the RTP client at the retransmission proxy cannot send  
>>> its NACK in the media SSM group, it is proposed to send these in  
>>> the *repair* SSM through its Distribution Source, i.e. the  
>>> retransmission server, either as RFC-4585-NACKs or in summarized  
>>> RSI form. However, by doing this, we are mixing the SSRC spaces  
>>> of two different (but associated) sessions. Also the  
>>> retransmission client doesn't know what to do with this feedback  
>>> as it would just think the NACK is from another *repair* client.
>>
>> You probably want to exchange RTCP information, so that all the  
>> devices see the full SSRC space, making this one RTP session.
>
> We definitely want to avoid forwarding RTCP information from every  
> single user either in either 'reflection' or 'summarized' mode into  
> the repair session. That is, in part, the reasoning behind the out- 
> of-band definition of who is who in the 'session', as below. It can  
> be a lot of information, which is not really necessary for running  
> IPTV. Is this exchange a prerequisite for forming a valid  
> 'session'? I mean, RTCP receiver bandwidth and session group size  
> can be communicated via SRB messages and RTCP for repair clients is  
> probably going to be 'off', anyway.

They need to share an SSRC space for it to be a single RTP session.  
If you can do that via out-of-band signalling, fine. My gut feeling,  
though, is that it might make sense to specify that full RTCP is  
distributed to every device in the session, to allow for future  
extensibility (there's no point forwarding RTCP into the repair  
session, since that would just loop it back to the receivers that  
generated it, but I think it does make sense that the retransmission  
proxies see the full RTCP).

>>> A proposed solution for indicating the repair client what to do with
>>> this forwarded NACK would be to use an additional SDP attribute  
>>> listing the SSRC of the RTP client (we would indicate the SSRCs  
>>> of the
>>> retransmission proxy and feedback target as well). The repair  
>>> clients
>>> would then know, by looking at the SSRCs that it is a forwarded NACK
>>> from the media SSM and that they must forward it to the media client
>>> for NACK damping. The appropriate semantics would probably have  
>>> to be
>>> writen down in an I-D.
>>
>> Explicit SDP signalling of the different roles, addresses, and  
>> SSRC values used would seem to be a good thing. It might also be  
>> possible to include role hints in-band in RTCP packets, although  
>> we'd need to think through the implications of that.
>
> I think the first option is the preferred one. What would be the  
> advantages of the second?

I'm not sure, but there do seem to be a lot of proposals for using  
RTCP in middleboxes (both for these IPTV applications, and for  
monitoring parts of VoIP systems). I'm wondering if it would be  
useful to explicitly identify various devices as middleboxes within  
RTCP, rather than other participants having to infer that.

>>> Now, that's one scenario. Another one, though less common, is  
>>> where losses happen dowstream of the retransmission proxy, where  
>>> it cannot detect them. We are still thinking about a solution for  
>>> that.
>>
>> You mean correlated loss downstream of the retransmission proxy?
>
> Yes. For that, we are planning on distributing a polling mask, much  
> like in PGM: a group of selected users has the 'privilege' to  
> report in advance during a period when noone else is allowed to do  
> it. The proxy then infers whether it is affecting a lot or just a  
> few users (mcast or unicast retransmission).

Something like this? http://citeseer.ist.psu.edu/bolot94scalable.html  
That might be a useful thing to standardise as an AVPF extension.

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


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt