Zeev Vax | 1 Jul 03:12 2009
Picon

Re: Port mappings, NAT, and RAMS

Roni,

My reference to general solution was beyond RTCP, any interactive two way application that have client in
the cloud and not using HTTP over TCP, have the same issue. As Ethernet gaining more reliability UDP become
a more valuable network solution, which will result in more application like that.

Zeev

-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:versteb <at> cisco.com]
Sent: Tuesday, June 30, 2009 2:15 PM
To: Roni Even; Zeev Vax; Dave Oran (oran)
Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; avt <at> ietf.org
Subject: RE: [AVT] Port mappings, NAT, and RAMS

Roni-

For the 2nd case, this problem also exists when the server's "request
port number" is different than the server's "response port number". This
is a very important case that breaks the port bindings in many NAT-ed
environments, and requires a standard solution.

Bill VerSteeg

-----Original Message-----
From: Roni Even [mailto:Even.roni <at> huawei.com]
Sent: Tuesday, June 30, 2009 10:02 AM
To: 'Zeev Vax'; Dave Oran (oran)
Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg (versteb);
avt <at> ietf.org
(Continue reading)

Zeev Vax | 1 Jul 03:12 2009
Picon

Re: Port mappings, NAT, and RAMS

I agree IETF is the right form, but I'm not sure the AVT WG is the right form as I think it is more general problem.

Zeev

-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:versteb <at> cisco.com]
Sent: Tuesday, June 30, 2009 2:14 PM
To: Zeev Vax; Dave Oran (oran); Roni Even
Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; avt <at> ietf.org
Subject: RE: [AVT] Port mappings, NAT, and RAMS

I agree that we should make a general solution for mapping unicast
sessions onto unicast sessions.

We need to solve this problem using data flows that will work across
multiple vendors' solutions, and thus need to do it in a standards
forum. The IETF is the correct place to do this.

Bill VerSteeg

-----Original Message-----
From: Zeev Vax [mailto:zeevvax <at> microsoft.com]
Sent: Tuesday, June 30, 2009 9:07 AM
To: Dave Oran (oran); Roni Even
Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg (versteb);
avt <at> ietf.org
Subject: RE: [AVT] Port mappings, NAT, and RAMS

I agree this should be a separate draft and we should work on a more
generic mechanism.
(Continue reading)

Roni Even | 1 Jul 06:58 2009

Re: Port mappings, NAT, and RAMS

Zeev,
You are right but I am trying to find the cases where for RTP/RTCP you
cannot address this on the application layer. For our work this means that
you cannot provide the information using SDP in offer/answer or declarative
way.
Roni

> -----Original Message-----
> From: Zeev Vax [mailto:zeevvax <at> microsoft.com]
> Sent: Wednesday, July 01, 2009 4:13 AM
> To: Bill Ver Steeg (versteb); Roni Even; Dave Oran (oran)
> Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; avt <at> ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Roni,
> 
> My reference to general solution was beyond RTCP, any interactive two
> way application that have client in the cloud and not using HTTP over
> TCP, have the same issue. As Ethernet gaining more reliability UDP
> become a more valuable network solution, which will result in more
> application like that.
> 
> Zeev
> 
> 
> 
> -----Original Message-----
> From: Bill Ver Steeg (versteb) [mailto:versteb <at> cisco.com]
> Sent: Tuesday, June 30, 2009 2:15 PM
> To: Roni Even; Zeev Vax; Dave Oran (oran)
(Continue reading)

Roni Even | 1 Jul 06:59 2009

Re: Port mappings, NAT, and RAMS

Bill,
If the server's sends the announcement using SDP this is not a problem
Roni

> -----Original Message-----
> From: Bill Ver Steeg (versteb) [mailto:versteb <at> cisco.com]
> Sent: Wednesday, July 01, 2009 12:15 AM
> To: Roni Even; Zeev Vax; Dave Oran (oran)
> Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; avt <at> ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Roni-
> 
> For the 2nd case, this problem also exists when the server's "request
> port number" is different than the server's "response port number".
> This
> is a very important case that breaks the port bindings in many NAT-ed
> environments, and requires a standard solution.
> 
> Bill VerSteeg
> 
> -----Original Message-----
> From: Roni Even [mailto:Even.roni <at> huawei.com]
> Sent: Tuesday, June 30, 2009 10:02 AM
> To: 'Zeev Vax'; Dave Oran (oran)
> Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg
> (versteb);
> avt <at> ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
(Continue reading)

Roni Even | 1 Jul 07:01 2009

Re: Port mappings, NAT, and RAMS

Zeev,
The IETF has worked on it as part of BEHAVE WG and defined ICE for SDP based
systems
Roni

> -----Original Message-----
> From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On Behalf Of
> Zeev Vax
> Sent: Wednesday, July 01, 2009 4:13 AM
> To: Bill Ver Steeg (versteb); Dave Oran (oran); Roni Even
> Cc: VAN CAENEGEM Tom; avt <at> ietf.org
> Subject: Re: [AVT] Port mappings, NAT, and RAMS
> 
> I agree IETF is the right form, but I'm not sure the AVT WG is the
> right form as I think it is more general problem.
> 
> Zeev
> 
> -----Original Message-----
> From: Bill Ver Steeg (versteb) [mailto:versteb <at> cisco.com]
> Sent: Tuesday, June 30, 2009 2:14 PM
> To: Zeev Vax; Dave Oran (oran); Roni Even
> Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; avt <at> ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> I agree that we should make a general solution for mapping unicast
> sessions onto unicast sessions.
> 
> We need to solve this problem using data flows that will work across
> multiple vendors' solutions, and thus need to do it in a standards
(Continue reading)

Zeev Vax | 1 Jul 18:09 2009
Picon

Re: Port mappings, NAT, and RAMS

Thanks Roni, can we use that work for our purpose?

Zeev

-----Original Message-----
From: Roni Even [mailto:Even.roni <at> huawei.com]
Sent: Tuesday, June 30, 2009 10:02 PM
To: Zeev Vax; 'Bill Ver Steeg (versteb)'; 'Dave Oran (oran)'
Cc: 'VAN CAENEGEM Tom'; avt <at> ietf.org
Subject: RE: [AVT] Port mappings, NAT, and RAMS

Zeev,
The IETF has worked on it as part of BEHAVE WG and defined ICE for SDP based
systems
Roni

> -----Original Message-----
> From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On Behalf Of
> Zeev Vax
> Sent: Wednesday, July 01, 2009 4:13 AM
> To: Bill Ver Steeg (versteb); Dave Oran (oran); Roni Even
> Cc: VAN CAENEGEM Tom; avt <at> ietf.org
> Subject: Re: [AVT] Port mappings, NAT, and RAMS
>
> I agree IETF is the right form, but I'm not sure the AVT WG is the
> right form as I think it is more general problem.
>
> Zeev
>
> -----Original Message-----
(Continue reading)

Roni Even | 1 Jul 18:24 2009

Re: Port mappings, NAT, and RAMS

Zeev,
I am not sure what you mean by our purpose. 
In my view the only missing part is how does the Receiver after receiving
the declarative SDP provide the transport address that he wants to use for
receiving the unicast burst or re-transmission for the SSM stream. We do not
need to address the topic of how the receiver found out this address

Roni 

> -----Original Message-----
> From: Zeev Vax [mailto:zeevvax <at> microsoft.com]
> Sent: Wednesday, July 01, 2009 7:10 PM
> To: Roni Even; 'Bill Ver Steeg (versteb)'; 'Dave Oran (oran)'
> Cc: 'VAN CAENEGEM Tom'; avt <at> ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Thanks Roni, can we use that work for our purpose?
> 
> Zeev
> 
> -----Original Message-----
> From: Roni Even [mailto:Even.roni <at> huawei.com]
> Sent: Tuesday, June 30, 2009 10:02 PM
> To: Zeev Vax; 'Bill Ver Steeg (versteb)'; 'Dave Oran (oran)'
> Cc: 'VAN CAENEGEM Tom'; avt <at> ietf.org
> Subject: RE: [AVT] Port mappings, NAT, and RAMS
> 
> Zeev,
> The IETF has worked on it as part of BEHAVE WG and defined ICE for SDP
> based
(Continue reading)

Roni Even | 2 Jul 15:24 2009

AVT WG requests for agenda time in Stockholm (IETF 75)

Hi,

 

If you wish to have agenda time at the upcoming meeting in Stockholm , please send an agenda request to the chairs, before July 14th .

 

 

We have two time slots:

 

1. Wednesday July 27     13:00 - 15:00

 

2. Wednesday July 27     15:10 – 16:10

 

 

 

 

 

I got so far the following requests:

 

1.  Enrico to present draft-ivov-avt-slic-00

2.  Ken Carlberg on Explicit Notification Extension (ECN) Support for RTP Sessions

3. Rolf on draft-mattsson-srtp-store-and-forward and draft-naslund-srtp-saf

 

 

 

 

 

Please note that the time slots are not final and may change. The final agenda for the meeting will be published July 6th .

 

The meeting time is intended for the following:

 

 

- Discussion of important drafts fundamental for the complete RTP framework.

 

- Discussion of issues that hasn't been possible to resolve on the mailing list.

 

- Discussion of new work that falls outside of our current charter.

 

- Discussion of important AVT relevant work in other WGs

 

 

So if you want time for discussing your issues in AVT. Then you are required to request time. These request shall contain the below information.

 

 

 

A. Presentation Title:

 

B. Name of presenter:

 

C. Draft Reference(s):

 

D. Requested amount of time in minutes:

 

 

 

 

 

Thanks

 

Tom Taylor & Roni Even

AVT Chairs

 

 

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Colin Perkins | 2 Jul 15:49 2009

Re: Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt

Mike,

Apologies - I was perhaps influenced by Art Allison's response, which made a stronger recommendation. Still, the suggestion that NTPv4 be implemented for synchronisation is stronger than I think desirable for a general draft such as this (although, of course, perfectly fine for some restricted domains in which RTP is used).

Cheers,
Colin




On 30 Jun 2009, at 23:41, Michael A Dolan wrote:

Colin-

I thought I was very careful to use "should" in my proposed reference clock language, and thus it is a recommendation and not required.  So, I am not sure I understand your comment below. If you prefer, "It is recommended....", that's fine of course.  But I do think we need to be much clearer that a common timebase is really important for sync.

I'll look at -03 "soon" and reply.

Thanks,

        Mike

At 11:12 PM 6/30/2009 +0100, Colin Perkins wrote:
Michael,

On 17 Jun 2009, at 20:46, Michael A Dolan wrote:
Colin-

Thanks.  I think we're close.

3550 only imprecisely recommends (not requires) using a common clock, and when it does, it uses the term, "wallclock", without defining it.  In order for the sync to even approach the numbers implied in this draft, the clocks must indeed be synchronized and they must use the same timebase.  Failing to minimally recommend this (even if you believe it is a restatement of 3550), it is not possible to achieve the implied sync times.  I really think you need to say MUST, but I leave that to you and Thomas.  And, it should be tied back to NTP fields since that it is a popular source of clock.  Here's a suggestion:

2.3 Clock Synchronization
In order to achieve more rapid and accurate sync, as recommended in RFC 3550, all senders and receivers should use a common reference clock. When NTPv4 is used, all instances of NTP packets should set the Reference ID (refid) field to the same timebase value (e.g. "GPS" - see NTPv4 Figure 12). Signaling for what Reference ID value is tp be used is accomplished out of band. When NTPv3 is used, all instances of NTP packets should use the same timebase, even if it is not explicitly signaled in the Reference ID field.
==============
Replace all uses of "wallclock", "NTP format clock", "NTP format wallclock", etc with a single term, such as "common reference clock", to be consistent with the first use in section 1, and to remove the ambiguity of all the varying uses in the text.
==============
Add a reference to NTPv4 (or maybe replace [7] RFC 1305?):
https://datatracker.ietf.org/drafts/draft-ietf-ntp-ntpv4-proto/

We can't require that senders and receivers use a common reference clock, or a particular clock synchronisation protocol - that's not realistic given the range of environments in which RTP is used - but I will add some text recommending that a common clock is used where possible.

Regarding the access point timing, I think a note would be good surrounding the tables to diffuse the implication that the 0.04 times in the table are realistic for an expected sync time (even if good for other purposes). We all agree there are other good reasons to send more frequent RTCP SR records that also improve clock accuracy, and are thus directly relevant to this draft. I did not mean to imply otherwise.  But I think it would be helpful to more clearly separate those reasons (e.g. decoder clock stability) from sync time expectations.  Let me know if you want a specific text suggestion.

I added some text to section 2.2 of the -03 draft. Is that sufficient?

Cheers,
Colin





Co-locating the RTCP SR records and the media access points is a helpful recommendation, and less systemic than the above points.

Thanks for considering these improvements (I think).

Regards,

        Mike


At 06:57 PM 6/17/2009 +0100, Colin Perkins wrote:
Michael,

On 16 Jun 2009, at 21:27, Michael A Dolan wrote:
FYI, I started out in March with a number of comments, some related to multicast UDLR with 1-2 links and I sense that's too big a topic to try and add at this point.  My comments therefore have distilled to addressing two major factors in syncing RTP sessions that I believe overshadow the time resolutions being discussed in the draft, and therefore it is an omission not to address them:

1. Common timebase
2. Media-specific access points

I stopped short of suggesting we should design anything. Therefore I still believe both topics belong here, and in this draft, and they are not so big as to defer at this point.

For clarification, I wasn't proposing we define a timebase signaling mechanism (although I do think that's a good idea).  All I am proposing is to add some text that explains that a common timebase is needed to achieve anything near the implied sync times discussed in this draft. How the senders and receivers figure that out is out of band. But if they don't and just go along with "wallclock", it makes much of the rest of this draft irrelevant since the timebase error will be huge by comparison.

That's already stated in RFC 3550. I'm not sure it needs repeating here, but can add something if you want.

Regarding the issue about access points, I'm not sure how much background to add, so apologies if this is obvious to everyone. Every media stream type has "access points" that arrive periodically - the point where a decoder can begin to decode the stream. In general, these are a function of the encoding, not constant per type, and not constant per stream. For example in H.264, these typically center around the presence of an IDR frame.  HE AAC has a simpler coding structure, but one still can't start decoding anywhere in the stream.  The "typical" periods of the H.264 access points range from 0.5 to 2 seconds, depending on the coding.  The exact period is application dependent, but is not relevant.  The point is that these periods greatly exceed the times shown in the tables which are implied to be the sync times - going as low as 0.04 seconds.  The tables in this draft suggesting that RTCP SR packets be sent 0.04 seconds apart for high rate streams. This is interesting (as Thomas notes) for jitter management and clock settling, but that high rate does not help you sync since you can't even start decoding the video for a relatively long time after the 0.04 seconds. This is mostly related to issues of late joiners of course.  Therefore, I was suggesting we make note of this fact to clarify there are other factors to sync and acquisition beyond receipt of NTP and the RTCP SR packet, and that these other times far exceed 0.04 seconds.

Okay, that's what I thought you meant. That certainly affects the join times, although I'm not sure I'd call that issue synchronisation latency. We can certainly add some wording to highlight it though.

Co-locating in time the RTCP SR packets with their related access points further improves the sync time.  For example, if the IDR is every 2 seconds, there is no benefit (for syncing) to sending the RTCP SR more frequently than that, especially if it is aligned with this access point in time.  If the RTCP SR packets are sent randomly in time, the sync time is the IDR period plus 1/2 the RTCP SR packet period, on average. This is more of an optimization, but then, that's what this whole draft is about - optimizing the sync time.

I agree that co-locating the SR information in time with the random access points helps, and will add something to the draft to say that explicitly if it's not already there. I disagree that's sufficient: sending the SR information more frequently gives the receiver more samples from which to estimate any skew between NTP and RTP timestamps, and gives more information to help filter out any incorrect mappings.

--
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Michael A Dolan | 2 Jul 17:33 2009

Re: Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt

Colin-

I proposed below (paraphrased): WHEN NTPv4 is used, then do X, and WHEN NTPv3 is used then do Y. I never said NTPv4 was preferred (except perhaps implied with my parenthetical to replace the older RFC reference). But I suggested that since NTPv4 is getting pretty close to pub and obsoletes NTPv3 (1305).  So trying to hang on to NTPv3 only is problematic, I think. But that's really a separate issue from my concern about the common timebase. Without a common timebase, the techniques described in this ID will be ineffective by an order of magnitude, no matter what version of NTP is used. So, I feel that some language substantively like what I propose below be added to this ID as necessary guidance.

Regards,

        Mike

At 02:47 PM 7/2/2009 +0100, Colin Perkins wrote:
Mike,

Apologies - I was perhaps influenced by Art Allison's response, which made a stronger recommendation. Still, the suggestion that NPTv4 be implemented for synchronisation is stronger than I think desirable for a general draft such as this (although, of course, perfectly fine for some restricted domains in which RTP is used).

Cheers,
Colin



On 30 Jun 2009, at 23:41, Michael A Dolan wrote:
Colin-

I thought I was very careful to use "should" in my proposed reference clock language, and thus it is a recommendation and not required.  So, I am not sure I understand your comment below. If you prefer, "It is recommended....", that's fine of course.  But I do think we need to be much clearer that a common timebase is really important for sync.

I'll look at -03 "soon" and reply.

Thanks,

        Mike

At 11:12 PM 6/30/2009 +0100, Colin Perkins wrote:
Michael,

On 17 Jun 2009, at 20:46, Michael A Dolan wrote:
Colin-

Thanks.  I think we're close.

3550 only imprecisely recommends (not requires) using a common clock, and when it does, it uses the term, "wallclock", without defining it.  In order for the sync to even approach the numbers implied in this draft, the clocks must indeed be synchronized and they must use the same timebase.  Failing to minimally recommend this (even if you believe it is a restatement of 3550), it is not possible to achieve the implied sync times.  I really think you need to say MUST, but I leave that to you and Thomas.  And, it should be tied back to NTP fields since that it is a popular source of clock.  Here's a suggestion:

2.3 Clock Synchronization
In order to achieve more rapid and accurate sync, as recommended in RFC 3550, all senders and receivers should use a common reference clock. When NTPv4 is used, all instances of NTP packets should set the Reference ID (refid) field to the same timebase value (e.g. "GPS" - see NTPv4 Figure 12). Signaling for what Reference ID value is tp be used is accomplished out of band. When NTPv3 is used, all instances of NTP packets should use the same timebase, even if it is not explicitly signaled in the Reference ID field.
==============
Replace all uses of "wallclock", "NTP format clock", "NTP format wallclock", etc with a single term, such as "common reference clock", to be consistent with the first use in section 1, and to remove the ambiguity of all the varying uses in the text.
==============
Add a reference to NTPv4 (or maybe replace [7] RFC 1305?):
https://datatracker.ietf.org/drafts/draft-ietf-ntp-ntpv4-proto/

We can't require that senders and receivers use a common reference clock, or a particular clock synchronisation protocol - that's not realistic given the range of environments in which RTP is used - but I will add some text recommending that a common clock is used where possible.

