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

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

Hi Dale,

Den 2020-05-06 kl. 04:40, skrev Dale R. Worley:
> Gunnar Hellstr\"om <[e-mail]> writes:
>> 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.
> 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.
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.


>
> 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"?

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

-- 

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

Gunnar Hellström
Omnitor
[e-mail]
[phone]