Re: [AVTCORE] WG Last Call: "RTP-mixer formatting of multi-party Real-time text"

[Lorenzo Miniero <[e-mail]>]

On Wed, 9 Dec 2020 16:40:09 +0100
Gunnar Hellström <[e-mail]> wrote:

> Lorentzo, I suggest to add the following paragraphs last in section
> 6.2
> 
> "
>    When a participant on the RTP side disappears, the corresponding 
> T.140 data channel(s) SHOULD be closed.
> 
> 
>    When a WebRTC user of T.140 data channels disconnects from the
> mixer, the corresponding RTP streams or sources in an RTP-mixed
> stream SHOULD be closed.
> 
> 
>    T.140 data channels MAY be opened and closed by negotiation or 
> renegotiation of the session or by any other valid means as specified
> in section 1 of ["I-D.ietf-mmusic-t140-usage-data-channel"].
> 


Hi Gunnar,

the proposed text does indeed help making it much clearer, thanks for
addressing the feedback!

Lorenzo


> 
> Regards
> 
> Gunnar
> 
> Den 2020-12-09 kl. 16:02, skrev Gunnar Hellström:
> >
> > Lorenzo,
> >
> > Thanks for looking into the WbRTC gatewaying side of this topic.
> >
> > See some answers below.
> >
> > Den 2020-12-09 kl. 12:39, skrev Lorenzo Miniero:  
> >> On Wed, 25 Nov 2020 14:16:43 -0800
> >> Bernard Aboba<[e-mail]>  wrote:
> >>  
> >>> This is an announcement of WG last call on "RTP-mixer formatting
> >>> of multi-party Real-time text"
> >>>
> >>> The document is available for inspection here:
> >>> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix
> >>>
> >>> WG Last Call will end on December 9, 2020.
> >>>
> >>> In response, please state one of the following:
> >>>
> >>> * I support advancing the document to Proposed Standard
> >>> * I object to advancement to Proposed Standard, due to Issues
> >>> described below <Issue description or link>.  
> >> Hi all,
> >>
> >> apologies for this late reply, hopefully I'm still in time. I'll
> >> just add a couple of considerations on section 6.2, which addresses
> >> gatewaying to WebRTC, since I have an open source prototype
> >> implementation of 1-1 WebRTC-to/from-SIP gatewaying already, which
> >> I'd like to extend to support multi-party as well sooner or later.
> >>
> >> The text is in general relatively clear to me, as are the
> >> assumptions on how new labels will be used on the WebRTC side for
> >> new joins, but there are a couple of areas where I believe there
> >> still is some ambiguity.
> >>
> >> Forst of all, it's not clear whether new participants should
> >> trigger a renegotiation, as the draft simply states:
> >>
> >> 	When a new participant has entered the session with RTP
> >> 	transport of rtt, a new t140 channel SHOULD be established
> >> to WebRTC users with the label parameter composed from the NAME
> >> 	field in RTCP on the RTP side.
> >>
> >> In the current specification,  
> > [GH] Do you mean RFC-to-be 8865 ?  
> >>   data channel IDs/labels are negotiated in
> >> the SDP in advance, via a dcmap attribute: does this mean new
> >> participants should be advertised by new dcmap attributes as well?
> >> Or should implementations simply be prepared to expect
> >> unadvertised data channels opening, and then match them to
> >> specific participants out of band? The former seems a bit
> >> overkill, considering data channels can be opened at any time with
> >> no signalling needed, but if the latter is the case, it seems to
> >> question why we'd need the dcmap attribute for the first
> >> negotiation as well.  
> >
> > [GH] RFC-to-be 8865, section 1 says:
> >
> > "
> >
> > While this document defines how to establish a
> >     T.140 data channel using the SDP-based external negotiation
> > method [I-D.ietf-mmusic-data-channel-sdpneg], the generic T.140 and
> > gateway considerations defined in Section 3, Section 5 and Section
> > 6 of this document can also be applied when a T.140 data channel is
> > established using another mechanism (e.g., the mechanism defined in
> >     [I-D.ietf-rtcweb-data-protocol]).  Section 5 of
> >     [I-D.ietf-mmusic-data-channel-sdpneg] defines the mapping
> > between the SDP dcmap attribute parameters and the protocol
> > parameters used in [I-D.ietf-rtcweb-data-protocol].
> >
> > "
> >
> > So, it should at least be possible to establish new T.140 channels 
> > with all required parameters without a renegotiation. Also the
> > label can be established that way. The side taking the initiative
> > to establish a channel would know best what label to assign to it.
> >
> > This behavior would have similarities to introducing new
> > participants in a conference on the traditional centralized SIP
> > conference. They are just announced by conference notifications and
> > then their SSRC is starting to appear in CSRC and RTCPs.
> >
> > On the other hand, even if it is possible and mentioned in
> > RFC-to-be 8865, I do not know if it regarded to be good behavior of
> > an entity to add channels in that way without renegotiation.
> >  
> >> Another issue I don't see addressed in the draft is what to do
> >> when a participant leaves instead: should the related data channel
> >> ID be closed? I guess the answer is yes, here, but in case, should
> >> this be addressed with a new offer/answer exchange, if adding
> >> users does?  
> >
> > [GH] Good point. I can insert a sentence about closing a channel in 
> > any way the application wants as a consequence of the cited
> > sentences above from section 1 in RFC-to-be 8865.
> >
> > Thanks,
> >
> > Gunnar
> >  
> >> Thanks,
> >> Lorenzo
> >>  
> > -- 
> > Gunnar Hellström
> > GHAccess
> > [e-mail]
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt  
> 



-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero