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

Christer Holmberg <> Tue, 27 August 2019 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 379A0120113 for <>; Tue, 27 Aug 2019 14:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sesE2svOSrJF for <>; Tue, 27 Aug 2019 14:40:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2496812004D for <>; Tue, 27 Aug 2019 14:40:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; 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;; 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; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 ( by ( 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 ([fe80::f0a1:2199:7816:ff8d]) by ([fe80::f0a1:2199:7816:ff8d%6]) with mapi id 15.20.2220.013; Tue, 27 Aug 2019 21:40:14 +0000
From: Christer Holmberg <>
To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= <>, Paul Kyzivat <>, "" <>
Thread-Topic: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
Date: Tue, 27 Aug 2019 21:40:14 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
authentication-results: spf=none (sender IP is );
x-originating-ip: []
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: <>
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;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( 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-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: <>
Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Aug 2019 21:40:20 -0000



>> 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 )
>   proposes the following new extensions to T.140:
>  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 [].
>   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 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.