Subject: [AVT] Minor comment on draft-xia-avt-mpeg2ts-preamble-02

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Tue, 16 Mar 2010 17:38:46 +0100

Hi,
 
I have two (minor) comments on the MPEG2TS preamble draft 

1)My understanding/assumption is that the MPEG2 TS pre-amble is sent as
MPEG2 TS encapsulated in RTP, as specified in RFC 2250.

However, in section 5.4 , there is no reference to RFC 2250, only to RFC
3550? Under the same assumption, shouldn't the marker bit, time stamp
and payload type not be defined identical as in RFC 2250? Is there a
conflict?

More specifically: should the Payload type not be 33 (valid both for the
SSM and the preamble)?

2) The SDP example includes a new attribute, but the attribute is not
defined in this draft.  I do agree there is need for such an attribute
to indicate that the RTP packets with pre-amble and transported in
alignment with RFC 2250 are indeed recognised as pre-amble associated
with the data inside the burst packets.

Regards

Tom

---

From: Roni Even <[email-masked]>
Date: Tue, 16 Mar 2010 20:37:42 +0200

Hi Tom, 

I am not the author but see inline

Roni Even

As individual

From: [email-masked] [mailto:[email-masked]] On Behalf Of VAN
CAENEGEM Tom
Sent: Tuesday, March 16, 2010 6:39 PM
To: IETF AVT WG
Subject: [AVT] Minor comment on draft-xia-avt-mpeg2ts-preamble-02

Hi,

However, in section 5.4 , there is no reference to RFC 2250, only to RFC
3550? Under the same assumption, shouldn't the marker bit, time stamp and
payload type not be defined identical as in RFC 2250? Is there a conflict?

Roni: Yes, this should be updated, section 5.5 mentioned that it is RFC
2250.

More specifically: should the Payload type not be 33 (valid both for the SSM
and the preamble)?

Roni: You are right that 33 is the static payload type number but it is
allowed to use dynamic payload type numbers with rtpmap (RFC 3551) even for
payload subtypes that has static numbers. The reason for static assignment
was the lack of a signaling way to bind the number to a payload subtype name
which became available with SDP.

2) The SDP example includes a new attribute, but the attribute is not
defined in this draft.  I do agree there is need for such an attribute to
indicate that the RTP packets with pre-amble and transported in alignment
with RFC 2250 are indeed recognised as pre-amble associated with the data
inside the burst packets.

Roni: I think the authors will add it if this is the agreed solution for
corelateing the preamble to the burst stream.

Regards

Tom