Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 27 August 2019 21:40 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 379A0120113 for <mmusic@ietfa.amsl.com>; Tue, 27 Aug 2019 14:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=ericsson.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 sesE2svOSrJF for <mmusic@ietfa.amsl.com>; Tue, 27 Aug 2019 14:40:17 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70045.outbound.protection.outlook.com [40.107.7.45]) (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 2496812004D for <mmusic@ietf.org>; Tue, 27 Aug 2019 14:40:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NezohMYWXH6c6YRl/bBpfqban3tozlo5M8atoS+wwvWucqAIPK6CT4pVTX8Yj/otK5oEIWg0hB5/OQ0Vdrie0Cq5OgMt/Vpi8fVfxf6r2SSTYuWzeaQCe5UQ4auKS3g4qVyk4n9SaiNoCIuEL4DBFpndYCoHnl8zHsanv/fIxqQSUdfslkCULJzwU+UvfU8PBrj8XH87Z1aA60YhlNgIafu3+lbpmNuReULJ3UXqPQO8tcW24jrpDkz+DaKtUriDu5cp+ok4yv0cNU1eu22Z+I7V9bYYr8ymXqbtZCvtwQmN7f0M4jN2czeqtBNVOZAx7EJobK9EEolLtYR5OO6r5g==
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=FWwFvyp3PTazT0la0/QNrD62w0ZtoqUBRYWRWcvXoP4=; b=AQo2i94qs1AfQ9DeVvoqkq16Vq8QpIC2/darFcewHRx4yMPb7vjY2ry8t9rbMS8gyx5+vPz1/392BG+IVC2H8JJ8ZmLwf3rcjTkxFSLK3iQN1gJkKGhsk5v1bq3AhlK/0dMy+MQtr+rSiit9pXuhOhoFvCl2wGzYm5cj4ZhYxd6lq0IAU2ta1Sj+zj3nXbWdR9gy1twNyigmKl8EkphB7621DG0rSlLrIQPojfavDczlM+B0E04jRWRtZ97DCQcxSq8CBgvarUGOOc+yRrXWGvjqzMH5ruWSan8VmkR8RFS+5/noz/KA+AvD3j99Kio5ju7zNwgEDZVwjvpCIBv9Ug==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FWwFvyp3PTazT0la0/QNrD62w0ZtoqUBRYWRWcvXoP4=; b=kXkxJFEMcewbAjPCW5LXbi9P3tcNJmwrkcRxH65MHWs24ZONakQPQTZb6fW+Zs5QZkmUTN8fAh/zT3P5DukZCZiqhKU5JvKFCBP+oIkHoYvnEKgZn8BHC6Dj/ux22IMDmLPLZRQSzT6eSXRrZe/4ymgYhiYo7rDDIw+un9Fw/e8=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3323.eurprd07.prod.outlook.com (10.170.247.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.12; Tue, 27 Aug 2019 21:40:14 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d%6]) with mapi id 15.20.2220.013; Tue, 27 Aug 2019 21:40:14 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= <gunnar.hellstrom@omnitor.se>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
Thread-Index: AQHVWxEvddfWyrxgrkCFyNXjkjXeRqcLee8ggAAVyACAAAccYIAAyvMAgADbfAD//+kmAIAAM2qAgAA9LACAAA5bv4AANhIAgAF8D4CAAATVgIAADq/AgAAX/4CAAAR8EA==
Date: Tue, 27 Aug 2019 21:40:14 +0000
Message-ID: <HE1PR07MB3161FB7EC96210CDC5120B7493A00@HE1PR07MB3161.eurprd07.prod.outlook.com>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <HE1PR07MB3161A9A0C696B9636BBD380C93A70@HE1PR07MB3161.eurprd07.prod.outlook.com> <6484f305-0c38-4178-ee12-05a7dc38364f@omnitor.se> <HE1PR07MB31617F7C6E81EF041716749793A60@HE1PR07MB3161.eurprd07.prod.outlook.com> <ee4e6d3a-e984-15c7-dcaa-571be0e726b8@omnitor.se> <HE1PR07MB3161CC8F09E178F2E982E5AC93A60@HE1PR07MB3161.eurprd07.prod.outlook.com> <a5057f34-f222-e290-df88-da6e96d56294@omnitor.se> <A48CA18B-567B-46B9-9501-4FF65D4C8CAE@ericsson.com> <6c6d13ad-8699-73b9-f8aa-8ef16c5b3451@omnitor.se> <FB8E32BC-89C2-41CE-BBE1-81C4E7A56E77@ericsson.com> <f59f9335-329d-7b26-dec3-0898051040ce@omnitor.se> <VI1PR07MB31675A98F9B08A07D984369293A10@VI1PR07MB3167.eurprd07.prod.outlook.com> <084e8ee3-56fe-b764-fbbe-8afbee72e8e3@omnitor.se> <255759e0-c2c0-981a-e530-e05f7553c26e@alum.mit.edu> <173fc580-3a30-913b-ebba-5b0cb59702c8@omnitor.se> <HE1PR07MB31613A53CA3818B1CBDAB20693A00@HE1PR07MB3161.eurprd07.prod.outlook.com> <744b22d5-0f6c-4297-82bd-942b645a6506@omnitor.se>
In-Reply-To: <744b22d5-0f6c-4297-82bd-942b645a6506@omnitor.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [37.136.1.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 35bc0f93-16aa-4f64-cd76-08d72b372566
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3323;
x-ms-traffictypediagnostic: HE1PR07MB3323:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <HE1PR07MB33235133FF07BFE8493BA16093A00@HE1PR07MB3323.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0142F22657
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(366004)(39860400002)(396003)(346002)(189003)(199004)(66066001)(44832011)(11346002)(478600001)(66476007)(66446008)(66556008)(9686003)(64756008)(66946007)(86362001)(14454004)(966005)(2906002)(6306002)(14444005)(33656002)(2501003)(256004)(2171002)(76116006)(71190400001)(71200400001)(55016002)(5660300002)(25786009)(53936002)(476003)(74316002)(3846002)(81166006)(81156014)(6436002)(99286004)(102836004)(26005)(305945005)(76176011)(7736002)(52536014)(7696005)(8936002)(8676002)(316002)(6116002)(186003)(486006)(6506007)(446003)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3323; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: oe1Orz/upTtiH/IGt27/fQjylZUBDGkAEl008GA9uG4E/ISMaj2UBJf/O38iC6ou8u7vrDdy9gPaNv43hR8yB/huv64C8W7Z4hyoEWZOOlcT87EKDZfxlzkulcBdr05OydHwEjDT2iGNbEapnCuyWBcPtLNlgZc7RFdtHQAUjxNHng42WSZwFrlO6gvivhE6geRrTO5MvVHym4LsQHJMyslAIXNZIsqFbFu2jxzxFYXQsVmLFvF5qzBEldphTlz1DtBHgpgFpGj8kcWpKddFjFCCnA8KokzHXX68dHIBIc8uK/txM5bYbFR4THKP3ksP5JieVvBrx6wmqik0B/I8VhLwdEIWSFAcyi9lsgenfA+1MB6oM4+J2x+u/1zDZq9P1rwKaems7Cg8tGvQ0LpUvnW/C6oX4qDKhruh8cCFqhk=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 35bc0f93-16aa-4f64-cd76-08d72b372566
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2019 21:40:14.5915 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bGSjg3iNG9j+RmrTVZiiNjNRCNDvYr5Rak0bfY6jKBvwja5LgydTqBBvv+3gIzVzPa0ngjUzjuqwA2QN8HkqzoBObbRC5SQsGW+FcxUZC8Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3323
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/mSRZoFAZKZdq1XM1EZ0wFMLd0p0>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
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: Tue, 27 Aug 2019 21:40:20 -0000

Hi,

.

>> You earlier told me about the IRC case, where meta data about the transmitted T140 text is included in the actual 
>> text, as some kind of a tag/label. You could define some kind of "protocol", so that the receiver doesn't print out 
>> those tags/labels as text, but use them for other things. 
>>
>> That way you don't have to extend T140. But, it would obviously only work for endpoints that support the "protocol". 
>> Perhaps even IETF could define such "protocol"?
>
> Yeah, maybe. 
>
> T.140 make use of control codes from ISO 6429, but implementations are not required to support all. Only a few are mentioned 
> in T.140. So, it would be possible to take another control code sequence and use its parameter space for the source information we need. 
>But I think the documented extension mechanism is more suitable. 
>
>This is how it is expressed in T.140:
>
>  8.7 Application protocol function
>  Purpose: Identify coding of extensions to the protocol, so that the extensions can be introduced
>  unilaterally without disturbing the display.
>  Coding: SOS, function code, parameter string, ST.
>  Where: The function code is one ISO/IEC 10646-1 character uniquely identifying the function.
>  The parameter string shall not be more than 255 ISO/IEC 10646-1 characters in length and shall not
>  include the ST character.
>  Procedure: The receiving terminal shall function according to the request. The whole function shall
>  be ignored by a terminal not supporting it. For terminals supporting the extended function, they will
>  have an effect specified for that function.
>  If no trailing ST is received after the maximum length of the parameter string, the protocol reverts to
>  normal element decoding mode.
>  (SOS and ST are control codes )
>
> https://tools.ietf.org/html/draft-hellstrom-text-conference-04   proposes the following new extensions to T.140:
>
> https://tools.ietf.org/html/draft-hellstrom-text-conference-04#section-6.  Presentation level source indicator
>
>   In certain application environments, it may be known to be unsuitable
>   to use the CSRC identification on the RTP level as the base for
>   identificating the source of text.  In such cases, an inline coding
>   of the source of text SHOULD be applied in the data stream itself,
>   and an RTP mixer function normally without CSRC identification used
>   for coordinating the sources of text into one RTP stream.
>
>   The support of this mixer type is indicated by the SIP header rtt-
>   mix=t140, both by the focus and the user agent.
>
>   Information uniquely identifying each user in the multi-party session
>   SHALL then be placed as the parameter value "cn" in the T.140
>   application protocol function with the function code "c".  The
>   identifier shall thus be formatted like this: SOS c cn field contents
>   ST, where SOS and ST are coded as specified in ITU-T T.140 [https://tools.ietf.org/html/draft-hellstrom-text-conference-04#ref-T.140].
>   The cn parameter shall be kept short so that it can be repeated in
>   the transmission without concerns for network load.
>   The information otherwise conveyed in the NAME field of an SDES
>   packet SHOULD then be placed as the parameter value in the T.140
>   application protocol function with the function code "n".
>
>   A T.140 application protocol function with the function code "c" MUST
>   be included in the text in the beginning of text when the source of
>   the text changes.  A T.140 application protocol function with the
>   function code "c" MAY be repeated in the text from the same the
>   source.  A T.140 application protocol function with the function code
>   "n" MAY be included in the text to further provide identification of
>   the transmitting party.  This information SHOULD also be provided in
>   the SDES name field.  A receiving UA SHOULD separate text from the
>   different sources and identify and display them accordingly.
>
>   In this case, the mixer can use the redundancy transmission function
>   of https://tools.ietf.org/html/rfc4103 without restrictions.
>
>-------------------------------------------------------------------------------------------------
> Before using it we must however as you say, know if the receiver support this. Otherwise, text from all participants
> will be merged in an unreadable way on the screen. So, a negotiation with an sdp attribute seems also to be needed.

Indicating/mandating support of a feature should not be a big problem.

> Still, Paul's question is relevant: Do we need support for one data channel transporting RTT from many sources?

I don't know. Input from people with more experience from working with conference servers etc would be useful.

Regards,

Christer