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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 11 Dec 2009 17:30:23 +0100

Hi,

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

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

Retransmitting the original RTCP packet the the RS received over the SSM
session doesn't work as it would be indicating that the receiver should
have received this flow, but he clearly hasn't yet. Also the time of
reception of an RTCP SR is important as that is basis for the RTT
measurements the sender can do based on RTCP SR + Receiver RTCP RR packet.

I think this information needs to be encapsulated in such a way that it
clear that it is retransmitted or forwarded or aggregated depending on
how one choses this.

Regards

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 11 Dec 2009 08:53:08 -0800

Hi Magnus,

Thanks for splitting the issues.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Friday, December 11, 2009 11:30 AM
> To: IETF AVT WG
> Subject: [AVT] draft-ietf-rtp-rapid-acquisition-for-rtp-05: RTCP information
> 
> Hi,
> 

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

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Dec 2009 10:49:49 +0100

Hi,

See inline.

> We are doing session multiplexing and use the same SSRC from the primary SSM session. So:

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.

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.

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

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 16 Dec 2009 07:34:51 -0800

Hi Magnus,

> From: Magnus Westerlund [mailto:[email-masked]]
> 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.
> 
> > 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).
> >

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.
 
> (SSM) session. I think we need to do more thinking here.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Dec 2009 15:55:19 +0100

> Let us know if this works for you.

Yes, I think that will work fine.

Cheers

Magnus Westerlund