Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 07 May 2020 21:12 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E073A0DD5 for <avt@ietfa.amsl.com>; Thu, 7 May 2020 14:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 iX3NaiiWjU3E for <avt@ietfa.amsl.com>; Thu, 7 May 2020 14:12:28 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2117.outbound.protection.outlook.com [40.107.22.117]) (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 BAF9B3A0DD1 for <avt@ietf.org>; Thu, 7 May 2020 14:12:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZLJ14NojBpPki4HbPl2QtiPkQKYm87Q+d1Hn00+p24x3KAEfRNN07K9B1EqZPo2qXpa1ZIt/mZLRxxJ5pcqASSnXNwN71CakYFpvjw9EfrX5qp9BfRh3jIepn4Im8BitTxH+CljcbYjDksVxPvJOh8mrcFIdHqLIns+/clzDjEY4KdIiCD/p071wiOg0PRmKQKKRX5M0O88P10TnBKvk3zAAzJOzMlYGM94ufX+QvFK/UZF7NfLORN+zPdcFevZ2ErWCVbBpPBhP8/2EYa7C6ItGn+cRoo3NdVTu0IlnddKBSe1+w6JVAZYh4kK1TBihLI784A+SpCSE3nwJeebdkg==
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=UUihtyw+z3Evl8roIwc9vmc0MK6IQtgzKbSomZyIEFo=; b=JeikSYF8/Y/zRDhDk525yL5PZz5ZDaDOdoYoHx9aU06QdzA7q7RpBgu6hrlArQsXkURbJ783O/+SQOVdj/YIGsWS/v/ixkAs0R3VrOdrg25LZsfQZWmM1fNop9gKcwFB8dZz1w3+lhIYh4i366fNEDedGlyP++ZrUSu3xbEvEsN2Wk2BkzGOX+fjujWJezwL04k9RnyyaVJ1rS0p5t0Iyt81V+6svDo3wIzOFWtHBDtaBGZt95H/XuPz8uAv71ypDKObj999FxOkhocuwS0wusf/mbZOA09uSZplAuK+VbTiYcN+2ioWuafw4xS0YD+VD8iq8QworA4boblswZvweg==
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=UUihtyw+z3Evl8roIwc9vmc0MK6IQtgzKbSomZyIEFo=; b=gHHTzexLp2Vmp6eWuILGsQoe7I4C+uExC8luIIIwYCZ1SzdSbug8bidKvvCRjkUrL1a7dD8VVFqbSu7hvv0r0YIY7OHOX0CFJ7ahjZbKvQecVYHpM+VOOrfjvL2+Ktr1u4mZnQxC3ShOIpyN/Mg/StZTNALqMnkt5WmDH8Mc0pU=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=omnitor.se;
Received: from PR3P193MB0650.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:32::13) by PR3P193MB0489.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:30::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Thu, 7 May 2020 21:12:23 +0000
Received: from PR3P193MB0650.EURP193.PROD.OUTLOOK.COM ([fe80::cc04:8066:494b:a9e2]) by PR3P193MB0650.EURP193.PROD.OUTLOOK.COM ([fe80::cc04:8066:494b:a9e2%9]) with mapi id 15.20.2958.034; Thu, 7 May 2020 21:12:23 +0000
To: "Dale R. Worley" <xthe.various.worley@ariadne.com>, =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Cc: avt@ietf.org
References: <87sggdaiq4.fsf@hobgoblin.ariadne.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <b14513ac-c8f2-7e54-75d9-d2c7f67c3f97@omnitor.se>
Date: Thu, 7 May 2020 23:12:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
In-Reply-To: <87sggdaiq4.fsf@hobgoblin.ariadne.com>
Content-Type: multipart/alternative; boundary="------------551C2C1F6B8E13D7D52BAB0F"
Content-Language: sv
X-ClientProxiedBy: HE1PR0102CA0024.eurprd01.prod.exchangelabs.com (2603:10a6:7:14::37) To PR3P193MB0650.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:32::13)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.2.136] (83.209.157.125) by HE1PR0102CA0024.eurprd01.prod.exchangelabs.com (2603:10a6:7:14::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28 via Frontend Transport; Thu, 7 May 2020 21:12:23 +0000
X-Originating-IP: [83.209.157.125]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 1e5b004b-30a4-43d6-d471-08d7f2cb5634
X-MS-TrafficTypeDiagnostic: PR3P193MB0489:
X-Microsoft-Antispam-PRVS: <PR3P193MB048958FAC4ED7D594AC329E4FBA50@PR3P193MB0489.EURP193.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 03965EFC76
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: dS4ZoEWHHAxQPuTBMgwsbjoAaIKSFVDrZswo18FIDS8ohLe1e50IdOEjcTWuYj6yF9I/ERDV0lbCMh4oyv3PM1QCtf/PQYu5XX0biLFvJz/k9VJMZhfZCKDawpOc8FqkBeDOZjxm4rVKQFqt6Js8ncv137Aj1fHAH///orrwnYqYuRlqmabhjAFb+1covp0TqGGWp/8V/xo/OD8XyHcHVgoQD+HbvAO+cSHO9Hd6Bg5oSM3WQ5g8JKZ4sRn5c8fsAb9O4WevU2YE1FLh0bPcmtVCx3DdMh3vok88nloOCLk2Y3jC39MaO7MR9O26n5XeGKdICE1PcWsWkNXNj9i1kQxPipAcUqkSPxa8wgrxBhiqxIih5AfaniTQ+nnPm9HsughpwubgvS7G9WQAIJU3ZtxZm1Z/tWKbM5cvp92x93tUkvAIOyE2cgEZxtKAtXDzv5UZNHtzQiKUiwF84CMVN+pwy5V+tZyMoQ0UpfxqYkkgRhSws5lJ0b+75nMssDFgffOcveqWzaR5Atl04xF1+i2MHSUXvi0//dE4OPLm+d0Sv3Zj3DWZjF7o4xD2P7SI8zcuRleXtnkCynGE4/asn75Zv96ZtjR7bo8BzcInkI5Fd8Amd0ZuKa7mOzP34R6sik8FE/op/tY4cY/I2cTuXg==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P193MB0650.EURP193.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(376002)(136003)(39830400003)(396003)(346002)(366004)(33430700001)(966005)(8676002)(8936002)(508600001)(166002)(4326008)(316002)(110136005)(66574014)(52116002)(31686004)(66556008)(86362001)(31696002)(956004)(2616005)(66946007)(16576012)(5660300002)(36756003)(6486002)(33440700001)(66476007)(16526019)(83320400001)(83280400001)(83310400001)(83290400001)(186003)(2906002)(83300400001)(26005)(43740500002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: k4fI//WZ7iG+sj452KJ/cLYY45Olpv75OWE5SwCY5JZjXyg81nAkGEP+wvI0KelM4GzJlbhiQOzIpu6hZ7nALufuTGW+HlnGfzFdIhmLDp1euJ96pgYl4CVKl+DDBWp6NdNB96ZEb5U/GpsE2CTOApYz94RVlpY6r3Ezb1tMmi/70fqLbht69velE7vwuGvPpI5RszbwInTCxcAKHoR5a863aegdEY9+z1zvM/CizpXLjyFO2uqJB9R3JTrAtdvmLKwuW8De+AyFxHOazHlrwVFtlq2bON8Gx4iIf/UcjnbP9tote9knZHilaCsK8nMDO8l0sgWwKEpHqOmbskXy4NBzfbaxAMEMCADG2yinSfJXtYiUgCryJt2e6qHSx+UnMFCnbcLKFF3lMpRUSu5e/f7DPrczxEwDI9Y3U0ZBGcbVQTfEH/d2aXi4ETGsEqsprjpGNErDkbCrIRGECw4iwOtLYGjX/P2XnKXc0Lx1HVFiTlDPkJc94P6KWBiVa2ToXoN3HCzyv0+EWR8RWDr4GzKuAJQkv+jpc845JAJ90I+Qrr7fHadejxN1V+pRrq0GfDWSWklWfS3+7P/XWlv3G/9ZtDCfVEWCZ/P6/C8ZuNucU2SCPfvs7Bke0OXalWJAY6PVmv2VEWw3Y9rDs5LlNsJ+H8VohWjviEzpK6M9ZF4Rzx3mKRsKanSI3EI3J0qy50D02Do8Is6VDOQLnHGGDs64FuZ+JIYy5R0exeoazMdiT4WC4792Dwt2EH+S9b7kEdZN6WbKmtRVKRukF8HJcx0SLx5iy6bazMStMrZlfQM=
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 1e5b004b-30a4-43d6-d471-08d7f2cb5634
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2020 21:12:23.6622 (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: mJBR9yDqLk8UcH29AKai7URjyEQUMeIswp6Sg0GnjW93NiFpPFYX2yeE4irbXxTa0wHRqDCjEYDw3q3aTW1P+9YHZ7P5IE1mDOQ78I7Hl6Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P193MB0489
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/jWzPzI8NrMwK6c-0yNFCMGAbjLA>
Subject: Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 May 2020 21:12:48 -0000

Hi Dale,

Den 2020-05-06 kl. 04:40, skrev Dale R. Worley:
> Gunnar Hellstr\"om <gunnar.hellstrom@ghaccess.se> writes:
>> I propose to add the following last in the introduction:
>>
>> -------
>>
>> 1.1.  Considered alternative
>>
>>      The mechanism specified in the present document makes use of the RTP
>>      mixer model specified in [RFC3550].  From some points of view, use of
>>      the RTP translator model specified in RFC 3550 would be more
>>      efficient, because the text packets can pass the translator with only
>>      minor modification.  However, there is no widely supported sdp
>>      [RFC4566] specification for the translator model.
> It doesn't seem to be that lack of an SDP specification for a
> translatory would be needed, but I suspect that's due to my lack of
> knowledge of the practical problems involved -- as far as I can tell,
> such a connection could be negotiated in the ordinary way, and the fact
> that the packets' SSRCs vary would identify that there were various
> sources interleaved.
RFC 3264 says in section 5 and a couple of other places 'each media stream

is described by an "m=" line and its associated attributes'

I am not so sure that "media stream" means the same as RTP stream for 
RTP based media, but that seems to be an often made conclusion.


>
> Though given that some protocol action will be necessary anyway (e.g.,
> defining a new payload type), would it be difficult to invent an SDP
> attribute that means "multiple sources will be interleaved, check the
> SSRCs"?

I found that idea documented in an expired draft:

https://tools.ietf.org/pdf/draft-even-mmusic-multiple-streams-02.pdf

I do not know if that idea has been continued elsewhere. Therefore I 
also doubt that current RTP implementations are easy to request to watch 
out for new SSRCs. I took a look into one RTP implementation, and yes, I 
found some traces of a possibility to look for new SSRCs, but also other 
places where the method documented in RTP to detect a shift of SSRC for 
an existing stream by seeing 50 packets received with the new SSRC.

A lot of work has gone into multiplexing multiple streams of different 
media types into one RTP session, in RFC 8108 and


  draft-ietf-mmusic-sdp-bundle-negotiation

It would be possible to use these for our case but it is overkill, and 
it is likely

not implemented in the systems where multi-party-real-time text is 
urgently wanted.


For our case, I think it is good if a new conference participant can be 
added to an existing session by just adding a new source in an RTP 
session, without SDP action. The SIP Conference model has a SIP 
notification for a new participant. That notification has a media 
element that can contain an ssrc element. That can be a way to announce 
the new participant's text stream and tell the receiving RTP stack what 
to be prepared for, either as a new merged stream in a stream from an 
RTP-mixer, or as a new stream in an RTP session from an RTP-translator. 
Indications so far say that RTP implementations do not support the 
translator. I would be glad to be told that that is wrong.


Regards

Gunnar

>
> Dale
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 

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

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