%% You should probably cite rfc9071 instead of this I-D.
@techreport{ietf-avtcore-multi-party-rtt-mix-12,
    number =    {draft-ietf-avtcore-multi-party-rtt-mix-12},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/12/},
    author =    {Gunnar Hellstrom},
    title =     {{RTP-mixer formatting of multi-party Real-time text}},
    pagetotal = 43,
    year =      2020,
    month =     dec,
    day =       15,
    abstract =  {Real-time text mixers for multi-party sessions need to identify the source of each transmitted group of text so that the text can be presented by endpoints in suitable grouping with other text from the same source, while new text from other sources is also presented in readable grouping as received interleaved in real-time. Use of RTT is increasing, and specifically, use in emergency calls is increasing. Emergency call use requires multi-party mixing. RFC 4103 "RTP Payload for Text Conversation" mixer implementations can use traditional RTP functions for source identification, but the performance of the mixer when giving turns for the different sources to transmit is limited when using the default transmission characteristics with redundancy. Enhancements for RFC 4103 real-time text mixing are provided in this document, suitable for a centralized conference model that enables source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multi-party real-time text session. The specified mechanism builds on the standard use of the CSRC list in the RTP packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two- party sessions. Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP- mixer model. The possibility to implement the solution in a wide range of existing RTP implementations made the RTP-mixer model be selected to be fully specified in this document. A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multi-party coded real-time text stream using the RTP-mixer method. The capability is indicated by use of an SDP media attribute "rtt-mixer". The document updates RFC 4103 "RTP Payload for Text Conversation". A specification of how a mixer can format text for the case when the endpoint is not multi-party aware is also provided.},
}