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

[James Sandford <[e-mail]>]

Hi,

I'm happy to do that. I'll hold off making the change until Adam has had a chance to review in case he has anything to add.

Regards,
James

==========
James Sandford
R&D Project Engineer

BBC Research and Development
5th Floor
Dock House
MediaCityUK
Salford
M50 2LH

Tel: 030304 (09549)
Web: http://www.bbc.co.uk/rd

________________________________________
From: Christer Holmberg [[e-mail]]
Sent: 29 October 2019 16:33
To: James Sandford; Magnus Westerlund; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)

Hi,

Since you are not defining any new SDP attributes etc, I don't think you need the SDP O/A procedure structure we normally use.

After a second thought, maybe the easiest way would be to simply rename Section 11.2 to "SDP Considerations" (I think "Mapping to SDP" sounds confusing), and then remove section 11.3.

Regards,

Christer







On 29/10/2019, 17.47, "James Sandford" <[e-mail]> wrote:

    Hi,
    Could you explain what you think prevents the use of offer/answer? I think the relevant parameter is codecs which specifies the content profile(s) the documents adhere to. That is declarative and there is no mechanism in TTML to negotiate content profiles used.

    Regards,
    James

    ==========
    James Sandford
    R&D Project Engineer

    BBC Research and Development
    5th Floor
    Dock House
    MediaCityUK
    Salford
    M50 2LH

    Tel: 030304 (09549)
    Web: http://www.bbc.co.uk/rd

    ________________________________________
    From: Christer Holmberg [[e-mail]]
    Sent: 29 October 2019 15:33
    To: Magnus Westerlund; James Sandford; [e-mail]
    Cc: [e-mail]; [e-mail]; [e-mail]
    Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)

    Hi,

    The way it is written now it sounds like you can't use this with SDP Offer/Answer, which I assume is not the intention.

    The Offerer and Answerer procedures may be very simple, but we have previously agreed that they should be there.  For example, one piece of important information is what (if any) changes are allowed in subsequent offers/answers.

    There are existing procedures that can be used as template, and I'm also happy to help if needed.

    Regards,

    Christer




    On 29/10/2019, 17.24, "Magnus Westerlund" <[e-mail]> wrote:

        Hi Christer,

        Actually, if they are all declarative it is actually sufficient. That results in
        all parameters behaving as defined in RFC 3264 and you actually don't have to go
        into details.

        Or do you disagree with that assessment?

        Cheers

        Magnus


        On Tue, 2019-10-29 at 14:52 +0000, Christer Holmberg wrote:
        >
        > Hi,
        >
        > I see that you have added an SDP Offer/Answer section, but the only statement
        > there is "All parameters are declarative".
        >
        > I assume (please correct me if I am wrong) it shall be possible for two
        > endpoints to negotiate a TTML RTP flow, in which case you need to describe the
        > procedures for the Offerer and the Answerer.
        >
        > Regards,
        >
        > Christer
        >
        >
        >
        >
        > From: avt <[e-mail]> on behalf of James Sandford <
        > [e-mail]>
        > Sent: Tuesday, October 29, 2019 4:24 PM
        > To: Magnus Westerlund <[e-mail]>; [e-mail] <
        > [e-mail]>
        > Cc: [e-mail] <[e-mail]>;
        > [e-mail] <[e-mail]>;
        > [e-mail] <[e-mail]>
        > Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-
        > ttml-03: (with DISCUSS and COMMENT)
        >
        > Changes have been submitted in -05.
        > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/
        >
        > Regards,
        > James
        >
        > ==========
        > James Sandford
        > R&D Project Engineer
        >
        > BBC Research and Development
        > 5th Floor
        > Dock House
        > MediaCityUK
        > Salford
        > M50 2LH
        >
        > Tel: 030304 (09549)
        > Web: http://www.bbc.co.uk/rd
        >
        > ________________________________________
        > From: Magnus Westerlund [[e-mail]]
        > Sent: 29 October 2019 14:13
        > To: James Sandford; [e-mail]
        > Cc: [e-mail]; [e-mail];
        > [e-mail]
        > Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-
        > ttml-03: (with DISCUSS and COMMENT)
        >
        > Hi James,
        >
        > Looks good to me.
        >
        > Thanks,
        >
        > Magnus
        >
        >
        > On Tue, 2019-10-29 at 13:52 +0000, James Sandford wrote:
        > > Thank you for your further comments.
        > >
        > > I will make the suggested changes to Section 8 and Section 11.1.
        > >
        > > With regards to further clarifying the fragmentation of documents, I propose
        > > the following:
        > >
        > > Section 6 OLD:
        > >   If a TTML document is assessed to be invalid then it MUST be discarded.
        > When
        > > processing a valid document, the following requirements apply.
        > >
        > > Section 6 NEW:
        > >   If a TTML document is assessed to be invalid then it MUST be discarded.
        > This
        > > includes empty documents, i.e. those of zero length. When processing a valid
        > > document, the following requirements apply.
        > >
        > > Section 8 ADDITIONAL PARAGRAPH:
        > >   As described in Section 6, only zero or one TTML document may be active at
        > > any point in time.  As such, there MUST only be one document transmitted for
        > a
        > > given RTP Timestamp.  Furthermore, as stated in Section 4.1, the Marker Bit
        > > MUST be set for a packet containing the last fragment of a document.  A
        > packet
        > > following one where the Marker Bit is set contains the first fragment of a
        > new
        > > document.  The first fragment might also be the last.
        > >
        > >
        > > Regards,
        > > James
        > >
        > >
        > > ==========
        > > James Sandford
        > > R&D Project Engineer
        > >
        > > BBC Research and Development
        > > 5th Floor
        > > Dock House
        > > MediaCityUK
        > > Salford
        > > M50 2LH
        > >
        > > Tel: 030304 (09549)
        > > Web: http://www.bbc.co.uk/rd
        > >
        > > ________________________________________
        > > From: Magnus Westerlund [[e-mail]]
        > > Sent: 29 October 2019 11:47
        > > To: James Sandford; [e-mail]
        > > Cc: [e-mail]; [e-mail];
        > > [e-mail]
        > > Subject: RE: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-
        > rtp-
        > > ttml-03: (with DISCUSS and COMMENT)
        > >
        > > Hi James,
        > >
        > > Thanks for the  many updates in -04. However, I think there are a couple of
        > > adjustments still needed.
        > >
        > > Section 8:
        > >
        > > When a document spans more than one RTP packet, the entire document
        > > is obtained by concatenating User Data Words from each contributing
        > > packet in ascending order of Sequence Number.
        > >
        > > I think this can be further clarified by adding "consecutive"
        > >
        > > When a document spans more than one RTP packet, the entire document
        > > is obtained by concatenating User Data Words from each consecutive
        > > contributing
        > > packet in ascending order of Sequence Number.
        > >
        > > What I think is unclear is what is considered contributing packets. It is
        > > quite common that one determine fragments based on timestamp and that may be
        > > assumed by some. I don't know if that is a dangerous assumption here. To my
        > > understanding one can determine the set of fragments by looking at the
        > > marker bit for the packets. From first 0 after a 1, until and including the
        > > packet with a m=1. If that is your intention for how one should do it, so
        > > that it works for multiple documents to share epoch and thus RTP timestamp
        > > documents I think this needs to be made explicit.
        > >
        > > In section 11.1 it says:
        > >
        > > In these situations, it is RECOMMENDED that streams use
        > > the same Synchronization Source and Clock Rate as the related media.
        > >
        > > You do need to insert "Time" before Synchronization source to not be
        > > misinterpret to mean SSRC. Or maybe better is to say "clock source".
        > >
        > > Cheers
        > >
        > > Magnus Westerlund
        > --
        > Cheers
        >
        > Magnus Westerlund
        >
        >
        > ----------------------------------------------------------------------
        > Networks, Ericsson Research
        > ----------------------------------------------------------------------
        > Ericsson AB                 | Phone  [phone]
        > Torshamnsgatan 23           | Mobile [phone]
        > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
        > ----------------------------------------------------------------------
        >
        >
        >
        > _______________________________________________
        > Audio/Video Transport Core Maintenance
        > [e-mail]
        > https://www.ietf.org/mailman/listinfo/avt
        --
        Cheers

        Magnus Westerlund


        ----------------------------------------------------------------------
        Networks, Ericsson Research
        ----------------------------------------------------------------------
        Ericsson AB                 | Phone  [phone]
        Torshamnsgatan 23           | Mobile [phone]
        SE-164 80 Stockholm, Sweden | mailto: [e-mail]
        ----------------------------------------------------------------------