Re: [AVTCORE] Multi-party real-time text requiring new RTP payload type

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

Hi Dale,

Thanks, a good question. It is the right time to consider which source 
multiplexing and reliability method to select, now when we need to 
introduce a new negotiation.

More below

Den 2020-04-23 kl. 04:27, skrev Dale R. Worley:
> I assume that there's a good reason why the case of redundant
> transmission of multi-party text isn't done by suitably interleaving the
> redundant packets of the serveral text sources (which can be separated
> by their SSRC values).  I can't remember if this is a violation of the
> RTP rules, or perhaps it's just inefficient.  But a quick read of the
> draft didn't mention why this approach doesn't work, and it seems like
> it would be a useful note to the reader.
Draft-hellstrom-avtcore-multi-party-rtt-source is intended to contain 
the solution for the type of bridge used in NG9-1-1 and 3GPP IMS, which 
seems to be based on the RFC4535 SIP centralised conference framework.
Backgrounds and discussions of possible methods with a wider scope are 
collected in

draft-hellstrom-avtcore-multi-party-rtt-solutions
<https://datatracker.ietf.org/doc/draft-hellstrom-avtcore-multi-party-rtt-solutions/?include_text=1>

where section 4.2.1 is similar to what you propose with separate ssrc:s 
per source. Each discussed method also has pros and cons briefly 
documented. Having separate SSRC per source is what RTP calls using a 
RTP translator.

Yes, I would have liked to use that method. But we have an urgency in 
implementing the selected method in NG9-1-1 systems and in 3GPP IMS. And 
it is said that many current RTP implementations do not support multiple 
SSRCs in the same RTP session and even that RFC 3264 says that one 
m-section in sdp can only support one SSRC. However, RFC 4588 (FEC) 
section 8.8 shows an SSRC-multiplexing sdp example where the original 
media stream has one SSRC and the redundancy another within the same 
m-section. But that is of course no evidence that current RTP 
implementations support it.

RFC 8108 clarifies in section 3.3 that one of its applications is for 
combining multiple media sources of the same kind in the same RTP 
session. But it has the total goal of multiplexing also multiple media 
in the same RTP session. The corresponding sdp specification (with a 
much wider scope than we need) is 
draft-ietf-mmusic-sdp-bundle-negotiation and it is not supported by many 
current RTP implementations ( but maybe soon is because of its use in 
WebRTC).

Methods that could be considered but are not yet documented in 
draft-hellstrom-avtcore-multi-party-rtt-solutions 
<https://datatracker.ietf.org/doc/draft-hellstrom-avtcore-multi-party-rtt-solutions/?include_text=1> 
are (excuse me if some look far fetched):

RFC 4588 FEC, using SSRC multiplexing if that works or session 
multiplexing if needed. In this case plain T.140 RTP would be sent from 
the mixer in one stream, with the ssrc of the mixer and csrc of the 
source, and in the redundancy stream the packets would be repeated 
(twice) with another ssrc in a small redundancy header.

RFC 8122 Comedia to improve reliability, but then I have not studied how 
to arrange for multi-party use.

draft-ietf-mmusic-t140-usage-data-channel using one WebRTC data channel 
per source.

RFC 8108 section 3.3 and draft-ietf-mmusic-sdp-bundle-negotiation

Avoiding solutions because of imagined limitations in current 
implementations may be a bad design criterium, so do you suggest that we 
rapidly look further into any of these or other options?

Thanks

Gunnar


>
> Dale

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