Re: [MMUSIC] Multi-party transport in draft-hellstrom-mmusic-multi-party-rtt-00.txt

[Christer Holmberg <[e-mail]>]

Hi,

The main issue, described in Section 4, is how the mixer is going to forward real-time text towards participants, in a way that allows the participants to determine which remote participant has sent the text - unlike audio, you can't just blend everything together and assume the participants will recognize the sender based on his/her voice.

Regards,

Christer



________________________________
From: mmusic <[e-mail]> on behalf of Gunnar Hellström <[e-mail]>
Sent: Saturday, February 22, 2020 3:58 PM
To: Paul Kyzivat <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [MMUSIC] Multi-party transport in draft-hellstrom-mmusic-multi-party-rtt-00.txt

Paul,

Den 2020-02-21 kl. 18:01, skrev Paul Kyzivat:
> Gunnar,
>
> There is a wg called PERC that sounds like it *might* have some
> relevance.  I think this was started quite some time ago, and I
> haven't followed the work so I'm not personally familiar with its
> status. The latest milestone milestone was in 2018, and I see some
> documents that appear to be stalled, so it may be dragging. But you
> might want to investigate.

Perc seems to be a good and relevant framework for end-to-end encrypted
conferences.

I get the impression that regular RFC 4103 with additional encapsulation
and key handling transactions will be sufficient for its use with RTT.

So, that means that the goal of end-to-end encryption should be split
off from the current multi-party RTT draft and handled in another draft
with less urgency.

Thanks for the useful hint,


Gunnar


