Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel
Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 23 August 2019 15:10 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B056120046 for <mmusic@ietfa.amsl.com>; Fri, 23 Aug 2019 08:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZFc43YdV3n6 for <mmusic@ietfa.amsl.com>; Fri, 23 Aug 2019 08:10:21 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F92112004A for <mmusic@ietf.org>; Fri, 23 Aug 2019 08:10:20 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7NFAIhT009709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Fri, 23 Aug 2019 11:10:19 -0400
To: mmusic@ietf.org
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <CAOW+2duTuUc8FXT-BEhJioUnPsOkzYJddK=xAp1oWiBQCKM2vg@mail.gmail.com> <HE1PR07MB3161874ED292FA17015EF95E93AE0@HE1PR07MB3161.eurprd07.prod.outlook.com> <665185b6-c1e7-62c3-4e3b-e9374d23bfd5@omnitor.se> <DF010721-81CD-40DE-A848-DE4D36836FDA@ericsson.com> <ED158CF5-E059-482B-8D7E-934BA2C753A1@ericsson.com> <2201665d-5054-1872-d208-a0fe2d26095c@omnitor.se> <VI1PR07MB3167055C995D17D4BA9E36DE93A50@VI1PR07MB3167.eurprd07.prod.outlook.com> <8d14b055-8405-4a4f-174d-d7580bea348c@omnitor.se> <0DA1248C-41FC-4155-A578-29A19883857C@ericsson.com> <a91850b9-6e86-058f-dddd-3f856bcd6710@omnitor.se> <3c5cf655-2a0c-718c-a2f3-23baabfec786@alum.mit.edu> <96569f0b-bd90-8821-272b-d099e376600e@omnitor.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <db1c4953-f2ab-a026-4cfc-a994c3579b51@alum.mit.edu>
Date: Fri, 23 Aug 2019 11:10:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <96569f0b-bd90-8821-272b-d099e376600e@omnitor.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/u_76KrssrAkWHViYxk-dCHEVdO8>
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2019 15:10:24 -0000
Gunnar, On 8/23/19 10:56 AM, Gunnar Hellström wrote: > > Den 2019-08-23 kl. 16:26, skrev Paul Kyzivat: >> Gunnar, >> >> What is the source for these requirements? > Paul, assuming that you ask for the source for all requirements I have > mentioned: > > 1. The cited U-C 5 requirement for multi-party support is from section > 3.2 of draft-ietf-rtcweb-data-channel-13 > > 2. The end-to-end encryption between technologies is hearsay from the > NANC INTEROPERABLE VIDEO CALLING group. I do not have the exact source. > > 3. The user requirement for a maximum of one second delay from text > entry to far end presentation is from ITU-T F.700 / F.703 (the > requirement may be more strict nowadays because of new applications) > > 4. The requirement to insert a missing text marker in case of suspected > loss is from ITU-T T.140 amendment 1 > > 5. The requirement to try to reconnect in case of channel break is just > general user expectation on call behavior. If the session is still up > and the RTP media flows, then the RTT is also expected to be maintained. > Only if the whole session is also lost, then it is accepted to give up > on the RTT. Thanks! That helps me with context. ISTM that some of these are *system* requirements that can't be resolved with link-level requirements, though there may be link-level features that can contribute to a solution. Thanks, Paul > Regards > > Gunnar > >> >> Thanks, >> Paul >> >> On 8/23/19 8:51 AM, Gunnar Hellström wrote: >>> I hope I can stop introducing new topics soon, and contribute to >>> resolving them instead... But another topic to cover is multi-party >>> session support. The requirement is: >>> >>> U-C 5: Realtime text chat during an audio and/or video call with an >>> individual or with multiple people in a conference. >>> >>> I hope that will be straightforward. >>> >>> /Gunnar >>> >>> >>> >>> Den 2019-08-23 kl. 12:09, skrev Christer Holmberg: >>>> Hi, >>>> >>>>>>> I want to add one issue for the security section: Can we specify >>>>>>> a way to achieve end-to-end encryption of T.140 >>>>>>> data between a WebRTC endpoint and a traditional SIP/RFC 4103 >>>>>>> endpoint through a gateway? I know that that is a >>>>>>> desired feature. >>>>>> How would you do that? The data channel uses DTLS encryption, and >>>>>> SIP/RFC 4103 uses SRTP encryption, so >>>>>> doesn't the gateway have to decrypt/encrypt the T.140 traffic? >>>>> I have just heard the requirement to have end-to-end >>>>> encryption of RTT, >>>>> I do not have the solution. One possibility would maybe be to >>>>> have media >>>>> encryption end-to-end as well as the two transport encryptions. >>>>> But that >>>>> complicates the possibility to insert the missing text markers >>>>> by the >>>>> gateway if text loss is detected. >>>> Yes. >>>> >>>> However, keep in mind that the scope of the draft is how to use SDP >>>> O/A to negotiate a T.140 WebRTC data channel. We DO include some >>>> text regarding interworking with SIP/RFC 4103, because we know there >>>> are environments where such interworking takes place. >>>> >>>> But, extending T.140 and/or RFC 4103 (e.g., defining a new >>>> application level encryption mechanism for T.140) is outside the scope. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> > >>>> > >>>> > Den 2019-08-22 kl. 16:28, skrev Christer Holmberg: >>>> >> I have created a pull request, which will be used for the >>>> changes based on Gunnar's comments: >>>> >> >>>> >>https://protect2.fireeye.com/url?k=f453465c-a88743e3-f45306c7-868f633d >>>> >> >>>> bf25-4deb49c05b8a2375&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-d >>>> >> atachannel-t140%2Fpull%2F5 >>>> >> >>>> >> Regards, >>>> >> >>>> >> Christer >>>> >> >>>> >> On 22/08/2019, 13.39, "mmusic on behalf of Christer >>>> Holmberg"<mmusic-bounces@ietf.org on behalf of >>>> christer.holmberg@ericsson.com> wrote: >>>> >> >>>> >> Hi Gunnar, >>>> >> >>>> >> Thanks you for your support (I assume :) and comments >>>> on the draft! >>>> >> >>>> >> See inline. >>>> >> >>>> >> >A couple of comments: >>>> >> >1) In 3.2, the attribute "cps" is misspelled "cpc" once. >>>> >> >>>> >> Will fix. >>>> >> >>>> >> --- >>>> >> >>>> >> >2) Section 5 has some historical references to >>>> real-time text transports that may not be of much interest anymore >>>> >> >and instead confuse the reader, while some other more >>>> relevant transports may be added. >>>> >> >>>> >> I took these from the schwarz draft. You probably know >>>> better >>>> >> than me which ones are relevant, so feel to suggest which >>>> one(s) >>>> >> should be removed, and which one(s) should be be added :) >>>> >> >>>> >> >I would also like to discuss if it could be possible >>>> to have a few general recommendations on the webrtc to sip/rfc4103 >>>> case without >>>> >> >the problems you see with having a detailed gateway >>>> section. >>>> >> >>>> >> The second last paragraph covers some things on the >>>> media plane (out of order and loss of RTP packets) that I think are >>>> worth mentioning. >>>> >> >>>> >> As far as SDP interworking is concerned, this draft >>>> defines the m- line for T.140 data channel, and RFC 4103 defines the >>>> m- line for T.140 RTP, and the interworking should be very straight >>>> forwards. Do you have something specific in mind regarding general >>>> recommendations? >>>> >> >>>> >> --- >>>> >> >>>> >> > 3) Reliability. Section 3.1 implies that the channel >>>> is used in the reliable and ordered mode. We have been discussing >>>> back and forth >>>> >> > if that is the right choice for real-time text. I >>>> tend to think it is, but it might be useful to discuss it once >>>> again. The traditional user >>>> >> > requirement on real-time text is that produced >>>> characters shall be presented to the receiver within one second from >>>> their creation. >>>> >> > Modern usage in speech-to-text applications may >>>> require more rapid transmission. As I understand it, the reliable >>>> mode of the >>>> >> > data channel may imply long periods of choked >>>> transmission in case of network problems or by influence of heavy >>>> transmission >>>> >> > in another channel. As long as this happens only in >>>> case of network problems, I now tend to think that that might be >>>> acceptable. >>>> >> > The effects of being forced to use an unreliable >>>> channel are so far-going so I would like to avoid that. >>>> >> > However, the word "reliable" is misleading. A >>>> "reliable" channel is not really reliable. It can break in case of >>>> problems. >>>> >> >>>> >> True, but "reliable" is the terminology used in both >>>> RFC 4960 (SCTP) and draft-ietf-rtcweb-data-channel. >>>> >> >>>> >> > I think some recommendations should be inserted in >>>> section 4 about what to do when a channel breaks. The natural action >>>> >> > would be for both sides to try to figure out what >>>> was the last T.140 data that was transmitted and received, and then >>>> try to >>>> >> > reconnect and resume transmission if successful. If >>>> any T.140 data was lost during the break, that state should be marked >>>> >> > by inserting the "missing data" T.140 indicator in >>>> the received stream. There needs of course also be a recommended action >>>> >> > if it turns out to be impossible to reconnect after >>>> a low number of retries. >>>> >> >>>> >> I can for sure add some text about that. Are there >>>> generic T.140 recommendations for failure that we can reference, or >>>> do you think there is something T.140 data channel specific? >>>> >> >>>> >> Regards, >>>> >> >>>> >> Christer >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> mmusic mailing list >>>> >>mmusic@ietf.org >>>> >>https://www.ietf.org/mailman/listinfo/mmusic >>>> >> >>>> >> >>>> > -- >>>> > ----------------------------------------- >>>> > Gunnar Hellström >>>> > Omnitor >>>> >gunnar.hellstrom@omnitor.se >>>> > +46 708 204 288 >>>> > >>>> > _______________________________________________ >>>> > mmusic mailing list >>>> >mmusic@ietf.org >>>> >https://www.ietf.org/mailman/listinfo/mmusic >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellström >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >
- [MMUSIC] Draft new: draft-holmberg-mmusic-t140-us… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Belling, Thomas (Nokia - DE/Munich)
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Bernard Aboba
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… R.Jesske
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Bernard Aboba
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Paul Kyzivat
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Paul Kyzivat
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- [MMUSIC] draft-holmberg-mmusic-t140-usage-data-ch… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Roni Even (A)
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Roni Even (A)
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Roni Even (A)
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Roni Even (A)
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat