headers
Ali C. Begen (abegen | 1 May 2009 01:45
Picon
Favicon

Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04

Hi Roni,

Thanks for the references. However, we cannot have a parameter that will relate the FEC stream to the source
as RFC 4588 did with "apt" since a lot of possibilities (multiple sources and/or multiple repair flows)
are possible with FEC. Instead, we use grouping and this works just fine in session multiplexing.

Regarding SSRC multiplexing of source and FEC streams, I don't think giving an explicit example is needed
or it is a good idea for this draft since SSRC-level grouping is just introduced in 4756bis and it will
include such examples anyway (actually the version I submitted today includes an example). We should
better only provide session multiplexing examples in this draft. This also emphasizes the recommended
way of doing FEC.

Reg the registration of the media types and SDP mappings, I believe the draft has the necessary details.

BR,
-acbegen

> -----Original Message-----
> From: Roni Even [mailto:ron.even.tlv <at> gmail.com] 
> Sent: Thursday, April 30, 2009 1:03 PM
> To: Ali C. Begen (abegen); vincent.roca <at> inrialpes.fr
> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> Subject: RE: [AVT] [Fecframe] FW: New Version Notification 
> for draft-ietf-fecframe-interleaved-fec-scheme-04
> 
> Ali,
> You can find examples in section 8.6 to 8.8 of RFC 4588, 
> notice that there is an optional parameter for the rtx stream 
> that defines the relation between the original and the rtx 
> stream. Similar solution is also specified for redundant
(Continue reading)

Permalink | Reply | 6 comments |
headers
Roni Even | 1 May 2009 08:56
Picon

Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04

Hi Ali,
This is up to the WG to decide if they want to have support for SSRC multiplexing and the implications of this
support. I am not sure what you mean by "we cannot have a parameter", I see only your view on the list.

If only session multiplexing is allowed then the draft should clearly state it and in this case I am not sure
why you are registering the video, audio and text media subtypes.

Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen <at> cisco.com] 
Sent: Friday, May 01, 2009 2:45 AM
To: Roni Even; vincent.roca <at> inrialpes.fr
Cc: avt <at> ietf.org; fecframe <at> ietf.org
Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04

Hi Roni,

Thanks for the references. However, we cannot have a parameter that will relate the FEC stream to the source
as RFC 4588 did with "apt" since a lot of possibilities (multiple sources and/or multiple repair flows)
are possible with FEC. Instead, we use grouping and this works just fine in session multiplexing.

Regarding SSRC multiplexing of source and FEC streams, I don't think giving an explicit example is needed
or it is a good idea for this draft since SSRC-level grouping is just introduced in 4756bis and it will
include such examples anyway (actually the version I submitted today includes an example). We should
better only provide session multiplexing examples in this draft. This also emphasizes the recommended
way of doing FEC.

Reg the registration of the media types and SDP mappings, I believe the draft has the necessary details.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Colin Perkins | 1 May 2009 11:24

Re: Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item

I support this draft being adopted as a working group item, since there's clearly interest in the work.

Colin


On 30 Apr 2009, at 21:12, Roni Even wrote:
Hi,

I would like to ask if there is interest to adopt Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to start the work usinghttp://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 as the initial text for the work.

 

I would also like to suggest that Bill Versteeg will be the editor of the WG document if adopted.

 

Please send any feedback to the mailing list by Friday May 8th. If there will be a consensus we will accept this topic and have the above draft as the initial document.

 

Thanks

Roni Even

AVT co-chair

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt



-- 
Colin Perkins


 

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 0 comments |
headers
Colin Perkins | 1 May 2009 11:27

Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04

On 1 May 2009, at 07:56, Roni Even wrote:
> Hi Ali,
> This is up to the WG to decide if they want to have support for SSRC  
> multiplexing and the implications of this support. I am not sure  
> what you mean by "we cannot have a parameter", I see only your view  
> on the list.

The grouping mechanism would seem to be sufficient. Why do we need a  
special-purpose mechanism, when we can reuse a general approach?

Colin

> If only session multiplexing is allowed then the draft should  
> clearly state it and in this case I am not sure why you are  
> registering the video, audio and text media subtypes.
>
> Roni
>
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen <at> cisco.com]
> Sent: Friday, May 01, 2009 2:45 AM
> To: Roni Even; vincent.roca <at> inrialpes.fr
> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- 
> ietf-fecframe-interleaved-fec-scheme-04
>
> Hi Roni,
>
> Thanks for the references. However, we cannot have a parameter that  
> will relate the FEC stream to the source as RFC 4588 did with "apt"  
> since a lot of possibilities (multiple sources and/or multiple  
> repair flows) are possible with FEC. Instead, we use grouping and  
> this works just fine in session multiplexing.
>
> Regarding SSRC multiplexing of source and FEC streams, I don't think  
> giving an explicit example is needed or it is a good idea for this  
> draft since SSRC-level grouping is just introduced in 4756bis and it  
> will include such examples anyway (actually the version I submitted  
> today includes an example). We should better only provide session  
> multiplexing examples in this draft. This also emphasizes the  
> recommended way of doing FEC.
>
> Reg the registration of the media types and SDP mappings, I believe  
> the draft has the necessary details.
>
> BR,
> -acbegen
>
>> -----Original Message-----
>> From: Roni Even [mailto:ron.even.tlv <at> gmail.com]
>> Sent: Thursday, April 30, 2009 1:03 PM
>> To: Ali C. Begen (abegen); vincent.roca <at> inrialpes.fr
>> Cc: avt <at> ietf.org; fecframe <at> ietf.org
>> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
>> for draft-ietf-fecframe-interleaved-fec-scheme-04
>>
>> Ali,
>> You can find examples in section 8.6 to 8.8 of RFC 4588,
>> notice that there is an optional parameter for the rtx stream
>> that defines the relation between the original and the rtx
>> stream. Similar solution is also specified for redundant
>> encoding red payload type (RFC 2198). You are offering both
>> streams with different payload type numbers in the same m-line.
>> In this case the media type must be video or audio same as
>> the media type of the protected stream. This is why you
>> needed the registration for type audio and video
>>
>> Roni
>>
>> -----Original Message-----
>> From: Ali C. Begen (abegen) [mailto:abegen <at> cisco.com]
>> Sent: Thursday, April 30, 2009 10:01 PM
>> To: Roni Even; vincent.roca <at> inrialpes.fr
>> Cc: avt <at> ietf.org; fecframe <at> ietf.org
>> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
>> for draft-ietf-fecframe-interleaved-fec-scheme-04
>>
>> Hi Roni,
>>
>>> I noticed that the fec framework will allow SSRC
>>
>> Yes, it will not be the recommended way of using FEC, but it
>> will be supported. The 4756bis draft also supports it now.
>>
>>> multiplexing, are you going to specify this in this draft in
>>> the SDP offer answer section.
>>
>> I am not sure what I need to specify additionally in this
>> section regarding SSRC multiplexing. Could you let me know if
>> there is such an example?
>>
>>> Maybe you should also discuss when to use application media
>>> type and when to use video or audio
>>
>> I believe the FEC is always application type, we did
>> registration for video, audio, etc. since FEC could relate to
>> sessions carrying such types.
>>
>> BR,
>> -acbegen
>>
>>>
>>>
>>> Roni
>>>
>>>
>>>
>>> From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On
>>> Behalf Of Ali C. Begen (abegen)
>>> Sent: Thursday, April 30, 2009 3:54 PM
>>> To: vincent.roca <at> inrialpes.fr
>>> Cc: avt <at> ietf.org; fecframe <at> ietf.org
>>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification
>>> for draft-ietf-fecframe-interleaved-fec-scheme-04
>>>
>>>
>>>
>>> Hi Vincent
>>>
>>> This draft is not an fec scheme so it is not related to fec
>>> framework. It is an rtp payload format draft. The wglc has
>>> been running almost a month now. If you have comments in this
>>> perspective, pls submit them soon.
>>>
>>>
>>>
>>>
>>> -acbegen
>>>
>>> ----- Original Message -----
>>> From: Vincent Roca <vincent.roca <at> inrialpes.fr>
>>> To: Ali C. Begen (abegen)
>>> Cc: fecframe <at> ietf.org <fecframe <at> ietf.org>; avt <at> ietf.org
>> <avt <at> ietf.org>
>>> Sent: Thu Apr 30 03:58:35 2009
>>> Subject: Re: [Fecframe] FW: New Version Notification for
>>>  draft-ietf-fecframe-interleaved-fec-scheme-04
>>>
>>> Hello Ali,
>>>
>>> I'm not in favor of finalizing the WGLC for this document.
>>> IMHO we must,
>>> first of all, finalize the framework document itself.
>>>
>>> For instance, the terminology used by the interleaved-fec-scheme I-D
>>> (section 3.1.) is not in line with the terminology used by the
>>> fecframe-framework-03 I-D (Section 2):
>>>        "Source Flow"   vs. "Source data flow"
>>>        "Repair Flow"   vs. "Repair data flow"
>>>        "Source Symbol" vs. nothing
>>>        "Repair Symbol" vs. nothing
>>>        "Source Packet" vs. nothing
>>>        "Repair Packet" vs. nothing
>>> And as I said before, IMHO the terminology proposed in the framework
>>> I-D should be discussed too.
>>>
>>> So let's do things in the right order, especially as the framework
>>> WGLC finishes soon.
>>>
>>> Additionally, I may have some comments for the
>>> interleaved-fec-scheme-04
>>> I-D. Since I missed the WGLC deadline, you have the right to
>>> blame me ;-)
>>> and I apologize in advance.
>>>
>>> Regards,
>>>
>>>  Vincent
>>>
>>>
>>> Ali C. Begen (abegen) wrote:
>>>> This version addresses the comments received from fecframe
>>> and avt so far.
>>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl
>> eaved-fec-scheme-04.txt
>>>>
>>>>
>>>> Fecframe chairs,
>>>>
>>>> Could we proceed and finalize WGLC?
>>>>
>>>> -acbegen
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org]
>>>> Sent: Wednesday, April 29, 2009 2:56 PM
>>>> To: Ali C. Begen (abegen)
>>>> Subject: New Version Notification for
>>> draft-ietf-fecframe-interleaved-fec-scheme-04
>>>>
>>>>
>>>> A new version of I-D,
>>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been
>>> successfuly submitted by Ali Begen and posted to the IETF
>> repository.
>>>>
>>>> Filename:      draft-ietf-fecframe-interleaved-fec-scheme
>>>> Revision:      04
>>>> Title:                 RTP Payload Format for 1-D
>>> Interleaved Parity FEC
>>>> Creation_date:         2009-04-29
>>>> WG ID:                 fecframe
>>>> Number_of_pages: 31
>>>>
>>>> Abstract:
>>>> This document defines a new RTP payload format for the
>> Forward Error
>>>> Correction (FEC) that is generated by the 1-D interleaved
>>> parity code
>>>> from a source media encapsulated in RTP.  The 1-D
>> interleaved parity
>>>> code is a systematic code, where a number of repair symbols are
>>>> generated from a set of source symbols and sent in a repair flow
>>>> separate from the source flow that carries the source
>> symbols.  The
>>>> 1-D interleaved parity code offers a good protection
>> against bursty
>>>> packet losses at a cost of decent complexity.  The new
>>> payload format
>>>> defined in this document is used (with some exceptions)
>> as a part of
>>>> the DVB Application-layer FEC specification.
>>>>
>>>
>>>>
>>>>
>>>> The IETF Secretariat.
>>>>
>>>>
>>>> _______________________________________________
>>>> Fecframe mailing list
>>>> Fecframe <at> ietf.org
>>>> https://www.ietf.org/mailman/listinfo/fecframe
>>>
>>>
>>
>>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt <at> ietf.org
> https://www.ietf.org/mailman/listinfo/avt

--

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

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 4 comments |
headers
Roni Even | 1 May 2009 12:22
Picon

Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04

Colin,
I am not sure that grouping will work when you have SSRC multiplexing and
both the protected stream and the fec stream are in the same m-line, the mid
attribute is per m-line

Roni

-----Original Message-----
From: Colin Perkins [mailto:csp <at> csperkins.org] 
Sent: Friday, May 01, 2009 12:27 PM
To: Roni Even
Cc: 'Ali C. Begen (abegen)'; avt <at> ietf.org; fecframe <at> ietf.org
Subject: Re: [AVT] [Fecframe] FW: New Version Notification for
draft-ietf-fecframe-interleaved-fec-scheme-04

On 1 May 2009, at 07:56, Roni Even wrote:
> Hi Ali,
> This is up to the WG to decide if they want to have support for SSRC  
> multiplexing and the implications of this support. I am not sure  
> what you mean by "we cannot have a parameter", I see only your view  
> on the list.

The grouping mechanism would seem to be sufficient. Why do we need a  
special-purpose mechanism, when we can reuse a general approach?

Colin

> If only session multiplexing is allowed then the draft should  
> clearly state it and in this case I am not sure why you are  
> registering the video, audio and text media subtypes.
>
> Roni
>
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen <at> cisco.com]
> Sent: Friday, May 01, 2009 2:45 AM
> To: Roni Even; vincent.roca <at> inrialpes.fr
> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- 
> ietf-fecframe-interleaved-fec-scheme-04
>
> Hi Roni,
>
> Thanks for the references. However, we cannot have a parameter that  
> will relate the FEC stream to the source as RFC 4588 did with "apt"  
> since a lot of possibilities (multiple sources and/or multiple  
> repair flows) are possible with FEC. Instead, we use grouping and  
> this works just fine in session multiplexing.
>
> Regarding SSRC multiplexing of source and FEC streams, I don't think  
> giving an explicit example is needed or it is a good idea for this  
> draft since SSRC-level grouping is just introduced in 4756bis and it  
> will include such examples anyway (actually the version I submitted  
> today includes an example). We should better only provide session  
> multiplexing examples in this draft. This also emphasizes the  
> recommended way of doing FEC.
>
> Reg the registration of the media types and SDP mappings, I believe  
> the draft has the necessary details.
>
> BR,
> -acbegen
>
>> -----Original Message-----
>> From: Roni Even [mailto:ron.even.tlv <at> gmail.com]
>> Sent: Thursday, April 30, 2009 1:03 PM
>> To: Ali C. Begen (abegen); vincent.roca <at> inrialpes.fr
>> Cc: avt <at> ietf.org; fecframe <at> ietf.org
>> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
>> for draft-ietf-fecframe-interleaved-fec-scheme-04
>>
>> Ali,
>> You can find examples in section 8.6 to 8.8 of RFC 4588,
>> notice that there is an optional parameter for the rtx stream
>> that defines the relation between the original and the rtx
>> stream. Similar solution is also specified for redundant
>> encoding red payload type (RFC 2198). You are offering both
>> streams with different payload type numbers in the same m-line.
>> In this case the media type must be video or audio same as
>> the media type of the protected stream. This is why you
>> needed the registration for type audio and video
>>
>> Roni
>>
>> -----Original Message-----
>> From: Ali C. Begen (abegen) [mailto:abegen <at> cisco.com]
>> Sent: Thursday, April 30, 2009 10:01 PM
>> To: Roni Even; vincent.roca <at> inrialpes.fr
>> Cc: avt <at> ietf.org; fecframe <at> ietf.org
>> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
>> for draft-ietf-fecframe-interleaved-fec-scheme-04
>>
>> Hi Roni,
>>
>>> I noticed that the fec framework will allow SSRC
>>
>> Yes, it will not be the recommended way of using FEC, but it
>> will be supported. The 4756bis draft also supports it now.
>>
>>> multiplexing, are you going to specify this in this draft in
>>> the SDP offer answer section.
>>
>> I am not sure what I need to specify additionally in this
>> section regarding SSRC multiplexing. Could you let me know if
>> there is such an example?
>>
>>> Maybe you should also discuss when to use application media
>>> type and when to use video or audio
>>
>> I believe the FEC is always application type, we did
>> registration for video, audio, etc. since FEC could relate to
>> sessions carrying such types.
>>
>> BR,
>> -acbegen
>>
>>>
>>>
>>> Roni
>>>
>>>
>>>
>>> From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On
>>> Behalf Of Ali C. Begen (abegen)
>>> Sent: Thursday, April 30, 2009 3:54 PM
>>> To: vincent.roca <at> inrialpes.fr
>>> Cc: avt <at> ietf.org; fecframe <at> ietf.org
>>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification
>>> for draft-ietf-fecframe-interleaved-fec-scheme-04
>>>
>>>
>>>
>>> Hi Vincent
>>>
>>> This draft is not an fec scheme so it is not related to fec
>>> framework. It is an rtp payload format draft. The wglc has
>>> been running almost a month now. If you have comments in this
>>> perspective, pls submit them soon.
>>>
>>>
>>>
>>>
>>> -acbegen
>>>
>>> ----- Original Message -----
>>> From: Vincent Roca <vincent.roca <at> inrialpes.fr>
>>> To: Ali C. Begen (abegen)
>>> Cc: fecframe <at> ietf.org <fecframe <at> ietf.org>; avt <at> ietf.org
>> <avt <at> ietf.org>
>>> Sent: Thu Apr 30 03:58:35 2009
>>> Subject: Re: [Fecframe] FW: New Version Notification for
>>>  draft-ietf-fecframe-interleaved-fec-scheme-04
>>>
>>> Hello Ali,
>>>
>>> I'm not in favor of finalizing the WGLC for this document.
>>> IMHO we must,
>>> first of all, finalize the framework document itself.
>>>
>>> For instance, the terminology used by the interleaved-fec-scheme I-D
>>> (section 3.1.) is not in line with the terminology used by the
>>> fecframe-framework-03 I-D (Section 2):
>>>        "Source Flow"   vs. "Source data flow"
>>>        "Repair Flow"   vs. "Repair data flow"
>>>        "Source Symbol" vs. nothing
>>>        "Repair Symbol" vs. nothing
>>>        "Source Packet" vs. nothing
>>>        "Repair Packet" vs. nothing
>>> And as I said before, IMHO the terminology proposed in the framework
>>> I-D should be discussed too.
>>>
>>> So let's do things in the right order, especially as the framework
>>> WGLC finishes soon.
>>>
>>> Additionally, I may have some comments for the
>>> interleaved-fec-scheme-04
>>> I-D. Since I missed the WGLC deadline, you have the right to
>>> blame me ;-)
>>> and I apologize in advance.
>>>
>>> Regards,
>>>
>>>  Vincent
>>>
>>>
>>> Ali C. Begen (abegen) wrote:
>>>> This version addresses the comments received from fecframe
>>> and avt so far.
>>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl
>> eaved-fec-scheme-04.txt
>>>>
>>>>
>>>> Fecframe chairs,
>>>>
>>>> Could we proceed and finalize WGLC?
>>>>
>>>> -acbegen
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org]
>>>> Sent: Wednesday, April 29, 2009 2:56 PM
>>>> To: Ali C. Begen (abegen)
>>>> Subject: New Version Notification for
>>> draft-ietf-fecframe-interleaved-fec-scheme-04
>>>>
>>>>
>>>> A new version of I-D,
>>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been
>>> successfuly submitted by Ali Begen and posted to the IETF
>> repository.
>>>>
>>>> Filename:      draft-ietf-fecframe-interleaved-fec-scheme
>>>> Revision:      04
>>>> Title:                 RTP Payload Format for 1-D
>>> Interleaved Parity FEC
>>>> Creation_date:         2009-04-29
>>>> WG ID:                 fecframe
>>>> Number_of_pages: 31
>>>>
>>>> Abstract:
>>>> This document defines a new RTP payload format for the
>> Forward Error
>>>> Correction (FEC) that is generated by the 1-D interleaved
>>> parity code
>>>> from a source media encapsulated in RTP.  The 1-D
>> interleaved parity
>>>> code is a systematic code, where a number of repair symbols are
>>>> generated from a set of source symbols and sent in a repair flow
>>>> separate from the source flow that carries the source
>> symbols.  The
>>>> 1-D interleaved parity code offers a good protection
>> against bursty
>>>> packet losses at a cost of decent complexity.  The new
>>> payload format
>>>> defined in this document is used (with some exceptions)
>> as a part of
>>>> the DVB Application-layer FEC specification.
>>>>
>>>
>>>>
>>>>
>>>> The IETF Secretariat.
>>>>
>>>>
>>>> _______________________________________________
>>>> Fecframe mailing list
>>>> Fecframe <at> ietf.org
>>>> https://www.ietf.org/mailman/listinfo/fecframe
>>>
>>>
>>
>>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt <at> ietf.org
> https://www.ietf.org/mailman/listinfo/avt

--

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

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 3 comments |
headers
Jonathan Lennox | 1 May 2009 17:38
Favicon

Re: [Fecframe] FW: New VersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04

The intention is to use ssrc-group (from
draft-ietf-mmusic-source-attributes) for ssrc grouping.

-- 
Jonathan Lennox
Vidyo, Inc
jonathan <at> vidyo.com

> -----Original Message-----
> From: Roni Even [mailto:ron.even.tlv <at> gmail.com]
> Sent: Friday, May 01, 2009 6:22 AM
> To: 'Colin Perkins'
> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft-
> ietf-fecframe-interleaved-fec-scheme-04
> 
> Colin,
> I am not sure that grouping will work when you have SSRC multiplexing
> and
> both the protected stream and the fec stream are in the same m-line,
> the mid
> attribute is per m-line
> 
> 
> Roni
> 
> -----Original Message-----
> From: Colin Perkins [mailto:csp <at> csperkins.org]
> Sent: Friday, May 01, 2009 12:27 PM
> To: Roni Even
> Cc: 'Ali C. Begen (abegen)'; avt <at> ietf.org; fecframe <at> ietf.org
> Subject: Re: [AVT] [Fecframe] FW: New Version Notification for
> draft-ietf-fecframe-interleaved-fec-scheme-04
> 
> On 1 May 2009, at 07:56, Roni Even wrote:
> > Hi Ali,
> > This is up to the WG to decide if they want to have support for SSRC
> > multiplexing and the implications of this support. I am not sure
> > what you mean by "we cannot have a parameter", I see only your view
> > on the list.
> 
> The grouping mechanism would seem to be sufficient. Why do we need a
> special-purpose mechanism, when we can reuse a general approach?
> 
> Colin
> 
> 
> 
> 
> > If only session multiplexing is allowed then the draft should
> > clearly state it and in this case I am not sure why you are
> > registering the video, audio and text media subtypes.
> >
> > Roni
> >
> > -----Original Message-----
> > From: Ali C. Begen (abegen) [mailto:abegen <at> cisco.com]
> > Sent: Friday, May 01, 2009 2:45 AM
> > To: Roni Even; vincent.roca <at> inrialpes.fr
> > Cc: avt <at> ietf.org; fecframe <at> ietf.org
> > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for
draft-
> > ietf-fecframe-interleaved-fec-scheme-04
> >
> > Hi Roni,
> >
> > Thanks for the references. However, we cannot have a parameter that
> > will relate the FEC stream to the source as RFC 4588 did with "apt"
> > since a lot of possibilities (multiple sources and/or multiple
> > repair flows) are possible with FEC. Instead, we use grouping and
> > this works just fine in session multiplexing.
> >
> > Regarding SSRC multiplexing of source and FEC streams, I don't think
> > giving an explicit example is needed or it is a good idea for this
> > draft since SSRC-level grouping is just introduced in 4756bis and it
> > will include such examples anyway (actually the version I submitted
> > today includes an example). We should better only provide session
> > multiplexing examples in this draft. This also emphasizes the
> > recommended way of doing FEC.
> >
> > Reg the registration of the media types and SDP mappings, I believe
> > the draft has the necessary details.
> >
> > BR,
> > -acbegen
> >
> >> -----Original Message-----
> >> From: Roni Even [mailto:ron.even.tlv <at> gmail.com]
> >> Sent: Thursday, April 30, 2009 1:03 PM
> >> To: Ali C. Begen (abegen); vincent.roca <at> inrialpes.fr
> >> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
> >> for draft-ietf-fecframe-interleaved-fec-scheme-04
> >>
> >> Ali,
> >> You can find examples in section 8.6 to 8.8 of RFC 4588,
> >> notice that there is an optional parameter for the rtx stream
> >> that defines the relation between the original and the rtx
> >> stream. Similar solution is also specified for redundant
> >> encoding red payload type (RFC 2198). You are offering both
> >> streams with different payload type numbers in the same m-line.
> >> In this case the media type must be video or audio same as
> >> the media type of the protected stream. This is why you
> >> needed the registration for type audio and video
> >>
> >> Roni
> >>
> >> -----Original Message-----
> >> From: Ali C. Begen (abegen) [mailto:abegen <at> cisco.com]
> >> Sent: Thursday, April 30, 2009 10:01 PM
> >> To: Roni Even; vincent.roca <at> inrialpes.fr
> >> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
> >> for draft-ietf-fecframe-interleaved-fec-scheme-04
> >>
> >> Hi Roni,
> >>
> >>> I noticed that the fec framework will allow SSRC
> >>
> >> Yes, it will not be the recommended way of using FEC, but it
> >> will be supported. The 4756bis draft also supports it now.
> >>
> >>> multiplexing, are you going to specify this in this draft in
> >>> the SDP offer answer section.
> >>
> >> I am not sure what I need to specify additionally in this
> >> section regarding SSRC multiplexing. Could you let me know if
> >> there is such an example?
> >>
> >>> Maybe you should also discuss when to use application media
> >>> type and when to use video or audio
> >>
> >> I believe the FEC is always application type, we did
> >> registration for video, audio, etc. since FEC could relate to
> >> sessions carrying such types.
> >>
> >> BR,
> >> -acbegen
> >>
> >>>
> >>>
> >>> Roni
> >>>
> >>>
> >>>
> >>> From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On
> >>> Behalf Of Ali C. Begen (abegen)
> >>> Sent: Thursday, April 30, 2009 3:54 PM
> >>> To: vincent.roca <at> inrialpes.fr
> >>> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification
> >>> for draft-ietf-fecframe-interleaved-fec-scheme-04
> >>>
> >>>
> >>>
> >>> Hi Vincent
> >>>
> >>> This draft is not an fec scheme so it is not related to fec
> >>> framework. It is an rtp payload format draft. The wglc has
> >>> been running almost a month now. If you have comments in this
> >>> perspective, pls submit them soon.
> >>>
> >>>
> >>>
> >>>
> >>> -acbegen
> >>>
> >>> ----- Original Message -----
> >>> From: Vincent Roca <vincent.roca <at> inrialpes.fr>
> >>> To: Ali C. Begen (abegen)
> >>> Cc: fecframe <at> ietf.org <fecframe <at> ietf.org>; avt <at> ietf.org
> >> <avt <at> ietf.org>
> >>> Sent: Thu Apr 30 03:58:35 2009
> >>> Subject: Re: [Fecframe] FW: New Version Notification for
> >>>  draft-ietf-fecframe-interleaved-fec-scheme-04
> >>>
> >>> Hello Ali,
> >>>
> >>> I'm not in favor of finalizing the WGLC for this document.
> >>> IMHO we must,
> >>> first of all, finalize the framework document itself.
> >>>
> >>> For instance, the terminology used by the interleaved-fec-scheme
I-
> D
> >>> (section 3.1.) is not in line with the terminology used by the
> >>> fecframe-framework-03 I-D (Section 2):
> >>>        "Source Flow"   vs. "Source data flow"
> >>>        "Repair Flow"   vs. "Repair data flow"
> >>>        "Source Symbol" vs. nothing
> >>>        "Repair Symbol" vs. nothing
> >>>        "Source Packet" vs. nothing
> >>>        "Repair Packet" vs. nothing
> >>> And as I said before, IMHO the terminology proposed in the
> framework
> >>> I-D should be discussed too.
> >>>
> >>> So let's do things in the right order, especially as the framework
> >>> WGLC finishes soon.
> >>>
> >>> Additionally, I may have some comments for the
> >>> interleaved-fec-scheme-04
> >>> I-D. Since I missed the WGLC deadline, you have the right to
> >>> blame me ;-)
> >>> and I apologize in advance.
> >>>
> >>> Regards,
> >>>
> >>>  Vincent
> >>>
> >>>
> >>> Ali C. Begen (abegen) wrote:
> >>>> This version addresses the comments received from fecframe
> >>> and avt so far.
> >>>>
> >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl
> >> eaved-fec-scheme-04.txt
> >>>>
> >>>>
> >>>> Fecframe chairs,
> >>>>
> >>>> Could we proceed and finalize WGLC?
> >>>>
> >>>> -acbegen
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org]
> >>>> Sent: Wednesday, April 29, 2009 2:56 PM
> >>>> To: Ali C. Begen (abegen)
> >>>> Subject: New Version Notification for
> >>> draft-ietf-fecframe-interleaved-fec-scheme-04
> >>>>
> >>>>
> >>>> A new version of I-D,
> >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been
> >>> successfuly submitted by Ali Begen and posted to the IETF
> >> repository.
> >>>>
> >>>> Filename:      draft-ietf-fecframe-interleaved-fec-scheme
> >>>> Revision:      04
> >>>> Title:                 RTP Payload Format for 1-D
> >>> Interleaved Parity FEC
> >>>> Creation_date:         2009-04-29
> >>>> WG ID:                 fecframe
> >>>> Number_of_pages: 31
> >>>>
> >>>> Abstract:
> >>>> This document defines a new RTP payload format for the
> >> Forward Error
> >>>> Correction (FEC) that is generated by the 1-D interleaved
> >>> parity code
> >>>> from a source media encapsulated in RTP.  The 1-D
> >> interleaved parity
> >>>> code is a systematic code, where a number of repair symbols are
> >>>> generated from a set of source symbols and sent in a repair flow
> >>>> separate from the source flow that carries the source
> >> symbols.  The
> >>>> 1-D interleaved parity code offers a good protection
> >> against bursty
> >>>> packet losses at a cost of decent complexity.  The new
> >>> payload format
> >>>> defined in this document is used (with some exceptions)
> >> as a part of
> >>>> the DVB Application-layer FEC specification.
> >>>>
> >>>
> >>>>
> >>>>
> >>>> The IETF Secretariat.
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Fecframe mailing list
> >>>> Fecframe <at> ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/fecframe
> >>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt <at> ietf.org
> https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 2 comments |
headers
Ali C. Begen (abegen | 1 May 2009 18:05
Picon
Favicon

Re: [Fecframe] FW: NewVersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04

Yes, this has been discussed in mmusic very recently and I updated the 4756bis draft accordingly.

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-02.txt

-acbegen  

> -----Original Message-----
> From: fecframe-bounces <at> ietf.org 
> [mailto:fecframe-bounces <at> ietf.org] On Behalf Of Jonathan Lennox
> Sent: Friday, May 01, 2009 8:38 AM
> To: Roni Even; Colin Perkins
> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> Subject: Re: [Fecframe] [AVT] FW: NewVersionNotification for 
> draft-ietf-fecframe-interleaved-fec-scheme-04
> 
> The intention is to use ssrc-group (from
> draft-ietf-mmusic-source-attributes) for ssrc grouping.
> 
> -- 
> Jonathan Lennox
> Vidyo, Inc
> jonathan <at> vidyo.com
> 
> 
> > -----Original Message-----
> > From: Roni Even [mailto:ron.even.tlv <at> gmail.com]
> > Sent: Friday, May 01, 2009 6:22 AM
> > To: 'Colin Perkins'
> > Cc: avt <at> ietf.org; fecframe <at> ietf.org
> > Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft-
> > ietf-fecframe-interleaved-fec-scheme-04
> > 
> > Colin,
> > I am not sure that grouping will work when you have SSRC 
> multiplexing
> > and
> > both the protected stream and the fec stream are in the same m-line,
> > the mid
> > attribute is per m-line
> > 
> > 
> > Roni
> > 
> > -----Original Message-----
> > From: Colin Perkins [mailto:csp <at> csperkins.org]
> > Sent: Friday, May 01, 2009 12:27 PM
> > To: Roni Even
> > Cc: 'Ali C. Begen (abegen)'; avt <at> ietf.org; fecframe <at> ietf.org
> > Subject: Re: [AVT] [Fecframe] FW: New Version Notification for
> > draft-ietf-fecframe-interleaved-fec-scheme-04
> > 
> > On 1 May 2009, at 07:56, Roni Even wrote:
> > > Hi Ali,
> > > This is up to the WG to decide if they want to have 
> support for SSRC
> > > multiplexing and the implications of this support. I am not sure
> > > what you mean by "we cannot have a parameter", I see only 
> your view
> > > on the list.
> > 
> > The grouping mechanism would seem to be sufficient. Why do we need a
> > special-purpose mechanism, when we can reuse a general approach?
> > 
> > Colin
> > 
> > 
> > 
> > 
> > > If only session multiplexing is allowed then the draft should
> > > clearly state it and in this case I am not sure why you are
> > > registering the video, audio and text media subtypes.
> > >
> > > Roni
> > >
> > > -----Original Message-----
> > > From: Ali C. Begen (abegen) [mailto:abegen <at> cisco.com]
> > > Sent: Friday, May 01, 2009 2:45 AM
> > > To: Roni Even; vincent.roca <at> inrialpes.fr
> > > Cc: avt <at> ietf.org; fecframe <at> ietf.org
> > > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for
> draft-
> > > ietf-fecframe-interleaved-fec-scheme-04
> > >
> > > Hi Roni,
> > >
> > > Thanks for the references. However, we cannot have a 
> parameter that
> > > will relate the FEC stream to the source as RFC 4588 did 
> with "apt"
> > > since a lot of possibilities (multiple sources and/or multiple
> > > repair flows) are possible with FEC. Instead, we use grouping and
> > > this works just fine in session multiplexing.
> > >
> > > Regarding SSRC multiplexing of source and FEC streams, I 
> don't think
> > > giving an explicit example is needed or it is a good idea for this
> > > draft since SSRC-level grouping is just introduced in 
> 4756bis and it
> > > will include such examples anyway (actually the version I 
> submitted
> > > today includes an example). We should better only provide session
> > > multiplexing examples in this draft. This also emphasizes the
> > > recommended way of doing FEC.
> > >
> > > Reg the registration of the media types and SDP mappings, 
> I believe
> > > the draft has the necessary details.
> > >
> > > BR,
> > > -acbegen
> > >
> > >> -----Original Message-----
> > >> From: Roni Even [mailto:ron.even.tlv <at> gmail.com]
> > >> Sent: Thursday, April 30, 2009 1:03 PM
> > >> To: Ali C. Begen (abegen); vincent.roca <at> inrialpes.fr
> > >> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
> > >> for draft-ietf-fecframe-interleaved-fec-scheme-04
> > >>
> > >> Ali,
> > >> You can find examples in section 8.6 to 8.8 of RFC 4588,
> > >> notice that there is an optional parameter for the rtx stream
> > >> that defines the relation between the original and the rtx
> > >> stream. Similar solution is also specified for redundant
> > >> encoding red payload type (RFC 2198). You are offering both
> > >> streams with different payload type numbers in the same m-line.
> > >> In this case the media type must be video or audio same as
> > >> the media type of the protected stream. This is why you
> > >> needed the registration for type audio and video
> > >>
> > >> Roni
> > >>
> > >> -----Original Message-----
> > >> From: Ali C. Begen (abegen) [mailto:abegen <at> cisco.com]
> > >> Sent: Thursday, April 30, 2009 10:01 PM
> > >> To: Roni Even; vincent.roca <at> inrialpes.fr
> > >> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification
> > >> for draft-ietf-fecframe-interleaved-fec-scheme-04
> > >>
> > >> Hi Roni,
> > >>
> > >>> I noticed that the fec framework will allow SSRC
> > >>
> > >> Yes, it will not be the recommended way of using FEC, but it
> > >> will be supported. The 4756bis draft also supports it now.
> > >>
> > >>> multiplexing, are you going to specify this in this draft in
> > >>> the SDP offer answer section.
> > >>
> > >> I am not sure what I need to specify additionally in this
> > >> section regarding SSRC multiplexing. Could you let me know if
> > >> there is such an example?
> > >>
> > >>> Maybe you should also discuss when to use application media
> > >>> type and when to use video or audio
> > >>
> > >> I believe the FEC is always application type, we did
> > >> registration for video, audio, etc. since FEC could relate to
> > >> sessions carrying such types.
> > >>
> > >> BR,
> > >> -acbegen
> > >>
> > >>>
> > >>>
> > >>> Roni
> > >>>
> > >>>
> > >>>
> > >>> From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On
> > >>> Behalf Of Ali C. Begen (abegen)
> > >>> Sent: Thursday, April 30, 2009 3:54 PM
> > >>> To: vincent.roca <at> inrialpes.fr
> > >>> Cc: avt <at> ietf.org; fecframe <at> ietf.org
> > >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification
> > >>> for draft-ietf-fecframe-interleaved-fec-scheme-04
> > >>>
> > >>>
> > >>>
> > >>> Hi Vincent
> > >>>
> > >>> This draft is not an fec scheme so it is not related to fec
> > >>> framework. It is an rtp payload format draft. The wglc has
> > >>> been running almost a month now. If you have comments in this
> > >>> perspective, pls submit them soon.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> -acbegen
> > >>>
> > >>> ----- Original Message -----
> > >>> From: Vincent Roca <vincent.roca <at> inrialpes.fr>
> > >>> To: Ali C. Begen (abegen)
> > >>> Cc: fecframe <at> ietf.org <fecframe <at> ietf.org>; avt <at> ietf.org
> > >> <avt <at> ietf.org>
> > >>> Sent: Thu Apr 30 03:58:35 2009
> > >>> Subject: Re: [Fecframe] FW: New Version Notification for
> > >>>  draft-ietf-fecframe-interleaved-fec-scheme-04
> > >>>
> > >>> Hello Ali,
> > >>>
> > >>> I'm not in favor of finalizing the WGLC for this document.
> > >>> IMHO we must,
> > >>> first of all, finalize the framework document itself.
> > >>>
> > >>> For instance, the terminology used by the interleaved-fec-scheme
> I-
> > D
> > >>> (section 3.1.) is not in line with the terminology used by the
> > >>> fecframe-framework-03 I-D (Section 2):
> > >>>        "Source Flow"   vs. "Source data flow"
> > >>>        "Repair Flow"   vs. "Repair data flow"
> > >>>        "Source Symbol" vs. nothing
> > >>>        "Repair Symbol" vs. nothing
> > >>>        "Source Packet" vs. nothing
> > >>>        "Repair Packet" vs. nothing
> > >>> And as I said before, IMHO the terminology proposed in the
> > framework
> > >>> I-D should be discussed too.
> > >>>
> > >>> So let's do things in the right order, especially as 
> the framework
> > >>> WGLC finishes soon.
> > >>>
> > >>> Additionally, I may have some comments for the
> > >>> interleaved-fec-scheme-04
> > >>> I-D. Since I missed the WGLC deadline, you have the right to
> > >>> blame me ;-)
> > >>> and I apologize in advance.
> > >>>
> > >>> Regards,
> > >>>
> > >>>  Vincent
> > >>>
> > >>>
> > >>> Ali C. Begen (abegen) wrote:
> > >>>> This version addresses the comments received from fecframe
> > >>> and avt so far.
> > >>>>
> > >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl
> > >> eaved-fec-scheme-04.txt
> > >>>>
> > >>>>
> > >>>> Fecframe chairs,
> > >>>>
> > >>>> Could we proceed and finalize WGLC?
> > >>>>
> > >>>> -acbegen
> > >>>>
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org]
> > >>>> Sent: Wednesday, April 29, 2009 2:56 PM
> > >>>> To: Ali C. Begen (abegen)
> > >>>> Subject: New Version Notification for
> > >>> draft-ietf-fecframe-interleaved-fec-scheme-04
> > >>>>
> > >>>>
> > >>>> A new version of I-D,
> > >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been
> > >>> successfuly submitted by Ali Begen and posted to the IETF
> > >> repository.
> > >>>>
> > >>>> Filename:      draft-ietf-fecframe-interleaved-fec-scheme
> > >>>> Revision:      04
> > >>>> Title:                 RTP Payload Format for 1-D
> > >>> Interleaved Parity FEC
> > >>>> Creation_date:         2009-04-29
> > >>>> WG ID:                 fecframe
> > >>>> Number_of_pages: 31
> > >>>>
> > >>>> Abstract:
> > >>>> This document defines a new RTP payload format for the
> > >> Forward Error
> > >>>> Correction (FEC) that is generated by the 1-D interleaved
> > >>> parity code
> > >>>> from a source media encapsulated in RTP.  The 1-D
> > >> interleaved parity
> > >>>> code is a systematic code, where a number of repair symbols are
> > >>>> generated from a set of source symbols and sent in a 
> repair flow
> > >>>> separate from the source flow that carries the source
> > >> symbols.  The
> > >>>> 1-D interleaved parity code offers a good protection
> > >> against bursty
> > >>>> packet losses at a cost of decent complexity.  The new
> > >>> payload format
> > >>>> defined in this document is used (with some exceptions)
> > >> as a part of
> > >>>> the DVB Application-layer FEC specification.
> > >>>>
> > >>>
> > >>>>
> > >>>>
> > >>>> The IETF Secretariat.
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> Fecframe mailing list
> > >>>> Fecframe <at> ietf.org
> > >>>> https://www.ietf.org/mailman/listinfo/fecframe
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > avt <at> ietf.org
> > > https://www.ietf.org/mailman/listinfo/avt
> > 
> > 
> > 
> > --
> > Colin Perkins
> > http://csperkins.org/
> > 
> > 
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Fecframe mailing list
> Fecframe <at> ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe
> 
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 0 comments |
headers
Bill Ver Steeg (versteb | 1 May 2009 19:39
Picon
Favicon

Re: Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS)as a working group item

