RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP

["Romascanu, Dan \(Dan\)" <[e-mail]>]

Alan,

I believe that we are not in disagreement from a technical perspective. I am just suggesting that reporting RTCP XR metrics to a RAQMON collector be one of the options that should be available 

This is not about pushing a RAQMON-centric technology to the industry or closing other options. This is about providing another way of transporting RTCP XR reports for these situations where the RTCP XR probes cannot be deployed . As the need for RTCP encryption will not run away completely, at least in some environments, and even the information carried by  RTCP XR may be considered confidential in some deployments, RAQMON reports carrying RTCP XR information can provide the missing functionality. 

RAQMON Reports will also support the case of the encrypted IP tunnels, as well as any combination of media and signaling encryption.

Regards,

Dan



> -----Original Message-----
> From: Alan Clark [mailto:[e-mail]]
> Sent: 02 December, 2004 7:45 PM
> To: Romascanu, Dan (Dan); Mark Baugher
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP
> 
> 
> Dan
> 
> I can understand your desire to create a RAQMON-centric 
> reporting system
> however the industry needs to keep its options open.  The 
> RTCP XR based VoIP
> performance management framework allows metrics to be 
> reported via the media
> path, signaling protocols or SNMP, and we need to give the 
> implementor as
> much flexibility as possible.  Reporting RTCP XR metrics to a RAQMON
> collector is one option that should be available however this 
> would not
> address many practical scenarios.
> 
> Service providers and network managers make extensive use of 
> probes and
> analyzers to monitor key demarc points in the network and 
> diagnose problems.
> Encrypting everything can severely limit the functionality of these
> mid-network systems and hence make it harder for the network 
> manager to
> manage the network.
> 
> If we had to trade the number of circumstances in which 
> knowledge of packet
> loss/ discard rates etc. were a security concern vs the number of
> circumstances under which network managers needed improved 
> tools to diagnose
> problems then I'd be surprised if the former was even a 
> minute fraction of
> the latter.
> It is also distinctly possible that if issues such as the 
> duration of a call
> was of concern then the IP endpoints would probably simply 
> use an encrypted
> IP tunnel - otherwise a mid-stream observer could examine the 
> RTP stream.
> 
> Regards
> 
> Alan
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Romascanu, Dan (Dan)
> Sent: Thursday, December 02, 2004 6:46 AM
> To: Alan Clark; Mark Baugher
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP
> 
> 
> I would be cautious in saying that in no circumstances the 
> contents of an XR
> payload would be remotely useful to an eavesdropper. We may 
> encounter some
> very security aware environments where even the fact that a 
> call happens
> between two IP phones, its duration, or QoS parameters need to be kept
> confidential. For this reason, while working to provide a strong
> recommendation for RTCP XR packets not to be encrypted, I do 
> not believe
> that we can make this a MUST requirements. As an alternative, 
> I suggest to
> use  RAQMON extensions to report the RTCP XR metrics to 
> RAQMON collectors
> without the security risks that may be of concern in some 
> environments.
> 
> Regards,
> 
> Dan
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Alan Clark
> > Sent: 01 December, 2004 2:08 PM
> > To: Mark Baugher
> > Cc: [e-mail]
> > Subject: [MMUSIC] RE: [AVT] RFC 3711 and RTCP
> >
> >
> > Mark
> >
> > To provide some background to the list - RFC3611 states the
> > following:-
> >
> >    "Any encryption or filtering of XR report blocks entails 
> a loss of
> >    monitoring information to third parties.  For example, a
> > network that
> >    establishes a tunnel to encrypt VoIP Report Blocks denies that
> >    information to the service providers traversed by the 
> tunnel.  The
> >    service providers cannot then monitor or respond to the 
> quality of
> >    the VoIP calls that they carry, potentially creating
> > problems for the
> >    network's users.  As a default, XR packets should not be
> > encrypted or
> >    filtered."
> >
> > I can't conceive of any circumstance in which the contents of
> > an XR payload
> > would be remotely useful to an eavesdropper and hence 
> stating that XR
> > payloads should always be left unencrypted would be (at least
> > in my opinion)
> > ok.  If we wanted to make this even more specific we could 
> narrow this
> > requirement down to only XR VoIP Metrics payloads to avoid
> > the situation in
> > which some future XR payload may be problematic.
> >
> > The availability of VoIP metrics payloads will be a huge
> > issue for service
> > providers - as we move through 2005 RTCP XR will be a 
> mainstay of VoIP
> > performance management and is already a mandatory requirement
> > within certain
> > sectors of the industry.  Making the VoIP metrics payload
> > unencrypted by
> > default may seem a small issue today however it will have
> > major consequences
> > to the industry as SRTP starts to roll out.
> >
> > Regards
> >
> > Alan
> >
> >
> >
> > -----Original Message-----
> > From: Mark Baugher [mailto:[e-mail]]
> > Sent: Tuesday, November 30, 2004 6:45 PM
> > To: Alan Clark
> > Cc: [e-mail]
> > Subject: Re: [AVT] RFC 3711 and RTCP
> >
> >
> > Alan
> >    I am copying MMUSIC (and not cross-posting to AVT) to
> > further discuss
> > a possible change to SDP security descriptions, which has 
> completed WG
> > last call.  The change is needed for RFC 3611, and we also 
> discovered
> > that
> > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions
> > -07.txt does not address the SRTCP E bit properly. I offered the
> > following text in a posting to AVT:
> > "As the default behavior when UNENCRYPTED_SRTCP is 
> signaled, all SRTCP
> > packets MUST have the E bit set to zero and MUST NOT be encrypted.
> > Otherwise, all SRTP packets MUST have the E bit set to one 
> and MUST be
> > encrypted by default.  Individual applications MAY override these
> > default behaviors in their specifications.  In a session where SRTCP
> > packets are encrypted, therefore, applications that use RFC 3611 MAY
> > set the E bit to 0 for XR packets as recommended by RFC 3611."
> >
> > One of my co-authors pointed out that the last sentence is
> > more than an
> > editorial change.  We also don't like the fact that an offerer or
> > answerer cannot explicitly signal when it wants the XR packet to be
> > encrypted or unencrypted.  In other words, if ENCRYPTED_SRTCP is the
> > default setting and RFC 3611 is also signaled, it is ambiguous as to
> > whether the SRTCP sender will encrypt the XR packet or not.  It's
> > solely up to the sender.  If the offerer or answerer want the
> > XR packet
> > to always be encrypted, there is no way to signal that.  
> Ditto for the
> > unencrypted case.
> >
> > I think we need to put the first three sentences of the above-quoted
> > paragraph into SDP security descriptions as an editorial 
> change.  I'm
> > proposing this to the working group.  I also propose not to
> > include the
> > last sentence.  Instead, we could add a new signaling parameter,
> > UNENCRYPTED_XR, which implies that all SRTCP messages are to be
> > encrypted except for the XR packets, which will have their E
> > bit clear,
> > of course.
> >
> > This new parameter could be placed in an RFC 3611bis or in 
> a revision
> > of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to
> > undergo another WG last call.  What do you (all) think about this?
> >
> > Mark
> >
> > On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote:
> >
> > > Alan
> > >   As Dave Oran has pointed out, the definition that you 
> want is not
> > > supported in the signaling, at present.  The current definition of
> > > 
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions
> > > -07.txt treats SRTCP encryption as either on or off and does not
> > > address the problem of setting the E bit in SRTCP packets.
> > This is a
> > > bug that we need to fix.
> > >
> > >   MMUSIC has finished last call on
> > > draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have
> > > reviewed it.  We'll be making some changes at Jon 
> Peterson's request
> > > and post another version in about a week.  This is an 
> opportunity to
> > > address the E bit, but the MMUSIC chairs or transport ADs may want
> > > another WG last call.  Off the top of my head, I would
> > offer something
> > > like the following.
> > >
> > > "As the default behavior when UNENCRYPTED_SRTCP is
> > signaled, all SRTCP
> > > packets MUST have the E bit set to zero and MUST NOT be encrypted.
> > > Otherwise, all SRTP packets MUST have the E bit set to one
> > and MUST be
> > > encrypted by default.  Individual applications MAY override these
> > > default behaviors in their specifications.  In a session 
> where SRTCP
> > > packets are encrypted, therefore, applications that use 
> RFC 3611 MAY
> > > set the E bit to 0 for XR packets as recommended by RFC 3611."
> > >
> > > Mark
> > >
> > > On Nov 24, 2004, at 2:33 PM, Alan Clark wrote:
> > >
> > >>
> > >>
> > >> Mark
> > >>
> > >> We tried to flag this in RFC3611 with the following text in the
> > >> "security
> > >> considerations" section
> > >>
> > >>    Any encryption or filtering of XR report blocks entails
> > a loss of
> > >>    monitoring information to third parties.  For 
> example, a network
> > >> that
> > >>    establishes a tunnel to encrypt VoIP Report Blocks denies that
> > >>    information to the service providers traversed by the
> > tunnel.  The
> > >>    service providers cannot then monitor or respond to the
> > quality of
> > >>    the VoIP calls that they carry, potentially creating
> > problems for
> > >> the
> > >>    network's users.  As a default, XR packets should not
> > be encrypted
> > >> or
> > >>    filtered.
> > >>
> > >> Could we potentially interpret this as being the
> > definition of what to
> > >> selectively encrypt in the case of the RFC3611 specification?
> > >>
> > >> Regards
> > >>
> > >> Alan
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Mark Baugher [mailto:[e-mail]]
> > >> Sent: Wednesday, November 24, 2004 2:42 PM
> > >> To: Alan Clark
> > >> Cc: Oren Peleg; Cullen Jennings; [e-mail]; David R
> > Oran; Michael
> > >> A.
> > >> Ramalho
> > >> Subject: Re: [AVT] RFC 3711 and RTCP
> > >>
> > >>
> > >> So, when the sender and receiver agree to encrypt SRTCP, 
> this would
> > >> mean
> > >> only that some SRTCP messages would be encrypted and the
> > sender would
> > >> decide which ones to encrypt?  My personal opinion is that
> > this is not
> > >> secure because it is unpredictable to the receiver, which
> > may have a
> > >> policy that all messages related to its session be encrypted.
> > >>
> > >> I can think of a few potential approaches to this problem.
> > >>
> > >> 1. Let individual SRTCP messages or a bundle of SRTCP messages
> > >> be signaled to be unencrypted when SRTCP encryption is used.
> > >>
> > >> 2. Make a blanket policy that the sender determine what
> > >> to selectively encrypt, as you suggest.
> > >>
> > >> 3. Define the policy of what to selectively encrypt in
> > >> the particular specification.  In other words, a document could
> > >> re-define the signaling of SRTCP encryption according to its
> > >> needs.  The specification of foo, therefore, could define a new
> > >> parameter such as foo_ENCRYPTED_SRTCP to be used in place of
> > >> ENCRYPTED_SRTCP.  The foo document would define what gets
> > >> encrypted and what does not get encrypted as per its needs.
> > >>
> > >> I commented on #2 already.  I don't like #1 because of its
> > signaling
> > >> complexity.  I like #3 because it limits the complexity to the
> > >> specific needs of an application.  #1 would be more 
> efficient than
> > >> #3 if lots of applications had their own specific needs for
> > >> selective encryption of SRTCP message.  But I don't think this is
> > >> the case.
> > >>
> > >> Mark
> > >>
> > >> On Nov 24, 2004, at 10:58 AM, Alan Clark wrote:
> > >>
> > >>>
> > >>> If the use of encryption in SRTCP is signalled by an
> > explicit (E) bit
> > >>> in the
> > >>> SRTCP header then perhaps the sender could autonomously decide
> > >>> whether
> > >>> it
> > >>> wants to encrypt?  Presumably since the sender is in the best
> > >>> position
> > >>> to
> > >>> decide if the data is sensitive then this would be ok - and the
> > >>> receiver is
> > >>> able to just look at the E bit and hence recognize that
> > decryption is
> > >>> needed.
> > >>>
> > >>> Alan
> > >>>
> > >>> -----Original Message-----
> > >>> From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of
> > >>> Mark Baugher
> > >>> Sent: Wednesday, November 24, 2004 1:33 PM
> > >>> To: David R Oran
> > >>> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark;
> > >>> [e-mail]
> > >>> Subject: Re: [AVT] RFC 3711 and RTCP
> > >>>
> > >>>
> > >>>
> > >>> On Nov 24, 2004, at 10:05 AM, David R Oran wrote:
> > >>>
> > >>>>
> > >>>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote:
> > >>>>
> > >>>>>
> > >>>>> Michael
> > >>>>>
> > >>>>> I don't see why this would be a problem unless you 
> included SDES
> > >>>>> and
> > >>>>> (SR or
> > >>>>> RR or XR) in the same RTCP packet.  SRTP (at least the
> > protocol) is
> > >>>>> apparently able to decided on a packet by packet basis
> > whether to
> > >>>>> encrypt
> > >>>>> RTCP - hopefully SRTP implementations also permit this.
> > >>>>>
> > >>>> Sure, they can do this. But remember offer-answer. How does a
> > >>>> receiver
> > >>>> communicate such a granular policy to the transmitter?
> > Right now if
> > >>>> can say whether to auth or auth+encrypt RTP, and auth or
> > >>>> auth+encrypt
> > >>>> RTCP. There's no way to say auth+encrypt SDES but only 
> auth SR/XR
> > >>>> etc.
> > >>>
> > >>> Seems to me that this is a problem with SDP security 
> descriptions.
> > >>> That problem might be there because we forgot about the E
> > bit.  This
> > >>> seems very messy for the reason you mention above -
> > granularity.  I
> > >>> don't think that we want to negotiate the encryption
> > policy for each
> > >>> type SDP message, which is a problem with something like
> > the E bit.
> > >>>
> > >>> Mark
> > >>>>
> > >>>>
> > >>>>> Logically I'd send SDES on its own at the start of a call to
> > >>>>> provide
> > >>>>> some
> > >>>>> user info, but would not send SR/RR/XR until at least
> > 8-10 seconds
> > >>>>> into the
> > >>>>> call as I need some time to gather statistics to report.
> > >>>> That's not exactly what the RTP specs say. RTCP timers 
> don't have
> > >>>> this
> > >>>> kind of policy today. In fact, there are porposals on
> > the table to
> > >>>> use
> > >>>> RTCP for early feedback to assess reception quality on
> > some initial
> > >>>> packets - e.g. the RTP-noop proposal. In any event that has no
> > >>>> bearing
> > >>>> on the present discussion.
> > >>>>
> > >>>>> After the
> > >>>>> start-of-call exchange there would appear to be 
> minimal need to
> > >>>>> include
> > >>>>> SDES. I'm sure we could construct some scenarios in
> > which you "may"
> > >>>>> need to
> > >>>>> include SDES with SR/RR/XR however the vast majority of
> > cases would
> > >>>>> either
> > >>>>> need only a single initial exchange or may not need 
> SDES at all.
> > >>>>>
> > >>>> Any time you change SSRC you potentially need to send SDES.
> > >>>> That said, I still don't see what bearing this has on
> > the discussion
> > >>>> about whether we need the complexity of encrypting some
> > RTCP packets
> > >>>> and not others for a single session.
> > >>>>
> > >>>> It's a tradeoff between extra complexity+less privacy versus
> > >>>> allowing
> > >>>> snoopers to gather RTCP stats.
> > >>>>
> > >>>> Dave.
> > >>>>
> > >>>>> Regards
> > >>>>>
> > >>>>> Alan
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Michael A. Ramalho [mailto:[e-mail]]
> > >>>>> Sent: Wednesday, November 24, 2004 9:39 AM
> > >>>>> To: Alan Clark
> > >>>>> Cc: Oren Peleg; [e-mail]
> > >>>>> Subject: RE: [AVT] RFC 3711 and RTCP
> > >>>>>
> > >>>>>
> > >>>>> At 07:54 AM 11/24/2004 -0500, Alan Clark wrote:
> > >>>>>> Hi Oren
> > >>>>>>
> > >>>>>> Yes - encryption is intended to provide privacy however this
> > >>>>>> relates
> > >>>>>> primarily to the voice payloads and to information 
> within RTCP
> > >>>>>> that
> > >>>>>> may be
> > >>>>>> associated with individual users (e.g. SDES).
> > >>>>>>
> > >>>>>> SR, RR and XR contain only peformance statistics and
> > there is no
> > >>>>>> privacy
> > >>>>>> consideration that I can think of related to this 
> type of data.
> > >>>>>>
> > >>>>>> The message is - encrypt RTP, optionally encrypt 
> RTCP SDES but
> > >>>>>> don't
> > >>>>> encrypt
> > >>>>>> RTCP SR/RR/XR
> > >>>>>
> > >>>>> Hi Alan,
> > >>>>>
> > >>>>> I am wondering about implementations utilizing your advise
> > >>>>> "optionally
> > >>>>> encrypt
> > >>>>> RTCP SDES but don't encrypt RTCP SR/RR/XR".
> > >>>>>
> > >>>>> Is there an easy way to tell SRTP to encrypt RTCP 
> SDES, but not
> > >>>>> RTCP
> > >>>>> SR/RR/XR? It seems that all the RTCP blocks would otherwise be
> > >>>>> highly
> > >>>>> related to each other. For example (quote out of RFC 3611):
> > >>>>>
> > >>>>> "XR packets supplement the existing RTCP packets, and may be
> > >>>>> stacked
> > >>>>> with
> > >>>>> other RTCP packets to form compound RTCP packets [9,
> > Section 6]."
> > >>>>>
> > >>>>> Thus, RFC3611 explicitly admits the possibility of 
> (but does not
> > >>>>> mandate)
> > >>>>> the piggybacking all the RTCP-XR block types.
> > >>>>>
> > >>>>> RTCP implementations would have to know the SRTP
> > encryption rules
> > >>>>> to
> > >>>>> make sure they don't perform piggybacking with SDES ...
> > but could
> > >>>>> allow
> > >>>>> (the more bandwidth efficient) piggybacking on the 
> other RTCP-XR
> > >>>>> blocks.
> > >>>>>
> > >>>>> This RTCP/SRTP interaction/dependency seems to add a
> > burden to both
> > >>>>> RTCP and SRTP implementations ... let alone the expressiveness
> > >>>>> required
> > >>>>> to signal your advise in existing SDP/SRTP mechanisms.
> > >>>>>
> > >>>>> Are you aware of any implementations that have 
> actually followed
> > >>>>> your
> > >>>>> advise above? I rather go into this one with our eyes open ...
> > >>>>> developers
> > >>>>> highly dislike this cross-functional entity dependency
> > (RTCP & SRTP
> > >>>>> along
> > >>>>> with expressing it in SDP/SRTP mechanisms).
> > >>>>>
> > >>>>> Regards,
> > >>>>>
> > >>>>> Michael Ramalho
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> Regards
> > >>>>>>
> > >>>>>> Alan
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Oren Peleg [mailto:[e-mail]]
> > >>>>>> Sent: Wednesday, November 24, 2004 7:50 AM
> > >>>>>> To: Alan Clark; [e-mail]
> > >>>>>> Subject: RE: [AVT] RFC 3711 and RTCP
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Isnt encryption is to prevent monitoring from the 
> first place?
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: [e-mail]
> > [mailto:[e-mail]] On Behalf
> > >>>>>> Of
> > >>>>>> Alan Clark
> > >>>>>> Sent: Tuesday, November 23, 2004 5:42 PM
> > >>>>>> To: [e-mail]
> > >>>>>> Subject: [AVT] RFC 3711 and RTCP
> > >>>>>>
> > >>>>>>
> > >>>>>>> From the flurry of discussion on RFC3711 it looks as
> > if there is
> > >>>>>> considerable interest in SRTP implementation.  I'd
> > like to add a
> > >>>>>> request
> > >>>>>> to
> > >>>>>> SRTP implementors with regard to manageability.
> > >>>>>>
> > >>>>>> RTCP SR, RR and more particularly XR (e.g. VoIP 
> Metrics report
> > >>>>>> block)
> > >>>>>> contain useful information for network monitoring, and
> > are often
> > >>>>>> used by
> > >>>>>> probes and analyzers to support problem diagnosis.
> > RFC3711 allows
> > >>>>>> the
> > >>>>>> selective encryption of RTCP payloads and hence I
> > would strongly
> > >>>>>> recomment
> > >>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR
> > >>>>>> payloads
> > >>>>>> as
> > >>>>>> this
> > >>>>>> adversely impacts manageability.
> > >>>>>>
> > >>>>>> Regards
> > >>>>>>
> > >>>>>> Alan Clark
> > >>>>>> Telchemy
> > >>>>>>
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> Audio/Video Transport Working Group
> > >>>>>> [e-mail]
> > >>>>>> https://www1.ietf.org/mailman/listinfo/avt
> > >>>>>>
> > >>>>>>
> > ******************************************************************
> > >>>>>> **
> > >>>>>> *
> > >>>>>> ******
> > >>>>> *
> > >>>>>> ********************************
> > >>>>>> This email and any files transmitted with it are confidential
> > >>>>>> material.
> > >>>>>> They are intended solely for the use of the designated
> > individual
> > >>>>>> or
> > >>>>>> entity
> > >>>>>> to whom they are addressed.
> > >>>>>> If the reader of this message is not the intended recipient,
> > >>>>>> you are hereby notified that any dissemination,use,
> > >>>>>> distribution or copying of this communication is strictly
> > >>>>>> prohibited
> > >>>>>> and
> > >>>>> may
> > >>>>>> be unlawful.
> > >>>>>>
> > >>>>>> If you have received this email in error please notify
> > >>>>>> [e-mail] and permanently delete the 
> e-mail and
> > >>>>>> files.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > ******************************************************************
> > >>>>>> **
> > >>>>>> *
> > >>>>>> ******
> > >>>>> *
> > >>>>>> *******************************
> > >>>>>>
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> Audio/Video Transport Working Group
> > >>>>>> [e-mail]
> > >>>>>> https://www1.ietf.org/mailman/listinfo/avt
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Audio/Video Transport Working Group
> > >>>>> [e-mail]
> > >>>>> https://www1.ietf.org/mailman/listinfo/avt
> > >>>>>
> > >>>> David R. Oran
> > >>>> Cisco Fellow
> > >>>> Cisco Systems
> > >>>> 7 Ladyslipper Lane
> > >>>> Acton, MA 01720 USA
> > >>>> Tel: [phone]
> > >>>> Email: [e-mail]
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> Audio/Video Transport Working Group
> > >>>> [e-mail]
> > >>>> https://www1.ietf.org/mailman/listinfo/avt
> > >>>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Audio/Video Transport Working Group
> > >>> [e-mail]
> > >>> https://www1.ietf.org/mailman/listinfo/avt
> > >>>
> > >>
> > >
> >
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> >
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic