Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel - modification proposals
Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 23 August 2019 22:52 UTC
Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D5512006A for <mmusic@ietfa.amsl.com>; Fri, 23 Aug 2019 15:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6ZMbheKz6Ef for <mmusic@ietfa.amsl.com>; Fri, 23 Aug 2019 15:52:46 -0700 (PDT)
Received: from vsp-unauthed02.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5843712000F for <mmusic@ietf.org>; Fri, 23 Aug 2019 15:52:46 -0700 (PDT)
X-Halon-ID: b6866d66-c5f8-11e9-837a-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [88.129.173.120]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id b6866d66-c5f8-11e9-837a-0050569116f7; Sat, 24 Aug 2019 00:52:42 +0200 (CEST)
To: mmusic@ietf.org
References: <49749CEF-41E8-4E87-8CC6-938DBDA0CEE7@ericsson.com> <CAOW+2duTuUc8FXT-BEhJioUnPsOkzYJddK=xAp1oWiBQCKM2vg@mail.gmail.com> <HE1PR07MB3161874ED292FA17015EF95E93AE0@HE1PR07MB3161.eurprd07.prod.outlook.com> <665185b6-c1e7-62c3-4e3b-e9374d23bfd5@omnitor.se> <DF010721-81CD-40DE-A848-DE4D36836FDA@ericsson.com> <ED158CF5-E059-482B-8D7E-934BA2C753A1@ericsson.com> <2201665d-5054-1872-d208-a0fe2d26095c@omnitor.se> <VI1PR07MB3167055C995D17D4BA9E36DE93A50@VI1PR07MB3167.eurprd07.prod.outlook.com> <8d14b055-8405-4a4f-174d-d7580bea348c@omnitor.se> <0DA1248C-41FC-4155-A578-29A19883857C@ericsson.com> <a91850b9-6e86-058f-dddd-3f856bcd6710@omnitor.se> <DBC532B8-38DC-4140-B7C4-0B6853F0EF77@ericsson.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <6fcf46a6-544d-027c-97c7-5c0e08caa555@omnitor.se>
Date: Sat, 24 Aug 2019 00:52:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <DBC532B8-38DC-4140-B7C4-0B6853F0EF77@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/GlMW_b0nGy5qnIfqbLPNgl-YF3Y>
Subject: Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t140-usage-data-channel - modification proposals
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2019 22:52:51 -0000
Christer, Here is a first set of modification proposals for the topics I have mentioned, and a few more editorial, but lacking the end-to-end encryption requirement for the interworking case that I do not know how to handle. I hope you can handle the simple change proposal format. Regards Gunnar ----------------------------------------------------------------------- 1. Change the title from "T.140 Text Conversation over WebRTC Data Channels" to "T.140 Real-time Text over WebRTC Data Channels" Reason: Real-time text is the current term for Text Conversation ------------------------------------------------------------------------------------------ 2. Modify the second line of the abstract from "transport mechanism for the ITU-T Protocol for multimedia application" to "transport mechanism for Real-time text media using the ITU-T Protocol for multimedia application" Reason: Real-time text is an important keyword for this media. ------------------------------------------------------------------------------------- 3. In 1. Introduction, line 3, change from "conversation, also known as realtime text or text telephony. The" to "conversation, also known as real-time text. The" Reason: Text telephony may use T.140, but is not required to have the same functionality as true real-time text. -------------------------------------------------------------------------------------------- 4. In 1. Introduction, last sentence of first paragraph, modify: The native transport for IP networks is based on the Real-time Transport Protocol (RTP) [RFC4103]. to The native transport for IP networks is RFC 4103 RTP Payload for Text Conversation" [RFC4103] based on the Real-time Transport Protocol (RTP). Reason: It looked confusing with the RFC4103 reference after the RTP abbreviation. ----------------------------------------------------------------------------------------------------------------- 5. In section 1. Introduction, first NOTE, second line there is an unbalanced right bracket.: "to the originally introduced concept of a "T.140 data channel"] for" Proposal: either delete the bracket or modify to [T140] -------------------------------------------------------------------------------- 6. In 1. Introduction, the first NOTE, Delete "back in 1998" Reason: Irrelevant ------------------------------------------------------------------------------------- 7. In 1. Introduction, number the notes NOTE 1 and NOTE 2. -------------------------------------------------------------------------------------- 8. In 3.1 third line, delete "(m= line)". The correct term is "media description" that is already correctly used. ------------------------------------------------------------------------------------------------------------------------------------------- 9. In 3.1 Use of dcmap Attribute: The second paragraph says that the "label" attribute MUST be included, but the next to last line says "without any label" and the example lacks the label. sdpneg says that "label" is optional, so I suggest that thestatement in the second paragraph is modified to not require "label" ------------------------------------------------------------------------------------------------------------- 10. In 3.2, first paragraph, third line, delete "(m= line)". ------------------------------------------------------------------------------ 11. In 4th paragraph in 3.2, change "cpc" to "cps" ------------------------------------------------------------------------------------------ 12. At the end of 3.2, add the following about language negotiation The users may be interested to negotiate language to use during the real-time text session. This is done by including specifications of language capabilities in the media descriptors for the t140 data channels by use of dsca attributes hlang-send and hlang-recv according to RFC 8373 [RFC8373]. The format is as follows: a=dsca:id hlang-send:language a=dsca:id hlang-send:language The negotiation is performed as indicated in RFC8373. -EDITORs NOTE - There may be a need for IANA registration of this way to use the human language attributes. ------------------------------------------------------------------------------ 13. In 3.3 Example, first line, delete "(m= line)" ----------------------------------------------------------------------------- 14. In 4.1, fourth bullet point, Deny session, change: "reject a request the establishment of a T.140 data channel," to "reject a request to establish a T.140 data channel," ---------------------------------------------------------------------------------------------------- 15. In 4.2, second paragraph, change "reduntant" to "redundant" --------------------------------------------------------------------------------------------------- 16. In 4.3, add at the end of the current paragraph: "The user requirements for smooth flow and low latency in text conversation should be considered when assigning a buffer time. The default transmission interval of 300 milliseconds from [RFC4103] or lower is recommended also for T.140 data channels." --------------------------------------------------------------------------------------------------------------------------- 17. Add a new section 4.4 " 4.4 Loss of T140blocks In case of network failure or congestion, T140 data channels may break. If this happens but the session sustains, it is recommended that a low number of retries are made to reconnect the T140 data channels. If reconnection is successful, an evaluation shall be made if any T140blocks were lost. Retransmission of already transmitted T140blocks MUST be avoided, and missing text markers [T140ad1] should be inserted in the received data stream where loss is detected or suspected and presented to the user. If instead also the session breaks, the break is accepted as end of session and the user should be informed about the unexpected end of session. " -------------------------------------------------------------------------------------------------------------------------------------------- 18. Add a new section 4.5 4.5 Multi-party considerations Implementations should be prepared to accept establishment and use of multiple T140 data channels in order to support multi-party sessions with real-time text. A number of scenarios are available for how multi-party sessions can be supported in the WebRTC environment. Implementations may select any suitable scenario. Presentation should be made so that the source of the real-time text is perceivable and the relative time relations in the conversation approximately presented. The "label" attribute may be used to convey a presentable source. ---------------------------------------------------------------------------------------------------------------------------------- 19. chapter 5, Gateway considerations is proposed to be replaced by the following: " 5. Interworking Considerations Real-time text transport protocols have been defined for a number of technical environments for both packet switched and circuit switched networks. Many of them are based on the ITU-T T.140 protocol on application and presentation level [T140]. Some of them are obsolete as their multimedia protocol base have become obsolete, while others are in use. When interworking with real-time text in another technical environment than WebRTC using the T.140 data channel is required, a number of factors need to be considered. The most used other real-time text transport protocol than the T.140 data channel is the RTP based RFC 4103 [RFC4103], used in legacy SIP situations. The considerations specified below for the interworking case between WebRTC with T.140 data channels and legacy SIP with RFC 4103 based T.140 transport can be taken as examples of what to consider also for other interworking situations using gateways. The considerations specified here are not to be seen as comprehensive, but rather as a brief description and a set of reminders. The detailed gateway procedures are out of scope of this document. 5.1 Channel establishment For each T140 data channel established on the WebRTC side of the gateway, an RFC 4103 RTP stream should be established on the legacy SIP side. Redundancy is by default declared and used on the RFC 4103 side to achieve reliability, while on the T.140 data channel side no redundancy and instead reliable channels are declared and used. 5.2 Transmission During normal flow of text, T140blocks received from one side are transmitted in the related session on the other side of the gateway. Keep-alive traffic is implicit on the T140 data channel side and not visible on the data channel transmission level, while some form of keep-alive traffic may need to be inserted and extracted by the gateway on the RTP side according to the habits for RFC 4103 usage. It is advisable to use the same transmission interval on both sides of the gateway if possible, and by that be able to transmit as soon as data is received, keeping the delay added by buffering in the gateway low. If the RTP session contains more than one RTT stream in a multi-party call through a text mixer, a corresponding mechanism for establishment and transmission in multiple T140 data channels shall be used. The "label" attribute on the T140 data channel side may be made to correspond to the Cname RTP field of the stream on the RFC 4103 side. If loss of data is detected or suspected after use of available redundancy on the RFC 4103 side, the gateway should insert the T.140 missing text marker [T140ad1]. If a T140 data channel breaks while the session is maintained, a limited number of reconnection efforts should be made. If re-connection of the T140 data channel is successful, then if text loss was detected after the reconnection, missing text marker should be inserted in the stream sent to the RTP side. -EDITOR NOTE-The last two items will be hard to achieve when an end-to-end encryption method is applied- " 20. At the end of 9.1, insert [T140ad1] ITU-T, "Recommendation ITU-T T.140 Addendum 1 (02/2000) [RFC8373] IETF RFC 8373 Negotiation of Human Language -------------------------------------------end of proposed changes-------------------------------- Den 2019-08-23 kl. 15:08, skrev Christer Holmberg: > Hi, > >> I hope I can stop introducing new topics soon, and contribute to resolving them instead... But another topic to cover is multi-party session >support. The requirement is: >> U-C 5: Realtime text chat during an audio and/or video call with an >> individual or with multiple people in a conference. >> >> I hope that will be straightforward. > I can't think of any impact on the document based on that. The SDP for such conference will contain an m- line for the T.140 data channel, as described in the draft, and m- lines for the RTP audio and video streams (described elsewhere). > > If there are some additional conference specific SDP attributes are needed for the T.140 data channel we can add them, but I can't think of any. > > Regards, > > Christer > > > > Den 2019-08-23 kl. 12:09, skrev Christer Holmberg: > Hi, > > I want to add one issue for the security section: Can we specify a way to achieve end-to-end encryption of T.140 > data between a WebRTC endpoint and a traditional SIP/RFC 4103 endpoint through a gateway? I know that that is a > desired feature. > How would you do that? The data channel uses DTLS encryption, and SIP/RFC 4103 uses SRTP encryption, so > doesn't the gateway have to decrypt/encrypt the T.140 traffic? > > I have just heard the requirement to have end-to-end encryption of RTT, > I do not have the solution. One possibility would maybe be to have media > encryption end-to-end as well as the two transport encryptions. But that > complicates the possibility to insert the missing text markers by the > gateway if text loss is detected. > > Yes. > > However, keep in mind that the scope of the draft is how to use SDP O/A to negotiate a T.140 WebRTC data channel. We DO include some text regarding interworking with SIP/RFC 4103, because we know there are environments where such interworking takes place. > > > But, extending T.140 and/or RFC 4103 (e.g., defining a new application level encryption mechanism for T.140) is outside the scope. > > Regards, > > Christer > > > > > > > > > Den 2019-08-22 kl. 16:28, skrev Christer Holmberg: > >> I have created a pull request, which will be used for the changes based on Gunnar's comments: > >> > >> https://protect2.fireeye.com/url?k=f453465c-a88743e3-f45306c7-868f633d > >> bf25-4deb49c05b8a2375&q=1&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-d > >> atachannel-t140%2Fpull%2F5 > >> > >> Regards, > >> > >> Christer > >> > >> On 22/08/2019, 13.39, "mmusic on behalf of Christer Holmberg" mailto:mmusic-bounces@ietf.orgonbehalfofchrister.holmberg@ericsson.com wrote: > >> > >> Hi Gunnar, > >> > >> Thanks you for your support (I assume :) and comments on the draft! > >> > >> See inline. > >> > >> >A couple of comments: > >> >1) In 3.2, the attribute "cps" is misspelled "cpc" once. > >> > >> Will fix. > >> > >> --- > >> > >> >2) Section 5 has some historical references to real-time text transports that may not be of much interest anymore > >> >and instead confuse the reader, while some other more relevant transports may be added. > >> > >> I took these from the schwarz draft. You probably know better > >> than me which ones are relevant, so feel to suggest which one(s) > >> should be removed, and which one(s) should be be added :) > >> > >> >I would also like to discuss if it could be possible to have a few general recommendations on the webrtc to sip/rfc4103 case without > >> >the problems you see with having a detailed gateway section. > >> > >> The second last paragraph covers some things on the media plane (out of order and loss of RTP packets) that I think are worth mentioning. > >> > >> As far as SDP interworking is concerned, this draft defines the m- line for T.140 data channel, and RFC 4103 defines the m- line for T.140 RTP, and the interworking should be very straight forwards. Do you have something specific in mind regarding general recommendations? > >> > >> --- > >> > >> > 3) Reliability. Section 3.1 implies that the channel is used in the reliable and ordered mode. We have been discussing back and forth > >> > if that is the right choice for real-time text. I tend to think it is, but it might be useful to discuss it once again. The traditional user > >> > requirement on real-time text is that produced characters shall be presented to the receiver within one second from their creation. > >> > Modern usage in speech-to-text applications may require more rapid transmission. As I understand it, the reliable mode of the > >> > data channel may imply long periods of choked transmission in case of network problems or by influence of heavy transmission > >> > in another channel. As long as this happens only in case of network problems, I now tend to think that that might be acceptable. > >> > The effects of being forced to use an unreliable channel are so far-going so I would like to avoid that. > >> > However, the word "reliable" is misleading. A "reliable" channel is not really reliable. It can break in case of problems. > >> > >> True, but "reliable" is the terminology used in both RFC 4960 (SCTP) and draft-ietf-rtcweb-data-channel. > >> > >> > I think some recommendations should be inserted in section 4 about what to do when a channel breaks. The natural action > >> > would be for both sides to try to figure out what was the last T.140 data that was transmitted and received, and then try to > >> > reconnect and resume transmission if successful. If any T.140 data was lost during the break, that state should be marked > >> > by inserting the "missing data" T.140 indicator in the received stream. There needs of course also be a recommended action > >> > if it turns out to be impossible to reconnect after a low number of retries. > >> > >> I can for sure add some text about that. Are there generic T.140 recommendations for failure that we can reference, or do you think there is something T.140 data channel specific? > >> > >> Regards, > >> > >> Christer > >> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mailto:mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > >> > > -- > > ----------------------------------------- > > Gunnar Hellström > > Omnitor > > mailto:gunnar.hellstrom@omnitor.se > > +46 708 204 288 > > > > _______________________________________________ > > mmusic mailing list > > mailto:mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > mailto:gunnar.hellstrom@omnitor.se > +46 708 204 288 > > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288
- [MMUSIC] Draft new: draft-holmberg-mmusic-t140-us… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Belling, Thomas (Nokia - DE/Munich)
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Bernard Aboba
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… R.Jesske
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Bernard Aboba
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Paul Kyzivat
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Paul Kyzivat
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] Draft new: draft-holmberg-mmusic-t14… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- [MMUSIC] draft-holmberg-mmusic-t140-usage-data-ch… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Roni Even (A)
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Roni Even (A)
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Roni Even (A)
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Gunnar Hellström
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Christer Holmberg
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Roni Even (A)
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat
- Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-dat… Paul Kyzivat