Regarding the access point timing, I think a note would be good surrounding the tables to diffuse the implication that the 0.04 times in the table are realistic for an expected sync time (even if good for other purposes). We all agree there are other good reasons to send more frequent RTCP SR records that also improve clock accuracy, and are thus directly relevant to this draft. I did not mean to imply otherwise.  But I think it would be helpful to more clearly separate those reasons (e.g. decoder clock stability) from sync time expectations.  Let me know if you want a specific text suggestion.

I added some text to section 2.2 of the -03 draft. Is that sufficient?

Cheers,
Colin





Co-locating the RTCP SR records and the media access points is a helpful recommendation, and less systemic than the above points.

Thanks for considering these improvements (I think).

Regards,

        Mike


At 06:57 PM 6/17/2009 +0100, Colin Perkins wrote:
Michael,

On 16 Jun 2009, at 21:27, Michael A Dolan wrote:
FYI, I started out in March with a number of comments, some related to multicast UDLR with 1-2 links and I sense that's too big a topic to try and add at this point.  My comments therefore have distilled to addressing two major factors in syncing RTP sessions that I believe overshadow the time resolutions being discussed in the draft, and therefore it is an omission not to address them:

1. Common timebase
2. Media-specific access points

I stopped short of suggesting we should design anything. Therefore I still believe both topics belong here, and in this draft, and they are not so big as to defer at this point.

For clarification, I wasn't proposing we define a timebase signaling mechanism (although I do think that's a good idea).  All I am proposing is to add some text that explains that a common timebase is needed to achieve anything near the implied sync times discussed in this draft. How the senders and receivers figure that out is out of band. But if they don't and just go along with "wallclock", it makes much of the rest of this draft irrelevant since the timebase error will be huge by comparison.

That's already stated in RFC 3550. I'm not sure it needs repeating here, but can add something if you want.

Regarding the issue about access points, I'm not sure how much background to add, so apologies if this is obvious to everyone. Every media stream type has "access points" that arrive periodically - the point where a decoder can begin to decode the stream. In general, these are a function of the encoding, not constant per type, and not constant per stream. For example in H.264, these typically center around the presence of an IDR frame.  HE AAC has a simpler coding structure, but one still can't start decoding anywhere in the stream.  The "typical" periods of the H.264 access points range from 0.5 to 2 seconds, depending on the coding.  The exact period is application dependent, but is not relevant.  The point is that these periods greatly exceed the times shown in the tables which are implied to be the sync times - going as low as 0.04 seconds.  The tables in this draft suggesting that RTCP SR packets be sent 0.04 seconds apart for high rate streams. This is interesting (as Thomas notes) for jitter management and clock settling, but that high rate does not help you sync since you can't even start decoding the video for a relatively long time after the 0.04 seconds. This is mostly related to issues of late joiners of course.  Therefore, I was suggesting we make note of this fact to clarify there are other factors to sync and acquisition beyond receipt of NTP and the RTCP SR packet, and that these other times far exceed 0.04 seconds.

Okay, that's what I thought you meant. That certainly affects the join times, although I'm not sure I'd call that issue synchronisation latency. We can certainly add some wording to highlight it though.

Co-locating in time the RTCP SR packets with their related access points further improves the sync time.  For example, if the IDR is every 2 seconds, there is no benefit (for syncing) to sending the RTCP SR more frequently than that, especially if it is aligned with this access point in time.  If the RTCP SR packets are sent randomly in time, the sync time is the IDR period plus 1/2 the RTCP SR packet period, on average. This is more of an optimization, but then, that's what this whole draft is about - optimizing the sync time.

I agree that co-locating the SR information in time with the random access points helps, and will add something to the draft to say that explicitly if it's not already there. I disagree that's sufficient: sending the SR information more frequently gives the receiver more samples from which to estimate any skew between NTP and RTP timestamps, and gives more information to help filter out any incorrect mappings.

--
Colin Perkins
http://csperkins.org/
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt



--
Dr Colin Perkins

Department of Computing Science
Sir Alwyn Williams Building
University of Glasgow
Glasgow G12 8QQ

The University of Glasgow, charity number SC004401
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt

Gmane