RE: [AVT] Reminder: WG Last Call: draft-ietf-avt-text-red-02.txt

["Gunnar Hellstrom" <gunnar.hellstrom at omnitor.se>]

I think it is OK to not detail the offer/answer aspects of the length of
the pt parameter list for expressing desired redundancy level.

One more thing I weant to be sure of, is that there is a good description
of the exact mapping of the position in the pt list to the level of
redundancy.

I still doubt that this is how RFC2198 is used in reality. I have even got
the impression that RFC2198 is used to get a chance to express alternative
or even complementary codings of the same sample sent in the same packet.
Is that how RFC2833 is transmitted? As alternate codings in the same packet
as the original audio coded sample is?

If that has become a habit, the use of fmtp for rfc 2198 audio should
reflect that, and there would be no reason to do anything else for
text-red.

Please note that there is an  draft-ietf-avt-text-red-03.txt out there at
http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-03.txt



Regards

Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom@Omnitor.se
--------------------------------------------


> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Monday, April 26, 2004 10:48 AM
> To: Gunnar Hellstrom
> Cc: IETF AVT WG; Magnus Westerlund
> Subject: Re: [AVT] Reminder: WG Last Call:
> draft-ietf-avt-text-red-02.txt
>
>
> On 11 Apr 2004, at 06:46, Gunnar Hellstrom wrote:
> > There has been a good discussion in the avt list about the use of the
> > a=fmtp parameter for text-red. The discussion has been linked to the
> > parallell work with real time text transmission in RFC2793bis, but is
> > valid
> > for text-red and should possibly influence the text-red draft slightly.
> >
> > Here are my review of text-red-02 including the result of the
> > discussion on
> > a=fmtp:
> >
> > 1. In section 4, there is this sentence:
> > "Any dynamic payload type in the list MUST NOT include its content-
> >    type only the payload type number."
> > The "type only" comes out a bit strange. I suggest rewording to what
> > you
> > shall do:
> > "Any dynamic payload type in the list MUST be represented by its
> > payload
> > type number and not by its content-type."
>
> okay
>
> > 2. The offer-answer aspects of the a=fmtp parameter
> > In a separate mail in the avt thread discussing a=fmtp for RFC2198, I
> > enter
> > offer-answer considerations for the a=fmtp parameter and suggest that
> > this
> > sentence is included in the sdp mapping section of text-red spec:
> >
> > "In an offer/answer situation, the fmtp parameter in the answer MAY
> > describe a different number of redundant levels than in the offer. The
> > session SHOULD use the highest number of redundant levels described."
>
> I don't think this is appropriate due to the problem of asymmetric loss
> we've previously discussed. I would suggest that the "text/red"
> registration remain silent about this issue, and that we consider
> offer/answer considerations for redundant audio when RFC 2198 is
> revised for Draft Standard. This will ensure that we have consistent
> specifications for all uses of the format.
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>



_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt