Re: [MMUSIC] Multi-party transport in draft-hellstrom-mmusic-multi-party-rtt-00.txt

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sat, 22 February 2020 17:50 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 794A83A041C for <mmusic@ietfa.amsl.com>; Sat, 22 Feb 2020 09:50:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=omnitorab.onmicrosoft.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 ggjhM-_t3jmU for <mmusic@ietfa.amsl.com>; Sat, 22 Feb 2020 09:50:40 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2103.outbound.protection.outlook.com [40.107.22.103]) (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 5A96C3A043D for <mmusic@ietf.org>; Sat, 22 Feb 2020 09:50:38 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K0w1jdc02kgJNs073KABgvmddzVVRZ6TaG/03nD3rtCC9VoxUhain0BOpZV/SvaXiMuY2qk/jbUg8+IowfNYRnGEOP3SlpTktsx0DINnomBznb7PVWM36pARvRORYbA/PTDFxrDSA3hQR4K0HlQq7O082K8Q80y85UlQX9kPg5uK+ejeo2+VvtnPu1RrRL5fKzuC4EHTjGykiJY7l/qSVdpslVE4lpIC1bP2RbvuaenGZsLqDS31Mf87l9hLY7hlFNgnddkyOQXkIIYqaTlEDzI7PaQ5YmYcNyCfZEd3F70SVb+zeHkVM7bsMbylEWlqxJNGjt6cPJaoMy/rYqz5Fg==
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=r2zzVC5JVJaNYfReCIoJXWgLn0UKFeIJit1sStgrKJM=; b=bawoGWLezFWRLjqv0/nv21/1B9DUipcuTE2n9vYy9NHClWONN8uKI+cznKAaH5qqpnNwYyctqWGoNV683VgjeniTVHCKvz0IAWMCo0f4OPWWIFIXzpFMnxhRD8NAEL5wyCCiGJfwRUkTgTBQWVhi2pYBaskIeS2IIz3tj72wRrgI7aqVUHuWm1/A4dP7BAKf4lxY6CQb19f5sOZeYN4ohkqB3epAhVZWcTKn2w1bCYu06v5F5fW7dqwcFMApkK8+qPElQB8zRkUs0JmaH9EY5dFYYtUSRgn1bX0iX2pMglAmgC4bMqxiyU8/1pxelafL5M4/dq3RdvsRCIkvoZtR0Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=omnitor.se; dmarc=pass action=none header.from=omnitor.se; dkim=pass header.d=omnitor.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnitorab.onmicrosoft.com; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r2zzVC5JVJaNYfReCIoJXWgLn0UKFeIJit1sStgrKJM=; b=M/N2qkcMYZiDWDbzW4uwNTNfcRetyOn7q89GbzZUayMWBhqezg3CaCgYjarqqsadcTrLbW3PsAGfqk6slfz/CbY9sM+BsKPHVRAlojiBdcJgabIPuDlaw1g37UgahY8J5Pll63UkTpznqprwhSwmm8tGh0m3Ka/tw64hvmd8uS4=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0301.EURP193.PROD.OUTLOOK.COM (52.134.123.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18; Sat, 22 Feb 2020 16:35:44 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1910:128d:b820:f765]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1910:128d:b820:f765%4]) with mapi id 15.20.2750.021; Sat, 22 Feb 2020 16:35:44 +0000
Received: from [192.168.2.136] (77.53.230.59) by FRYP281CA0017.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Sat, 22 Feb 2020 16:35:44 +0000
From: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <gunnar.hellstrom@omnitor.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Multi-party transport in draft-hellstrom-mmusic-multi-party-rtt-00.txt
Thread-Index: AQHVtSzNCz3t0SMEM0aHvyj8XcicRae/q60AgAGEpgCAAB9pgIBkwR6AgAA14ACAAV8mgIAAIj4AgAAJxQA=
Date: Sat, 22 Feb 2020 16:35:44 +0000
Message-ID: <f544b594-6e5c-4db0-bccd-211a669a9b93@omnitor.se>
References: <8673BEBE-C66C-4264-A327-08ABCF4A31E1@ericsson.com> <51f31590-cc68-983e-5c61-88c0d6d0878c@omnitor.se> <20191218110754.05ea4b32@lminiero> <fdac2243-4eb0-7305-55a7-34749833cdab@omnitor.se> <1B68EE05-0230-40E4-9BF3-CD405A0FD768@ericsson.com> <8df6510d-4fcf-b0e1-b438-2f3570fbec43@omnitor.se> <de42f775-21bd-a330-5ea1-948d08f1070c@alum.mit.edu> <7ca10052-ed5c-b14b-f280-f63e6dd7a183@omnitor.se> <AM0PR07MB39873B3AC61970DFDDFF588993EE0@AM0PR07MB3987.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB39873B3AC61970DFDDFF588993EE0@AM0PR07MB3987.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: FRYP281CA0017.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::27) To VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (2603:10a6:800:159::12)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [77.53.230.59]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a6d6a0dd-2e85-45c1-fe0e-08d7b7b54354
x-ms-traffictypediagnostic: VI1P193MB0301:
x-microsoft-antispam-prvs: <VI1P193MB03015D6757E14C4C6B237E4BFBEE0@VI1P193MB0301.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03218BFD9F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(366004)(39830400003)(136003)(199004)(189003)(21615005)(8676002)(52116002)(31696002)(4001150100001)(71200400001)(53546011)(6486002)(16526019)(66574012)(316002)(16576012)(31686004)(966005)(85202003)(186003)(956004)(508600001)(2616005)(110136005)(2906002)(81156014)(81166006)(66946007)(36756003)(19627405001)(86362001)(66476007)(66556008)(66446008)(85182001)(5660300002)(26005)(8936002)(30864003)(64756008)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0301; H:VI1P193MB0669.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ehbvk9mFpj3jH0Whx6eSgBsu1FiZ2R/ECvUOegOJ4P5SsiXftyMDCg7w7dEFUfXOCvpX0XARTImT8t8mbc+fjF2Wv2wDypUhGsKBSG+7lus5lue6nbHOolItCDqv1fd/8Zmlj6oTAznx04VavJWV/yMJfPsuAkhpOXNLKr+/RWf1yS8OUbKrA3fLcivvzcvcwLJjIxMvH4da8+CuW2/jXWwI099DNI1+bmGV27og8vCXkZgWX7nxPk2tsl55x8NJ5WWuDQLuou00Nd3XUgPxnMhHF2Ina155pGX9PIQlqUSNAJlAI6L8T2S+Bnmgr5noxqedDAq3lU7hnciNDig0Bs/CP5pzmm9g/BmvoYq2yUPOzPvLqz5Bn1Y6FrGShOMH/SqIcsK3CXru4BmdFwThPcUidsFScQTPRFJLmMdCqPZ8sfns9h0lS6xAdJzduOD2Vxhd6/PfPKMgzeb+xjWJhhIsQUWJrel542j2YB0stjxM1i+Q0o/ZoOhBhAPaL2VSYWchOMn0GFDJTB2D5yCevA==
x-ms-exchange-antispam-messagedata: keh71zXAvVIqSOJqJIUFarpi7o1/nJbC1uf2GK9bAtBl030J/o+2R4awJqjBaaovUJO17xb0Kgd6ZY3qH0DvnRVFzngec3/1bsTKIhLAuIYMi6McJcndQWj9G+84A1507DEl3u/tEW4VdtWW3x48nw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_f544b5946e5c4db0bccd211a669a9b93omnitorse_"
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: a6d6a0dd-2e85-45c1-fe0e-08d7b7b54354
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2020 16:35:44.5694 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /oZJOUyIl6nn1B+QwkP+DgvXoNNiXSWThwN/eaFTc1/YBTUSGag36wpFRjn6FiJihurHQeScx3SvktcrGMFECJ6MgUYMdbGr0E1FSkDOocE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0301
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/oaWdROcqWSETTk0rdsIyKafQC4A>
Subject: Re: [MMUSIC] Multi-party transport in draft-hellstrom-mmusic-multi-party-rtt-00.txt
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: Sat, 22 Feb 2020 17:50:46 -0000

Hi,

Den 2020-02-22 kl. 17:00, skrev Christer Holmberg:
Hi,

The main issue, described in Section 4, is how the mixer is going to forward real-time text towards participants, in a way that allows the participants to determine which remote participant has sent the text

Yes, and that is what I think I just created. Include CSRC lists in the RTP packets with three members, corresponding to the SSRC for the original, the first redundant level and the second redundant level in that packet in a specified order. The receiver can then distribute the received text among the presentation areas, and recovery and marking of text loss after packet loss can be made.


This can be documented in a short document updating RFC 4103.


There are other use cases mentioned in the multi-party-rtt draft, (e.g. for end-to-end-encryption where the hints from Paul look useful) so it would also be good to keep it updated. I will start at that end.


Regards


Gunnar



- unlike audio, you can't just blend everything together and assume the participants will recognize the sender based on his/her voice.


Regards,

Christer



________________________________
From: mmusic <mmusic-bounces@ietf.org><mailto:mmusic-bounces@ietf.org> on behalf of Gunnar Hellström <gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>
Sent: Saturday, February 22, 2020 3:58 PM
To: Paul Kyzivat <pkyzivat@alum.mit.edu><mailto:pkyzivat@alum.mit.edu>; mmusic@ietf.org<mailto:mmusic@ietf.org> <mmusic@ietf.org><mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] Multi-party transport in draft-hellstrom-mmusic-multi-party-rtt-00.txt

Paul,

Den 2020-02-21 kl. 18:01, skrev Paul Kyzivat:
> Gunnar,
>
> There is a wg called PERC that sounds like it *might* have some
> relevance.  I think this was started quite some time ago, and I
> haven't followed the work so I'm not personally familiar with its
> status. The latest milestone milestone was in 2018, and I see some
> documents that appear to be stalled, so it may be dragging. But you
> might want to investigate.

