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

From: Gunnar Hellström <[email-masked]>
Date: Tue, 5 May 2020 16:46:38 +0200

Dale,

See proposed text below

Den 2020-04-24 kl. 10:55, skrev Gunnar Hellström:
> Den 2020-04-24 kl. 03:22, skrev Dale R. Worley:
>> Gunnar Hellstrom <[email-masked]> writes:
>>> 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.
>> My idea wasn't that I had any better idea, but rather that there were
>> some obvious ideas, and clearly, people who had studied the matter found
>> that the obvious ideas were not the best.  What I really meant was that
>> it would be useful to give brief documentation why the obvious ideas
>> aren't best.

I propose to add the following last in the introduction:

-------

1.1.  Considered alternative

    The mechanism specified in the present document makes use of the RTP
    mixer model specified in [RFC3550].  From some points of view, use of
    the RTP translator model specified in RFC 3550 would be more
    efficient, because the text packets can pass the translator with only
    minor modification.  However, there is no widely supported sdp
    [RFC4566] specification for the translator model.

-----

Regards
Gunnar

>
> Your question provided a good opportunity to review solution 
> alternatives.
>
> Since the effort to specify multi-party real-time text aims at 
> additions to current implementations of bridges and endpoints I think 
> one requirement should be to keep the solution as close to the current 
> solutions for the other media handles by these bridges and endpoints.
>
> NG9-1-1, NG 112 and 3GPP CONF services specify use of the RFC 4535 SIP 
> conference framework. Adding new participants in that framework 
> usually does not cause any new sdp interaction with the other 
> participants, as long as no new media is added. Just a notification is 
> sent. I assume that it can be good to keep that way of action also for 
> adding participants with real-time text. Using the RTP mixer model 
> adding just members in the CSRC lists is then the most simple model. 
> So, this is yet another reason for why to keep to the RTP-mixer 
> solution for the first specification in the 
> draft-hellstrom-avtcore-multi-party-rtt-source draft. It might be 
> followed by other selected cases in the 
> draft-hellstrom-avtcore-multi-party-rtt-solutions draft, where WebRTC 
> and use of sdp-bundle can be spcified, which are out of scope for the 
> first case.
>
>
> Even if different solutions are discussed in the 
> draft-hellstrom-avtcore-multi-party-rtt-solutions draft, I accept your 
> point and will include a brief motivation also in the 
> draft-hellstrom-avtcore-multi-party-rtt-source draft.
>
> Comments are very welcome about the reasoning.
>
> Thanks
>
> Gunnar
>
>>
>> Dale
>
-- 
Gunnar Hellström
GHAccess
[email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 05 May 2020 22:40:51 -0400

>     [RFC4566] specification for the translator model.

It doesn't seem to be that lack of an SDP specification for a
translatory would be needed, but I suspect that's due to my lack of
knowledge of the practical problems involved -- as far as I can tell,
such a connection could be negotiated in the ordinary way, and the fact
that the packets' SSRCs vary would identify that there were various
sources interleaved.

Though given that some protocol action will be necessary anyway (e.g.,
defining a new payload type), would it be difficult to invent an SDP
attribute that means "multiple sources will be interleaved, check the
SSRCs"?

Dale

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 7 May 2020 23:12:20 +0200

Hi Dale,

> that the packets' SSRCs vary would identify that there were various
RFC 3264 says in section 5 and a couple of other places 'each media stream

is described by an "m=" line and its associated attributes'

I am not so sure that "media stream" means the same as RTP stream for 
RTP based media, but that seems to be an often made conclusion.

> attribute that means "multiple sources will be interleaved, check the

I found that idea documented in an expired draft:

https://tools.ietf.org/pdf/draft-even-mmusic-multiple-streams-02.pdf

I do not know if that idea has been continued elsewhere. Therefore I 
also doubt that current RTP implementations are easy to request to watch 
out for new SSRCs. I took a look into one RTP implementation, and yes, I 
found some traces of a possibility to look for new SSRCs, but also other 
places where the method documented in RTP to detect a shift of SSRC for 
an existing stream by seeing 50 packets received with the new SSRC.

A lot of work has gone into multiplexing multiple streams of different 
media types into one RTP session, in RFC 8108 and

  draft-ietf-mmusic-sdp-bundle-negotiation

It would be possible to use these for our case but it is overkill, and 
it is likely

not implemented in the systems where multi-party-real-time text is 
urgently wanted.

For our case, I think it is good if a new conference participant can be 
added to an existing session by just adding a new source in an RTP 
session, without SDP action. The SIP Conference model has a SIP 
notification for a new participant. That notification has a media 
element that can contain an ssrc element. That can be a way to announce 
the new participant's text stream and tell the receiving RTP stack what 
to be prepared for, either as a new merged stream in a stream from an 
RTP-mixer, or as a new stream in an RTP session from an RTP-translator. 
Indications so far say that RTP implementations do not support the 
translator. I would be glad to be told that that is wrong.

Regards

Gunnar

>
> Dale
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 

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

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 07 May 2020 21:19:33 -0400

Gunnar Hellstrom <[email-masked]> writes:
> Therefore I 

Yes, it sounds like that's the crux.  While it's easy enough to say that
the protocol has the fields to allow that the packets all have the same
encoding and need to be sorted into separate streams based on the SSRCs,
the usage has always been that SSRCs change infrequently, e.g. video
cuts.  And that means that the implementations likely all embed that
assumption.

Dale

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 12 May 2020 21:11:56 +0200

Dale,

Assuming that we will stay with an RTP based solution, I made one more 
effort to create a motivation for not using the RTP translator model.

> cuts.  And that means that the implementations likely all embed that

New proposed text in the introduction as solution to issue 4.

     1.1 Selected solution and considered alternative

    The mechanism specified in the present document makes use of the RTP
    mixer model specified in RFC3550.
    From some points of view, use of
    the RTP translator model specified in RFC 3550 would be more
    efficient, because then the text packets can pass the translator 
with only
    minor modification.  However, there may be a lack of support
    for the translator model in existing RTP implementations, and 
therefore the more common    RTP-mixer model was selected.

Regards

Gunnar