It probably goes without saying, but I am very interested in moving this work forward.
 
Bill verSteeg

From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On Behalf Of Roni Even
Sent: Thursday, April 30, 2009 4:13 PM
To: avt <at> ietf.org
Cc: 'Tom Taylor'
Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS)as a working group item

Hi,

I would like to ask if there is interest to adopt Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 as the initial text for the work.

 

I would also like to suggest that Bill Versteeg will be the editor of the WG document if adopted.

 

Please send any feedback to the mailing list by Friday May 8th. If there will be a consensus we will accept this topic and have the above draft as the initial document.

 

Thanks

Roni Even

AVT co-chair

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 0 comments |
headers
Orit Levin | 1 May 2009 19:56
Picon
Favicon

Re: Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item

As a co-author of one of the earlier drafts on this subject, I support the adoption of the draft as a new WG item. It incorporates most of the requirements discussed and agreed upon so far and can also serve as a solid basis for extensions to the mechanism going forward.

 

Thanks,

Orit Levin.

 

From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On Behalf Of Roni Even
Sent: Thursday, April 30, 2009 1:13 PM
To: avt <at> ietf.org
Cc: 'Tom Taylor'
Subject: [AVT] Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item

 

Hi,

I would like to ask if there is interest to adopt Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item. The suggestion is to start the work using http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 as the initial text for the work.

 

I would also like to suggest that Bill Versteeg will be the editor of the WG document if adopted.

 

Please send any feedback to the mailing list by Friday May 8th. If there will be a consensus we will accept this topic and have the above draft as the initial document.

 

Thanks

Roni Even

AVT co-chair

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 0 comments |
headers
David R Oran | 1 May 2009 20:01
Picon
Favicon

Re: Adopting Rapid Acquisition of Multicast RTP Sessions (RAMS) as a working group item

On Apr 30, 2009, at 4:12 PM, Roni Even wrote:

> Hi,
> I would like to ask if there is interest to adopt Rapid Acquisition  
> of Multicast RTP Sessions (RAMS) as a working group item. The  
> suggestion is to start the work
usinghttp://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03 
>  as the initial text for the work.
>
For my part, yes.

>
> I would also like to suggest that Bill Versteeg will be the editor  
> of the WG document if adopted.
>
This is fne too.

>
> Please send any feedback to the mailing list by Friday May 8th. If  
> there will be a consensus we will accept this topic and have the  
> above draft as the initial document.
>
> Thanks
> Roni Even
> AVT co-chair
> _______________________________________________
> Audio/Video Transport Working Group
> avt <at> ietf.org
> https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply | 0 comments |

Gmane