Re: [AVT] Observations on MPEG2-TS preamble drafts

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi Roni,

I am not sure where you are confused. Ignoring the preamble for now, consider the following scenario:

RS receives the RAMS request, figures out the burst starting point. Assume the burst will start with the source packet with seqnum 100. The burst will continue until it catches up with the multicast. So, the burst packets sent by RS will have OSN fields set to 100, 101, 102, .... so on.

However, the seqnum field in the RTP header of the first burst packet could be 2000 (a random number). The second burst packet will have seqnum field set to 2001, so on. Assuming the burst will end when RS sends the source packet with seqnum 103, this is what we get:

1st burst packet (SN: 2000, OSN: 100)
2nd burst packet (SN: 2001, OSN: 101)
3rd burst packet (SN: 2002, OSN: 102)
4th burst packet (SN: 2003, OSN: 103)

When RR joined the multicast, the first packet RR receives could be the one with seqnum 103. RR will know that it is a duplicate, and will discard it. There could be re-ordering, but it does not matter. By using the OSN fields of the burst packets and the seqnum fields of the multicast packets, RR puts everything in the right order.

Now, if a preamble RTP packet needs to be sent prior to the burst, in our approach this is what we do:

1st preamble packet (SN: 2000 - there is no OSN field)
1st burst packet (SN: 2001, OSN: 100)
2nd burst packet (SN: 2002, OSN: 101)
3rd burst packet (SN: 2003, OSN: 102)
4th burst packet (SN: 2004, OSN: 103)

What I am saying is that the seqnums in the retransmission session (where we payload-type multiplex the preamble packets with the burst packets) are independent of the OSNs of the burst packets. More precisely, its starting value has nothing to do with the OSNs.

I am still not clear what Frank proposes in his proposal and am looking forward to some explanatory diagrams in the meeting. If the RTP packets carrying the Preamble data will be retransmitted intact, 4588 can be used provided that the OSN fields are properly set. But, as I mentioned earlier, that introduces new problems.

HTH,
-acbegen


> -----Original Message-----
> From: Roni Even [mailto:Even.roni at huawei.com]
> Sent: Monday, October 26, 2009 3:05 PM
> To: 'Frank Xia'; Ali C. Begen (abegen); avt at ietf.org
> Subject: RE: [AVT] Observations on MPEG2-TS preamble drafts
> 
> Ali,
> I am also confused. The RAMS draft references the OSN only in step 8 of
> section 6.2 (terminate) and reading step 8 I do not see why you think that
> the Xia proposal will break in this case.
> Thanks
> Roni Even