Perc seems to be a good and relevant framework for end-to-end encrypted
conferences.

I get the impression that regular RFC 4103 with additional encapsulation
and key handling transactions will be sufficient for its use with RTT.

So, that means that the goal of end-to-end encryption should be split
off from the current multi-party RTT draft and handled in another draft
with less urgency.

Thanks for the useful hint,


Gunnar


>
>     Thanks,
>     Paul
>
> On 2/21/20 8:48 AM, Gunnar Hellström wrote:
>> Hi,
>>
>> Continuing the discussion of chapter 4 of
>> https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00 :
>>
>> I have searched for examples of media mixing for other media than
>> real-time-text, in order to find if they are provided end-to-end
>> encrypted, and combined under one m-section in SDP.
>>
>> Three considered possible use cases are for 3GPP IMS and NG-112/NG9-1-1
>> emergency services. All three say that conferences use the RFC
>> 4353/RFC4575/RFC 4579 SIP conference model. All these seem to me specify
>> sending just SIP Notifications to all participants when a new user joins
>> without introducing any new media. And the SSRC of the media mixed to
>> earlier streams are provided in that Notify.
>>
>> I assume that then the media is mixed into the current stream by
>> inserting packets with the mixer's SSRC, and the new participant's SSRC
>> as CSRC.
>>
>> I wonder if this scheme can allow end-to-end encryption? One reason for
>> problems is that the mixer likely must do some media parameter
>> alignments because it has no means to convey separate parameters per
>> source. Another reason is that there is no SDP exchange of keys for
>> separate participants in RFC 4579.
>>
>> If nothing is wrong in my findings, we can satisfy the main use cases of
>> mixing for RTT with a method that allows a central mixer to decrypt and
>> merge the RTT packets from different sources into one stream with the
>> SSRCs of the sources provided as CSRC in the combined stream, and never
>> have more than one source CSRC per packet. ( that will still require a
>> bit of considerations on packetization level)
>>
>> Once this is settled, we can move on and try to solve also the
>> end-to-end encryption case. Can anyone provide examples of how that is
>> done for multi-party audio and video?
>>
>> Regards
>>
>> Gunnar
>>
>>
>>
>>
>>
>> Den 2019-12-19 kl. 12:11, skrev Christer Holmberg:
>>> Hi,
>>>
>>> Regarding how to signal, at the moment my strong preference is to
>>> use a single m- line for RTP-based multi-party RTT, in one way or
>>> another. Having a separate m- line for each remote participant
>>> doesn't scale, and would probably not work in many networks. It
>>> could also cause lots of offer/answer transactions when people are
>>> joining/leaving conferences.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>> On 19/12/2019, 11.19, "mmusic on behalf of Gunnar Hellström"
>>> <mmusic-bounces@ietf.org on behalf of gunnar.hellstrom@omnitor.se><mailto:mmusic-bounces@ietf.orgonbehalfofgunnar.hellstrom@omnitor.se>
>>> wrote:
>>>
>>>       Thanks Lorenzo for your views on the different transport and
>>> mixing
>>>       alternatives.
>>>             I intend to continue the overview of the alternatives
>>> that Christer
>>>       asked for.
>>>             But, in the meantime:
>>>             It would be good to have comments on if there are any
>>> specific methods
>>>       for signaling multi-party control for WebRTC, e.g. announcing
>>> the focus
>>>       role and announcing participants' entry and departure and
>>> capabilities
>>>       to the conference.
>>>             And also if the RFC 7579 / RFC 7575 SIP conference
>>> control is so
>>>       widespread that it would be suitable to rely on it in the SIP
>>>       environment for  e.g. announcing the focus role and announcing
>>>       participants' entry and departure and capabilities to the
>>> conference.
>>>             About your comment that the conference-unaware mixing
>>> alternative: Yes,
>>>       it is not favourable, but possible. And I think it is needed
>>> in order to
>>>       be able to introduce multi-party support in services where
>>> there are
>>>       already many conference-unaware UAs out there.
>>>             One factor that you find not good for that method and
>>> the T140-mixing
>>>       method is that the mixer need to be able to decrypt and
>>> encrypt the text
>>>       stream. Is that not usually the case for the other media,
>>> audio and
>>>       video in the centralized bridge mixing?
>>>             Thanks,
>>>             Gunnar
>>>             Den 2019-12-18 kl. 11:07, skrev Lorenzo Miniero:
>>>       > Hi all,
>>>       >
>>>       > apologies if I'm chiming in only now. I've recently started
>>> working on
>>>       > an (open source) integration between SIP RTT and WebRTC: I
>>> already
>>>       > exchanged some thoughts with Gunnar in private, but I plan
>>> to write a
>>>       > post to introoduce the effort later today.
>>>       >
>>>       > Since the effort has been on a server side component that
>>> acts like a
>>>       > gateway, in this context, how to deal with multiparty is indeed
>>>       > something I'm interested about, so I've added some comments
>>> inline.
>>>       >
>>>       >
>>>       > On Tue, 17 Dec 2019 22:53:31 +0000
>>>       > Gunnar Hellström <gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se> wrote:
>>>       >
>>>       >> Hi Christer,
>>>       >>
>>>       >> Den 2019-12-17 kl. 09:01, skrev Christer Holmberg:
>>>       >> Hi,
>>>       >>
>>>       >> Before we decide on support indicators, we need to decide
>>> on how we
>>>       >> are going to implement multi-party RTT. Yes, these
>>> discussions at
>>>       >> least need to go in parallel. Note that I switched subject
>>> now when
>>>       >> the topic is multi-party RTT transport alternatives.
>>>       >>
>>>       >> Section 4 specifies different alternatives. Are we going to
>>> specify
>>>       >> all of those, or only a subset?
>>>       >>
>>>       >> Related to Section 4, it would be nice with an SDP example
>>> for each
>>>       >> alternative.
>>>       >>
>>>       >>   The problem so far has been that it has been said that
>>> multi-party
>>>       >> RTT can be arranged with regular RTP methods, and that has
>>> provided
>>>       >> too wide freedom of choice.
>>>       >>
>>>       >> So, I want to eventually change the draft to elaborate on
>>> either one
>>>       >> common alternative for real-time transport for both SIP/RTP
>>> and
>>>       >> WebRTC, or one each for these two environments. The other
>>>       >> alternatives may be briefly mentioned in a background
>>> chapter or
>>>       >> deleted.
>>>       >>
>>>       >> So, let us go through the alternatives, and try to look at
>>> both
>>>       >> chapter 4 and 5. That is both SIP/RTP and WebRTC.
>>>       >>
>>>       >> 1. Control code in the T.140 stream.
>>>       >>
>>>       >>
>>> 4.3<https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#section-4.3>.3>.
>>>       >>   RTP Mixer indicating participants by a control code in
>>> the stream
>>>       >>
>>>       >> and
>>>       >>
>>> 5.2<https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#section-5.2>.2>.
>>>       >>   RTT bridging in WebRTC with one common data channel
>>>       >>
>>>       >> Both build on the same principle. The presentation protocol
>>> T.140 is
>>>       >> extendable. New one letter  function codes can be defined
>>> and sent
>>>       >> together with a parameter framed by the control codes
>>> called SOS and
>>>       >> ST as defined in ISO 6429. So, we could define (or rather
>>> ask ITU-T
>>>       >> SG26 to define) a function code "c" followed by a string
>>> uniquely
>>>       >> identifying the source of the following text (or rather
>>> T140blocks).
>>>       >> The data for each transmission request from the mixer
>>> should start
>>>       >> with the SOS,c,source,ST code as soon as more than two
>>> parties are
>>>       >> involved in the session. The receiving party need to scan
>>> incoming
>>>       >> T140blocks and direct the received text to the proper area for
>>>       >> presentation of text from each source in one of the
>>> suitable styles
>>>       >> for RTT presentation (see chapter 9).
>>>       >>
>>>       >> For 4.3, the RTP variant, I don't think we need to
>>> prescribe any more
>>>       >> SDP than a regular one stream RTT plus an indication of
>>> multi-party
>>>       >> RTT capability.
>>>       >>
>>>       >> Example, combining this alternative with capability
>>> negotiation 7.3
>>>       >>
>>>       >> Offer
>>>       >>   m=text 11000 RTP/AVP 100 98
>>>       >>        a=rtpmap:98 t140/1000
>>>       >>        a=rtpmap:100 red/1000
>>>       >>        a=fmtp:100 98/98/98
>>>       >>        a=rtt-mixer:t140-mixer
>>>       >>
>>>       >> Answer of a capable party
>>>       >>   m=text 12000 RTP/AVP 100 98
>>>       >>        a=rtpmap:98 t140/1000
>>>       >>        a=rtpmap:100 red/1000
>>>       >>        a=fmtp:100 98/98/98
>>>       >>        a=rtt-mixer:t140-mixer
>>>       >> The parties can start exchanging multi-party text in one
>>> stream with
>>>       >> T.140 source indications.
>>>       >>
>>>       >> Answer of an uncapable party
>>>       >>   m=text 12000 RTP/AVP 100 98
>>>       >>        a=rtpmap:98 t140/1000
>>>       >>        a=rtpmap:100 red/1000
>>>       >>        a=fmtp:100 98/98/98
>>>       >>
>>>       >>
>>>       >> The mixer can start sending multi-party text prepared for
>>>       >> presentation to a multi-party unaware UA according to
>>> chapter 10 and
>>>       >> Appendix A, providing a lower functionality fixed view
>>> presentation.
>>>       >>
>>>       >> This method can be combined with multi-party conferencing
>>> control for
>>>       >> SIP as said in the beginning of chapter 7
>>>       >>
>>>       >>
>>>       >> "A method for detection of conference-awareness for
>>> centralized SIP
>>>       >> conferencing in general is specified in RFC
>>>       >> 4579<https://tools.ietf.org/html/rfc4579>
>>>       >> [RFC4579<https://tools.ietf.org/html/rfc4579><https://tools.ietf.org/html/rfc4579>]rfc4579>]. The focus
>>> sends the
>>>       >> "isfocus" feature tag in a SIP Contact header. This causes the
>>>       >> conference-aware UA to subscribe to conference
>>> notifications from the
>>>       >> focus. The focus then sends notifications to the UA about
>>> entering
>>>       >> and disappearing conference participants and their media
>>>       >> capabilities. The information is carried XML-formatted in a
>>>       >> 'conference-info' block in the notification according to
>>>       >> RFC<https://tools.ietf.org/html/rfc4575>
>>>       >> 4575<https://tools.ietf.org/html/rfc4575>75>. The mechanism is
>>> described
>>>       >> in detail in RFC 4575<https://tools.ietf.org/html/rfc4575>
>>>       >> [RFC4575<https://tools.ietf.org/html/rfc4575><https://tools.ietf.org/html/rfc4575>]."
>>>       >>
>>>       >>
>>>       >> But I think now that we do not need to make us so dependent
>>> on that
>>>       >> mechanism. Any way to introduce and delete parties in the
>>> conference
>>>       >> may be used.  The draft is currently too much tied to use
>>> of the RFC
>>>       >> 4579 / RFC 4575 procedure.
>>>       >>
>>>       >>
>>>       >> For 5.2, the WebRTC case with T.140 source marked text,
>>> according to
>>>       >> draft-ietf-mmusic-t140-usage-data-channel the sdp would be
>>>       >>
>>>       >>   Offer:
>>>       >>
>>>       >>         m=application 1400 UDP/DTLS/SCTP webrtc-datachannel
>>>       >>         c=IN IP6 2001:db8::3
>>>       >>         a=max-message-size:1000
>>>       >>         a=sctp-port 5000
>>>       >>         a=dcmap:2 label="ACME customer
>>> service";subprotocol="t140"
>>>       >>         a=dcsa:2 rtt-mixer:t140-mixer
>>>       >>
>>>       >>     Answer from a capable party:
>>>       >>
>>>       >>         m=application 2400 UDP/DTLS/SCTP webrtc-datachannel
>>>       >>         c=IN IP6 2001:db8::1
>>>       >>         a=max-message-size:1000
>>>       >>         a=sctp-port 6000
>>>       >>         a=dcmap:2 label="ACME customer
>>> service";subprotocol="t140"
>>>       >>         a=dcsa:2 rtt-mixer:t140-mixer
>>>       >>
>>>       >>
>>>       >> The parties can start exchanging multi-party text in one
>>> stream with
>>>       >> T.140 source indications.
>>>       >>
>>>       >>
>>>       >> (and if the negotiation does not find multi-party
>>> capability for both
>>>       >> parties, then the mixer can start sending according to
>>> chapter 10 and
>>>       >> Appendix A.)
>>>       >>
>>>       >> The exact form of the multi-party capability indication
>>> should go
>>>       >> into the negotiation discussion belonging to chapter 7.
>>> (maybe it
>>>       >> should be a new fmtp - parameter instead of a new sdp
>>> attribute if
>>>       >> using sdp )
>>>       >>
>>>       >> Pros:
>>>       >>
>>>       >> Equal handling for SIP/RTP and WebRTC
>>>       >> Simple session and stream establishment.
>>>       >>
>>>       >> Cons:
>>>       >>
>>>       >> The mixer need to manipulate the T.140 stream.
>>>       >> In SIP/RTP, if more than 3 consecutive packets are lost,
>>> the source
>>>       >> of the loss is not known, and an indication of possible
>>> loss needs to
>>>       >> be inserted in some other place than in the stream that had
>>> loss. The
>>>       >> mixer needs to be allowed to decrypt and encrypt the stream.
>>>       >>
>>>       >>
>>>       >> I need to stop here and describe the other alternatives
>>> another day.
>>>       >>
>>>       >
>>>       > I'm personally not fond of the idea of the new control code.
>>> First of
>>>       > all, it would require the mixer to indeed terminate the RTT
>>> session,
>>>       > which means end-to-end encryption wouldn't be possible.
>>> Besides, with
>>>       > data channels and the flexibility they provide (e.g., via
>>> the label you
>>>       > can negotiate in the related draft), you don't really need
>>> the extra
>>>       > inband control code to discriminate sessions.
>>>       >
>>>       > I did read the multiparty document, and did have some
>>> opitions going
>>>       > through the alternatives, so I thought I'd share them
>>> quickly here
>>>       > (apologies to Gunnar if I'm repeating what the draft already
>>> says, or
>>>       > if I'm completely misunderstanding some concepts, as I'm
>>> indeed new to
>>>       > the specification as a whole):
>>>       >
>>>       >     1. Section 4.1 introduces the usage of different SSRCs for
>>>       >     different participants, which does seem like a good
>>> option to
>>>       >     me: SSRCs would indeed provide the info required to
>>> demultiplex
>>>       >     and relay participants without having to look at the
>>> payload,
>>>       >     and would be very easy to map to labels when a translation
>>>       >     to/from a WebRTC session is needed. There is indeed the
>>> problem
>>>       >     of how you advertise those SSRCs, which brings back painful
>>>       >     memories of the Plan B vs. Unified Plan fight in WebRTC:
>>> this
>>>       >     section suggests a single m-line (à-la Plan B, I believe),
>>>       >     which has some drawbackas; different participants may
>>>       >     use different approaches (e.g., some may be using red,
>>> other
>>>       >     t140, and payload types may differ) which indeed
>>> complicates
>>>       >     the SDP negotiation, especially if the mixer is supposed to
>>>       >     just relay those streams and not terminate them.
>>>       >
>>>       >     2. Section 4.2 suggests using a shared SSRC, and using
>>> CSRC to
>>>       >     mention participants. Again, the need for decrypting the
>>>       >     traffic is problematic. Besides, I'm not sure detecting
>>> packet
>>>       >     loss would be trivial as the document states: if the
>>> SSRC is
>>>       >     shared, so is the timestamp/sequence number space, which
>>> means
>>>       >     that it would be problematic, if not downright
>>> impossible, to
>>>       >     detect packet losses for a specific participant at the
>>> source,
>>>       >     considering sequence numbers originated by the mixer may be
>>>       >     increasing sequentially with no gaps in between.
>>> Probably I'm
>>>       >     missing something obvious in the scenario?
>>>       >
>>>       >     3. Section 4.3 is where the new control code Gunnar
>>> described
>>>       >     is introduced, and I already shared my view on why I'm not
>>>       >     particularly fond of the idea.
>>>       >
>>>       >     4. Section 4.4 describes a full mesh, which does work
>>> but is
>>>       >     indeed more "verbose", and requires multiple sessions to
>>> take
>>>       >     place, and may be a bit overkill. That said, one of the
>>> pros
>>>       >     the document suggests is that this should be possible
>>> with most
>>>       >     RTP implementations, which isn't to be ignored: I'd
>>> consider
>>>       >     this a good backup when dealing with participants
>>> unaware of
>>>       >     whatever method will be chosen, possibly establishing the
>>>       >     multiple sessions with the mixer itself, though, rather
>>> than
>>>       >     the other participants themselves.
>>>       >
>>>       >     5. Section 4.5 documents the approach where multiple RTP
>>>       >     sessions are negotiated, one per participant, I guess via
>>>       >     separate m-lines. This is indeed a variant of 4.1 which
>>> again
>>>       >     brings back the Plan B vs. Unified Plan discussion that
>>>       >     happened in WebRTC, where the former signalled multiple
>>> SSRCs
>>>       >     on the same m-line, and the latter used separate m-lines
>>>       >     instead. Whatever signalling approach is used, I do feel
>>> that
>>>       >     using SSRCs to demultiplex would make the process simpler.
>>>       >
>>>       >     6. Finally, section 4.6 introduces the concept of
>>> "mixing" for
>>>       >     RTT streams, which I'm not a fan of either, as it
>>> "flattens"
>>>       >     everything, breaking end-to-end encryption when
>>> available in
>>>       >     the process. The document provides even more cons, and
>>>       >     clarifies how it should only be a last resort, which I
>>> agree on.
>>>       >
>>>       > On the WebRTC side, things are much easier I believe. The
>>> approach
>>>       > suggested in 5.1 is definitely what I'd go with, that is
>>> leveraging
>>>       > labels to demultiplex participants: I wouldn't be too
>>> concerned about
>>>       > the overhead of establishing a high number of channels, as most
>>>       > implementations have ways to deal with high numbers anyway.
>>>       >
>>>       > Lorenzo
>>>       >
>>>       >
>>>       >> Thanks
>>>       >>
>>>       >> Gunnar
>>>       >>
>>>       >> Regards,
>>>       >>
>>>       >> Christer
>>>       >>
>>>       >> From: mmusic
>>>       >> <mmusic-bounces@ietf.org><mailto:mmusic-bounces@ietf.org><mailto:mmusic-bounces@ietf.org><mailto:mmusic-bounces@ietf.org>
>>> on behalf
>>>       >> of Gunnar Hellstrom
>>>       >>
>>> <gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>
>>>       >> Date: Sunday, 15 December 2019 at 22.25 To:
>>>       >> "mmusic@ietf.org"<mailto:mmusic@ietf.org><mailto:mmusic@ietf.org><mailto:mmusic@ietf.org>
>>>       >> <mmusic@ietf.org><mailto:mmusic@ietf.org><mailto:mmusic@ietf.org><mailto:mmusic@ietf.org> Subject: [MMUSIC]
>>>       >> Negotiation in draft-hellstrom-mmusic-multi-party-rtt-00.txt
>>>       >>
>>>       >>
>>>       >> Hi,
>>>       >>
>>>       >>
>>> draft-hellstrom-mmusic-multi-party-rtt/<https://datatracker.ietf.org/doc/draft-hellstrom-mmusic-multi-party-rtt/><https://datatracker.ietf.org/doc/draft-hellstrom-mmusic-multi-party-rtt/>
>>>       >> currently contains sets of alternative solutions for different
>>>       >> aspects of multi-party real-time text (RTT).
>>>       >>
>>>       >> I would like to discuss these alternatives aspect by
>>> aspect, and
>>>       >> eventually reduce them to one solution per aspect. By
>>> aspects, I mean
>>>       >> negotiation for SIP, negotiation for WebRTC, source
>>> identification
>>>       >> and multi-party transport for SIP, source identification and
>>>       >> multi-party transport for WebRTC and mixing for the
>>> multi-party
>>>       >> unaware case.
>>>       >>
>>>       >> The main requirements are described in section 3 of the
>>> draft. One
>>>       >> requirement is that the solution should be implementable in
>>> a near
>>>       >> future. Point-to-point RTT solutions based on SIP and RTP
>>> with RFC
>>>       >> 4103 transport are implemented, and there are cases where
>>> upgrade to
>>>       >> multi-party support is urgent. It is assumed that most
>>> multi-party
>>>       >> cases will be based on one central bridge. The media coding is
>>>       >> according to ITU-T T.140, that is Unicode text transmitted
>>> UTF-8
>>>       >> transformed, with some control codes from ISO 6429.
>>> Transmission
>>>       >> takes place without any special action by the user other than
>>>       >> creating text. Transmission is usually time sampled in
>>> about 300 ms
>>>       >> samples.
>>>       >>
>>>       >> I want to start with the negotiation aspect. Before the
>>> bridge can
>>>       >> start transmitting RTT in a way suitable for good
>>> presentation of
>>>       >> multi-party RTT, it must know that the receiving party is
>>> capable of
>>>       >> separating text from the different participants. Also the
>>> UA may need
>>>       >> an indication that it should include source information in
>>> a specific
>>>       >> way for multi-party RTT to work..
>>>       >>
>>>       >> Therefore, a negotiation method is needed. Chapter 7
>>> contains the
>>>       >> following negotiation alternatives.
>>>       >>
>>>       >> 7.1 Implicit negotiation by the bridge expressing RTT
>>> multi-party
>>>       >> capability indications according to RFC 4575, and the UA
>>> showing
>>>       >> multi-party awareness only if it supports multi-party RTT.
>>>       >>
>>>       >> 7.2 Define a new SIP media tag indicating RTT multi-party
>>> capability.
>>>       >> Start using multi-party RTT after a successful capability
>>> exchange.
>>>       >>
>>>       >> 7.3 Define a new SDP attribute on media level, indicating RTT
>>>       >> multi-party capability. Start using multi-party RTT after a
>>>       >> successful capability exchange.
>>>       >>
>>>       >> There may be other alternatives that I have not thought about.
>>>       >>
>>>       >> Pros and cons for these methods are documented in chapter 7.
>>>       >>
>>>       >> I hope we can discuss the negotiation methods and soon get
>>> to a
>>>       >> conclusion.
>>>       >>
>>>       >>
>>>       >>
>>>       >> Regards
>>>       >>
>>>       >> Gunnar
>>>       >>
>>>       >>
>>>       >>
>>>       >>
>>>       >> Den 2019-11-01 kl. 00:43, skrev Gunnar Hellström:
>>>       >>
>>>       >> Hi mmusic and avtcore,
>>>       >>
>>>       >> I have replaced an old expired draft about real-time text
>>> multi-party
>>>       >> handling. It touches both transport and negotiation topics,
>>> so I am
>>>       >> sending this to both mmusic and avtcore, but I hope we can
>>> keep the
>>>       >> discussion in mmusic. So, please respond with your comments
>>> to mmusic.
>>>       >>
>>>       >> Right now, the draft is a discussion paper. I intend to
>>> convert it to
>>>       >> a true BCP format after some discussions on the preferences
>>> I have
>>>       >> proposed.
>>>       >>
>>>       >> Regards
>>>       >>
>>>       >> Gunnar Hellström
>>>       >>
>>>       >>
>>>       >> -------- Vidarebefordrat meddelande --------
>>>       >> Ämne:
>>>       >> I-D Action: draft-hellstrom-mmusic-multi-party-rtt-00.txt
>>>       >> Datum:
>>>       >> Thu, 31 Oct 2019 16:33:35 -0700
>>>       >> Från:
>>>       >> internet-drafts@ietf.org<mailto:internet-drafts@ietf.org><mailto:internet-drafts@ietf.org><mailto:internet-drafts@ietf.org>
>>>       >> Svar till:
>>>       >> internet-drafts@ietf.org<mailto:internet-drafts@ietf.org><mailto:internet-drafts@ietf.org><mailto:internet-drafts@ietf.org>
>>>       >> Till:
>>>       >> i-d-announce@ietf.org<mailto:i-d-announce@ietf.org><mailto:i-d-announce@ietf.org><mailto:i-d-announce@ietf.org>
>>>       >>
>>>       >>
>>>       >>
>>>       >> A New Internet-Draft is available from the on-line
>>> Internet-Drafts
>>>       >> directories.
>>>       >>
>>>       >>
>>>       >> Title : Real-time text media handling in multi-party
>>> conferences
>>>       >> Author : Gunnar Hellstrom
>>>       >> Filename : draft-hellstrom-mmusic-multi-party-rtt-00.txt
>>>       >> Pages : 36
>>>       >> Date : 2019-10-31
>>>       >>
>>>       >> Abstract:
>>>       >> This memo specifies methods for Real-Time Text (RTT) media
>>> handling
>>>       >> in multi-party calls. The main solution is to carry
>>> Real-Time text
>>>       >> by the RTP protocol in a time-sampled mode according to RFC
>>> 4103.
>>>       >> The main solution for centralized multi-party handling of
>>> real-time
>>>       >> text is achieved through a media control unit coordinating
>>> multiple
>>>       >> RTP text streams into one RTP session.
>>>       >>
>>>       >> Identification for the streams are provided through the RTCP
>>>       >> messages. This mechanism enables the receiving application to
>>>       >> present the received real-time text medium in different ways
>>>       >> according to user preferences. Some presentation related
>>> features
>>>       >> are also described explaining suitable variations of
>>> transmission and
>>>       >> presentation of text.
>>>       >>
>>>       >> Call control features are described for the SIP environment. A
>>>       >> number of alternative methods for providing the multi-party
>>>       >> negotiation, transmission and presentation are discussed and a
>>>       >> recommendation for the main one is provided. Two
>>> alternative methods
>>>       >> using a single RTP stream and source identification inline
>>> in the
>>>       >> text stream are also described, one of them being provided
>>> as a lower
>>>       >> functionality fallback method for endpoints with no
>>> multi-party
>>>       >> awareness for RTT.
>>>       >>
>>>       >> Brief information is also provided for multi-party RTT in
>>> the WebRTC
>>>       >> environment.
>>>       >>
>>>       >> EDITOR NOTE: A number of alternatives are specified for
>>> discussion.
>>>       >> A decision is needed which alternatives are preferred and
>>> then how
>>>       >> the preferred alternatives shall be emphasized.
>>>       >>
>>>       >>
>>>       >> The IETF datatracker status page for this draft is:
>>>       >>
>>> https://datatracker.ietf.org/doc/draft-hellstrom-mmusic-multi-party-rtt/
>>>
>>>       >>
>>>       >> There are also htmlized versions available at:
>>>       >>
>>> https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00
>>>       >>
>>> https://datatracker.ietf.org/doc/html/draft-hellstrom-mmusic-multi-party-rtt-00
>>>       >>
>>>       >>
>>>       >> Please note that it may take a couple of minutes from the
>>> time of
>>>       >> submission until the htmlized version and diff are
>>> available at
>>>       >> tools.ietf.org.
>>>       >>
>>>       >> Internet-Drafts are also available by anonymous FTP at:
>>>       >> ftp://ftp.ietf.org/internet-drafts/
>>>       >>
>>>       >> _______________________________________________
>>>       >> I-D-Announce mailing list
>>>       >> I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org><mailto:I-D-Announce@ietf.org><mailto:I-D-Announce@ietf.org>
>>>       >> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>       >> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>       >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>       >>
>>>       >>
>>>       >>
>>>       >> _______________________________________________
>>>       >>
>>>       >> mmusic mailing list
>>>       >>
>>>       >> mmusic@ietf.org<mailto:mmusic@ietf.org><mailto:mmusic@ietf.org>
>>>       >>
>>>       >> https://www.ietf.org/mailman/listinfo/mmusic
>>>       >>
>>>       >> --
>>>       >>
>>>       >>
>>>       >>
>>>       >> + + + + + + + + + + + + + +
>>>       >>
>>>       >>
>>>       >>
>>>       >> Gunnar Hellström
>>>       >>
>>>       >> Omnitor
>>>       >>
>>>       >>
>>> gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>
>>>       >>
>>>       >> +46 708 204 288
>>>       >>
>>>       >> --
>>>       >>
>>>       >> + + + + + + + + + + + + + +
>>>       >>
>>>       >> Gunnar Hellström
>>>       >> Omnitor
>>>       >>
>>> gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se><mailto:gunnar.hellstrom@omnitor.se>
>>>       >> +46 708 204 288
>>>       >
>>>       >
>>>       --
>>>             + + + + + + + + + + + + + +
>>>             Gunnar Hellström
>>>       Omnitor
>>>       gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se>
>>>       +46 708 204 288
>>>             _______________________________________________
>>>       mmusic mailing list
>>>       mmusic@ietf.org<mailto:mmusic@ietf.org>
>>>       https://www.ietf.org/mailman/listinfo/mmusic
>>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org<mailto:mmusic@ietf.org>
> https://www.ietf.org/mailman/listinfo/mmusic

--

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se>
+46 708 204 288

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic

--

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se>
+46 708 204 288