Subject: [AVT] Re: maxptime (and rtp-mime, AMR and EVRC drafts)

From: Stephen Casner <[email-masked]>
Date: Thu, 30 Aug 2001 19:12:53 -0700 (PDT)

This is a followup to emails on the confctrl (MMUSIC) mailing list
regarding the a=maxptime attribute in SDP.  I'm cc'ing avt because it
affects three drafts there which need changes:

  draft-ietf-avt-rtp-mime-05.txt
  draft-ietf-avt-rtp-amr-10.txt (in AD review after IESG Last Call)
  draft-ietf-avt-evrc-07.txt (in AVT WG last call)

Magnus Westerlund started the exchange by noting that in London at the
MMUSIC meeting there was discussion concerning whether the new SDP
attribute maxptime was not backwards compatible for payload formats
that were standardized before maxptime was defined.  The potential
problem is that a sender that did not understand maxptime would ignore
it and might send more than the receiver was prepared to receive.  It
was suggested that a sentence like the following be added to the the
SDP update draft:

"Note that this attribute is introduced after RFC 2327, and non updated
implementations will ignore this attribute."

Flemming Andreasen commented that doing something like this was
essentially the conclusion of the MMUSIC discussion.  Colin Perkins
has not commented on adding this, though.

QUESTION:  Is it a problem that draft-ietf-avt-rtp-mime-05.txt added
maxptime as an optional parameter for all the MIME registrations it
contains?  If we decide that use of maxptime should be allowed for all
payload formats, then perhaps some sentence like the one quoted above
needs to be added to the rtp-mime draft as well.

A side point that was clarified by Colin Perkins in the confctrl
discussion was that "a=maxptime" is an attribute by itself and cannot
be included as a parameter on the "fmtp" line.  This affects both the
AMR and EVRC drafts which require fixes:

  - The AMR draft mentions "maxptime" only in the MIME registrations.
    The use there is OK.  However, the editing to replace the
    "maxframes" with "maxptime" was incomplete because the SDP
    examples still show "maxframes" in two places.  Considering the
    point above, this must be edited, for example:

    Old:    a=fmtp:99 maxframes=3; interleaving=15
    New:    a=fmtp:99 interleaving=15
	    a=maxptime:60

    Since the AMR draft is in AD review, we should bring this to
    Allison's attention and possibly submit a revised draft unless she
    would prefer to wait to see if she has comments about other things
    to change.

  - The EVRC draft says consistently uses "maxptime", but it needs to
    move:

    Old:    a = fmtp:97 ptype=1; maxptime=80
    Old:    a=fmtp:97 ptype=1
	    a=maxptime:80

    In addition, the EVRC draft begins the example with the statement
    "Parameters are mapped to SDP [5] as usual."  I don't think "as
    usual" is sufficient because the specification of the mapping has
    only been defined since draft-ietf-avt-rtp-mime was written.  The
    EVRC draft should either refer to draft-ietf-avt-rtp-mime or copy
    the relevant text from it.

The authors of these drafts should not be faulted since we decided to
create the "maxptime" SDP attribute as a general replacement for
separate format-specific parameters that were definited initially.

Since "maxptime" is defined in draft-ietf-mmusic-sdp-new-03.txt, the
AMR and EVRC drafts need to refer to that draft rather than to RFC
2327.  They may also need to refer to draft-ietf-avt-rtp-mime-05.txt
for the mapping from MIME parameters to SDP syntax.  This references
make the drafts dependent which may cause some delay.  Perhaps the
revised SDP can be published soon also.  The rtp-mime draft is
dependent on the revised RTP spec and profile.  It is our goal that
these be published soon as well, but their size and significance means
that it may take longer for them to be reviewed.  Reference to the
rtp-mime draft could be avoided by copying the relevant text instead.

							-- Steve

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Aug 2001 09:23:15 +0200

Hi Steve,

You propose to reference the SDP-new draft in AMR payload format for the
definition of maxptime. We have discussed this earlier with the conclusion
that it should be defined in the AMR payload format. The reason is that we
can't wait the necessary time for SDP-new to become an RFC. I believe that
SDP-new will take at least 9 months before being in WG last call. The main
reason is that the SDP interop tests has not yet started, not even a
document on what to test exists. The AMR payload format should have been
finished in march, and absolutely must be an RFC before the end of the
year.

My proposal regarding the maxptime and the AMR payload format is: We agree
on the definition of maxptime that is added in SDP-new, i.e. should any
updates be made regarding the wording and backwards compability issue. Use
that definition in the AMR draft and also update it with comments on how to
place it in SDP, and with correct examples. This will avoid any
dependencies on SDP-new and RTP-Mime which would create delay.

I and Johan Sjöberg will inform Allison Mankin about the error in the SDP
example. We propose that we wait until the IESG or AD has given us their
comments before issuing an update version of the draft. In that way we can
look over and fix any comments in one go.

Regards

Magnus

--

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Stephen Casner <[email-masked]>
Date: Fri, 31 Aug 2001 16:14:30 -0700 (PDT)

Magnus,

> finished in march, and absolutely must be an RFC before the end of the

I meant to convey in my message that I was concerned about delaying
AMR and EVRC, but I didn't make that clear.  I was implicitly asking
for comments on how long it would take to publish the SDP update.
Your estimates may be right, and I agree that AMR should not be
delayed like that.

> dependencies on SDP-new and RTP-Mime which would create delay.

Yes, I think that would work.  I think it would also be a good idea to
say explicitly that the maxptime attribute is expected to be in the
revision of RFC 2327 and that it is being added here with a consistent
definition.  RFC 2327 allows other documents to extend SDP by
specifying attributes and to register those attributes with IANA.
Therefore the IANA Considerations section of the AMR spec needs to say
that it is registering a new SDP attribute "maxptime" with the
definition we agree upon.  EVRC does not need to and should not
register it again, but should probably reference the registration in
AMR RFC.  RFC 2327bis should probably also have a note to say that it
is re-registering "maxptime" with the same definition as AMR, or some
such.

> look over and fix any comments in one go.

Fine.
							-- Steve