Re: [AVTCORE] Multi-party real-time text Issue 4: Motivation for not using RTP translator

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.

Den 2020-05-08 kl. 03:19, skrev Dale R. Worley:
> Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> writes:
>> 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.
> 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

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

>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se