Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 07 November 2019 16:51 UTC
Return-Path: <gunnar.hellstrom@omnitor.se>
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 1EFBE120978 for <mmusic@ietfa.amsl.com>; Thu, 7 Nov 2019 08:51:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=omnitorab.onmicrosoft.com
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 mGv53vt2apUU for <mmusic@ietfa.amsl.com>; Thu, 7 Nov 2019 08:51:24 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130138.outbound.protection.outlook.com [40.107.13.138]) (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 F2D6F120972 for <mmusic@ietf.org>; Thu, 7 Nov 2019 08:51:23 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dfNXZlt1couoNz9ZG3smf6MgiKBpvnVKHnhLbgTBTLugC5hcV/eRPlpWEAlYYiTcrXaT2lQj7vbzSywxuYDxScspwcTNr+uIsLsUekJ9Gjm8JcBEnRho85kGIrCq7iZFQenq+sfQ3b85shVDl0iCj9GinWDLz5F4UWBHzMtaN/4CmUnD2BY5YwE0w6ERNJxnDFrXZEVZStoXRbaUnZEUqHkn1JJ1rw51WYPJw8limaedPEEkaffD3eBOA5VqgekPSZAtOlz9uyB7H9AvsFdTskdmAYofCR7uagauKFNXxZWIaXNUut83jP055ThFA9MSc5Aeggg0+lcgqsF20KhUHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KjJ9cNyvImJfmI42mElcRpNRqORCvZ5jfbBI4W5Z7HA=; b=jM4BpTpyP3D25BHCGo69pl6C/I9XKxIaZ+bhnLLFueSMSkhLGBcIJOmR4PvNuqa7LDOP0BbqR3LJviBSZ1HMqRPro2Fv2a7XVEyCewLN/aQVL+exazxqRTnaZ5NCqLb1UlawAajroiDeSPUIp+e0vRWxyQrK0dpUj8pTuIRLmNoWnlPeLXXWKHljZWCkKn2s15M6ULVvubtxnyeWLJSTMEXzdsCtkXXusXuIMxwmrQNgCygii7UdK656L5pV4DIePbomIKx7vXyD/AVB2w/ckAMoWMG2zuO7FD2e64gNT6YjdbUZw7YhvK0a3Wyxy+6NobYYsdckeEt6PB3UVX5q1w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=omnitor.se; dmarc=pass action=none header.from=omnitor.se; dkim=pass header.d=omnitor.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnitorab.onmicrosoft.com; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KjJ9cNyvImJfmI42mElcRpNRqORCvZ5jfbBI4W5Z7HA=; b=H+Mp3rN1DZZEzIGdiXgPHRzgDvjSQw6qLwQjiwxz15f99dW/imSSRUlpYMff7ncExqBMUURpPUnHQXxwpmvX7qHh5DuHcELorDQMOC/2uTPQ9PkxsJqxAuYr3/tNaE5MjmyGfxMAhGTXmzhwiVqRDg4zAReS2LSpTg7BBwzkmi8=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0301.EURP193.PROD.OUTLOOK.COM (52.134.123.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Thu, 7 Nov 2019 16:51:20 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1dfd:c8d1:a788:87cd]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1dfd:c8d1:a788:87cd%7]) with mapi id 15.20.2430.023; Thu, 7 Nov 2019 16:51:20 +0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Bo Burman <bo.burman@ericsson.com>, "mmusic (mmusic@ietf.org)" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
Thread-Index: AQHVk909yEtpzH2MKEqkZmDSG+/rpKd9K6IAgACj3A+AAHGsCYAAFbG3gABHZYCAAN5BAIAAGIoAgAAbjQCAABJ7gP//9UiAgAAYhACAAB6JgA==
Date: Thu, 07 Nov 2019 16:51:19 +0000
Message-ID: <3d0479a3-3221-bcc0-d9f6-b7a3d292ffbc@omnitor.se>
References: <31B83060-1653-48A1-AB78-9D2418B49CC6@ericsson.com> <5742e425-788d-7d10-0e68-0a75bea74f3a@omnitor.se> <HE1PR07MB31619BBC3A73260C14CC693693790@HE1PR07MB3161.eurprd07.prod.outlook.com> <VI1P193MB06698D287FB68B4DDE435E98FB790@VI1P193MB0669.EURP193.PROD.OUTLOOK.COM> <HE1PR07MB31610CA6717330B5823EC72F93790@HE1PR07MB3161.eurprd07.prod.outlook.com> <c45c5029-72b2-d25f-4a3f-bc1d1c445a1f@omnitor.se> <HE1PR07MB3161BB6FFAC11E637111E0D193780@HE1PR07MB3161.eurprd07.prod.outlook.com> <f79712fd-84fd-3289-f7cb-97e547b2537d@omnitor.se> <FC883EE8-E05F-4E3E-ABF9-A1E94EB61F52@ericsson.com> <169e65c6-207f-3ccd-6c2c-9268d425e2fb@omnitor.se> <HE1PR07MB32593108119FAE1F07C2D7478D780@HE1PR07MB3259.eurprd07.prod.outlook.com> <E6D08311-B137-4583-9AAD-74C1BA728CFB@ericsson.com>
In-Reply-To: <E6D08311-B137-4583-9AAD-74C1BA728CFB@ericsson.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: GV0P278CA0015.CHEP278.PROD.OUTLOOK.COM (2603:10a6:710:26::25) To VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (2603:10a6:800:159::12)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [83.209.227.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c3c7d2ef-98f4-4f4b-872c-08d763a2b6ae
x-ms-traffictypediagnostic: VI1P193MB0301:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <VI1P193MB030112E7A25C5170BDC5DED2FB780@VI1P193MB0301.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0214EB3F68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(396003)(39830400003)(136003)(189003)(199004)(13464003)(3846002)(31696002)(26005)(110136005)(305945005)(186003)(86362001)(85182001)(486006)(7736002)(14444005)(2616005)(256004)(81166006)(81156014)(8676002)(316002)(11346002)(2906002)(8936002)(446003)(561944003)(25786009)(36756003)(476003)(6116002)(66556008)(6486002)(66946007)(966005)(508600001)(229853002)(14454004)(66446008)(85202003)(76176011)(6436002)(52116002)(71190400001)(71200400001)(6506007)(53546011)(102836004)(386003)(66066001)(31686004)(6512007)(6306002)(6246003)(66476007)(99286004)(66574012)(30864003)(5660300002)(64756008); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0301; H:VI1P193MB0669.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: udWPv87FWL7vywfN5S7LY+PJkt4iI/RaT9HT+P2CWIRFsFfSHYEqy3xFsycqGXC27+l6btbmeXPMI8fXEyBcrh317BSuYJT5lRp31VuK7bx7w1eQuDdTqZ+6kJbiBuRcsG2KFp02GLySGZ0/n3dpPJ7RlBrWiF7a1bmgqJr4UmhXcM0drtKsVan1vzWcBl6q9bL6NpZam+p710D3sEhZYjYjIL3a+DcFMsqujTkeFlEi+UuvTtUo9cF0cdGOEHge9+aTafBloOHVPRmEwGCZkAeFodKonm6T84jrmyhjp+d6JqSfINted7CZHeDAKS3K+UT4K9aXBiuwxsIFc3WBT7Dbbitvz8mlf+jPznHDFcit0DJxEg8PmrbJ11uXz+ZzaeLJOuRykDK0dQQdOoGc2cXT1OMkZHrLu7LHI9XKnJ6aE0TUSyCVWPxE0NZyCXExKY1QV7L9qIRIt3xRZ6t1W9yiwyvkBN9zzNGgsR2AL0w=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <D38CBB4F8C4DC34EB5D0B658B867788D@EURP193.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: c3c7d2ef-98f4-4f4b-872c-08d763a2b6ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 16:51:19.9456 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DkKQ45IteRy1pb+NV6kHEAOiyTca/xpk/3go6YCVFU/xZPEZI021pdRHTf79xrBc1bypWMTLwax/a0i55n0RcIbQ0I/l7LZZudDHQP9qUfQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0301
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/NaCEwl2aGkguFSg5dO4Km1MN8ZA>
Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments
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: Thu, 07 Nov 2019 16:51:35 -0000
Hi, I am sorry, I have not yet found a reference for the common look of messages with a leading source label that I called "IRC style". Anyone knows? Regards Gunnar Den 2019-11-07 kl. 16:01, skrev Christer Holmberg: > Hi, > > I have updated the pull request based on Bo's technical comments. Please take a look. > > https://github.com/cdh4u/draft-datachannel-t140/pull/52 > > Gunnar, which RFC should I add as reference for the IRC labels? > > Regards, > > Christer > > > > On 07/11/2019, 15.34, "Bo Burman" <bo.burman@ericsson.com> wrote: > > Yes, I agree that should resolve the issue I had with the text. > Thanks, > /Bo > > > -----Original Message----- > > From: Gunnar Hellström <gunnar.hellstrom@omnitor.se> > > Sent: den 7 november 2019 14:13 > > To: Christer Holmberg <christer.holmberg@ericsson.com>; Bo Burman > > <bo.burman@ericsson.com>; mmusic (mmusic@ietf.org) > > <mmusic@ietf.org> > > Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140- > > usage-data-channel-07 - Bo's technical comments > > > > Hi, > > > > Christer, I accept your proposal below. With the remaining text it should be > > apparent for all that the solution has limitations. > > > > I hope also Bo thinks that the issues are solved now. > > > > Regards > > > > Gunnar > > > > > > Den 2019-11-07 kl. 14:06, skrev Christer Holmberg: > > > Hi, > > > > > >>> In the first paragraph we say that one needs to use separate data > > >>> channels, so it sounds strange to then have a note saying that is not true. > > Also, the way you suggest the text makes it look like you are defining a > > mechanism for using a single channel. > > >> Yes, I realized the conflict and tried to avoid it by the words > > >> "limited functionality multi-party RTT presentation in one display area", > > and "This presentation style does not meet all RTT requirements". > > >> > > >> But maybe that was not obvious. So, I accept your proposal below with > > >> some modifications > > >> > > >>> Maybe something like this: > > >>> > > >>> "The usage of a single T.140 data channel, without any protocol > > extensions, would require the conference server to only forward > > >>> real-time text from one source at any given time, and e.g., include IRC > > style text labels in the real-time text in order for the receiver > > >>> to separate real-time text from different sources. The procedures of > > such mechanism is outside the scope of this document." > > >> Yes, quite good, I suggest a few modifications to: > > >> > > >> "The usage of a single T.140 data channel, without any protocol > > >> extensions, would require the conference server to only forward > > >> real-time text from one source at any given time, and e.g., include > > >> IRC style text labels in the real-time text in order for the receiver to > > present real-time text from different sources separated. The procedures of > > such mechanisms cause functional limitations and are outside the scope of > > this document." > > > I am ok to replace 'separate' with 'present', but with the modification to the > > last sentence you would still have the question what those 'functional > > limitations' are, and we would need to include additional text... > > > > > > So, I suggest that we remove the text about functional limitations. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > From: Gunnar Hellström mailto:gunnar.hellstrom@omnitor.se > > > Sent: Wednesday, November 6, 2019 9:44 PM > > > To: Christer Holmberg mailto:christer.holmberg@ericsson.com; Bo Burman > > > mailto:bo.burman=40ericsson.com@dmarc.ietf.org; mmusic > > > (mailto:mmusic@ietf.org) mailto:mmusic@ietf.org > > > Subject: Re: [MMUSIC] Starting shepherd's review of > > > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments > > > > > > Hi, > > > Even if I accepted to delete the last sentence in section 5 on multi-party, I > > want to propose a solution that might better address the original issue 5. > > > > > > So, this is a proposal for new wording of the last sentence in 5, as a solution > > on issue 5: > > > "Conference mixers that use a single T.140 data channel > > > to transmit real-time text towards clients might however without any > > protocol extensions produce a limited functionality multi-party RTT > > presentation in one display area. Only one source at a time can be presented > > in real-time, but switch of source of text to display in real-time can be made > > automatically by the mixer and at suitable points in the text streams. Sources > > could be identified by inline text labels in IRC style. This presentation style > > does not meet all RTT requirements and if used, should be a temporary > > fallback method for conference-unaware clients." > > > > > > This wording is a self sustained description on what is possible and would > > also match better the recently revived work on multi-party rtt. > > > > > > Regards > > > > > > Gunnar > > > > > > > > > > > > Den 2019-11-06 kl. 17:29, skrev Christer Holmberg: > > > Bo, are you ok with the proposals? > > > > > > Regards, > > > > > > Christer > > > > > > > > > From: Gunnar Hellström mailto:gunnar.hellstrom@omnitor.se > > > Sent: Wednesday, November 6, 2019 5:16 PM > > > To: Christer Holmberg mailto:christer.holmberg@ericsson.com; Bo Burman > > > mailto:bo.burman=40ericsson.com@dmarc.ietf.org; mmusic > > > (mailto:mmusic@ietf.org) mailto:mmusic@ietf.org > > > Cc: 'mailto:mmusic-chairs@tools.ietf.org' > > > mailto:mmusic-chairs@tools.ietf.org > > > Subject: SV: [MMUSIC] Starting shepherd's review of > > > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments > > > > > > Christer, > > > I agree with your proposals. > > > > > > Regards > > > Gunnar > > > > > > ---------------------------------------------------------------------- > > > Gunnar Hellström > > > Omnitor > > > mailto:gunnar.hellstrom@omnitor.se > > > +46 708 20 42 88 > > > > > > Från: Christer Holmberg mailto:christer.holmberg@ericsson.com > > > Skickat: den 6 november 2019 09:58:30 > > > Till: Gunnar Hellström mailto:gunnar.hellstrom@omnitor.se; Bo Burman > > > mailto:bo.burman=40ericsson.com@dmarc.ietf.org; mmusic > > > (mailto:mmusic@ietf.org) mailto:mmusic@ietf.org > > > Kopia: 'mailto:mmusic-chairs@tools.ietf.org' > > > mailto:mmusic-chairs@tools.ietf.org > > > Ämne: Re: [MMUSIC] Starting shepherd's review of > > > draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's technical comments > > > > > > Hi, > > > > > > --- > > > 3) In section 4.2.1, it says that “If the 'fmtp' attribute is not included, it > > indicates that no maximum character transmission rate is indicated. It does > > not mean that the default value of 30 applies”; >why is this deviation from > > RFC 4103 chosen? Does it introduce a risk for interoperability problems with > > systems that also doesn’t use fmtp but interprets it as maximum 30 cps? > > > Gunnar? > > > [GH] I don't know why this deviation was chosen. But I have not > > commented it. You are right that it may introduce an increased risk for > > interoperability problems. But RFC 4103 has a precaution. In chapter 6, where > > the cps is introduced, it is said: > > > " > > > receivers of text/t140 MUST be designed so they can handle temporary > > > reception of characters at a higher rate than this parameter > > > specifies. As a result malfunction due to buffer overflow is avoided > > > for text conversation with human input." > > > > > > (the reason for this note is for backward compatibility with RFC 2793, > > > the obsoleted predecessor of RFC 4103, so it is not exactly our case, but still > > valid.) We have discussed the risk that implementations may not implement > > setting or reading the dcsa attributes because of the complexity to do so > > alongside with the WebRTC API. That situation may cause a situation where a > > sent cps parameter is not obeyed. So the case is quite similar to the case in > > RFC 4103, and applications would be required to prepare for handling > > temporary reception at high rates. > > > The intention of T.140 is to handle real-time text conversation between > > humans. Huge cut and paste chunks of text cannot be required to be > > handled rapidly. The highest speed human interaction would be with speech- > > to-text applications. A very rapid speaker may produce 200 words per > > minute. That is 17 characters per second. The speech-to-text applications > > often makes corrections by long backspaces and resendings. That may add 10 > > characters per second in the total. That results in a practical need of up to 27 > > characters per second for one stream. > > > This calculation shows that for two-party calls, it would not hurt to use the > > same convention regarding cps default as RFC 4103 (30). > > > For centralized conference solutions with just one data channel from the > > conference server discussed in section 5.5, the need would be a multiple of > > that rate (27) corresponding to the number of simultaneous text senders. In > > well managed conferences this multiple is very close to one. > > > The figures above are extremes. Currently most use of RTT is typing at > > maximum speeds of about 7 characters per second. > > > Leaving the default to unrestricted might attract some misuse by > > implementations or users trying to use the T.140 data channel for data > > transmission of data totally different from the intended real-time text. > > > Conclusion after all this discussion: > > > Neither leaving the default to unlimited, nor changing to a default of 30 cps > > as in RFC 4103 seems very critical. Any solution will do. > > > > > > [Christer] I am pretty sure IESG would ask about this too, I suggest that we > > change the default to 30 cps. > > > > > > --- > > > 5) In section 5.5, in the note, it says ‘…with limitations in real-time > > performance and presentation style’; I think it would be helpful to briefly > > elaborate on what type of limitations would be >expected and why. > > > I think it is explained in the other text of the section. For example, using a > > single data channel without any protocol extensions would not allow to > > separate the sources etc. > > > [GH] I think we can offer a bit more text at the end of the note to clarify. > > How about this: > > > "T.140 shows two examples of presentation layout for real-time text, one > > being column oriented, with one column per participant, another being > > arranged in one column with labels identifying the beginning of text from > > each participant and text from a number of participants received and placed > > in places corresponding to these different participants. With a conference > > mixer using one text stream and not applying any presentation protocol > > extension would only be able to produce a string for presentation in one > > column, including a source label in the beginning of text from one participant > > and only show text in real time from one participant at a time, shifting real- > > time presented participant at suitable points in the text stream. (end of > > phrase, end of sentence, line separator, long delay etc.). This presentation > > style may not be preferred by the user and it may cause delay before > > presentation of text from other than the currently presenting participant." > > > Pew, maybe too long and detailed.... > > > > > > [Christer] Or, could we simply remove the last sentence ("Conference > > mixers that...")? The 1st paragraph already says why separate channels are > > needed, and the note says that future extensions may allow usage of a single > > channel, so I think it is pretty clear that using a single channel without any > > such extensions would come with limitations. > > > > > > --- > > > > > > 6) In section 6, bullet “If the gateway detects or suspects loss of data on the > > RTP stream…”; shouldn’t it await possible redundancy first and missing text > > marker is inserted only when the used >redundancy is not capable to repair > > the loss? > > > Gunnar? > > > [GH]The intention was that it would mean "after using possibly received > > redundant data". You could interpret "loss of data" to mean that (instead of > > "loss of packets"), but let me try an improvement: "If the gateway detects or > > suspects loss of data on the RTP stream, after use of possibly received > > redundant data, …" > > > > > > [Christer] What about? > > > > > > > > > "If the gateway detects or suspects loss of data on the RTP stream, and the > > lost data has not been retrieved using a redundancy mechanism, the > > gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data > > sent on the outgoing T.140 data channel." > > > --- > > > > > > 12) In section 11.1, in the [T140ad1] reference, is “aEUR” really part of the > > name? The name I find listed on the ITU-T web is “ITU-T T.140 (1998) Add. 1 > > (02/2000)”, and the title in the document >itself seems to be “Protocol for > > multimedia application text conversation; Addendum 1”. > > > Interesting. There is no "aEUR" in the XML file, so this seems to be > > something created by XML2RFC. > > > > > > The intended title is: > > > > > > Recommendation ITU-T.140 – Addendum 1 (02/2000), "Protocol for > > multimedia application text conversation" > > > > > > I will fix it. > > > [GH] I chased a number of such occurrences earlier. I think it was because > > your editor inserted an unusual slanting quotation mark. Note that there is > > also a double quotation mark on the third line of the same reference. > > > > > > [Christer] I will double check. > > > > > > --- > > > > > > Regards, > > > > > > Christer > > > > > > > > -- > > > > + + + + + + + + + + + + + + > > > > Gunnar Hellström > > Omnitor > > gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > > -- + + + + + + + + + + + + + + Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg
- Re: [MMUSIC] Starting shepherd's review of draft-… Gunnar Hellström
- Re: [MMUSIC] Starting shepherd's review of draft-… Gunnar Hellström
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg
- Re: [MMUSIC] Starting shepherd's review of draft-… Gunnar Hellström
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg
- Re: [MMUSIC] Starting shepherd's review of draft-… Gunnar Hellström
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg
- Re: [MMUSIC] Starting shepherd's review of draft-… Gunnar Hellström
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg
- Re: [MMUSIC] Starting shepherd's review of draft-… Gunnar Hellström
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg
- Re: [MMUSIC] Starting shepherd's review of draft-… Gunnar Hellström
- Re: [MMUSIC] Starting shepherd's review of draft-… Bo Burman
- Re: [MMUSIC] Starting shepherd's review of draft-… Bo Burman
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg
- Re: [MMUSIC] Starting shepherd's review of draft-… Bo Burman
- Re: [MMUSIC] Starting shepherd's review of draft-… Gunnar Hellström
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg
- Re: [MMUSIC] Starting shepherd's review of draft-… Gunnar Hellström
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg
- Re: [MMUSIC] Starting shepherd's review of draft-… Christer Holmberg