Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
"Schwarz, Albrecht (Nokia - DE)" <albrecht.schwarz@nokia.com> Mon, 29 February 2016 08:46 UTC
Return-Path: <albrecht.schwarz@nokia.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9777A1B2DD3 for <mmusic@ietfa.amsl.com>; Mon, 29 Feb 2016 00:46:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.501
X-Spam-Level:
X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 rP5C94e-uwOF for <mmusic@ietfa.amsl.com>; Mon, 29 Feb 2016 00:46:03 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 633711B2E32 for <mmusic@ietf.org>; Mon, 29 Feb 2016 00:46:03 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 687EBE4772CBB for <mmusic@ietf.org>; Mon, 29 Feb 2016 08:45:59 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1T8k1At020950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mmusic@ietf.org>; Mon, 29 Feb 2016 08:46:01 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1T8jwb5019053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Mon, 29 Feb 2016 09:46:00 +0100
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.33]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 29 Feb 2016 09:45:59 +0100
From: "Schwarz, Albrecht (Nokia - DE)" <albrecht.schwarz@nokia.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
Thread-Index: AQHRK4TSx7C8BOzqRoKqmvGfP3/g4Z61TmFp///0nACAXN0KB4ALF657gBzt17uAAHRDgIAEUD8xgAApQACAA7xPAIAAc4rA
Date: Mon, 29 Feb 2016 08:45:58 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1ACE19D4AFD@FR711WXCHMBA03.zeu.alcatel-lucent.com>
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BE0F51.7050700@alum.mit.edu> <56C05B90.5070107@alcatel-lucent.com> <56C1F810.4060309@alum.mit.edu> <56C31DC5.80105@alcatel-lucent.com> <56C471D1.8010701@alcatel-lucent.com> <56C745EB.6060605@alum.mit.edu> <56CC5EC6.2030402@alcatel-lucent.com> <56CCCE6F.9040106@alum.mit.edu> <56CE49C1.2020605@nteczone.com> <56CF7470.10706@alum.mit.edu> <56D05E8D.5080306@alcatel-lucent.com> <56D08F58.1040709@alum.mit.edu> <56D3B18E.7000904@nteczone.com>
In-Reply-To: <56D3B18E.7000904@nteczone.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/1C0Y14sjdHXrA5vZjNbPXMZ24fs>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 29 Feb 2016 08:46:09 -0000
> Perhaps a document could be created that defined RTP/AVP, RTP/AVPF, > RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the > websocket/datachannel registry. And then that document might say that > any sdp attribute designed to be used with protos */(each of these > subprotocols) may also be used in dcsa for a channel using these > protocols. [CNG] Yes it "could" be, if someone actually wanted to carry RTP over a data channel. That would follow with what is being done for MSRP and BFCP. I don't see RTP as being any different. There isn't any use case at all for RTP-over-DC, neither for RTP in general nor specific RTP profiles "RTP/<Profile(s)>". Thus, I concur to Christian. Regards, Albrecht -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Christian Groves Sent: Montag, 29. Februar 2016 03:49 To: mmusic@ietf.org Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg Hello Paul and Juergen, On 27/02/2016 4:46 AM, Paul Kyzivat wrote: > Hi, > > On 2/26/16 9:17 AM, Juergen Stoetzer-Bradler wrote: >> Hello Paul, Christian, >> >> Would propose to add following definition of term "subprotocol" to >> the terminology section 3 of the sdpneg draft: >> >> Data channel subprotocol: The application protocol which is >> transported over a single data channel. Data channel subprotocol >> messages are sent as data channel payload over an established >> data >> channel. If an SDP offer/answer exchange is used as specified in >> this document to negotiate the establishment of data channels, >> corresponding data channel properties, associated data channel >> subprotocols and data channel subprotocol properties, then the >> data >> channel subprotocols may be identified by the values of the >> "subprotocol" parameters of the SDP "a=dcmap" attributes as >> described in Section 5.1.1.5. Within this document the term >> "data >> channel subprotocol" is often abbreviated as just "subprotocol". >> >> This text could explicitly narrow down the notion of "subprotocol" >> within the data channel SDP offer/answer context and might especially >> be helpful distinguishing it from the usages of "subprotocol" in the >> Websocket RFC 6455 (where the term "subprotocol" was taken from, but >> where it does not seem to be formally defined). This text may >> certainly not be helpful in more general non-data channel contexts. >> But it might help to clarify that every occurrence of of the term >> "subprotocol" in the sdpneg draft refers to the application protocol >> which (typically but not necessarily) is identified via the a=dcmap's "subprotocol" >> parameter. >> >> Would such an explicit definition be helpful from your point of view? > > It might *help*, but it doesn't get at the main problem I see. > > The question is how does this sub-protocol relate the the proto field > used in m-lines? But not to the proto of the m-line for data channel. > My point is that many sdp attributes were designed to be used with > particular proto fields. For instance, with RTP/AVP, RTP/AVPF, > TCP/RTP/AVP, RTP/SAVP, DCCP/RTP/AVP, DCCP/RTP/SAVP, DCCP/RTP/AVPF, > RTP/SAVPF, UDP/TLS/RTP/SAVP, DCCP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF, > DCCP/TLS/RTP/SAVPF, ... [CNG] Does sub-protocol have to relate to the proto field? The proto field in the case of WebRTC-datachannel is UDP/DTLS/SCTP. What ever is carried in the individual data channels is the sub-protocol. Draft-ietf-mmusic-data-channel-sdpneg is only considering this. > > In general they are described as being applicable to RTP. But what is > RTP? Is it a subprotocol (of UDP, TCP, DCCP)? Or is it a > super-protocol (of AVP, AVPF, SAVP, SAVPF)? [CNG] I'm not sure it matters? If someone wants to run a particular RTP profile over a data channel then it is a sub-protocol of UDP/DTLS/SCTP. All the other above examples have already been defined so I don't see we gain anything by trying to label them as a sub-protocol etc. > > If we wanted to define use of RTP over a data channel, what > sub-protocol(s) would we have to define? I *think* we would have to > define as many of RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF as we wanted > to support over a data channel. [CNG] Yes I would agree. > > And then how would we do it, and where would we specify which > attributes could be used with dcsa? Would we have to update the > documents that define those attributes? [CNG] I assume we'd follow the example of draft-ietf-mmusic-msrp-usage-data-channel. It discusses the use of existing attributes. I don't see that RTP would need to do anything different. > > ISTM there are similar (though not so complex) issues for pretty much > any attribute that we might want to reuse over a data channel. [CNG] Some will be complex, some will be a no brainer. What draft-ietf-mmusic-data-channel-sdpneg provides is a syntax for re-using attributes. It doesn't provide semantics for every attribute. Implementors need to understand that some attributes have been defined with a particular protocol stack in mind and that they the behaviour may need to be modified when using a data channel. > > Perhaps a document could be created that defined RTP/AVP, RTP/AVPF, > RTP/SAVP, RTP/SAVPF as sub-protocols and registered them in the > websocket/datachannel registry. And then that document might say that > any sdp attribute designed to be used with protos */(each of these > subprotocols) may also be used in dcsa for a channel using these > protocols. [CNG] Yes it "could" be, if someone actually wanted to carry RTP over a data channel. That would follow with what is being done for MSRP and BFCP. I don't see RTP as being any different. > > Thanks, > Paul > >> Thanks, >> Juergen >> >> >> On 25.02.2016 22:38, EXT Paul Kyzivat wrote: >>> On 2/24/16 7:24 PM, Christian Groves wrote: >>>> Hello Juergen and Paul, >>>> >>>> Please see at end. >>>> >>>> Regards, Christian >>>> >>>> On 24/02/2016 8:26 AM, Paul Kyzivat wrote: >>>>> ..snip.. >>>>>> >>>>>> On 19.02.2016 17:42, EXT Paul Kyzivat wrote: >>>>>>> On 2/17/16 8:12 AM, Juergen Stoetzer-Bradler wrote: >>>>>>>> Hi Paul, Christian, Flemming, Bo, >>>>>>>> >>>>>>>> Have just submitted version 08 of >>>>>>>> draft-ietf-mmusic-data-channel-sdpneg. >>>>>>>> The changes compared to version 07 are essentially as follows. >>>>>>>> >>>>>>>> * Two new paragraphs in section 5.1.2.1 (dcsa Attribute) >>>>>>>> regarding the >>>>>>>> relationship of subprotocols and their attributes. >>>>>>>> * Two new SDP offer/answer considerations in section 5.2.5 >>>>>>>> (Various >>>>>>>> SDP Offer/Answer Scenarios and Considerations) regarding unknown >>>>>>>> subprotocol attributes or known subprotocol attributes, whose data >>>>>>>> channel transport specific semantic is not known. >>>>>>>> * A new paragraph in section 8.1 (IANA Considerations / >>>>>>>> Subprotocol >>>>>>>> Identifiers) related to cases, where a subprotocol is defined for >>>>>>>> data >>>>>>>> channel and Websocket transport. >>>>>>>> >>>>>>>> These changes should address the points discussed in this email >>>>>>>> thread. >>>>>>> >>>>>>> This is an improvement. But I think things could still be made >>>>>>> clearer. >>>>>>> >>>>>>> Consider the following addition to 5.1.2.1: >>>>>>> >>>>>>> It is assumed that in general the usages of subprotocol related >>>>>>> media >>>>>>> level attributes are independent from the subprotocol's >>>>>>> transport >>>>>>> protocol. Such transport protocol independent subprotocol >>>>>>> related >>>>>>> attributes are used in the same way as defined in the original >>>>>>> subprotocol specification, also if the subprotocol is >>>>>>> transported >>>>>>> over a data channel and if the attribute is correspondingly >>>>>>> embedded >>>>>>> in a "a=dcsa" attribute. >>>>>>> >>>>>>> There may be cases, where the usage of a subprotocol related >>>>>>> media >>>>>>> level attribute depends on the subprotocol's transport >>>>>>> protocol. In >>>>>>> such cases the subprotocol related usage of the attribute is >>>>>>> expected >>>>>>> to be described for the data channel transport. A data channel >>>>>>> specific usage of a subprotocol attribute is expected to be >>>>>>> specified >>>>>>> in the same document, which registers the subprotocol's >>>>>>> identifier >>>>>>> for data channel usage as described in Section 8.1. >>>>>>> >>>>>>> This text makes sense when there is a clear distinction between >>>>>>> subprotocol and protocol. Unfortunately, the way SDP has evolved >>>>>>> there >>>>>>> is no such clear distinction in many cases, such as RTP over UDP or >>>>>>> TCP, etc. Those are combined into a single protocol value. While >>>>>>> that >>>>>>> can usually be parsed apart at slashes, there isn't good >>>>>>> terminology >>>>>>> for it. >>>>>>> >>>>>>> My point is that when I read the above, I don't know how it applies >>>>>>> to, say, RTP attributes. Or does it only apply for attributes that >>>>>>> are >>>>>>> clearly defined for a *sub*protocol? >>>>>>> >>>>>>> I think this is primarily that we lack well defined vocabulary for >>>>>>> all >>>>>>> of this. But I think it would be too much to expect this draft to >>>>>>> *solve* the vocabulary problem. In lieu of doing so, maybe it >>>>>>> would be >>>>>>> sufficient to give some concrete examples, even if they have to be >>>>>>> hypothetical ones. >>>>>> >>>>>> [Juergen] Agree that it would be helpful to have more precise >>>>>> definitions of the differences of the terms protocol and >>>>>> subprotocol, >>>>>> especially when those terms are used outside the scope of data >>>>>> channels >>>>>> (or Websockets). When only focusing on data channels the notion of a >>>>>> "subprotocol" seems to be clearer - at least >>>>>> draft-ietf-rtcweb-data-protocol explicitly refers to the "WebSocket >>>>>> Subprotocol Name Registry" when specifying DCEP's "Protocol" >>>>>> parameter. >>>>>> (But draft-ietf-rtcweb-data-channel does not define what a data >>>>>> channel's "subprotocol" is.) So far the sdpneg draft relatively >>>>>> informally starts using the term "subprotocol" in the >>>>>> introduction and >>>>>> there refers to Websocket "subprotocols". Perhaps we should add the >>>>>> term >>>>>> "subprotocol" to the list of used terminology in section 3. >>>>>> >>>>>> The sdpneg document, together with the data channel subprotocol >>>>>> specific >>>>>> document (which defines the value of the a=dcmap attribute's >>>>>> "subprotocol" parameter), should certainly give clear guidance on >>>>>> how to >>>>>> interpret SDP offers or answers like e.g.: >>>>>> >>>>>> m=application 10001 UDP/DTLS/SCTP webrtc-datachannel >>>>>> c=IN IP4 10.10.10.1 >>>>>> a=max-message-size:100000 >>>>>> a=sctp-port:5000 >>>>>> ... >>>>>> a=dcmap:0 subprotocol="MSRP" >>>>>> a=dcsa:0 accept-types:message/cpim text/plain >>>>>> a=dcsa:0 framerate:... >>>>>> a=dcsa:0 lang:... >>>>>> >>>>>> An implementation receiving such an offer would need to decide >>>>>> what to >>>>>> do with the dcsa embedded framerate and lang attributes. Or, someone >>>>>> implementing MSRP over data channel based services may need to >>>>>> decide >>>>>> whether or not to use these attributes, and if yes, how. >>>>>> (I am using these two attributes just as hypothetical examples - >>>>>> don't >>>>>> want to suggest that those may indeed be used for MSRP over data >>>>>> channel >>>>>> transport). >>>>>> >>>>>> The msrp-usage-data-channel document doesn't mention these two >>>>>> attributes. When looking at the IANA SDP attribute registry >>>>>> tables, I >>>>>> would find both attributes specified in RFC 4566. There, >>>>>> "framerate" is >>>>>> explicitly said to be defined only "for video media". Just to be >>>>>> sure I >>>>>> could additionally have a look at the MSRP specifying documents, RFC >>>>>> 4975 and RFC 4976, but there would not find any text at all >>>>>> related to >>>>>> "framerate". So this case seems pretty clear and I would therefore >>>>>> conclude that the "framerate" attribute should not be used for >>>>>> MSRP, and >>>>>> that a receiver of such an offer or answer should ignore it. >>>>>> >>>>>> When looking at the definition of the "lang" attribute in RFC 4566 I >>>>>> would not see any explicit hint of what protocols this attribute >>>>>> might >>>>>> be used with, especially if "lang" could be used when negotiating an >>>>>> MSRP session. When then looking at RFC 4975 I would indeed find >>>>>> "lang" - >>>>>> but not as SDP attribute, rather as XML tag parameter within an >>>>>> example >>>>>> MSRP message payload. Thus, the case of the "lang" attribute >>>>>> might not >>>>>> be as unambiguous as the one with the "framerate" attribute, but >>>>>> here >>>>>> too I think the typical choice would be to ignore that attribute >>>>>> when >>>>>> receiving such an offer or answer. >>>>>> It seems to me that the two new "ignore" rules in section 5.2.5 of >>>>>> sdpneg-08 may also be applied in these cases. >>>>>> >>>>>> Admittedly, these examples may seem a bit far-fetched, but would >>>>>> those >>>>>> go into the direction you had in mind? >>>>> >>>>> Yes. Note that using examples is just me grasping at straws, since a >>>>> real solution looks like to big a problem for this draft to tackle by >>>>> itself. I am entirely open to other ideas for how to deal with this. >>>> [CNG] I don't see what the example buys? I don't see that the >>>> behaviour >>>> is any different between using additional attributes in the >>>> datachannel >>>> vs. the non data channel case. E.g. for >>>> >>>> c=IN IP4 10.10.10.1 >>>> m=message 7394 TCP/MSRP * >>>> a=accept-types:message/cpim text/plain text/html >>>> a=lang:.... >>>> a=framerate:... >>>> The ignore behaviour would be the same. >>>> In the above example the attributes are scoped by the m= line. In the >>>> data channel case the attributes are scoped by the relevant a=dcmap: >>>> line. >>> >>> My concern is that SDP has no notion of subprotocol, even though in >>> practice it shows up lots of places. It only has a notion of the >>> protocol field in the m-line. Beyond that a *convention* has developed >>> to denote a layering within the protocol through use of "/". AFAIK >>> this isn't formally written down anywhere. >>> >>> So, in principle we could define an RTP sub-protocol for use over a >>> data channel. And then we could talk about using the attributes that >>> apply to RTP in dcsa for a channel using RTP. But note there is no >>> formal definition of the *protocol*s where RTP attributes are relevant. >>> >>> A lot of the very old stuff was just sloppy. To be fair, it was >>> probably good enough for the cases in front of them at the time, and >>> they weren't yet in a position to foresee how things would evolve. It >>> is just another example of how old stuff rots and has to be refreshed >>> from time to time. >>> >>> But I don't think *this* draft is the place to fix it. So, in lieu of >>> doing that I'm just looking for some way to clarify things. >>> >>> Thanks, >>> Paul >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-… Bo Burman
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… DRAGE, Keith (Keith)
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… DRAGE, Keith (Keith)
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Schwarz, Albrecht (Nokia - DE)
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat