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

Christer Holmberg <> Mon, 26 August 2019 17:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9FA7120ADD for <>; Mon, 26 Aug 2019 10:04:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 A3UCzvyhmx83 for <>; Mon, 26 Aug 2019 10:04:00 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe1e::603]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9BF8120A67 for <>; Mon, 26 Aug 2019 10:03:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=fe7tZgHBHYXyZyQIrgbrcfLsJevoZKcpTzKsFLDD0m1wMsw5w5+ohDnzTjdGC495YxRo4Fz75Ps3TiqgipexMimS69jcjNk2fA98KiemB4/Daplp5SCgyifMrXLmQGr1U3ctUOepHkuyPrYX6gY2ddGjKXR5fn9kE5rtVy2bIGfq/FXauJVSXz6uOqfiiRIAvbgMX2QnKYjT88OnNc/IQ05lvVepXjQojIy37KPiP+zpUedFZIlt7RmnUa6FbeYSVGcY8plnXrMwQt3RX88yiabn/SvV+75Gxx5qMfN+AYZT/Dge1EolIOdA58xO0jFuuQCj7Ygb3reyvxOAQGeucg==
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=Se4GtkcFZIypieRuMF3sG/bTlRUeoAPWMDfmsDcfcaA=; b=Twh/OyjTvn47XWgRL9ps+8EnW/a41DFSt+x7rNVNxFrZH7moi3FoKNHos7GfBlq2sutlcevwnRr4qqckJwLCrWa1yjQpKDboH6O+cLlogUr8DgEYh4BQw+cYpwPB526VWkrfnmB9novQYBxh7agiwcslRbLzSSaEFikl9EDJxTpJ/bilu/RtxK9ktScxrLoyTzEg8zkuQR2VPDBbf1SqTF0mJ/TmrXu4AbI9u3QNUsUyz5RAGsF363NWNIL7qSVkFmpBnnmA6ddVPhUo1PCHvhwln8Jnu2rAYFxbj1/MfXTz+E3leUpHaGZz8f7g0EB74sM+FOR3eIVYnNz+TSggJQ==
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=Se4GtkcFZIypieRuMF3sG/bTlRUeoAPWMDfmsDcfcaA=; b=qWIjP+26TpeYMdZzANioCT5fh8ZoCc9oF4Rbu/h4H38GJL3wqho+sKXCBPqGk+WVPEGpq46qMgW6JKhW/PdQo5S65uTRZqIavRdP+AYFsJdgmVs1NBSDtFz3pdl9m6JlU2ba0NPORkHh/D/THhwJu/3/1bbB5Q1+3Oxw33x5tTE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.13; Mon, 26 Aug 2019 17:03:54 +0000
Received: from ([fe80::d031:8cb6:bfb:dc3]) by ([fe80::d031:8cb6:bfb:dc3%3]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 17:03:54 +0000
From: Christer Holmberg <>
To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= <>, "" <>
Thread-Topic: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
Thread-Index: AQHVWxEvddfWyrxgrkCFyNXjkjXeRqcLee8ggAAVyACAAAccYIAAyvMAgADbfAD//+kmAIAAM2qAgAA9LACAAA5bvw==
Date: Mon, 26 Aug 2019 17:03:54 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 07bb96d3-a8a3-4a6a-4324-08d72a4760a9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1PR07MB4702;
x-ms-traffictypediagnostic: VI1PR07MB4702:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(346002)(376002)(366004)(396003)(199004)(189003)(561944003)(966005)(54896002)(229853002)(44832011)(236005)(55016002)(5660300002)(2501003)(74316002)(33656002)(53936002)(478600001)(606006)(6306002)(14454004)(316002)(110136005)(86362001)(52536014)(76116006)(66476007)(66556008)(64756008)(66446008)(66946007)(99286004)(9686003)(476003)(486006)(6436002)(11346002)(446003)(102836004)(76176011)(71190400001)(71200400001)(6116002)(2906002)(19627405001)(25786009)(81166006)(81156014)(6506007)(26005)(8936002)(256004)(7696005)(66066001)(7736002)(6246003)(66574012)(3846002)(8676002)(186003)(105004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4702;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: SAGOFbSO/joa0cAWLqP1+O9kQSjmsO3T9Owh+tm+04GlKC3kvj+fENw228nW23zIDdkjdAN7XZL3Ii9Y2OH66iM/EeGfpXSezDxahVCLIaZwXu1aP5o4bWEhLTozjJ1h4v8sphbMAtpuzvkjtQJJ66Pl8P8ObJitKZAftkyBunA37SMdo8q0y5dPF9hnGwz15Xp00WsnthlFRp/UXvsO8bdZDeA9HpHry4fqYCxdAF7fS1BQCC/VAuGs+HLHUkDsQzKFFvuqPAv71Wt0Cp8vkOXhfgDT3U7iRZHjhkl8c8lePlBzFYK4bFTqX3Y1EeYcY51TJPNpEN0fWQ2FNq92+xxrQkOPFBF3VCFQmGUKCm4aTH5KHFWzPI+jfrVeJsI/8tMpveZy3yspmvyXf3HDUte1Yqm8gpysC2j3XVL4m2c=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB31675A98F9B08A07D984369293A10VI1PR07MB3167eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 07bb96d3-a8a3-4a6a-4324-08d72a4760a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2019 17:03:54.8195 (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: YjXVEISqDHGy+4Y88bELZVIxJ91UKCnF6kQLC2JUP7VKekti1EAWyqg4uVjooWPnUBHoyEwOPqYvZZvL70Z+ucVYSbn0GzA8WEaWjcZ6QN0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4702
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: Mon, 26 Aug 2019 17:04:05 -0000

Hi Gunnar,

>Bringing the "label" discussion into the right thread:
>The discussion about the use of "label" for a visible representation of
>the source of text belonged of course to the multi-media aspects, and
>came from this proposal for text in a new section 4.5
>"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."
> As I said, I discovered that currently "label" is required in draft-ietf-rtcweb-data-channel-13
> section 6.4 to be identical in both directions.
> And you commented:
> "If we want to change the identical requirement we need to raise it in RTCWEB.
> It's probably a good idea to also ask them if they think 'label' is good for indicating source in the first place."
> Yes, I think it is good to raise the issue in RTCWEB.
>"label" could possibly be made good for indicating source in a similar way as CNAME is used for that in RTCP.
>It is not guaranteed to be unique, so it cannot be part of the protocol for appending incoming T140blocks to the >right real-time text stream. That is instead the task for the stream-id.
>Without the "label" used for this purpose, we have no mechanism for knowing the source of a T.140 data channel.


Just to clarify, though: as each data channel will use a unique SCTP port/stream-id, it will be possible to associate each T140block with a data channel.

The "label" would be used to provide additional information (e.g., source) about a data channel, but it is not needed to determine on which data channel a T140block is received.

>But we also need to consider what happens when a T140 data channel breaks because of network problems and >is then reconnected. Can the stream-id be reused for the reconnection, so that we can continue placing the new >incoming text where it belongs?

I would need to double-check what the specs say, but if the stream-id change I assume there will a new offer/answer exchange to indicate that.

>Or do we need to create a unique source attribute and add a place for it to the protocol?

If we indicate the source in the SDP it is not needed.

(In future, if a single data channel will be used for multiple sources, then you obviously need something in the protocol - as we will indicate in the NOTE).



Den 2019-08-26 kl. 11:15, skrev Christer Holmberg:
> Hi,
>> I can accept to not include "the T140 data channel data format".
> Note that we are not restricting how the problem can be solved in the future. It's a note, and the sentence contains an "e.g.," in the so we are just giving examples :)
> Regards,
> Christer
>      Den 2019-08-26 kl. 09:33, skrev Christer Holmberg:
>      > Hi Gunnar,
>      >
>      >>>>> So, what about the following text:
>      >>>>>
>      >>>>> "If an implementation needs to support multi-party scenarios,
>      >>>>> implementations (both clients and servers) need to support multiple
>      >>>>> simultaneous T.140 data channels, one for each source. At the time of
>      >>>>> writing this document, this is true even in scenarios where each participants
>      >>>>> communicate via a centralized conference server. The reason is that, unlike
>      >>>>> RTP media, WebRTC data channels and the T.140 protocol do not support the
>      >>>>> indication of the source of T.140 data.
>      >>>> "participants" s.b. "participant"
>      >>> Will fix.
>      >>>
>      >>>>> NOTE: Future extensions to T.140, or to the T140block, might allow
>      >>>>> indicating the source of T.140 data, in which case it might be possible to use
>      >>>>> a single T.140 data channel to transport data from multiple sources."
>      >>>> Should also "the T140 data channel data format" be among the options for where to place the source information?
>      >>> What is the "data format"? Isn't the T140block the data format?
>      >>
>      >>     Currently yes, but a more complex format could be defined, e.g. with a
>      >>     structure containing a source indicator and the T140blocks with some
>      >>     separator or structure. Of coulse it would be best to have that
>      >>     structure in place already from the beginning in this draft, so that
>      >>     there will be no interworking problems when a source address is
>      >>     introduced. Or at least a specified way to extend the format.
>      > Yes. But, again, that work would have to be done elsewhere. It is not within the charter of MMUSIC to define media plane formats.
>      >
>      > Regards,
>      >
>      > Christer
>      >
>      >
>      > _______________________________________________
>      > mmusic mailing list
>      >
>      >
>      --
>      -----------------------------------------
>      Gunnar Hellström
>      Omnitor
>      +46 708 204 288
> _______________________________________________
> mmusic mailing list

Gunnar Hellström
+46 708 204 288