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

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 26 August 2019 17:04 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 C9FA7120ADD for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 10:04:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 A3UCzvyhmx83 for <mmusic@ietfa.amsl.com>; Mon, 26 Aug 2019 10:04:00 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::603]) (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 D9BF8120A67 for <mmusic@ietf.org>; Mon, 26 Aug 2019 10:03:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fe7tZgHBHYXyZyQIrgbrcfLsJevoZKcpTzKsFLDD0m1wMsw5w5+ohDnzTjdGC495YxRo4Fz75Ps3TiqgipexMimS69jcjNk2fA98KiemB4/Daplp5SCgyifMrXLmQGr1U3ctUOepHkuyPrYX6gY2ddGjKXR5fn9kE5rtVy2bIGfq/FXauJVSXz6uOqfiiRIAvbgMX2QnKYjT88OnNc/IQ05lvVepXjQojIy37KPiP+zpUedFZIlt7RmnUa6FbeYSVGcY8plnXrMwQt3RX88yiabn/SvV+75Gxx5qMfN+AYZT/Dge1EolIOdA58xO0jFuuQCj7Ygb3reyvxOAQGeucg==
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=Se4GtkcFZIypieRuMF3sG/bTlRUeoAPWMDfmsDcfcaA=; b=Twh/OyjTvn47XWgRL9ps+8EnW/a41DFSt+x7rNVNxFrZH7moi3FoKNHos7GfBlq2sutlcevwnRr4qqckJwLCrWa1yjQpKDboH6O+cLlogUr8DgEYh4BQw+cYpwPB526VWkrfnmB9novQYBxh7agiwcslRbLzSSaEFikl9EDJxTpJ/bilu/RtxK9ktScxrLoyTzEg8zkuQR2VPDBbf1SqTF0mJ/TmrXu4AbI9u3QNUsUyz5RAGsF363NWNIL7qSVkFmpBnnmA6ddVPhUo1PCHvhwln8Jnu2rAYFxbj1/MfXTz+E3leUpHaGZz8f7g0EB74sM+FOR3eIVYnNz+TSggJQ==
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=Se4GtkcFZIypieRuMF3sG/bTlRUeoAPWMDfmsDcfcaA=; b=qWIjP+26TpeYMdZzANioCT5fh8ZoCc9oF4Rbu/h4H38GJL3wqho+sKXCBPqGk+WVPEGpq46qMgW6JKhW/PdQo5S65uTRZqIavRdP+AYFsJdgmVs1NBSDtFz3pdl9m6JlU2ba0NPORkHh/D/THhwJu/3/1bbB5Q1+3Oxw33x5tTE=
Received: from VI1PR07MB3167.eurprd07.prod.outlook.com (10.175.243.17) by VI1PR07MB4702.eurprd07.prod.outlook.com (20.177.57.138) 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 VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::d031:8cb6:bfb:dc3]) by VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::d031:8cb6:bfb:dc3%3]) with mapi id 15.20.2199.021; Mon, 26 Aug 2019 17:03:54 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= <gunnar.hellstrom@omnitor.se>, "mmusic@ietf.org" <mmusic@ietf.org>
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: <VI1PR07MB31675A98F9B08A07D984369293A10@VI1PR07MB3167.eurprd07.prod.outlook.com>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@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> <DBC532B8-38DC-4140-B7C4-0B6853F0EF77@ericsson.com> <6fcf46a6-544d-027c-97c7-5c0e08caa555@omnitor.se> <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>
In-Reply-To: <f59f9335-329d-7b26-dec3-0898051040ce@omnitor.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [79.134.118.162]
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: <VI1PR07MB47022A92FD138C1BC7EE0F9B93A10@VI1PR07MB4702.eurprd07.prod.outlook.com>
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; H:VI1PR07MB3167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 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-OriginatorOrg: ericsson.com
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: <https://mailarchive.ietf.org/arch/msg/mmusic/CS6TwTPPKE953-do2nChgAMcI30>
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: 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.

Correct.

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).

Regards,

Christer






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
>      > 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