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

[Paul Kyzivat <[e-mail]>]

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.

	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
>>       
>>