Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix Issue 1: transport

[Gunnar Hellström <[e-mail]>]

I have concluded that only two of the discussed transports are realistic.

Comments below

Den 2020-05-11 kl. 12:22, skrev Gunnar Hellström:
> In a recent e-mail, I listed 9 issues to act on in 
> draft-ietf-avtcore-multi-party-rtt-mix-00
>
> I want to deal with them one by one or in small groups. Here is number 1:
>
> 1. Consider rapidly if there is any more reliable transport that is 
> feasible to move to.
>> (e.g. Comedia RFC 4145 and RFC 4572, or the recently approved WebRTC 
>> t140 data channel draft-ietf-mmusic-t140-data-channel-usage, or use 
>> of SAVPF with NAK and retransmission RFC 4588) 
>
> It may look strange with this issue after many months as an individual 
> draft. But I want to touch it anyway before we move on in one fixed 
> direction.
>
> T.140 and its RTP transport (RFC 2793 - later RFC 4103) were created 
> 1998 - 2000 as the third real-time medium for human conversations 
> beside voice and video. The idea was to give equal opportunities to 
> persons wanting to communicate by text as the ones who use voice or 
> video. That means real-time transmission while text is created and 
> accepting some rare dropouts just as we do with voice and video. 
> However, users are nowadays used to text messaging where it is 
> customary to accept a delay and get the text complete in most cases, 
> rather than to have loss. That user experience might be expected from 
> real-time text as well. I do not have any strong user indications that 
> this is the case, it is just my own thinking.
>
> The reason to bring this up now, is that we seem to need to introduce 
> the multi-party mixed format at least as a new text media subtype, 
> text/rex instead of text/red. Then we are anyway introducing signaling 
> complexity of similar kind that another transport will do.
>
> Are any of the initially mentioned more reliable transports realistic 
> and easily implemented in the target implementation environments: NG 
> emergency services, 3GPP IMS MTSI, IETF RUM, and plain SIP multimedia? 
> Or are there any other not mentioned?
>
> When considering this, we should have in mind that the proposed 
> transport should be with security so that we do not need to introduce 
> more options to negotiate between.
>
> And we shall also keep in mind that NAT traversal needs to be 
> supported as well as multi-party-signaling through the SIP central 
> conferencing model RFC 4353.
>
> Another complexity is that current regulation requires RFC 4103 and it 
> would be best that the finaly specified multi-party solution can be 
> perceived as an extension to RFC 4103.
>
> What can be said about the options?
>
>  1. Comedia RFC 4145 and RFC 4572. Makes use of TLS for transport, so 
> it is secured. Should use RFC 6544 ICE for TCP for NAT traversal. 
> Requires specification of how to arrange the streams and code the 
> sources in the multi-party environment. I do not know how well these 
> RFCs are supported in the target environments. Seems to increase 
> complexity.
--Increases complexity - not selected
>
> 2. draft-ietf-mmusic-t140-usage-data-channel. Has security, NAT 
> traversal and possibility to code multi-party source. Has good 
> opportunity for being supported in endpoint devices, because all of 
> them are expected to support WebRTC. Maybe less supported in 
> traditional SIP bridges.
--A realistic solution. The base is already approved and is for a 
popular environment. Multi-party is briefly mentioned but should 
probably be a bit further specified. Should however not be the only 
solution. The RTP based solution is also needed.
>
> 3. SAVPF with NACK and RFC 4588 retransmission. I assume this can be 
> combined with OSRTP RFC 8643 for security negotiation. When the 
> immediate or early feedback option can be used, this method can likely 
> be used without redundancy to achieve a reliability enhancement. That 
> will not work well over networks with high latency. Further study 
> needed if redundancy or FEC is needed as complement for high latency 
> networks. Easy to achieve up to 5 simultaneously sending users.
--Increases complexity - not selected
>
> 4. (Not mentioned in the introduction above) Use RFC 4103 plus one of 
> the RTP based methods for multi-party source indication but just 
> increase redundancy to one original and three (instead of two) 
> redundant generations. Can easily be done if reliability increase is 
> really a concern. Has low overhead. Easily applicable to OSRTP 
> security, SIP conferencing model and ICE NAT traversal.
--Easily done by local recommendations if 3 generations redundancy 
(including the original) would not be felt sufficient somewhere.
>
>
> 5. Accept reliability that is quite good as it is with RTP with one 
> original and two redundant generations in the RFC 2198 - style ( with 
> one of the additional methods discussed for increasing switching 
> performance)
>
--Realistic and regarded sufficient. By move to a mixer method allowing 
300 ms transmission interval, the protection against burtsy packet loss 
is quite good. Continue on this track.


The conclusion is reflected in version -01 of the draft, just published.

Regards

Gunnar


> Comments please so we can take a rapid decision and move on with one 
> solution.
>
> Regards
>
>
> Gunnar
>
>
>
>
-- 
Gunnar Hellström
GHAccess
[e-mail]