> > > - First of all, is this an RTP payload format draft or not? The
> > > draft
> > > seems
> > > to be defining that, yet, title does not say so, and the draft does
> > > not
> > > have
> > > the sections needed for defining a new payload format. See the
> > > guidelines
> > > document.
> > > Frank=>This draft did not define a new payload format.
> > > This is negotiatable if RFC4588 can't be used directly.
> > > Some further related response see below.
> >
> > You are carrying something in RTP, so one way or another, you are
> > defining
> > a
> > new payload format. As I mentioned earlier, usage of 4588 does not
> > seem
> > to
> > be correct here.
> > Frank=>Good point. However, I still believe it is make sense to
> > reuse
> > 4588.
> > draft-ietf-avt-rapid-acquisition-for-rtp uses 4588 for unicast RTP
> > burst
> > which are not RETRANSMISSION packets as to the RR.
>
> I believe you are confused here. Burst packets are "retransmission"
> packets - totally in accordance with RFC 4588. They are retransmissions
> of
> earlier RTP packets sent in the primary multicast stream. And the
> receiver
> considers them as retransmission packets.
> Frank=>They are not retransmission packets.
> In rapid acquistion (e.g fast channel change),
> these packets are never sent to the RR before.
From RR's viewpoint, this does not matter (whether the packets were sent
but
they were lost or they were never sent - receiver cannot know the
difference). The important thing here, the burst packets are the exact
replicas of the original RTP packets encapsulated in 4588 format. But, the
way you describe sending the raw TS packets does modify the source
packets,
which means 4588 should not be used.Hi
Frank=>Copies of the original RTP packets are not retransmission packets.