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

[Paul Kyzivat <[e-mail]>]

On 3/6/20 2:07 PM, Gunnar Hellström wrote:
> Paul,
> 
> Den 2020-03-06 kl. 19:04, skrev Paul Kyzivat:
>> 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.
> 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.

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

>>  I don't think this is a problem as long as the scheme is properly 
>> 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
> 
> 
>>
>>     Thanks,
>>     Paul
>>
>> On 3/6/20 8:12 AM, Gunnar Hellström wrote:
>>> 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
>>>
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
>