From fecframe-bounces@ietf.org Tue Dec 9 10:19:08 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA46728C11E; Tue, 9 Dec 2008 10:19:08 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E43B3A6B42; Tue, 9 Dec 2008 10:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[AWL=-1.909, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geXC7ED+R7p8; Tue, 9 Dec 2008 10:19:05 -0800 (PST) Received: from mr1.dcs.gla.ac.uk (mr1.dcs.gla.ac.uk [130.209.249.184]) by core3.amsl.com (Postfix) with ESMTP id B12713A69F2; Tue, 9 Dec 2008 10:19:04 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71]:62451 helo=[192.168.254.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1LA7Af-000084-AU; Tue, 09 Dec 2008 18:18:57 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <30C07EFF-2957-4427-92AA-58928687C260@csperkins.org> From: Colin Perkins Date: Tue, 9 Dec 2008 18:18:21 +0000 To: Mark Watson X-Mailer: Apple Mail (2.753.1) Cc: avt@ietf.org, "fecframe@ietf.org" Subject: Re: [Fecframe] Question from FECFRAME about RTP Payload Format Parameters X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1209559212==" Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org --===============1209559212== Content-Type: multipart/alternative; boundary=Apple-Mail-2--716085033 --Apple-Mail-2--716085033 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Mark, RTP payload formats are named using media subtypes, which have =20 associated media subtype parameters. Those parameters are conveyed =20 in SDP using the "a=3Dfmtp:" line. If you're designing an RTP payload =20= format, it should use that standard mechanism for naming the format =20 and conveying its parameters. The FEC-scheme-specific information =20 would be one of those parameters, I assume, carried in the "a=3Dfmtp:" =20= line. Colin On 17 Nov 2008, at 18:21, Mark Watson wrote: > All, > > The following question was discussed at FECFRAME and it was =20 > suggested to take this to AVT as well. > > FECFRAME has defined an SDP attribute to carry information about =20 > FEC repair flows which is specific to the particular FEC Scheme =20 > being used. This attribute contains an =91opaque=92 container which =20= > contains FEC-Scheme-specific information that is supposed to be =20 > handled by the FEC scheme. This is a generic mechanism which could =20 > be applied whether the FEC repair data is carried over RTP or =20 > directly over UDP. > > In the case that RTP is used for repair data, then RTP Payload =20 > Format must be defined for the FEC Scheme in the usual way. In this =20= > context we have the possibility to define RTP Payload Format =20 > parameters which would then be carried in the a=3Dfmtp SDP parameter. > > The question under discussion is whether we should define RTP =20 > Payload Format parameters at all, or whether we can use the FEC =20 > Framework SDP attribute in the RTP context just as it is used for =20 > repair data carried over UDP. > > The advantage of defining RTP Payload Format Parameters is that =20 > this is the standard and recognised way of communicating parameters =20= > which are needed to process data carried in an RTP Payload. > > The disadvantage of defining RTP Payload Format Parameters is that =20 > we essentially end up with two mechanisms for carrying the same =20 > information and this causes additional implementation work and =20 > potential for confusion about which mechanism should be used when. > > An example of SDP using the FECFRAME attribute would be: > > v=3D0 > o=3Dali 1122334455 1122334466 IN IP4 fec.example.com > t=3D0 0 > a=3Dgroup:FEC S1 R1 > m=3Dvideo 30000 RTP/AVP 100 > c=3DIN IP4 224.1.1.1/127 > a=3Drtpmap:100 MP2T/90000 > a=3Dmid:S1 > m=3Dapplication 30000 RTP/AVP 110 > c=3DIN IP4 224.1.2.1/127 > a=3Drtpmap:110 raptorfec/90000 > a=3Dfec-repair-flow: encoding-id=3D0; fssi=3D4W5S6X > a=3Drepair-window: 200 ms > a=3Dmid:R1 > > And an example using RTP Payload Format Parameters would be: > > v=3D0 > o=3Dali 1122334455 1122334466 IN IP4 fec.example.com > t=3D0 0 > a=3Dgroup:FEC S1 R1 > m=3Dvideo 30000 RTP/AVP 100 > c=3DIN IP4 224.1.1.1/127 > a=3Drtpmap:100 MP2T/90000 > a=3Dmid:S1 > m=3Dapplication 30000 RTP/AVP 110 > c=3DIN IP4 224.1.2.1/127 > a=3Drtpmap:110 raptorfec/90000 > a=3Dfmtp:110 sbl=3D1231; symbol-size=3D96; repair-window=3D200ms= > a=3Dmid:R1 > > FECFRAME would like to hear opinions from AVT on this question. > > Regards, > > Mark Watson > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-2--716085033 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Mark,

RTP payload formats are named using media = subtypes, which have associated media subtype parameters. =A0Those = parameters are conveyed in SDP using the "a=3Dfmtp:" line. =A0If you're = designing an RTP payload format, it should use that standard mechanism = for naming the format and conveying its parameters. The = FEC-scheme-specific information would be one of those parameters, I = assume, carried in the "a=3Dfmtp:" = line.

Colin



On 17 Nov 2008, at 18:21, Mark Watson = wrote:
All,

The following = question was discussed at FECFRAME and it was suggested to take this to = AVT as well.

FECFRAME has defined an SDP attribute to carry = information about FEC repair flows which is specific to the particular = FEC Scheme being used. This attribute contains an =91opaque=92 container = which contains FEC-Scheme-specific information that is supposed to be = handled by the FEC scheme. This is a generic mechanism which could be = applied whether the FEC repair data is carried over RTP or directly over = UDP.

In the case that RTP is used for repair data, then RTP = Payload Format must be defined for the FEC Scheme in the usual way. In = this context we have the possibility to define RTP Payload Format = parameters which would then be carried in the a=3Dfmtp SDP = parameter.

The question under discussion is whether we should = define RTP Payload Format parameters at all, or whether we can use the = FEC Framework SDP attribute in the RTP context just as it is used for = repair data carried over UDP.

The advantage of defining RTP = Payload Format Parameters is that this is the standard and recognised = way of communicating parameters which are needed to process data carried = in an RTP Payload.

The disadvantage of defining RTP Payload = Format Parameters is that we essentially end up with two mechanisms for = carrying the same information and this causes additional implementation = work and potential for confusion about which mechanism should be used = when.

An example of SDP using the FECFRAME attribute would = be:

 =A0=A0=A0=A0=A0=A0=A0v=3D0<= br> =A0=A0=A0=A0=A0=A0=A0=A0o=3Dali 1122334455 1122334466 IN IP4 = fec.example.com
=A0=A0=A0=A0=A0=A0=A0=A0t=3D0 0
= =A0=A0=A0=A0=A0=A0=A0=A0a=3Dgroup:FEC S1 R1
=A0=A0=A0=A0=A0=A0=A0=A0m=3D= video 30000 RTP/AVP 100
=A0=A0=A0=A0=A0=A0=A0=A0c=3DIN IP4 = 224.1.1.1/127
=A0=A0=A0=A0=A0=A0=A0=A0a=3Drtpmap:100 MP2T/90000
= =A0=A0=A0=A0=A0=A0=A0=A0a=3Dmid:S1
= =A0=A0=A0=A0=A0=A0=A0=A0m=3Dapplication 30000 RTP/AVP 110
= =A0=A0=A0=A0=A0=A0=A0=A0c=3DIN IP4 224.1.2.1/127
= =A0=A0=A0=A0=A0=A0=A0=A0a=3Drtpmap:110 raptorfec/90000
= =A0=A0=A0=A0=A0=A0=A0=A0a=3Dfec-repair-flow: encoding-id=3D0; = fssi=3D4W5S6X
=A0=A0=A0=A0=A0=A0=A0=A0a=3Drepair-window: 200 ms
= =A0=A0=A0=A0=A0=A0=A0=A0a=3Dmid:R1

And = an example using RTP Payload Format Parameters would be:

= =A0=A0=A0=A0=A0=A0=A0=A0v=3D0
=A0=A0=A0=A0=A0=A0=A0=A0o=3Dali = 1122334455 1122334466 IN IP4 fec.example.com
=A0=A0=A0=A0=A0=A0=A0=A0t= =3D0 0
=A0=A0=A0=A0=A0=A0=A0=A0a=3Dgroup:FEC S1 R1
= =A0=A0=A0=A0=A0=A0=A0=A0m=3Dvideo 30000 RTP/AVP 100
=A0=A0=A0=A0=A0=A0= =A0=A0c=3DIN IP4 224.1.1.1/127
=A0=A0=A0=A0=A0=A0=A0=A0a=3Drtpmap:100 = MP2T/90000
=A0=A0=A0=A0=A0=A0=A0=A0a=3Dmid:S1
=A0=A0=A0=A0=A0=A0=A0=A0m=3Dapplication = 30000 RTP/AVP 110
=A0=A0=A0=A0=A0=A0=A0=A0c=3DIN IP4 = 224.1.2.1/127
=A0=A0=A0=A0=A0=A0=A0=A0a=3Drtpmap:110 = raptorfec/90000
=A0=A0=A0=A0=A0=A0=A0=A0a=3Dfmtp:110 sbl=3D1231; = symbol-size=3D96; repair-window=3D200ms
=A0=A0=A0=A0=A0=A0=A0=A0a=3Dmid:R1

FECFRAME would like to hear = opinions from AVT on this question.

Regards,

Mark = Watson
Fecframe mailing list

=


--=A0
Co= lin Perkins


 =

= --Apple-Mail-2--716085033-- --===============1209559212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe --===============1209559212==-- From fecframe-bounces@ietf.org Tue Dec 9 14:07:39 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB30528C18A; Tue, 9 Dec 2008 14:07:39 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D686828C187; Tue, 9 Dec 2008 14:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.865 X-Spam-Level: *** X-Spam-Status: No, score=3.865 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlRaMQaP6Dgx; Tue, 9 Dec 2008 14:07:31 -0800 (PST) Received: from server515.appriver.com (server515i.exghost.com [72.32.253.75]) by core3.amsl.com (Postfix) with ESMTP id 2912328C18A; Tue, 9 Dec 2008 14:07:31 -0800 (PST) Received: from FE1.exchange.rackspace.com ([72.32.49.5] verified) by server515.appriver.com (CommuniGate Pro SMTP 5.2.8) with ESMTP id 107032737; Tue, 09 Dec 2008 16:07:17 -0600 Received: from 34093-C4-EVS1.exchange.rackspace.com ([192.168.1.91]) by FE1.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Dec 2008 16:07:25 -0600 Received: from 68.167.207.221 ([68.167.207.221]) by 34093-C4-EVS1.exchange.rackspace.com ([192.168.1.101]) via Exchange Front-End Server owa.mailseat.com ([192.168.1.79]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Dec 2008 22:07:24 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 09 Dec 2008 14:07:23 -0800 From: Mark Watson To: Roni Even , 'Colin Perkins' Message-ID: Thread-Topic: [AVT] [Fecframe] Question from FECFRAME about RTP Payload Format Parameters Thread-Index: AclaKqwkzM22C1QuS0mRlk85Da7Q8AAC0kewAAUjdbI= In-Reply-To: <493ecf1f.05ae660a.75be.209a@mx.google.com> Mime-version: 1.0 X-OriginalArrivalTime: 09 Dec 2008 22:07:25.0331 (UTC) FILETIME=[84780E30:01C95A4A] Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] Question from FECFRAME about RTP Payload Format Parameters X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1551854574==" Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1551854574== Content-type: multipart/alternative; boundary="B_3311676443_1773904" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3311676443_1773904 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Roni, Colin, I guess I should clarify that the FECFRAME SDP attributes will be defined i= n any case because they are needed for flows which are signaled in SDP but which do not use RTP. In the case that RTP is used, then, we have the choice of using the FECFRAM= E attributes or using RTP Payload Format parameters. To be honest, my feeling is that it is not very clean either way: either we break the RTP convention (or rule?) that all the required information to interpret the payload is available in the RTP Payload Format Parameters or we have duplicate ways to signal the same information. Colin=B9s mail suggests we could define an RTP Payload Format parameter to carry the scheme-specific information in the same way that the FECFRAME SDP attribute does (as a base64-encoded octet string) and then all FECFRAME RTP Payload Formats could use the same parameter. But I wonder whether the advantage of this is marginal compared to the advantage of the parameters being clearly visible in the SDP. Regards, Mark On 12/9/08 12:03 PM, "Roni Even" wrote: > Hi, > Just to emphasis Colin email. > If raptorfec is a the payload format you want to standardize than it can = have > parameters specified for this payload type and conveyed in fmtp line. > =20 > The first example is using the generic SDP parameters approach and you wi= ll > need to specify the semantics for session and media level usage of the > parameters. I noticed that it is different from > draft-begen-fecframe-sdp-elements-00. This solution will need to register= the > parameter and I assume they will relate to a registered scheme id as spec= ified > in the begen draft. > =20 > Both will work and it depends what approach you are using. > =20 > Roni Even > =20 > =20 > =20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Col= in > Perkins > Sent: Tuesday, December 09, 2008 8:18 PM > To: Mark Watson > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] Question from FECFRAME about RTP Payload Fo= rmat > Parameters > =20 > Mark, >=20 > =20 >=20 > RTP payload formats are named using media subtypes, which have associated > media subtype parameters. Those parameters are conveyed in SDP using the > "a=3Dfmtp:" line. If you're designing an RTP payload format, it should use= that > standard mechanism for naming the format and conveying its parameters. Th= e > FEC-scheme-specific information would be one of those parameters, I assum= e, > carried in the "a=3Dfmtp:" line. >=20 > =20 >=20 > Colin >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On 17 Nov 2008, at 18:21, Mark Watson wrote: >> All, >>=20 >> The following question was discussed at FECFRAME and it was suggested to= take >> this to AVT as well. >>=20 >> FECFRAME has defined an SDP attribute to carry information about FEC rep= air >> flows which is specific to the particular FEC Scheme being used. This >> attribute contains an =8Copaque=B9 container which contains FEC-Scheme-speci= fic >> information that is supposed to be handled by the FEC scheme. This is a >> generic mechanism which could be applied whether the FEC repair data is >> carried over RTP or directly over UDP. >>=20 >> In the case that RTP is used for repair data, then RTP Payload Format mu= st be >> defined for the FEC Scheme in the usual way. In this context we have the >> possibility to define RTP Payload Format parameters which would then be >> carried in the a=3Dfmtp SDP parameter. >>=20 >> The question under discussion is whether we should define RTP Payload Fo= rmat >> parameters at all, or whether we can use the FEC Framework SDP attribute= in >> the RTP context just as it is used for repair data carried over UDP. >>=20 >> The advantage of defining RTP Payload Format Parameters is that this is = the >> standard and recognised way of communicating parameters which are needed= to >> process data carried in an RTP Payload. >>=20 >> The disadvantage of defining RTP Payload Format Parameters is that we >> essentially end up with two mechanisms for carrying the same information= and >> this causes additional implementation work and potential for confusion a= bout >> which mechanism should be used when. >>=20 >> An example of SDP using the FECFRAME attribute would be: >>=20 >> v=3D0 >> o=3Dali 1122334455 1122334466 IN IP4 fec.example.com >> t=3D0 0 >> a=3Dgroup:FEC S1 R1 >> m=3Dvideo 30000 RTP/AVP 100 >> c=3DIN IP4 224.1.1.1/127 >> a=3Drtpmap:100 MP2T/90000 >> a=3Dmid:S1 >> m=3Dapplication 30000 RTP/AVP 110 >> c=3DIN IP4 224.1.2.1/127 >> a=3Drtpmap:110 raptorfec/90000 >> a=3Dfec-repair-flow: encoding-id=3D0; fssi=3D4W5S6X >> a=3Drepair-window: 200 ms >> a=3Dmid:R1 >>=20 >> And an example using RTP Payload Format Parameters would be: >>=20 >> v=3D0 >> o=3Dali 1122334455 1122334466 IN IP4 fec.example.com >> t=3D0 0 >> a=3Dgroup:FEC S1 R1 >> m=3Dvideo 30000 RTP/AVP 100 >> c=3DIN IP4 224.1.1.1/127 >> a=3Drtpmap:100 MP2T/90000 >> a=3Dmid:S1 >> m=3Dapplication 30000 RTP/AVP 110 >> c=3DIN IP4 224.1.2.1/127 >> a=3Drtpmap:110 raptorfec/90000 >> a=3Dfmtp:110 sbl=3D1231; symbol-size=3D96; repair-window=3D200ms >> a=3Dmid:R1 >>=20 >> FECFRAME would like to hear opinions from AVT on this question. >>=20 >> Regards, >>=20 >> Mark Watson >>=20 >> _______________________________________________ >>=20 >> Fecframe mailing list >>=20 >> Fecframe@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/fecframe > =20 >=20 > =20 --B_3311676443_1773904 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [AVT] [Fecframe] Question from FECFRAME about RTP Payload Format= Parameters Roni,= Colin,

I guess I should clarify that the FECFRAME SDP attributes will be defined i= n any case because they are needed for flows which are signaled in SDP but w= hich do not use RTP.

In the case that RTP is used, then, we have the choice of using the FECFRAM= E attributes or using RTP Payload Format parameters.

To be honest, my feeling is that it is not very clean either way: either= we break the RTP convention (or rule?) that all the required informatio= n to interpret the payload is available in the RTP Payload Format Parameters= or we have duplicate ways to signal the same information.

Colin’s mail suggests we could define an RTP Payload Format parameter= to carry the scheme-specific information in the same way that the FECFRAME = SDP attribute does (as a base64-encoded octet string) and then all FECFRAME = RTP Payload Formats could use the same parameter. But I wonder whether the a= dvantage of this is marginal compared to the advantage of the parameters bei= ng clearly visible in the SDP.

Regards,

Mark

On 12/9/08 12:03 PM, "Roni Even" <ron.even.tlv@gmail.com> w= rote:

Hi,
Just to emphasis Colin email.
If rapto= rfec is a the payload format you want to standardize than it can have parame= ters specified for this payload type and conveyed in fmtp line.
 
The first example is using the generic SDP parameters approach and you will= need to specify the semantics for session and media level usage of the para= meters. I noticed that it is different from draft-begen-fecframe-sdp-element= s-00. This solution will need to register the parameter and I assume they wi= ll relate to a registered scheme id as specified in the begen draft.
 
Both will work and it depends what approach you are using.
 
Roni Even
=
 

From: avt-bounc= es@ietf.org [mailto:avt-bounces@ietf.= org] On Behalf Of Colin Perkins
Sent: Tuesday, December 09, 2008 8:18 PM
To: Mark Watson
Cc: avt@ietf.org; fecframe@ietf.org
Subject: Re: [AVT] [Fecframe] Question from FECFRAME about RTP Paylo= ad Format Parameters
Mark,

 

RTP payload formats are named using media subtypes, which have associated m= edia subtype parameters.  Those parameters are conveyed in SDP using th= e "a=3Dfmtp:" line.  If you're designing an RTP payload format,= it should use that standard mechanism for naming the format and conveying i= ts parameters. The FEC-scheme-specific information would be one of those par= ameters, I assume, carried in the "a=3Dfmtp:" line.

 

Colin

 

 

 

On 17 Nov 2008, at 18:21, Mark Watson wrote:
All,

The following question was discussed at FECFRAME and it was suggested to ta= ke this to AVT as well.

FECFRAME has defined an SDP attribute to carry information about FEC repair= flows which is specific to the particular FEC Scheme being used. This attri= bute contains an ‘opaque’ container which contains FEC-Scheme-sp= ecific information that is supposed to be handled by the FEC scheme. This is= a generic mechanism which could be applied whether the FEC repair data is c= arried over RTP or directly over UDP.

In the case that RTP is used for repair data, then RTP Payload Format must = be defined for the FEC Scheme in the usual way. In this context we have the = possibility to define RTP Payload Format parameters which would then be carr= ied in the a=3Dfmtp SDP parameter.

The question under discussion is whether we should define RTP Payload Forma= t parameters at all, or whether we can use the FEC Framework SDP attribute i= n the RTP context just as it is used for repair data carried over UDP.

The advantage of defining RTP Payload Format Parameters is that this is the= standard and recognised way of communicating parameters which are needed to= process data carried in an RTP Payload.

The disadvantage of defining RTP Payload Format Parameters is that we essen= tially end up with two mechanisms for carrying the same information and this= causes additional implementation work and potential for confusion about whi= ch mechanism should be used when.

An example of SDP using the FECFRAME attribute would be:

       v=3D0
        o=3Dali 1122334455 1122334466= IN IP4 fec.example.com
        t=3D0 0
        a=3Dgroup:FEC S1 R1
        m=3Dvideo 30000 RTP/AVP 100         c=3DIN IP4 224.1.1.1/127
        a=3Drtpmap:100 MP2T/90000
        a=3Dmid:S1
        m=3Dapplication 30000 RTP/AVP= 110
        c=3DIN IP4 224.1.2.1/127
        a=3Drtpmap:110 raptorfec/9000= 0
        a=3Dfec-repair-flow: encoding= -id=3D0; fssi=3D4W5S6X
        a=3Drepair-window: 200 ms
        a=3Dmid:R1

And an example using RTP Payload Format Parameters would be:

        v=3D0
        o=3Dali 1122334455 1122334466= IN IP4 fec.example.com
        t=3D0 0
        a=3Dgroup:FEC S1 R1
        m=3Dvideo 30000 RTP/AVP 100         c=3DIN IP4 224.1.1.1/127
        a=3Drtpmap:100 MP2T/90000
        a=3Dmid:S1
        m=3Dapplication 30000 RTP/AVP= 110
        c=3DIN IP4 224.1.2.1/127
        a=3Drtpmap:110 raptorfec/9000= 0
        a=3Dfmtp:110 sbl=3D1231; symbol= -size=3D96; repair-window=3D200ms
        a=3Dmid:R1

FECFRAME would like to hear opinions from AVT on this question.

Regards,

Mark Watson

_______________________________________________

Fecframe mailing list

Fecframe@ietf.org

https://www.ietf.org/mailman/listinfo/fecframe

--B_3311676443_1773904-- --===============1551854574== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe --===============1551854574==-- From fecframe-bounces@ietf.org Wed Dec 17 12:19:32 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF5A28C1FB; Wed, 17 Dec 2008 12:19:32 -0800 (PST) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B25428C1FB for ; Wed, 17 Dec 2008 12:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+IL6t2xH7BC for ; Wed, 17 Dec 2008 12:19:31 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id D137728C1DC for ; Wed, 17 Dec 2008 12:19:30 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 13977852 for fecframe@ietf.org; Wed, 17 Dec 2008 15:19:22 -0500 Message-Id: <02D92818-FF7C-40EB-847F-E12039308B2E@multicasttech.com> From: Marshall Eubanks To: fecframe@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 15:19:22 -0500 References: <20081217201449.C972328C1E4@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Subject: [Fecframe] Fwd: 74th IETF - Registration X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org FYI Begin forwarded message: > From: IETF Secretariat > Date: December 17, 2008 3:14:49 PM EST > To: IETF Announcement list > Cc: irsg@isi.edu, wgchairs@ietf.org, bofchairs@ietf.org > Subject: 74th IETF - Registration > > 74th IETF Meeting > San Francisco, CA, USA > March 22-27, 2009 > Host: Juniper Networks > > Registration is now open for the 74th IETF Meeting! > > You can register on line at: > http://www.ietf.org/meetings/74/ > > REGISTRATION INFORMATION: > Early-Bird Registration - USD 635.00 > If you register and pay for your attendance to the IETF-74 before > Friday, > 13 March 2009 at 17:00 PDT (24:00 UTC/GMT), you will pay the early- > bird > price of USD 635.00. > > After Early-Bird cutoff - USD 785.00 > You can still register and pay online at USD 785.00 until Friday, 20 > March 2009 at 17:00 PDT (24:00 UTC/GMT). > > Full-time Student Registrations - USD 150.00 > Full-time students with proper ID are eligible to receive a special > USD > 150.00 student rate. Student rate is not subject to any late-fees. > Students will also be able to register on-site at the special student > rate. Failure to provide valid student ID on-site will revoke the > special > student status. > > Experimental New Feature: Optional Attendee Profile URL > When you register for the meeting, you will have the option to > provide a > personal profile URL as part of your registration information. The > intent > is to enable attendees to share additional information about > themselves. > The link is your choice - to your own website, or to your profile on > LinkedIn or any of the other professional networking websites. This > is > strictly voluntary and has been put in place as a way to facilitate > networking and relationship building among interested attendees. > > Your profile will be part of an enhanced online attendee list that is > only available to other IETF meeting registrants. A registration ID > (which you receive via email once you register) and your email address > will be required to view the profile information. Anyone who has not > registered for the meeting will only see the usual online attendee > list, > which does not include the profile information. > > CANCELLATION: > The cut-off for registration cancellation is Monday, 16 March 2009 at > 17:00 PDT (24:00 UTC/GMT). Cancellations are subject to a 10% (ten > percent) cancellation fee if requested by that date and time. > > ON-SITE REGISTRATION: > You can register onsite at the meeting in San Francisco, CA starting > Sunday, 22 March 2009 at 12:00 noon PDT (local San Francisco Time). > > The IETF meetings start Monday morning and run through Friday at 15:15 > PDT, with late scheduling changes. Most training sessions take place > on > Sunday afternoon 22 March 2009. Participants should plan their travel > accordingly. > > The IETF Secretariat > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe