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

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

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.

2. draft-ietf-mmusic-t140-data-channel-usage. 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.

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.

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.

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)

Comments please so we can take a rapid decision and move on with one 
solution.

Regards


Gunnar




-- 
Gunnar Hellström
GHAccess
[e-mail]