Re: [AVT] draft-ietf-rtp-rapid-acquisition-for-rtp-05: RTCP information

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Magnus,

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Monday, December 14, 2009 4:50 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG
> Subject: Re: [AVT] draft-ietf-rtp-rapid-acquisition-for-rtp-05: RTCP information
> 
> Hi,
> 
> See inline.
> 
> Ali C. Begen (abegen) skrev:
> >> I realized one more issue which clearly are insufficient described in
> >> this specification. That is how the necessary RTCP information are
> >> provided to the RTP_Rx.
> >>
> >> The only thing I can find is the following in Section 6.2, bullet 2:
> >>
> >>        It is RECOMMENDED to include a sender report with the RAMS-I
> >>        message in the same compound RTCP packet.  This allows rapid
> >>        synchronization among multiple RTP flows
> >>        [I-D.ietf-avt-rapid-rtp-sync].
> >
> > Just note that regular sender reports for the unicast session will continue to flow the
> ret server to the receiver during the course of unicast session. The RTCP sender reports
> in the SSM session are multicast from the distribution source anyway (I.e., there are two
> RTCP sessions).
> >
> >> I think that fails to take into account the SSRC being used here. The
> >> RTP_Rx is interested in the SSRC(s) "SSRC_Mx" used by the real media
> >> sender into the SSM session. However, the RS is using a SSRC of its own,
> >> that is different from SSRC_Mx, which I here call SSRC_Rx. Following the
> >
> > We are doing session multiplexing and use the same SSRC from the primary SSM session.
> So:
> > SSRC_Rx <- SSRC_Mx
> 
> You are actually trying to do something that isn't specified in the RTP
> retransmission part what I remember. The authoritative synchronization
> information in the RTP session multiplexing RTP retransmission case
> comes from the original session.

OK, I see your point now (based on our offline conversation). The synchronization information comes from the primary session, agreed. The sender reports in the unicast session will synchronize the packets in that session only, which is not what we want. The ret server can only know the synch info if it has received it from the primary session.
 
> I see an issue in that some of the RTCP information will be for the
> retransmission or burst stream and other will apply for the original
> (SSM) session. I think we need to do more thinking here.

Indeed.
 
> 
> >
> >> lines of RTP Retransmission there will be a mapping between the SSRC_Rx
> >> to a particular SSRC_Mx. However the RTCP information that is sent as
> >> originated by SSRC_Rx is the one about the repair or burst flow. Not the
> >> synchronization information that is correct for SSRC_Mx.
> >>
> >> So, what is the proposal to provide the RTP_Rx with SSRC_Mx SR and CNAME
> >> and any additional RTCP information when doing RAMS?
> >
> > We simply use the SSRC of the media sender in the unicast session, too.
> >
> > Would that answer your question?
> 
> No, I still think we have an issue here that needs detailed
> specification. I am also not certain if the method of making the RTCP
> information for the unicast session apply also for the SSM session can
> work, or if there is need for an encapsulation solution.

I talked to Colin about this. And we agree that a header-extension based approach will be a better option here. The source in the primary session sends the header extensions frequently enough so that the randomly joining receivers will quickly synchronize the RTP streams (See http://www.ietf.org/id/draft-ietf-avt-rapid-rtp-sync-07.txt)

In the unicast retransmission session, the ret server observes these header extensions and conveys them to the receiver during the burst. 4588 says the header extensions in the original packets SHOULD be carried in the ret packets. This will allow the receivers to synchronize the RTP streams quickly both in the unicast session as well as when they join the primary SSM session.

This approach does not need a new encapsulation for the sender reports.

Let us know if this works for you.

Cheers, acbegen.
 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------