[AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-04: (with DISCUSS)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-payload-rtp-ttml-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the discussion and addressing most of the issues completely. I leave
these in so that I know that the remaining text issues to be addressed are
associated with these.


3. Section 7.1:

        It may be appropriate to use the same Synchronization
   Source and Clock Rate as the related media.

        Using the same SSRC as another media stream in the same RTP Session is
        no-no. If you meant to use multiple RTP sessions and associate them
        using the same SSRC in diffiernt, yes it works but is not recommended.
        This points to the need for a clearer discussion of how to achieve
        linkage and the reasons for why same RTP timestamp may be useful or not.

4. Fragmentation:
        I think the fragmentation of an TTML document across multiple RTP
        payloads are a bit insufficiently described. I have the impression that
        it is hard to do something more clever than to fill each RTP payload to
        MTU limtiation, and send them out insequence. However, I think a firm
        requirement to apply RTP sequence number for a single document in
        consecutive numbers. Also the re-assebly process appear to have to
        parts for detecting what belongs together, same timestamp and last
        packet of document should have marker bit set. As a receiver can loose
        the last packet in the previous document, still know that it has
        received everything for the following document. However, if the losses
        are multiple, inspection of the re-assemblied document will be
        necessary to determine if the correct beginning is present. I have the
        impression that a proper section discussing these matter of
        fragmentation and re-assembly are necessary for good interoperability
        and function.