Re: [AVT] Comments on draft-ietf-text-red-00.txt

Magnus,

> I have had some off-line discussion regarding the MIME registration
> problem for text/RED. Know understanding the intention having the
> ordering requirement on RFC 2198 being firm for the "pt" list, I would
> propose the following text change for the "pt" list:
>
> "pt: a comma-separated ordered list enumerating the primary, secondary,
> etc., encoding's RTP payload types in accordance with RFC 2198.  Because
> comma is ..."

There was a desire early on not to explicitly tie the MIME registration to
RFC 2198.  Certainly, it is the main driver for producing the document, but
it was viewed as not the only potential user of this registration.  Thus, do
we really want this text or just leave it as it is in the current draft?

> Then one addition to the SDP section (4) is also needed in my opinion.
> Please add the following text where appropriate.
>
> "For each redundancy payload type defined the ordering of the primary,
> and redundancy encoding(s) are fixed. If more than one combination of
> primary, and redundancy encoding(s) are desired, multiple redundancy
> payload types needs to be defined."

Perhaps you can educate me here, but why would the order matter?  The
payload format defined in RFC 2198 allows for the PT of the redundant data
to be specified along with the payload.  Thus, it seems that the ordering of
is not so important.  Of course, a distinction must be made between primary
versus redundant, but it is not clear to me why this strict clause is
needed. Please clarify.

> Then only the last issue below remains to be resolved as I see it.

And, how can we close on that issue below?

Paul

>
> Cheers
>
> Magnus
>
> Magnus Westerlund wrote:
>
> >
> >>>>
> >>>
> >>> When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the
> >>> pt=content-type structure at all. As the information is available in
> >>>
> >>
> >> the
> >>
> >>
> >>> SDP as defined PT. Therefore you only need to reference these PTs. So
> >>> when having SDP should you in fact remove all of these pt=content-type
> >>> declarations and only use PTs in the list?
> >>>
> >>> I would also like to point out that the this declaration of
> >>> "dynamic-payload-type "=" content-type" is not sufficiently clear. For
> >>> RTP payload formats using parameters to configure this, this string is
> >>> insufficient unless the parameter list can be included in the
> >>> content-type part.
> >>>
> >>
> >>
> >> Ah, I understand.  As I mentioned above, this follows the example in
RFC
> >> 3555, which also does not go into discussion on this (as far as I
know).
> >> I
> >> assume the reason for that was simply that the entire focus was on SDP,
> >> anyway, with little focus on MIME, really.
> >>
> >> In any case, I can add text in this regard, but I need some guidance as
> >> to
> >> what we should have inserted to make this clearer.
> >>
> >>
> >>
> > I would definitely like to have some more input from Colin and others
> > about how this problem should be resolved.
> >
>
> -- 
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>
>

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