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

["Jose Rey" <[e-mail]>]

Colin,

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.

> 
> > 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?

> 
> > 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).

Cheers,

José



Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt