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

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

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]