Subject: [AVTCORE] Improved RTP-mixer performance for RFC 2198 and RFC 4103 redundancy coding

From: Gunnar Hellström <[email-masked]>
Date: Fri, 6 Mar 2020 14:12:42 +0100

Hi,

I have submitted a proposal for improved performance for multi-party 
mixers dealing with RFC 4103 real-time text.

https://datatracker.ietf.org/doc/draft-hellstrom-avtcore-multi-party-rtt-source/

It just came to my mind that the same solution can be used for any media transport using the RFC 2198 redundancy coding.

The problems with the redundancy packetization is that there is no place for source for each redundant part in the reduncancy header. Therefore the traditional assumption is that all payload parts of a packet has the same source. That makes source switching in a mixer inefficient.

The solution is to let the members of the CSRC list in the RTP packet exactly correspond to the sources of the different parts of the payload ( primary, 1st redundant etc).

I want to progress the draft for the RFC 4103 use, but am interested to support any discussion on the more general use of the solution.

Regards
Gunnar

-- 

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

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 6 Mar 2020 13:04:30 -0500

Gunnar,

I'm not deeply knowledgeable regarding RTP, but I think I understand 
what you are proposing. It seems like it should work in typical cases 
for RTT. But I think it doesn't work properly for other media (notably 
voice) and might not work for some unusual cases of RTT.

The issue is that you are repurposing CSRC. In the case of audio mixing, 
multiple sources are literally mixed to form a single stream of audio, 
and the CSRCs are used to show which ones have been mixed. In that 
situation your scheme doesn't seem to work.

Similarly, ISTM that it is at least *possible* to build a RTT mixer that 
does something similar, mixing multiple sources into a single text 
stream. If this was done then again your scheme for coding redundancy 
wouldn't work right.

I don't think this is a problem as long as the scheme is properly 
circumscribed to the situations where is is applicable.

	Thanks,
	Paul

On 3/6/20 8:12 AM, Gunnar Hellström wrote:
> It just came to my mind that the same solution can be used for any media 
> transport using the RFC 2198 redundancy coding.
> 
> The problems with the redundancy packetization is that there is no place 
> for source for each redundant part in the reduncancy header. Therefore 
> the traditional assumption is that all payload parts of a packet has the 
> same source. That makes source switching in a mixer inefficient.
> 
> The solution is to let the members of the CSRC list in the RTP packet 
> exactly correspond to the sources of the different parts of the payload 
> ( primary, 1st redundant etc).
> 
> I want to progress the draft for the RFC 4103 use, but am interested to 
> support any discussion on the more general use of the solution.
> 
> Regards
> Gunnar
>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 6 Mar 2020 20:07:43 +0100

Paul,

Den 2020-03-06 kl. 19:04, skrev Paul Kyzivat:
> The issue is that you are repurposing CSRC. In the case of audio 
> mixing, multiple sources are literally mixed to form a single stream 
> of audio, and the CSRCs are used to show which ones have been mixed. 
> In that situation your scheme doesn't seem to work.
Right. So I should not bother about the use of the method for other 
media than real-time text.
>
> Similarly, ISTM that it is at least *possible* to build a RTT mixer 
> that does something similar, mixing multiple sources into a single 
> text stream. If this was done then again your scheme for coding 
> redundancy wouldn't work right.

Yes, in the other draft with a wider description about the problem and 
possible solutions,  ( draft-hellstrom-mmusic-multi-party-rtt ) , there 
are three different solutions discussed based on traditional RTP-mixing, 
with two of them having the source identified in the stream, but the one 
I recommend and made the specific draft for ( 
draft-hellstrom-avtcore-multi-party-rtt-source ) having the specific use 
of the CSRC list to indicate the source of each primary and redundancy 
element.

In order to know that the parties agree on using that specific use of 
the CSRC list, I propose a negotiation by a new SDP media attribute 
"a=rtt-mix" . Only if both parties include that attribute in the 
real-time text media description they may assume that the CSRC list is 
used the way the draft specifies.

> circumscribed to the situations where is is applicable.

And that is what I believe I have done in 
draft-hellstrom-avtcore-multi-party-rtt-source.

Thanks for the discussion. We need to progress this draft. It is 
urgently needed as a response to discussions in a group in Canada called 
TIF-89, but also as response to liaisons between ETSI HF and 3GPP SA4.

Regards

Gunnar

>> It just came to my mind that the same solution can be used for any 
>> media transport using the RFC 2198 redundancy coding.
>>
>> The problems with the redundancy packetization is that there is no 
>> place for source for each redundant part in the reduncancy header. 
>> Therefore the traditional assumption is that all payload parts of a 
>> packet has the same source. That makes source switching in a mixer 
>> inefficient.
>>
>> exactly correspond to the sources of the different parts of the 
>> payload ( primary, 1st redundant etc).
>>
>> I want to progress the draft for the RFC 4103 use, but am interested 
>> to support any discussion on the more general use of the solution.
>>
>> Regards
>> Gunnar
>>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 

Gunnar Hellström
Omnitor

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 6 Mar 2020 15:57:46 -0500

> used the way the draft specifies.

I agree that this seems to do the job. I'm interested to hear if others 
who are experts in RTP are happy with this mechanism.

	Thanks,
	Paul