Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix-08.txt - please review

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

See answer below,

Den 2020-10-12 kl. 17:04, skrev Paul Kyzivat:
> On 10/12/20 10:35 AM, Gunnar Hellström wrote:
>
>> Den 2020-10-10 kl. 20:50, skrev Paul Kyzivat:
>
>>> * Section 2.1:
>>>
>>> Why was "rtt-mix-rtp-mixer" chosen as the name of the attribute? It 
>>> seems cumbersome and redundant. Wouldn't "rtt-mixer" be sufficient?
>> Yes, a better name may be needed.
>> draft-hellstrom-avtcore-multi-party-rtt-solutions has in sections 6.3 
>> and 6.4 a discussion on the sdp attribute. I agree that the name is 
>> long and maybe confusing. The thought is that the first part, 
>> "rtt-mix", indicates the purpose: to indicate support for a type of 
>> mixer for real-time text. The second part, "rtp-mixer", indicates 
>> what type of mixer that is supported. It is the rtp-mixer style as 
>> described in RFC 3550.
>>
>> There is no plan right now, but it would be possible that later work 
>> specifies another mixer type as an alternative. It could be a 
>> multi-stream mixer using the rtp-translator style from RFC 3550. That 
>> work could then register another attribute, e.g. called 
>> "rtt-mix-rtp-translator". That is not sufficiently likely to motivate 
>> the effort to now create an attribute with values, but the reasoning 
>> motivated a name that indicates both the purpose and the solution.
>>
>> That said, looking at your name proposal "rtt-mixer", I find that it 
>> can meet the criteria. "rtt-" indicates that it is about real-time 
>> text, and "mixer" can be taken to mean the "rtp-mixer" style. It was 
>> also used as the name in early versions of this draft.
>>
>> So, the simple conclusion is: Yes, accepted and done.
>
> When I looked at "rtt-mix-rtp-mixer" my first thought was as you 
> describe - that there would be several attributes pertaining to rtt 
> mixers. But then I found no others in the draft, and none starting 
> with "rtt-mix" already in the iana registry. So simplifying seemed in 
> order.
>
> But, if you foresee some possibility of others being defined in the 
> future then it might indeed be worth planning for that now. As you see 
> fit, or perhaps it should be further discussed.

I hope that the current draft is what we need for SIP based services. 
And I hope that the SIP environment will be the only one where 
implementations got spread without multi-party support. The presentation 
level standard T.140 requires multi-party support, but the 
implementations did not fulfill that. That is why we now need the 
attribute.

The next environment where I expect RTT to spread is in WebRTC, where 
the to-be RFC 8865 specifies how to transport RTT in data channels. In 
that spec the normal way to handle multi-party is by multiple data 
channels. The normal design would be to support additions of data 
channels in a session. A bridge would detect if addition of a channel 
for a new participant is unsuccessful and can take that as an indication 
that multi-party is not supported ( or the maximum number of supported 
participants is reached) and take appropriate action.

So, at the moment, I do not see a need for other multi-party rtt attributes.


Thanks,

Gunnar

>
>     Thanks,
>     Paul
>
-- 
Gunnar Hellström
GHAccess
[e-mail]