>
>     Thanks,
>     Paul
>
> On 2/21/20 8:48 AM, Gunnar Hellström wrote:
>> Hi,
>>
>> Continuing the discussion of chapter 4 of
>> https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00 :
>>
>> I have searched for examples of media mixing for other media than
>> real-time-text, in order to find if they are provided end-to-end
>> encrypted, and combined under one m-section in SDP.
>>
>> Three considered possible use cases are for 3GPP IMS and NG-112/NG9-1-1
>> emergency services. All three say that conferences use the RFC
>> 4353/RFC4575/RFC 4579 SIP conference model. All these seem to me specify
>> sending just SIP Notifications to all participants when a new user joins
>> without introducing any new media. And the SSRC of the media mixed to
>> earlier streams are provided in that Notify.
>>
>> I assume that then the media is mixed into the current stream by
>> inserting packets with the mixer's SSRC, and the new participant's SSRC
>> as CSRC.
>>
>> I wonder if this scheme can allow end-to-end encryption? One reason for
>> problems is that the mixer likely must do some media parameter
>> alignments because it has no means to convey separate parameters per
>> source. Another reason is that there is no SDP exchange of keys for
>> separate participants in RFC 4579.
>>
>> If nothing is wrong in my findings, we can satisfy the main use cases of
>> mixing for RTT with a method that allows a central mixer to decrypt and
>> merge the RTT packets from different sources into one stream with the
>> SSRCs of the sources provided as CSRC in the combined stream, and never
>> have more than one source CSRC per packet. ( that will still require a
>> bit of considerations on packetization level)
>>
>> Once this is settled, we can move on and try to solve also the
>> end-to-end encryption case. Can anyone provide examples of how that is
>> done for multi-party audio and video?
>>
>> Regards
>>
>> Gunnar
>>
>>
>>
>>
>>
>> Den 2019-12-19 kl. 12:11, skrev Christer Holmberg:
>>> Hi,
>>>
>>> Regarding how to signal, at the moment my strong preference is to
>>> use a single m- line for RTP-based multi-party RTT, in one way or
>>> another. Having a separate m- line for each remote participant
>>> doesn't scale, and would probably not work in many networks. It
>>> could also cause lots of offer/answer transactions when people are
>>> joining/leaving conferences.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>> On 19/12/2019, 11.19, "mmusic on behalf of Gunnar Hellström"
>>> <[e-mail] on behalf of [e-mail]>
>>> wrote:
>>>
>>>       Thanks Lorenzo for your views on the different transport and
>>> mixing
>>>       alternatives.
>>>             I intend to continue the overview of the alternatives
>>> that Christer
>>>       asked for.
>>>             But, in the meantime:
>>>             It would be good to have comments on if there are any
>>> specific methods
>>>       for signaling multi-party control for WebRTC, e.g. announcing
>>> the focus
>>>       role and announcing participants' entry and departure and
>>> capabilities
>>>       to the conference.
>>>             And also if the RFC 7579 / RFC 7575 SIP conference
>>> control is so
>>>       widespread that it would be suitable to rely on it in the SIP
>>>       environment for  e.g. announcing the focus role and announcing
>>>       participants' entry and departure and capabilities to the
>>> conference.
>>>             About your comment that the conference-unaware mixing
>>> alternative: Yes,
>>>       it is not favourable, but possible. And I think it is needed
>>> in order to
>>>       be able to introduce multi-party support in services where
>>> there are
>>>       already many conference-unaware UAs out there.
>>>             One factor that you find not good for that method and
>>> the T140-mixing
>>>       method is that the mixer need to be able to decrypt and
>>> encrypt the text
>>>       stream. Is that not usually the case for the other media,
>>> audio and
>>>       video in the centralized bridge mixing?
>>>             Thanks,
>>>             Gunnar
>>>             Den 2019-12-18 kl. 11:07, skrev Lorenzo Miniero:
>>>       > Hi all,
>>>       >
>>>       > apologies if I'm chiming in only now. I've recently started
>>> working on
>>>       > an (open source) integration between SIP RTT and WebRTC: I
>>> already
>>>       > exchanged some thoughts with Gunnar in private, but I plan
>>> to write a
>>>       > post to introoduce the effort later today.
>>>       >
>>>       > Since the effort has been on a server side component that
>>> acts like a
>>>       > gateway, in this context, how to deal with multiparty is indeed
>>>       > something I'm interested about, so I've added some comments
>>> inline.
>>>       >
>>>       >
>>>       > On Tue, 17 Dec 2019 22:53:31 +0000
>>>       > Gunnar Hellström <[e-mail]> wrote:
>>>       >
>>>       >> Hi Christer,
>>>       >>
>>>       >> Den 2019-12-17 kl. 09:01, skrev Christer Holmberg:
>>>       >> Hi,
>>>       >>
>>>       >> Before we decide on support indicators, we need to decide
>>> on how we
>>>       >> are going to implement multi-party RTT. Yes, these
>>> discussions at
>>>       >> least need to go in parallel. Note that I switched subject
>>> now when
>>>       >> the topic is multi-party RTT transport alternatives.
>>>       >>
>>>       >> Section 4 specifies different alternatives. Are we going to
>>> specify
>>>       >> all of those, or only a subset?
>>>       >>
>>>       >> Related to Section 4, it would be nice with an SDP example
>>> for each
>>>       >> alternative.
>>>       >>
>>>       >>   The problem so far has been that it has been said that
>>> multi-party
>>>       >> RTT can be arranged with regular RTP methods, and that has
>>> provided
>>>       >> too wide freedom of choice.
>>>       >>
>>>       >> So, I want to eventually change the draft to elaborate on
>>> either one
>>>       >> common alternative for real-time transport for both SIP/RTP
>>> and
>>>       >> WebRTC, or one each for these two environments. The other
>>>       >> alternatives may be briefly mentioned in a background
>>> chapter or
>>>       >> deleted.
>>>       >>
>>>       >> So, let us go through the alternatives, and try to look at
>>> both
>>>       >> chapter 4 and 5. That is both SIP/RTP and WebRTC.
>>>       >>
>>>       >> 1. Control code in the T.140 stream.
>>>       >>
>>>       >>
>>> 4.3<https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#section-4.3>.
>>>       >>   RTP Mixer indicating participants by a control code in
>>> the stream
>>>       >>
>>>       >> and
>>>       >>
>>> 5.2<https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#section-5.2>.
>>>       >>   RTT bridging in WebRTC with one common data channel
>>>       >>
>>>       >> Both build on the same principle. The presentation protocol
>>> T.140 is
>>>       >> extendable. New one letter  function codes can be defined
>>> and sent
>>>       >> together with a parameter framed by the control codes
>>> called SOS and
>>>       >> ST as defined in ISO 6429. So, we could define (or rather
>>> ask ITU-T
>>>       >> SG26 to define) a function code "c" followed by a string
>>> uniquely
>>>       >> identifying the source of the following text (or rather
>>> T140blocks).
>>>       >> The data for each transmission request from the mixer
>>> should start
>>>       >> with the SOS,c,source,ST code as soon as more than two
>>> parties are
>>>       >> involved in the session. The receiving party need to scan
>>> incoming
>>>       >> T140blocks and direct the received text to the proper area for
>>>       >> presentation of text from each source in one of the
>>> suitable styles
>>>       >> for RTT presentation (see chapter 9).
>>>       >>
>>>       >> For 4.3, the RTP variant, I don't think we need to
>>> prescribe any more
>>>       >> SDP than a regular one stream RTT plus an indication of
>>> multi-party
>>>       >> RTT capability.
>>>       >>
>>>       >> Example, combining this alternative with capability
>>> negotiation 7.3
>>>       >>
>>>       >> Offer
>>>       >>   m=text 11000 RTP/AVP 100 98
>>>       >>        a=rtpmap:98 t140/1000
>>>       >>        a=rtpmap:100 red/1000
>>>       >>        a=fmtp:100 98/98/98
>>>       >>        a=rtt-mixer:t140-mixer
>>>       >>
>>>       >> Answer of a capable party
>>>       >>   m=text 12000 RTP/AVP 100 98
>>>       >>        a=rtpmap:98 t140/1000
>>>       >>        a=rtpmap:100 red/1000
>>>       >>        a=fmtp:100 98/98/98
>>>       >>        a=rtt-mixer:t140-mixer
>>>       >> The parties can start exchanging multi-party text in one
>>> stream with
>>>       >> T.140 source indications.
>>>       >>
>>>       >> Answer of an uncapable party
>>>       >>   m=text 12000 RTP/AVP 100 98
>>>       >>        a=rtpmap:98 t140/1000
>>>       >>        a=rtpmap:100 red/1000
>>>       >>        a=fmtp:100 98/98/98
>>>       >>
>>>       >>
>>>       >> The mixer can start sending multi-party text prepared for
>>>       >> presentation to a multi-party unaware UA according to
>>> chapter 10 and
>>>       >> Appendix A, providing a lower functionality fixed view
>>> presentation.
>>>       >>
>>>       >> This method can be combined with multi-party conferencing
>>> control for
>>>       >> SIP as said in the beginning of chapter 7
>>>       >>
>>>       >>
>>>       >> "A method for detection of conference-awareness for
>>> centralized SIP
>>>       >> conferencing in general is specified in RFC
>>>       >> 4579<https://tools.ietf.org/html/rfc4579>
>>>       >> [RFC4579<https://tools.ietf.org/html/rfc4579>]. The focus
>>> sends the
>>>       >> "isfocus" feature tag in a SIP Contact header. This causes the
>>>       >> conference-aware UA to subscribe to conference
>>> notifications from the
>>>       >> focus. The focus then sends notifications to the UA about
>>> entering
>>>       >> and disappearing conference participants and their media
>>>       >> capabilities. The information is carried XML-formatted in a
>>>       >> 'conference-info' block in the notification according to
>>>       >> RFC<https://tools.ietf.org/html/rfc4575>
>>>       >> 4575<https://tools.ietf.org/html/rfc4575>. The mechanism is
>>> described
>>>       >> in detail in RFC 4575<https://tools.ietf.org/html/rfc4575>
>>>       >> [RFC4575<https://tools.ietf.org/html/rfc4575>]."
>>>       >>
>>>       >>
>>>       >> But I think now that we do not need to make us so dependent
>>> on that
>>>       >> mechanism. Any way to introduce and delete parties in the
>>> conference
>>>       >> may be used.  The draft is currently too much tied to use
>>> of the RFC
>>>       >> 4579 / RFC 4575 procedure.
>>>       >>
>>>       >>
>>>       >> For 5.2, the WebRTC case with T.140 source marked text,
>>> according to
>>>       >> draft-ietf-mmusic-t140-usage-data-channel the sdp would be
>>>       >>
>>>       >>   Offer:
>>>       >>
>>>       >>         m=application 1400 UDP/DTLS/SCTP webrtc-datachannel
>>>       >>         c=IN IP6 2001:db8::3
>>>       >>         a=max-message-size:1000
>>>       >>         a=sctp-port 5000
>>>       >>         a=dcmap:2 label="ACME customer
>>> service";subprotocol="t140"
>>>       >>         a=dcsa:2 rtt-mixer:t140-mixer
>>>       >>
>>>       >>     Answer from a capable party:
>>>       >>
>>>       >>         m=application 2400 UDP/DTLS/SCTP webrtc-datachannel
>>>       >>         c=IN IP6 2001:db8::1
>>>       >>         a=max-message-size:1000
>>>       >>         a=sctp-port 6000
>>>       >>         a=dcmap:2 label="ACME customer
>>> service";subprotocol="t140"
>>>       >>         a=dcsa:2 rtt-mixer:t140-mixer
>>>       >>
>>>       >>
>>>       >> The parties can start exchanging multi-party text in one
>>> stream with
>>>       >> T.140 source indications.
>>>       >>
>>>       >>
>>>       >> (and if the negotiation does not find multi-party
>>> capability for both
>>>       >> parties, then the mixer can start sending according to
>>> chapter 10 and
>>>       >> Appendix A.)
>>>       >>
>>>       >> The exact form of the multi-party capability indication
>>> should go
>>>       >> into the negotiation discussion belonging to chapter 7.
>>> (maybe it
>>>       >> should be a new fmtp - parameter instead of a new sdp
>>> attribute if
>>>       >> using sdp )
>>>       >>
>>>       >> Pros:
>>>       >>
>>>       >> Equal handling for SIP/RTP and WebRTC
>>>       >> Simple session and stream establishment.
>>>       >>
>>>       >> Cons:
>>>       >>
>>>       >> The mixer need to manipulate the T.140 stream.
>>>       >> In SIP/RTP, if more than 3 consecutive packets are lost,
>>> the source
>>>       >> of the loss is not known, and an indication of possible
>>> loss needs to
>>>       >> be inserted in some other place than in the stream that had
>>> loss. The
>>>       >> mixer needs to be allowed to decrypt and encrypt the stream.
>>>       >>
>>>       >>
>>>       >> I need to stop here and describe the other alternatives
>>> another day.
>>>       >>
>>>       >
>>>       > I'm personally not fond of the idea of the new control code.
>>> First of
>>>       > all, it would require the mixer to indeed terminate the RTT
>>> session,
>>>       > which means end-to-end encryption wouldn't be possible.
>>> Besides, with
>>>       > data channels and the flexibility they provide (e.g., via
>>> the label you
>>>       > can negotiate in the related draft), you don't really need
>>> the extra
>>>       > inband control code to discriminate sessions.
>>>       >
>>>       > I did read the multiparty document, and did have some
>>> opitions going
>>>       > through the alternatives, so I thought I'd share them
>>> quickly here
>>>       > (apologies to Gunnar if I'm repeating what the draft already
>>> says, or
>>>       > if I'm completely misunderstanding some concepts, as I'm
>>> indeed new to
>>>       > the specification as a whole):
>>>       >
>>>       >     1. Section 4.1 introduces the usage of different SSRCs for
>>>       >     different participants, which does seem like a good
>>> option to
>>>       >     me: SSRCs would indeed provide the info required to
>>> demultiplex
>>>       >     and relay participants without having to look at the
>>> payload,
>>>       >     and would be very easy to map to labels when a translation
>>>       >     to/from a WebRTC session is needed. There is indeed the
>>> problem
>>>       >     of how you advertise those SSRCs, which brings back painful
>>>       >     memories of the Plan B vs. Unified Plan fight in WebRTC:
>>> this
>>>       >     section suggests a single m-line (à-la Plan B, I believe),
>>>       >     which has some drawbackas; different participants may
>>>       >     use different approaches (e.g., some may be using red,
>>> other
>>>       >     t140, and payload types may differ) which indeed
>>> complicates
>>>       >     the SDP negotiation, especially if the mixer is supposed to
>>>       >     just relay those streams and not terminate them.
>>>       >
>>>       >     2. Section 4.2 suggests using a shared SSRC, and using
>>> CSRC to
>>>       >     mention participants. Again, the need for decrypting the
>>>       >     traffic is problematic. Besides, I'm not sure detecting
>>> packet
>>>       >     loss would be trivial as the document states: if the
>>> SSRC is
>>>       >     shared, so is the timestamp/sequence number space, which
>>> means
>>>       >     that it would be problematic, if not downright
>>> impossible, to
>>>       >     detect packet losses for a specific participant at the
>>> source,
>>>       >     considering sequence numbers originated by the mixer may be
>>>       >     increasing sequentially with no gaps in between.
>>> Probably I'm
>>>       >     missing something obvious in the scenario?
>>>       >
>>>       >     3. Section 4.3 is where the new control code Gunnar
>>> described
>>>       >     is introduced, and I already shared my view on why I'm not
>>>       >     particularly fond of the idea.
>>>       >
>>>       >     4. Section 4.4 describes a full mesh, which does work
>>> but is
>>>       >     indeed more "verbose", and requires multiple sessions to
>>> take
>>>       >     place, and may be a bit overkill. That said, one of the
>>> pros
>>>       >     the document suggests is that this should be possible
>>> with most
>>>       >     RTP implementations, which isn't to be ignored: I'd
>>> consider
>>>       >     this a good backup when dealing with participants
>>> unaware of
>>>       >     whatever method will be chosen, possibly establishing the
>>>       >     multiple sessions with the mixer itself, though, rather
>>> than
>>>       >     the other participants themselves.
>>>       >
>>>       >     5. Section 4.5 documents the approach where multiple RTP
>>>       >     sessions are negotiated, one per participant, I guess via
>>>       >     separate m-lines. This is indeed a variant of 4.1 which
>>> again
>>>       >     brings back the Plan B vs. Unified Plan discussion that
>>>       >     happened in WebRTC, where the former signalled multiple
>>> SSRCs
>>>       >     on the same m-line, and the latter used separate m-lines
>>>       >     instead. Whatever signalling approach is used, I do feel
>>> that
>>>       >     using SSRCs to demultiplex would make the process simpler.
>>>       >
>>>       >     6. Finally, section 4.6 introduces the concept of
>>> "mixing" for
>>>       >     RTT streams, which I'm not a fan of either, as it
>>> "flattens"
>>>       >     everything, breaking end-to-end encryption when
>>> available in
>>>       >     the process. The document provides even more cons, and
>>>       >     clarifies how it should only be a last resort, which I
>>> agree on.
>>>       >
>>>       > On the WebRTC side, things are much easier I believe. The
>>> approach
>>>       > suggested in 5.1 is definitely what I'd go with, that is
>>> leveraging
>>>       > labels to demultiplex participants: I wouldn't be too
>>> concerned about
>>>       > the overhead of establishing a high number of channels, as most
>>>       > implementations have ways to deal with high numbers anyway.
>>>       >
>>>       > Lorenzo
>>>       >
>>>       >
>>>       >> Thanks
>>>       >>
>>>       >> Gunnar
>>>       >>
>>>       >> Regards,
>>>       >>
>>>       >> Christer
>>>       >>
>>>       >> From: mmusic
>>>       >> <[e-mail]><mailto:[e-mail]>
>>> on behalf
>>>       >> of Gunnar Hellstrom
>>>       >>
>>> <[e-mail]><mailto:[e-mail]>
>>>       >> Date: Sunday, 15 December 2019 at 22.25 To:
>>>       >> "[e-mail]"<mailto:[e-mail]>
>>>       >> <[e-mail]><mailto:[e-mail]> Subject: [MMUSIC]
>>>       >> Negotiation in draft-hellstrom-mmusic-multi-party-rtt-00.txt
>>>       >>
>>>       >>
>>>       >> Hi,
>>>       >>
>>>       >>
>>> draft-hellstrom-mmusic-multi-party-rtt/<https://datatracker.ietf.org/doc/draft-hellstrom-mmusic-multi-party-rtt/>
>>>       >> currently contains sets of alternative solutions for different
>>>       >> aspects of multi-party real-time text (RTT).
>>>       >>
>>>       >> I would like to discuss these alternatives aspect by
>>> aspect, and
>>>       >> eventually reduce them to one solution per aspect. By
>>> aspects, I mean
>>>       >> negotiation for SIP, negotiation for WebRTC, source
>>> identification
>>>       >> and multi-party transport for SIP, source identification and
>>>       >> multi-party transport for WebRTC and mixing for the
>>> multi-party
>>>       >> unaware case.
>>>       >>
>>>       >> The main requirements are described in section 3 of the
>>> draft. One
>>>       >> requirement is that the solution should be implementable in
>>> a near
>>>       >> future. Point-to-point RTT solutions based on SIP and RTP
>>> with RFC
>>>       >> 4103 transport are implemented, and there are cases where
>>> upgrade to
>>>       >> multi-party support is urgent. It is assumed that most
>>> multi-party
>>>       >> cases will be based on one central bridge. The media coding is
>>>       >> according to ITU-T T.140, that is Unicode text transmitted
>>> UTF-8
>>>       >> transformed, with some control codes from ISO 6429.
>>> Transmission
>>>       >> takes place without any special action by the user other than
>>>       >> creating text. Transmission is usually time sampled in
>>> about 300 ms
>>>       >> samples.
>>>       >>
>>>       >> I want to start with the negotiation aspect. Before the
>>> bridge can
>>>       >> start transmitting RTT in a way suitable for good
>>> presentation of
>>>       >> multi-party RTT, it must know that the receiving party is
>>> capable of
>>>       >> separating text from the different participants. Also the
>>> UA may need
>>>       >> an indication that it should include source information in
>>> a specific
>>>       >> way for multi-party RTT to work..
>>>       >>
>>>       >> Therefore, a negotiation method is needed. Chapter 7
>>> contains the
>>>       >> following negotiation alternatives.
>>>       >>
>>>       >> 7.1 Implicit negotiation by the bridge expressing RTT
>>> multi-party
>>>       >> capability indications according to RFC 4575, and the UA
>>> showing
>>>       >> multi-party awareness only if it supports multi-party RTT.
>>>       >>
>>>       >> 7.2 Define a new SIP media tag indicating RTT multi-party
>>> capability.
>>>       >> Start using multi-party RTT after a successful capability
>>> exchange.
>>>       >>
>>>       >> 7.3 Define a new SDP attribute on media level, indicating RTT
>>>       >> multi-party capability. Start using multi-party RTT after a
>>>       >> successful capability exchange.
>>>       >>
>>>       >> There may be other alternatives that I have not thought about.
>>>       >>
>>>       >> Pros and cons for these methods are documented in chapter 7.
>>>       >>
>>>       >> I hope we can discuss the negotiation methods and soon get
>>> to a
>>>       >> conclusion.
>>>       >>
>>>       >>
>>>       >>
>>>       >> Regards
>>>       >>
>>>       >> Gunnar
>>>       >>
>>>       >>
>>>       >>
>>>       >>
>>>       >> Den 2019-11-01 kl. 00:43, skrev Gunnar Hellström:
>>>       >>
>>>       >> Hi mmusic and avtcore,
>>>       >>
>>>       >> I have replaced an old expired draft about real-time text
>>> multi-party
>>>       >> handling. It touches both transport and negotiation topics,
>>> so I am
>>>       >> sending this to both mmusic and avtcore, but I hope we can
>>> keep the
>>>       >> discussion in mmusic. So, please respond with your comments
>>> to mmusic.
>>>       >>
>>>       >> Right now, the draft is a discussion paper. I intend to
>>> convert it to
>>>       >> a true BCP format after some discussions on the preferences
>>> I have
>>>       >> proposed.
>>>       >>
>>>       >> Regards
>>>       >>
>>>       >> Gunnar Hellström
>>>       >>
>>>       >>
>>>       >> -------- Vidarebefordrat meddelande --------
>>>       >> Ämne:
>>>       >> I-D Action: draft-hellstrom-mmusic-multi-party-rtt-00.txt
>>>       >> Datum:
>>>       >> Thu, 31 Oct 2019 16:33:35 -0700
>>>       >> Från:
>>>       >> [e-mail]<mailto:[e-mail]>
>>>       >> Svar till:
>>>       >> [e-mail]<mailto:[e-mail]>
>>>       >> Till:
>>>       >> [e-mail]<mailto:[e-mail]>
>>>       >>
>>>       >>
>>>       >>
>>>       >> A New Internet-Draft is available from the on-line
>>> Internet-Drafts
>>>       >> directories.
>>>       >>
>>>       >>
>>>       >> Title : Real-time text media handling in multi-party
>>> conferences
>>>       >> Author : Gunnar Hellstrom
>>>       >> Filename : draft-hellstrom-mmusic-multi-party-rtt-00.txt
>>>       >> Pages : 36
>>>       >> Date : 2019-10-31
>>>       >>
>>>       >> Abstract:
>>>       >> This memo specifies methods for Real-Time Text (RTT) media
>>> handling
>>>       >> in multi-party calls. The main solution is to carry
>>> Real-Time text
>>>       >> by the RTP protocol in a time-sampled mode according to RFC
>>> 4103.
>>>       >> The main solution for centralized multi-party handling of
>>> real-time
>>>       >> text is achieved through a media control unit coordinating
>>> multiple
>>>       >> RTP text streams into one RTP session.
>>>       >>
>>>       >> Identification for the streams are provided through the RTCP
>>>       >> messages. This mechanism enables the receiving application to
>>>       >> present the received real-time text medium in different ways
>>>       >> according to user preferences. Some presentation related
>>> features
>>>       >> are also described explaining suitable variations of
>>> transmission and
>>>       >> presentation of text.
>>>       >>
>>>       >> Call control features are described for the SIP environment. A
>>>       >> number of alternative methods for providing the multi-party
>>>       >> negotiation, transmission and presentation are discussed and a
>>>       >> recommendation for the main one is provided. Two
>>> alternative methods
>>>       >> using a single RTP stream and source identification inline
>>> in the
>>>       >> text stream are also described, one of them being provided
>>> as a lower
>>>       >> functionality fallback method for endpoints with no
>>> multi-party
>>>       >> awareness for RTT.
>>>       >>
>>>       >> Brief information is also provided for multi-party RTT in
>>> the WebRTC
>>>       >> environment.
>>>       >>
>>>       >> EDITOR NOTE: A number of alternatives are specified for
>>> discussion.
>>>       >> A decision is needed which alternatives are preferred and
>>> then how
>>>       >> the preferred alternatives shall be emphasized.
>>>       >>
>>>       >>
>>>       >> The IETF datatracker status page for this draft is:
>>>       >>
>>> https://datatracker.ietf.org/doc/draft-hellstrom-mmusic-multi-party-rtt/
>>>
>>>       >>
>>>       >> There are also htmlized versions available at:
>>>       >>
>>> https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00
>>>       >>
>>> https://datatracker.ietf.org/doc/html/draft-hellstrom-mmusic-multi-party-rtt-00
>>>       >>
>>>       >>
>>>       >> Please note that it may take a couple of minutes from the
>>> time of
>>>       >> submission until the htmlized version and diff are
>>> available at
>>>       >> tools.ietf.org.
>>>       >>
>>>       >> Internet-Drafts are also available by anonymous FTP at:
>>>       >> ftp://ftp.ietf.org/internet-drafts/
>>>       >>
>>>       >> _______________________________________________
>>>       >> I-D-Announce mailing list
>>>       >> [e-mail]<mailto:[e-mail]>
>>>       >> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>       >> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>       >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>       >>
>>>       >>
>>>       >>
>>>       >> _______________________________________________
>>>       >>
>>>       >> mmusic mailing list
>>>       >>
>>>       >> [e-mail]<mailto:[e-mail]>
>>>       >>
>>>       >> https://www.ietf.org/mailman/listinfo/mmusic
>>>       >>
>>>       >> --
>>>       >>
>>>       >>
>>>       >>
>>>       >> + + + + + + + + + + + + + +
>>>       >>
>>>       >>
>>>       >>
>>>       >> Gunnar Hellström
>>>       >>
>>>       >> Omnitor
>>>       >>
>>>       >>
>>> [e-mail]<mailto:[e-mail]>
>>>       >>
>>>       >> [phone]
>>>       >>
>>>       >> --
>>>       >>
>>>       >> + + + + + + + + + + + + + +
>>>       >>
>>>       >> Gunnar Hellström
>>>       >> Omnitor
>>>       >>
>>> [e-mail]<mailto:[e-mail]>
>>>       >> [phone]
>>>       >
>>>       >
>>>       --
>>>             + + + + + + + + + + + + + +
>>>             Gunnar Hellström
>>>       Omnitor
>>>       [e-mail]
>>>       [phone]
>>>             _______________________________________________
>>>       mmusic mailing list
>>>       [e-mail]
>>>       https://www.ietf.org/mailman/listinfo/mmusic
>>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic

--

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

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

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic