Re: [AVTCORE] Source switching performance in draft-hellstrom-avtcore-multi-party-rtt-source-01.txt - suggested text changes

Gunnar Hellström <> Wed, 18 March 2020 19:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14EA93A1A9D for <>; Wed, 18 Mar 2020 12:21:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Status: No, score=-1.698 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id peCz-QvRcCni for <>; Wed, 18 Mar 2020 12:21:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86A073A1A98 for <>; Wed, 18 Mar 2020 12:21:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=Lc8hA9V7e5cNOTNesqm5vtcR9tGAYBZFOK0OUERaUTsl/EaQrQXWwWISFb20S5OXBIQq6qO8eU6Pa0qVDCDuMLhLouW6s+pvzDsnsb4wb/ywcFeMR1R6VhlMLThtKS0xVasfqtrHc+uGGgE4fUq922zoRVsuHUCuabzubpIeZNG41LcnyVu6JEYLrRpHCKv/pR07ASpaUCzga/zWNWVKwMJkXONPXdOA/fS2p0OGZ/aDzn4iLoZrVgvaVCVfJyWfCrhcjiKKLSaMCw3Go5Z8NplSGwYPvdtk7s17ak0pnuVfLhUTrKIVALCUI6QTMPg7UXvxICr1CiETQuPdx0z4dw==
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=mBAKDlod2RrGSr0SivKOF5Vi4AcEs6ZDAOB9fCs4YzI=; b=Ox8u2RTBCJfuDk1aVYrIafFWR5qTuyqHYAqYfe9UeF+tJYptCEt8anuCMIYWGFmIgQK//iFE+Ry3f6QMQKV7DtJgd94z65V6OSONMVGzVUQiNuLgW+G9eHCsESeX6Dpc/yzBWhGgjDcv7RC2wRAVe2BTOUoaKSfEmNESIVJH3YGTbCqwGnKKwRn0EHhZ+lsJm4uTtmtXABOWXeaH0BO77KDOhx/vs2hECcdpuB/U8yOawiiNFkev0zjEreh2SJfbHM20bQakN4WWEety2bg1kx5qmqFPJ6MXceIpRLqQz0nK4mOSWm78RCTGXb4fKFUDsX8FYsQofP1AV0wRuW67BQ==
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-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=mBAKDlod2RrGSr0SivKOF5Vi4AcEs6ZDAOB9fCs4YzI=; b=iwRiRzDZlJOJn+BvwSY3FUa643EsT1ST6PJF6lkreKBm3tu0c1Kg6+Fa/wh40hNEvDo676lHASFwVZ8i+8JlvFfm8SS7p8lCzHeaVHWONaBqkblDRsqviR2sElqXU85wanPPkn5W7RQzTCEDpRNfB5H7AOsu476y4hrlQ6LTwYU=
Authentication-Results: spf=none (sender IP is );
Received: from PR3P193MB0618.EURP193.PROD.OUTLOOK.COM ( by PR3P193MB0522.EURP193.PROD.OUTLOOK.COM ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.16; Wed, 18 Mar 2020 19:21:34 +0000
Received: from PR3P193MB0618.EURP193.PROD.OUTLOOK.COM ([fe80::d96c:b1fb:87f4:b274]) by PR3P193MB0618.EURP193.PROD.OUTLOOK.COM ([fe80::d96c:b1fb:87f4:b274%3]) with mapi id 15.20.2814.021; Wed, 18 Mar 2020 19:21:34 +0000
To: James Hamlin <>, "" <>
References: <> <> <>
From: Gunnar Hellström <>
Message-ID: <>
Date: Wed, 18 Mar 2020 20:21:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------18BF83073836E1E5FFB098B6"
Content-Language: sv
X-ClientProxiedBy: AM0P190CA0021.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::31) To PR3P193MB0618.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:3b::18)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [] ( by AM0P190CA0021.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.18 via Frontend Transport; Wed, 18 Mar 2020 19:21:34 +0000
X-Originating-IP: []
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 4317aaf8-7f98-48ff-cf9d-08d7cb719253
X-MS-TrafficTypeDiagnostic: PR3P193MB0522:
X-Microsoft-Antispam-PRVS: <PR3P193MB052231B225D529EB78281201FBF70@PR3P193MB0522.EURP193.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:7691;
X-Forefront-PRVS: 03468CBA43
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39830400003)(346002)(376002)(396003)(199004)(6486002)(86362001)(52116002)(2616005)(508600001)(966005)(956004)(81166006)(8936002)(5660300002)(316002)(16576012)(81156014)(8676002)(66476007)(110136005)(66556008)(66946007)(2906002)(31686004)(21615005)(31696002)(16526019)(53546011)(19627405001)(26005)(66574012)(36756003)(186003)(30864003); DIR:OUT; SFP:1102; SCL:1; SRVR:PR3P193MB0522; H:PR3P193MB0618.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
Received-SPF: None ( does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 1vhDvHOh7hVDtzYX4FG9MqIWgO1KZJd8MkK0XJadukH+9h4AKe607/M0xjqjI9OnsTVJzYQp8DKgjuRetP1kI/KYEeQPdjYoJKpNRTTLDeHjtAODztaNfPGe7mU0ZSHv2EjZ522asEet+SrGNfYyLk0WNHtAh8pyCXWUGZCo1RPCVFvJZHiyGGkXMwRAnH/3YXvE4ru6go6P6jA+UZrNtWoaUHFK82xPPvTzcMzcC7W+d9lWJZkZ7gEVI7ut2Tn6to9UKtGgRjGXGirH/h/K+ddE4fF/uTOPgB2IYDrnxDEbQ2OR9vTxjnN+nVfmFGjwI8domuXt+nSintPz4ROsFrZGeEWC2Sww2SokhXCYzQv+MPyVX8Y9DftikfxrWL6kzlQZquZbYUYKrjaDb5fIZQ53FHrMS0IcapmgrlpYuiaFjeRdE0JJRR57QYJie/BibJ2WBA+WPQjcmBoJBOsgXeBGUQz3M3egtW/KJ36HWeZRzbYGOMyhKXp/SJtnLhA0um5o7/vo/NH+WmVdp8OSVg==
X-MS-Exchange-AntiSpam-MessageData: 8UiQB3ZSoT0qqe7KTUI9UVWbZo6nuXTjO0MAMuaxH+3+ngx6lIDXCEeA//k8Qx5Pzrtjj+CBBpgk/8b/c5nKPxkRrjW+cwB7zuI32Fhe+9zq0EhRiUrQQJIWFNT0mpvHa1Qr1E9/Mza/Jd30wcD8Lg==
X-MS-Exchange-CrossTenant-Network-Message-Id: 4317aaf8-7f98-48ff-cf9d-08d7cb719253
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2020 19:21:34.4775 (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: NT+dMyRsobhME0PR/pyu+QvaidqVG5hEYYpbGrutlH1idBE+gqGOYosYxn4viUCOLnFw+f+lW6EoRUh8Upalf+fda2gXv6IbyXgqUPOS8cY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P193MB0522
Archived-At: <>
Subject: Re: [AVTCORE] Source switching performance in draft-hellstrom-avtcore-multi-party-rtt-source-01.txt - suggested text changes
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Mar 2020 19:21:46 -0000

Hi James,

Thanks for good proposals.

Comments inline.

Den 2020-03-18 kl. 12:50, skrev James Hamlin:
> Hi Gunnar
> Having thought through some alternatives, it is now easier to suggest 
> possible changes to the current text.
> In Section 11 SDP Capability negotiation, append:-
>     When an rtp-mixer offers the "rtt-mix" capability, it SHOULD be
>     willing to provide a mixed stream according to
>     [or should this be in-lined?] that is compatible with RFC4103
>     implementations that do not implement this specification, unless
>     it is known that it will not need to inter-operate with such
>     implementations.
[GH] Interesting proposal. I had imagined this multi-party-rtt-source 
draft to be a pure technical specification for the multi-party rtt 
transport. This proposal makes it a slightly wider prescription on what 
mixers should do also in other cases. It is good that you link this with 
the rtt-mix capability indication, because that provides an opportunity 
to make the presentation on an un-aware device just a little bit better.
I would like to hear comments from the expected users of this 
specification if we shall have this requirement here.

Next thing. I do not want to make us depend on the progress of the 
draft. Therefore if we decide to have this requirement included, I would 
like to include a minimal description of the mixing procedure for 
multi-party unaware terminals. A rewording of this section: 

> In section 10.  Usage without redundancy:-
>     When transmitting, using the text/t140 format, to a party that has
>     indicated the "rtt-mix" capability, the CSRC-list SHOULD
>     contain exactly one member.
>     To avoid potential interoperability problems with older RFC 4103
>     implementations which do not expect a CSRC-list, the CSRC-list
>     SHOULD be empty when transmitting to a party that has not has
>     indicated the "rtt-mix" capability.
[GH]That would be against RTP RFC 3550. I assume that current 
implementations simply ignore the CSRC list. Therefore including CSRC 
would be the right thing to do to follow RFC 3550.
>     The text/red format SHOULD be used unless some other protection
>     against packet loss is utilized, for example a reliable transport
>     such as TCP.
[GH]I will not mention TCP. It is more likely that there are other 
resons for why the network or transport can be called reliable.
> Section 10 could move to after the current section 11 so the SDP gets 
> defined first.
> In section 4 "Use of fields in the RTP packets" insert:
>     Note: This specification departs from section 4 of RFC2198 which
>     associates the whole of the CSRC-list with the primary data and
>     assumes that the same list applies to reconstructed redundant
>     data. In this specification a text block is associated
>     with exactly one CSRC as described above. Also RFC2198 anticipates
>     infrequent change to
>     CSRCs; implementers should be aware that the order of the
>     CSRC-list according to this specification will rotate during
>     transitions between different participants sending text.
[GH]Good catch
> In "9.  Use with SIP centralized conferencing framework" insert:
>     The CSRC-list in an RTP packet
>     only includes participants who's text is included in one or
>     more text blocks. It is not the same as the list of participants
>     in a conference. With audio and video media, the CSRC-list would
>     often contain all participants who are not muted whereas text
>     participants that don't type are completely silent and so don't
>     show up in RTP packet CSRC-lists.
[GH]Yes, can be good to have that explanation.



> Best regards
> James
> James Hamlin
> Contractor
> Purple, a Division of ZP Better Together, LLC
> The information contained in this e-mail message is intended only for 
> the personal and confidential use of the recipient(s) named above. If 
> you have received this communication in error, please notify us 
> immediately by e-mail, and delete the original message.
> ------------------------------------------------------------------------
> *From:* Gunnar Hellström <>
> *Sent:* 13 March 2020 16:41
> *To:*; James Hamlin
> *Subject:* Source switching performance in 
> draft-hellstrom-avtcore-multi-party-rtt-source-01.txt
> Hi,
> I want to follow-up on the good discussion on source switching 
> performance a couple of days ago, under the subject "[AVTCORE] 
> Improved RTP-mixer performance for RFC 2198 and RFC 4103 redundancy 
> coding"
> *Two parts in the performance increase solution.*
> Two actions are proposed in 
> draft-hellstrom-avtcore-multi-party-rtt-source:
> a) Reduce the packet transmission interval from 300 to 100 ms.
> b) Use a strict relation between members in the CSRC list and the 
> parts of the payload that is original text and first generation 
> redundancy and second generation redundancy so that the mixer can 
> switch source for every new packet and the sources of text recovered 
> from redundancy can be assessed by the receiver.
> I think it is worth while to move forward with the complete 
> improvement a) and b) proposed in the draft. It will cause less 
> complexity, lower delays and lower risk for stalling in case of many 
> participants entering new text simultaneously.
> Here is my reasoning:
> I have the following view of the achievable performance improvements 
> for different cases:
> 1. With the original source switching with RFC 4103 and an RTP-mixer 
> using 300 ms transmission interval and not allowing a mix of sources 
> in one packet, there can be one source switching per second by the 
> mixer with an introduced delay of up to one second.
> 2. By just reducing the transmission interval from 300 to 100 ms, it 
> will be possible to have three source switches per second with an 
> introduced delay of up to one second. (with just two parties sending 
> text simultaneously, the delay will be maximum 300 ms. )
> 3. And by applying the proposal from the multi-party-rtt-source draft 
> with the CSRC-list as a source list for the redundancy, and also using 
> 100 ms transmission interval, there can be switching between five 
> source per second with an introduced delay of max 500 ms. With just 
> two parties typing simultaneously, the delay will be a maximum of 100 ms.
> The delays are extreme values from when all sources start to type 
> simultaneously.  It was agreed that at least the improvement from the 
> reduced transmission interval is needed.
> Case 1 and 2 are a bit complex for the mixer to implement. From the 
> moment it has text queued for transmission from another source B than 
> the one currently transmitted A, then the mixer needs to stop adding 
> new text from A to the packets, but still send two more packets with 
> the agreed transmission interval, progressing the latest transmitted 
> original text to first generation redundancy and then again one more 
> packet with the text as second level redundancy. Not until that is 
> done, the mixer is allowed to start taking text from the transmission 
> queue from B to transmit. This is the background of the 1 s vs 300 ms 
> delays in case 1 and 2.
> In case 3, there is much less complexity. When there is something from 
> B in queue for transmission, the mixer can decide to insert that in 
> next packet and add the redundancy from earlier transmissions from A, 
> because their sources are included in the CSRC list in the same packet.
> Therefore I want to move on with the complete solution in case 3.
> -----------------------------------
> *Influence on the multi-party capability negotiation:*
> There is an installed park of RTT implementations without multi-party 
> awareness. The receiver need to take active part in planning the 
> multi-party RTT presentation. Therefore a capability negotiation is 
> needed. A simple sdp attribute a=rtt-mix without value is proposed in 
> the draft.
> It is important to let this attribute mean capability of the complete 
> solution case 3).  If there is a temptation to have different levels 
> of implementation, some only implementing the shorter transmission 
> interval (2) and some implementing the complete solution (3), then 
> threre will be a need for two different attributes, or one attribute 
> with a list of parameter values for the two cases. That would 
> complicate the evaluation of the negotiation. Therefore I would prefer 
> that the attribute can mean capability to use the complete mixing 
> solution (3).
> Regards
> Gunnar
> Den 2020-02-29 kl. 20:13, skrev
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>          Title           : Indicating source of multi-party Real-time text
>>          Author          : Gunnar Hellstrom
>> 	Filename        : draft-hellstrom-avtcore-multi-party-rtt-source-01.txt
>> 	Pages           : 13
>> 	Date            : 2020-02-29
>> Abstract:
>>     Real-time text mixers need to identify the source of each transmitted
>>     text chunk so that it can be presented in suitable grouping with
>>     other text from the same source.  An enhancement for RFC 4103 real-
>>     time text is provided, suitable for a centralized conference model
>>     that enables source identification, for use by text mixers and
>>     conference-enabled participants.  The mechanism builds on use of the
>>     CSRC list in the RTP packet.  A capability exchange is specified so
>>     that it can be verified that a participant can handle the multi-party
>>     coded real-time text stream.  The capability is indicated by an sdp
>>     media attribute "rtt-mix".
>> The IETF datatracker status page for this draft is:
>> There are also htmlized versions available at:
>> A diff from the previous version is available at:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> I-D-Announce mailing list
>> Internet-Draft directories:
>> or
> -- 
> + + + + + + + + + + + + + +
> Gunnar Hellström
> Omnitor
> +46 708 204 288


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

Gunnar Hellström
+46 708 204 288