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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 29 August 2019 09:50 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 55CFB120815 for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 02:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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] 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 aa4Qm-aSU8_U for <mmusic@ietfa.amsl.com>; Thu, 29 Aug 2019 02:50:33 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60050.outbound.protection.outlook.com [40.107.6.50]) (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 D80C612082B for <mmusic@ietf.org>; Thu, 29 Aug 2019 02:50:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cBx65bUBK2iuPoQF4mAQhg1PjGWlL2OCA9W5Gm0uh0qTUdLTEzbY//JgNAUMgK2iWeuIQ3cij5Lw4tFxyjTTU5ez35gCMMVdGWy9oYsuFRLNoqbpBaPANeV4Lc+OHi5tfMRmJ9tTjqi0eqIzN8NsrX8cT/dlOtv1C16FOWtADcf7hgSqE1HMGQMuIVXHpC+hvaxtxFYNPg6nCWOV5vbN3IZGxFXBraXNzxuu+MNhm2wvhSekPE0PSDo2n0BkTUtwH9TophfVvnbHrpFyDcYEjBiHtyBlpnhyhFZdFyZ3rvwq3H9kPYQeRgfowjJ8ihotZ7EwEX3wxseSpQEkYGUGtA==
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=dmTws2nEt5zbtdJ2FvdzVj1pOCnqxn6wr3PBnUqUeBs=; b=P9rrRtrEhA/FGwmS0Kf5PM/e+ij4qDkFF6BeUV5GWmSF+CW10NGRRmvC+e21LWb6k5mICRfDy9yw+NJNKrtXrKzy2jcY/XrcPv2MfTOJZCkjFq0fFgvOgcR/peNBJRzBLOrWHt3SWVTteiaUs60copgy8L7A70BrMFIauUjFx6meO60sBYFmiXgTSM7ImlAnC/wR2UmYMuTNWY654EKOLxmuOGkbV8YVdQDsRVrQ/qESgnW1xNtenib446Wp4ZkObbJC9miocTYW9RuMJGRFuInMdIdZEoQlYJ0Bh0IXnPOC3YqPbzrgv5PAKPTMkT7ibj1QqFvKc7pcTCT+BkQccA==
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=dmTws2nEt5zbtdJ2FvdzVj1pOCnqxn6wr3PBnUqUeBs=; b=G0Gv6MvZtcMzQ6GddPYAuB1oN4kxB+Snb47lAmB9I+cI1pu5xUvpRrmb7Y8upOfuHtQhEPwKpMoXDluBJFo4dE0g2bPrpiMPItj0TtI3wGpPKVv9SIemL9V0fG5wM2WgVWPajfddWjeb1HXtAUBrmwEUWP8iHVo2x2EpcH5LT0Q=
Received: from AM4PR07MB3156.eurprd07.prod.outlook.com (10.171.187.141) by AM4PR07MB3267.eurprd07.prod.outlook.com (10.171.189.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.15; Thu, 29 Aug 2019 09:50:30 +0000
Received: from AM4PR07MB3156.eurprd07.prod.outlook.com ([fe80::80eb:171e:dd12:a00c]) by AM4PR07MB3156.eurprd07.prod.outlook.com ([fe80::80eb:171e:dd12:a00c%7]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 09:50:30 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Roni Even (A)" <roni.even@huawei.com>, Gunnar Hellström <gunnar.hellstrom@omnitor.se>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
Thread-Index: AQHVWxEvddfWyrxgrkCFyNXjkjXeRqcR2wqAgAAzk4D//9IhAIAAM3+A///QGQCAADY0AA==
Date: Thu, 29 Aug 2019 09:50:30 +0000
Message-ID: <F6C8AB24-0303-43C2-A4D6-2161000457F7@ericsson.com>
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <CAOW+2duTuUc8FXT-BEhJioUnPsOkzYJddK=xAp1oWiBQCKM2vg@mail.gmail.com> <HE1PR07MB3161874ED292FA17015EF95E93AE0@HE1PR07MB3161.eurprd07.prod.outlook.com> <665185b6-c1e7-62c3-4e3b-e9374d23bfd5@omnitor.se> <DF010721-81CD-40DE-A848-DE4D36836FDA@ericsson.com> <ED158CF5-E059-482B-8D7E-934BA2C753A1@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> <6E58094ECC8D8344914996DAD28F1CCD23D43936@dggemm526-mbx.china.huawei.com> <65CFD7ED-04EA-498C-9CB3-18F49C04AF73@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD23D43990@dggemm526-mbx.china.huawei.com> <5D9A5640-FCF5-4888-9B05-58EE0468511F@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD23D439CA@dggemm526-mbx.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD23D439CA@dggemm526-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1b.0.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9afa63c5-7cd3-4a36-8388-08d72c665448
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM4PR07MB3267;
x-ms-traffictypediagnostic: AM4PR07MB3267:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM4PR07MB3267F9982201985B90E6D5A593A20@AM4PR07MB3267.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0144B30E41
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(366004)(396003)(39860400002)(376002)(189003)(199004)(66556008)(76116006)(6436002)(229853002)(66446008)(446003)(91956017)(11346002)(66946007)(256004)(26005)(2616005)(186003)(476003)(66476007)(14444005)(33656002)(486006)(44832011)(66066001)(53546011)(6486002)(6506007)(102836004)(71190400001)(966005)(6116002)(3846002)(14454004)(71200400001)(99286004)(76176011)(8936002)(6246003)(478600001)(81156014)(81166006)(86362001)(5660300002)(8676002)(64756008)(2906002)(305945005)(7736002)(2501003)(6306002)(316002)(6512007)(110136005)(58126008)(66574012)(36756003)(25786009)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3267; H:AM4PR07MB3156.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: baSStUZr1kwKpLNif1Bbw3jCxvNjuFBcubylgkmcwNbokHpZX5kmhVuMCuf3nZRLS2YUCAYSlZMcFDTpb9je3EvQO9LfPZJZKslGszUhnSHVsUEr2X09WywNxwWuukuX+MijP2oEVgITduPvM0rDOF7j98tNktjqRqwfg95tG4lWRahD4E0kQcKs5FDZ4oYNzKFdQPp7HYQFMxfkxzMYdLfRYZFJEqY1tWHOAXv2dwaRWgVx0l9XhLWdxHe2/vtJVYxbKBzibddWAh5AFmj/bMt/w4BtRQ26vuoqfdlpGSbGONzn6pLqwBPieRrg/8I/rLNSo+XfA9Kt736JEgz75vdq7YEV2Cpp2A8tFxAH5pEGjfLuplzcvAtQPaSwp8wJHT+0wicHqJnMl5hspnO0cuczTCqj/jyFcn88lCFoaiQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <6E5944F5CFDBEB40AC6E97C2B516FA19@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9afa63c5-7cd3-4a36-8388-08d72c665448
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 09:50:30.7200 (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: 0U38KG16UFQeE2fNlUiZlO/wmzKNRp2PObSi07S5UCnJzJgA4IjUAc8PtW4q3nbn7Sk2EA2LojHa/l5k3u4YOSdEsDPzYg6jc+lqwofvqdU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3267
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/T2KeV3cvogT7VCOd7MLYTPrjIzQ>
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: Thu, 29 Aug 2019 09:50:36 -0000

Hi,

>>> I you want to multiplex but know who is contributing the data you need 
>>> some identifier as part of the T.140 data packet similar to SSRC in the RTP header.
>>    
>>  Exactly, and that is what have been discussed :)
>>    
>>> It is not even similar to CSRC since CSRC is more about providing 
>>> about the content of this specific RTP packet but in this case each t.140 packet is 
>>> coming from a single source so one identifier is needed.
>>    
>> Your comment above shows why I have suggested to take the discussion to AVT: there you will find 
>>  people (like yourself) that know more about that kind of stuff :)
>    
>  RE: This is not AVT and not MMUSIC since it is some encapsulation for T.140 which is not RTP. 
> This is a topic for dispatch since it may be a single draft that needs a home

We are using the RFC 4103 T140block also on the data channel, so *IF* the solution would be an update to that, wouldn't it belong to AVT?

*IF* the solution is an update to T.140, I guess that should be done in ITU-T?

Having said that, before going into solutions there should be *A* venue to discuss the problem. 

Regards,

Christer
    
    
    
     
     
    From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
    Sent: Thursday, August 29, 2019 12:08 PM
    To: Roni Even (A); Gunnar Hellström; mmusic@ietf.org
    Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
     
    Hi Roni,
     
    >My view is that is we are talking about WEBRTC, the multiparty and user information will be part of the communication between the application >server and the browser and the application server is doing whatever mixing or forwarding that it needs.
    >I can see that there must be some way for the application server to know what is each t.140 data channel   if there is more than one , some >distinction is the language attribute. If you want more maybe as Christer suggested use the “content” attribute whose objective is to provide >information about stream. 
     
    The main issue is if you want to use a *single* data channel for T.140 traffic from multiple remote participants. In that case you need to be able to indicate the source of the T.140 data, but unlike RTP you don’t have SSRC etc for doing that.
     
    Regards,
     
    Christer 
     
     
    From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Gunnar Hellström
    Sent: Sunday, August 25, 2019 9:49 AM
    To: Christer Holmberg; mailto:mmusic@ietf.org
    Subject: Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel - multi-party
     
    Hi Christer,
    Below are comments on the multi-party considerations
     
    Den 2019-08-24 kl. 12:04, skrev Christer Holmberg:
    --------------------------------------------------------------------------------------------------------------------------------------------
     
    18. Add a new section 4.5
     
    4.5 Multi-party considerations
     
    Implementations should be prepared to accept establishment and use of multiple T140 data channels in order to support multi-party sessions with real-time text. A number of scenarios are available for how multi-party sessions can be supported in the WebRTC environment. 
    Implementations may select any suitable scenario.
    I don't think we need the two last sentences.
     
    Also, in some cases all communication will go via a central server, so there will only be one T.140 data channel towards each participant.
    No, T.140 has no source indicator of its own, it relies on the transport to indicate the source for each T140block. In RTP, this can be done by an RTP mixer making one stream from multiple sources including CSRC for the sources of the primary text and for the redundant generations of text in each packet. On the T140 data channel side, I do not know any corresponding way to indicate different sources in the same data channel. 
    The solutions I see are: 1) create one T140 channel per source/destination pair. or 2) Introduce a source indicator in the data format for the T140 data channel, either one per STCP message requiring all T140blocks in the message being from one source only, or inline between series of T140blocks from different sources. This is because the real-time text from multiple sources simultaneously need to be presented with some separation, so that the text gets readable at least sentence-wise from each source. The T.140 Appendix 1 shows two ways to do this, one column-oriented, and one sentence-oriented with a label per start of sentence. You can read more about the topic in https://www.ietf.org/archive/id/draft-hellstrom-text-conference-04.txt
     
     
    So, maybe something like:
     
    "In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly 
    with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels."
    While that is true, it does not tell us how to solve the case with a conference server.
    
    
     
     
    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.
    I am not sure I understand the "relative time relations" part.
    In order to enable the reader to follow the flow of a multi-party text conversation, it is a good habit to present older text placed higher in the text area and newer text placed lower. (This is valid for both when you present text in one column per source and if you combine all sources in one (IRC-style) column).  
    It is also a good habit to present text from the same source readable together, e.g. sentence by sentence, (and not break the text just because a text item from another source was received during the time the sentence was created).
    These two requirements are in conflict. A true time-related presentation would fragment simultaneous text from different sources into unreadability, and presenting all text from each source in one chunk each would give no clue about the flow of the discussion.  
    Therefore this expression " the relative time relations in the conversation approximately presented".
     
     
    Regarding the source, perhaps extending my suggested text above with something like:
     
    "In order for an implementation to be able to support multi-party scenarios where each participant will communicate directly 
    with the other participants, the implementation need to be able to support multiple simultaneous T.140 data channels. The label
    attribute can be used to provide information that helps an implementation to distinguish between the T.140 data channels."
     
    Yes, this is a good statement for the case without the server, or can be modified for a server that maintains a channel per source. But which solution do you prefer if we allow a mixing server?
    1) require also servers to support one T140 data channel per source
    2) introduce a data format for the T140 data channel containing a unique source identifier
    3) introduce a source identifier in-line in the T.140 data stream. (T.140 is extendable)
     
    /Gunnar
    ----------------------------------------------------------------------------------------------------------------------------------
     
    -
    - 
    -----------------------------------------
    Gunnar Hellström
    Omnitor
    mailto:gunnar.hellstrom@omnitor.se
    +46 708 204 288