Subject: maxptime

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Aug 2001 10:07:52 +0200

Hi,

In London at the MMUSIC meeting there was discussion concerning the new
SDP attribute MAXPTIME that it was not backwards compatible. What I
understood  the issue was: A receiver does not understand the maxptime
and ignores it. This will result in no restrictions on how much data is
put in each packet. The fear was that this will break the other end
point.

There is several purposes of the maxptime:
1. Limit the delay imposed by packetization. If it is known that a extra
packetization delay of more than e.g. 80 ms will make this media stream
useless this can be signaled.

2. Signal that there is a limit on my buffering memory. Normally this
should be a rather large limit. If the RTP audio and video profile is
used, a receiver SHOULD be capable of receiving at least 200 ms worth of
media in a single packet.

I don't see that the attribute in itself breaking any implementations. A
receiver signaling its desire to limit packetization must not trust the
other party to comply. So if you have memory restrictions you still need
have mechanisms for handling buffer overflow. An application trying to
limit delay can always end the session if limit is not meet and
resulting in unacceptable performance. The result of not understanding
and following maxptime must only be that sub-optimal performance is
achived.

It might be a good thing to add a comment in the SDP-new draft that this
attribute might not be followed due to older non upgraded SDP
implementations. But on the other side maxptime is only a suggested
attribute, and I don't see any requirments that is needs to be
implemented.

Regards

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: Flemming Andreasen <[email-masked]>
Date: Mon, 20 Aug 2001 18:01:26 -0400

Magnus Westerlund wrote:

> implementations.

Right - that was essentially the conclusion.

> But on the other side maxptime is only a suggested

That's a little weaker than I thought.

Since we are on the subject anyway, I have a related question:

Since "maxptime" is a media stream attribute, and we may have multiple
codecs for a given media stream, how does one satisfy that

        "The time SHOULD be a multiple of the frame size."

There is a similar issue with "ptime" of course, but the language is
somewhat weaker there.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Aug 2001 09:21:52 +0200

Hi Flemming and others,

So should a sentence like this be added to the maxptime definition?

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

> That's a little weaker than I thought.

Yes, it is weak, but this is the requirement level attributes are defined on
in SDP. One way of making implementors aware of that they need to implement
this attribute is to make it an optional one in the MIME type for new payload
formats that desire to use this. All audio codecs in
draft-ietf-avt-rtp-mime-05.txt has ptime and maxptime as optional parameters,
and also the AMR and EVRC draft.

This creates a question regarding parameters in the MIME type for a payload
format. Any optional or required MIME parameter can go into the "a=fmtp:"
line. What are the implications for a parameter that are defined as an media
attribute, such as maxptime?

m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 maxptime=60; interleaving=15
This is allowed.

But also this is.
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 interleaving=15
a=maxptime:60

So what happens if I do this?
m=audio 49120 RTP/AVP 97 99
a=rtpmap:97 GSM-EFR/8000
a=maxptime:80
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 maxptime:60;interleaving=15

Alternative 1.
Both codecs uses maxptime 80

Alternative 2.
PT 97 uses maxptime 80 and PT 99 uses maxptime 60

So SDP experts, what is the answer?

> There is a similar issue with "ptime" of course, but the language is

I don't see that as a problem. If you have two codecs for a certain media that
has different frame lengths you can choose which multiple to use. For the
other codec you have a very valid reason why you don't meet that should.
Another possibility might be to specify different maxptime for each codec on
there separate "a=fmtp:" line.

Regards

Magnus Westerlund

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 22 Aug 2001 18:58:28 -0400

Magnus Westerlund wrote:

> in SDP.

Maybe in theory, but certainly not in practice, e.g. consider the "rtpmap" and
"fmtp" attributes.

> One way of making implementors aware of that they need to implement

However it's not really a codec attribute but rather a media stream attribute.

> line.

Can they ? The -05 version of the MIME draft says:

   o  The general (and optional) parameters "ptime" and "maxptime" go
       in the SDP "a=ptime" and "a=maxptime" attributes, respectively.

    o  Any payload-format-specific parameters go in the SDP "a=fmtp"
       attribute.  The format and syntax of these parameters may be...

> What are the implications for a parameter that are defined as an media

I don't believe the above is valid the way the specs are currently written.

> other codec you have a very valid reason why you don't meet that should.

Seems like a spec deficiency to me.

> there separate "a=fmtp:" line.

It's still not clear to me that's allowed. Maybe Colin can clarify some of the
above ?

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Aug 2001 10:10:15 +0200

Hi Flemming,

Both you and I may desire a stronger requirement for implementation of the maxptime
attribute. But the SDP specification only says they are suggested attributes and not
understood attributes must be ignored. Some of these attributes, like "rtpmap" and
"fmtp" are a must implement, at least when used for RTP session setup. But if you
look at attributes like "quality" or "type" they can rather safely be ignored by an
implementation without effecting interoperability. "maxptime" as a new attribute,
that I hope will be very useful, has problem in how to get it implemented. One way
of getting it implemented is to stick it as an optional parameter to as many audio
codecs as possible. This will make more implementors aware that this is a must
support attribute.

There must also be very clear that "maxptime" might not be understood by older
implementations. And this must not break any implementations. So the question here
is, should any note concerning this be added to the definition in SDP-new?

>        attribute.  The format and syntax of these parameters may be...

Ok, I missed that part. This seems to invalidate my previous suggestions that it
should be possible to stick "maxptime" in the "fmtp" line. Not allowing it also
clarifies the matter considerably as only a single "maxptime" should be present for
each media part. But please Colin or other, comment on this.

> Seems like a spec deficiency to me.

We could change the sentence to:

"The time SHOULD be a multiple of the frame size of one of the codecs used for this
media."

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 28 Aug 2001 14:26:06 -0400

>each media part. But please Colin or other, comment on this.

The "maxptime" attribute cannot be included on the "fmtp" line. 

>"The time SHOULD be a multiple of the frame size of one of the codecs used for this

I don't see a real issue. If the "maxptime" is not an exact multiple of the
frame size, you have to include one less frame to ensure that the packet is 
less than the maximum size. That's why the text uses SHOULD not MUST.

Colin

---

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:

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

---

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

Stephen Casner wrote:

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

--

Magnus Westerlund

---

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