Subject: [AVT] Comments on draft-xia-avt-mpeg2ts-preamble-02.txt

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 Mar 2010 14:25:33 -0600

There are a few parts I had questions about. I'm still trying to get my head around some of the other parts so I may have some more questions on theses but few initial questions about some RTP aspects ...

I did not understand why the sequence numbers needed to be constructed so they all ended up smaller than the other position of the other multicast stream. It seems the SSRC/ports keeps these number spaces separate. How do these get used and why does it need to be this way? What happens if while you are sending the unicast burst, you receive new information that changes how many RTP packets you are going to need to send and thus you can not make these seq number constraints? On a related note, why do the SSRC need to be different. I'm not arguing any of these constraints are wrong, it was just reading the draft it did not seem to specify enough about how they were used for me to understand why they were needed or if they were a good idea or not. They are constraints not typically seen on RTP systems so I worry about how they will interact with existing systems. 

How does the receiver know if preamble packets are missing or not? Particularly near the boundary packets when there is reordering of packets. 

In the SDP in fig 11, what does the " a=preamble 100 " indicate?

In section 6 where you are talking about if a software update is needed or not, I think I got a bit lost. Am I correct in my assumption that this would require the software was updated to support RAMS and can't work on existing system?

Cullen <in my individual contributor roll>

---

From: Peilin YANG <[email-masked]>
Date: Thu, 18 Mar 2010 13:03:52 +0800

Dear Cullen,

Thank you for your comments.

The RTP packets of the preamble information are new RTP packets which are different from primary multicast stream. Constructing the sequence number of the preamble information associated with the unicast burst is to facilitate the conveying of the sequence number in the RAMS-I message. We also can separate the space of both the preamble sequence number and the seuqnce number of the unicast burst. If so, we need more information in RAMS-I. T
he reason using a different SSRC is to faciliate RTP receivers to request retransmission when a preamble packet lost. Cullen, thank you for your comments, I need to add some new text to make it earier to understand, and add the parameter description of RAMS-I relative to the preamble. 
As for software update, it means if the codec chip of RTP receivers has supported some PSI inforamtion(e.g. private data) which isn't inlcuded in the current preamble, our approach doesn't need to update the software of RTP receivers.  
I don't know if I clearly explain your question.

Many thanks,

Peilin

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

Subject: [AVT] Comments on draft-xia-avt-mpeg2ts-preamble-02.txt
From: Cullen Jennings <[email-masked]>
To: IETF AVT WG <[email-masked]>
Date: Wed, 17 Mar 2010 14:25:33 -0600
List-Id: Audio/Video Transport Working Group <avt.ietf.org>

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