Re: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06

[Christer Holmberg <[e-mail]>]

Hi Gunnar,

Please see inline.

...

    >>> 4. In 3, delete "using the RTP timestamp". It is usually the sequence number that helps finding where data is missing.
    >> The sequence number is used to detect missing data, but the timestamp is used for data redundancy.
    >>
    >>     "The RTP header is followed by one or more redundant data block
    >>     headers: one for each redundant data block to be included.  Each of
    >>     these headers provides the timestamp offset and length of the
    >>     corresponding data block,"  (RFC 4103, Section 4.1)
    >
    > {GH] Well, that is the coding of the redundancy data block, but not how 
    > loss is detected.

The beginning of the sentence says:

   "Instead, when RTP based transport is used, the RTP sequence number is used
    to detect packet loss and out-of-order packets"

    > I do not know any implementation that bothers about 
    > details in the RTP timestamp for detecting loss. 

    The text doesn't say that :)
 
...  

    >>> 10. In 4.2.3.1.2 second paragraph. The wording about not indicating 'sendrecv' means implicit marking as sendrecv is a bit confusing and may
    >>> cause implementers to believe that they must always provide explicit marking of direction. A remedy might be to swap order between the two
    >>> sentences in the second paragraph and insert "(implicitly or explicitly)" after "sendrecv" to make the paragraph wording:
    >>> "If the answerer does not explicitly mark the data channel, a 'sendrecv' attribute inside a 'dcsa' attribute is implicitly applied. If the offerer
    >>> marked the data channel as sendrecv (implicitly or explicitly), the answerer SHOULD mark the data channel as sendrecv(implicitly or explicitly),
    >>> sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. "
    >> I don't like the SHOULD. We define the procedures for an answerer that do support the procedures.
    >>
    >> The last paragraph of Section 4.2.3.1.1 already points out that the answerer may not support setting the direction attribute, and how the offerer handles it.
    >>
    >> Other than that, I am fine with your suggestion to change the ordering.
    >>
    >> Or, we could make it even shorter:
    >>
    >>     "If the offerer marked the data channel as sendrecv (implicitly or
    >>       explicitly), the answerer MUST mark the data channel as sendrecv
    >>       sendrecv (implicitly or explicitly), sendonly, recvonly or inactive with
    >>       a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute inside
    >>       a 'dcsa' attribute."
    > [GH] accepted, ( but you have double sendrcv on lines 2-3 in your 
    > proposal above)

    Will be fixed.

...

    >>> 12. In 5.2 Change the header to "5.2 Data Encoding, Sending and Receiving"
    >>> and insert last this important hint for interoperability.
    >>> "The T.140 coding details contain information on optional control codes intended for controlling the
    >>> presentation that may not be supported by the presentation level of the receiving application. The
    >>> receiving application MUST handle reception of such T.140 control codes properly (e.g. ignore them)
    >>> even if their effect on presentation is not supported."
    >> That is not data channel specific, is it? I assume it is already part of T.140, so we shall not specify new MUST requirements.
    >>
    >> With that, I suggest to not change the title.
    >    
    > [GH] Right, but it is an important reminder for interoperability between 
    > implementations. So, make it a NOTE instead and change the MUST to 
    > something suitable (needs to ?).

What about?

   "NOTE: The T.140 encoding might also contain control codes intended for controlling the presentation
   of the real-time text. As defined in [T140], a T.140 endpoint is required to ignore received control codes
   that it does not support."

...

    >>> 13. In 6. Gateway considerations:
    >>> At the end of bullet point 4 add "in reception"
    >> I think "was lost in reception" sounds strange.  What about "was lost due to the data channel failure"?
    > [GH] I wanted to point out in what direction it was lost. In T.140 data 
    > channels, the sender has in fact better opportunity than the receiver to 
    > detect if something was lost. Bullet point 4 was intended to tell about 
    > data received on the T.140 data channel to be sent on the RTP stream. I 
    > want to insert a new bullet point (see 14) for when the gateway detects 
    > loss in sending in the T.140 data channel. Therefore it should be clear 
    > that bullet point 4 is for the reception case. What about "was lost when 
    > receiving from the T.140 data channel due to the data channel failure" ?
    
    What about?

    "that data sent by the T.140 data channel endpoint has been lost."

Regards,

Christer




    > Den 2019-10-02 kl. 15:25, skrev Bo Burman:
    > Greetings MMUSIC ,
    >
    > This is to announce a 2 week WGLC on the draft:
    >
    >      https://protect2.fireeye.com/url?k=806502d9-dcecd8e4-80654242-0cc47ad93c0c-e10d1004cdda139e&q=1&u=https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.txt
    >
    > as Proposed Standard. Please review and provide any comments you may have on the document by Wednesday, October 16, 2019. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.
    >
    > Thanks,
    >
    > /Bo
    > (MMUSIC co-chair)
    >   
    >
    >
    > _______________________________________________
    > mmusic mailing list
    > mailto:[e-mail]
    > https://protect2.fireeye.com/url?k=a6662b9d-faeff1a0-a6666b06-0cc47ad93c0c-f61b6b0757d55756&q=1&u=https://www.ietf.org/mailman/listinfo/mmusic
    >
    -- 
    
    + + + + + + + + + + + + + +
    
    Gunnar Hellström
    Omnitor
    [e-mail]
    [phone]