Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel - modification proposals

[Gunnar Hellström <[e-mail]>]

Christer,

I am satisfied with all your responses and actions except for number 18, 
the multi-party case. I will handle that in a separate answer.

For number 16, I had no reason for not inserting "real-time text" in the 
sentence you asked about.

Thanks, no inline comments here.

Gunnar

Den 2019-08-24 kl. 12:04, skrev Christer Holmberg:
> Hi Gunnar,
>
> Thank You for the detailed review and suggestions! Please see inline.
>
>> Here is a first set of modification proposals for the topics I have mentioned, and a few more editorial, but
>> lacking the end-to-end encryption requirement for the interworking case that I do not know how to handle.
> Maybe that should be looked at as a separate delivery, probably in a separate WG (AVT?).
>
>> I hope you can handle the simple change proposal format.
> That's fine - based on the outcome of your comments I will update the pull request :)
>
> -----------------------------------------------------------------------
>
>> 1. Change the title from
>>
>> "T.140 Text Conversation over WebRTC Data Channels"
>>
>> to
>>
>> "T.140 Real-time Text over WebRTC Data Channels"
>>
>> Reason: Real-time text is the current term for Text Conversation
> See my reply to comment #3.
>
> ------------------------------------------------------------------------------------------
>
>> 2. Modify the second line of the abstract from
>>
>> "transport mechanism for the ITU-T Protocol for multimedia application"
>>
>> to
>>
>> "transport mechanism for Real-time text media using the ITU-T Protocol for multimedia application"
>>
>> Reason: Real-time text is an important keyword for this media.
> See my reply to comment #3.
>
> -------------------------------------------------------------------------------------
>
> 3. In 1. Introduction, line 3, change from
>
>>     "conversation, also known as realtime text or text telephony. The"
>>
>> to
>>
>>     "conversation, also known as real-time text.  The"
>>
>> Reason: Text telephony may use T.140, but is not required to have the same functionality as true real-time text.
> I will change as suggested.
>
> --------------------------------------------------------------------------------------------
>
> 4. In 1. Introduction, last sentence of first paragraph, modify:
>
>> The  native transport for IP networks is based on the Real-time Transport
>>     Protocol (RTP) [RFC4103].
>>
>> to
>>
>> The native transport for IP networks is RFC 4103 RTP Payload for Text Conversation" [RFC4103] based on the Real-time Transport
>>     Protocol (RTP).
>>
>> Reason: It looked confusing with the RFC4103 reference after the RTP abbreviation.
> I will change as suggested, but I don't think we need to say "RFC 4103" in the beginning of the sentence.
>
> So, something like:
>
> "native transport for IP networks is "RTP Payload for Text Conversation" [RFC4103], based on the Real-time Transport Protocol (RTP) [RFC3550]."
>
> -----------------------------------------------------------------------------------------------------------------
>
> 5. In section 1. Introduction, first NOTE, second line there is an unbalanced right bracket.:
>
>> "to the originally introduced concept of a "T.140 data channel"] for"
>>
>> Proposal: either delete the bracket or modify to [T140]
> I will remove the bracket, as there is a reference at the end of the sentence.
>
> --------------------------------------------------------------------------------
>
> 6. In 1. Introduction, the first NOTE,
>
>> Delete "back in 1998"
>>
>> Reason: Irrelevant
> Will be removed.
>
> -------------------------------------------------------------------------------------
>
> 7. In 1. Introduction, number the notes NOTE 1 and NOTE 2.
>
> Will add NOTE numbers.
>
> --------------------------------------------------------------------------------------
>
> 8. In 3.1 third line, delete "(m= line)". The correct term is "media description" that is already correctly used.
>
> In other documents (e.g., BUNDLE) we say "SDP media description (m= section)" on the first occurrence, and later only 'm= section'.
>
> Maybe would could do the same in this document? I do agree that we don't need to say 'SDP media description' and 'm= section/m= line' in every occurrence.
>
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> 9. In 3.1 Use of dcmap Attribute:
>
>> The second paragraph says that the "label" attribute MUST be included, but the next to last line says
>> "without any label" and the example lacks the label.
>>
>> sdpneg says that "label" is optional, so I suggest that thestatement in the second paragraph is modified to not require "label"
> Will fix as suggested.
>
> -------------------------------------------------------------------------------------------------------------
>
> 10. In 3.2, first paragraph, third line, delete "(m= line)".
>
> See my reply to comment #8.
>
> ------------------------------------------------------------------------------
>
> 11. In 4th paragraph in 3.2, change "cpc" to "cps"
>
> Will fix.
>
> ------------------------------------------------------------------------------------------
>
>
> 12. At the end of 3.2, add the following about language negotiation
>
> You sent a follow-up e-mail regarding this this comment, so I will address it in a reply to that e-mail.
>
> ------------------------------------------------------------------------------
>
> 13. In 3.3 Example, first line, delete "(m= line)"
>
> See my reply to comment #8.
>
> -----------------------------------------------------------------------------
>
> 14. In 4.1, fourth bullet point, Deny session,    change:
>
>> "reject a request the establishment of a T.140 data channel,"
>>
>> to
>>
>> "reject a request to establish a T.140 data channel,"
> Will fix.
>
> ----------------------------------------------------------------------------------------------------
>
> 15. In 4.2, second paragraph, change "reduntant" to "redundant"
>
> Will fix.
>
> ---------------------------------------------------------------------------------------------------
>
> 16. In 4.3, add at the end of the current paragraph:
>
> "The user requirements for smooth flow and low latency in text conversation should be considered when assigning a buffer time.
> The default transmission interval of 300 milliseconds from [RFC4103] or lower is recommended also for T.140 data channels."
>
> I will add the text.
>
> Is there a reason why you want to say "text conversation" instead of "real-time text conversation" in this case?
>
> ---------------------------------------------------------------------------------------------------------------------------
>
> 17. Add a new section 4.4
>
>> "
>>
>> 4.4 Loss of T140blocks
>>
>> In case of network failure or congestion, T140 data channels may break.
>> If this happens but the session sustains, it is recommended that a low number of retries are made to reconnect
>> the T140 data channels. If reconnection is successful, an evaluation shall be made if any T140blocks were lost.
>> Retransmission of already transmitted T140blocks MUST be avoided, and missing text markers [T140ad1] should
>> be inserted in the received data stream where loss is detected or suspected and presented to the user.
>>
>> If instead also the session breaks, the break is accepted as end of session and the user should be informed about the unexpected end of session.
>>
>> "
> I will add the text (with some minor editorial changes).
>
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> 18. Add a new section 4.5
>
>> 4.5 Multi-party considerations
>>
>> Implementations should be prepared to accept establishment and use of multiple T140 data channels in order to support multi-party sessions
>> with real-time text. A number of scenarios are available for how multi-party sessions can be supported in the WebRTC environment.
>> Implementations may select any suitable scenario.
> I don't think we need the two last sentences.
>
> Also, in some cases all communication will go via a central server, so there will only be one T.140 data channel towards each participant.
>
> So, maybe something like:
>
> "In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly
> with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels."
>
>> Presentation should be made so that the source of the real-time text is perceivable and the relative time relations in the conversation approximately presented.
>> The "label" attribute may be used to convey a presentable source.
> I am not sure I understand the "relative time relations" part.
>
> Regarding the source, perhaps extending my suggested text above with something like:
>
> "In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly
> with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels. The label
> attribute can be used to provide information that helps an implementation to distinguish between the T.140 data channels."
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
> 19. chapter 5, Gateway considerations is proposed to be replaced by the
> following:
>
> In order to not make the e-mails too long, I will address this in a separate reply :)
>
> Thanks!
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]