Subject: [AVT] RTPtimescale override in dynamic payload type

From: "Jae-Hwan Kim" <[email-masked]>
Date: Wed, 1 Oct 2003 17:09:45 +0900

Dear experts,

Is the following discussion true? i.e. Can we override RTP timescale if
we use dynamic payload type?

For example, despite of no static payload type, RTP payload document
about H.263 only allows 90000 timescale.
In many interoperability tests, other values except 90000 have not been
allowed. But I should have checked out the exact definition of 'dynamic
payload type'. I would appriciate you for a straight solution on this.

In addition, can we use dynamic payload type about a media defined as
static. For example, RFC 3551 newly defines QCELP has static payload
type value,12, but dynamic value has been used before. e.g. 96. For the
backward compatibility, can we use the old payload type instead of new
payload type? It seems to have been discussed before but I could not
find it exactly.

Thanks in advance,

-Jae-Hwan

------------<snip>------------------------------------------------------
------
To: <[email-masked]>, "Ross Finlayson" <[email-masked]> 
Subject: Re: [AVT] Can the 'rtpmap' timestamp frequency override static
payload type's default frequency? 
From: "M. Reha Civanlar" <[email-masked]> 
Date: Wed, 9 Jan 2002 17:20:26 -0500 
Cc: <[email-masked]> 
List-Id: Audio/Video Transport Working Group <avt.ietf.org> 
Organization: AT&T Labs - Research 
References: <4.3.1.1.20020108195131.00c8be90@localhost> 
Reply-To: "M. Reha Civanlar" <[email-masked]> 
Sender: [email-masked] 

------------------------------------------------------------------------
--------

Yes, it would have been "more legal" (if there is such a thing :-) if it
had
used a dynamic payload type for this purpose. As decided in the London
meeting, I am supposed to update RFC 2250 to explicitly state that "any
clock rate can be specified out-of-band using a dynamic payload type
with
the payload formats defined in RFC 2250." Then, it will be "really
legal."

------------------------------------------------------------------------
----
------
M. Reha Civanlar
Division Manager
Speech & Image Processing Services Research Lab
AT&T Labs - Research
200 Laurel Ave. South, A5 4D04
Middletown, NJ 07748
+1 732 420 9170    Fax: +1 732 368 9456
[email-masked]
http://www.research.att.com/info/mrc

----- Original Message -----
From: "Ross Finlayson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 08, 2002 11:00 PM
Subject: [AVT] Can the 'rtpmap' timestamp frequency override static
payload
type's default frequency?

> Today I saw the following lines in a session's SDP description:
> m=audio 0 RTP/AVP 14
> a=rtpmap:14 MPA/22050
>
> I.e., the session was using the standard MPEG audio payload format (as
> defined in RFC2250), but with a RTP timestamp frequency of 22050
instead
of
> 90000.
>
> My question: Is this legal?  Section 4.5.13 of
> <draft-ietf-avt-profile-new-12.txt> states
> 4.5.13 MPA
> ...
> The RTP timestamp clock rate is always 90000,
> independent of the sampling rate.
> which suggests that it's not legal to use a RTP timestamp frequency
other
> than 90000 for MPA (and MPV, although
<draft-ietf-avt-profile-new-12.txt>
> is less explicit in this case).
>
> If the above SDP is not legal, would it have been any more legal if it
had
said
> m=audio 0 RTP/AVP 96
> a=rtpmap:96 MPA/22050
> i.e., using a dynamic payload type instead of the static payload type
(14)
> for MPA?
>
> Ross.
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/avt
>

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 01 Oct 2003 13:56:24 +0200

Hi,

See below:

> payload type'. I would appriciate you for a straight solution on this.

The clock rate for the RTP timestamp is dependent on the payload format. 
  I agree with your assesment that H.263 does not allow any other clock 
rate then 90 kHz. In cases the payload format does not allow other rates 
the rate can't be redefined.

> payload type? It seems to have been discussed before but I could not

There is a section about this in RFC 3551:
   "This profile reserves payload type numbers in the range 96-127
    exclusively for dynamic assignment.  Applications SHOULD first use
    values in this range for dynamic payload types.  Those applications
    which need to define more than 32 dynamic payload types MAY bind
    codes below 96, in which case it is RECOMMENDED that unassigned
    payload type numbers be used first.  However, the statically assigned
    payload types are default bindings and MAY be dynamically bound to
    new encodings if needed.  Redefining payload types below 96 may cause
    incorrect operation if an attempt is made to join a session without
    obtaining session description information that defines the dynamic
    payload types."

So I don't see a problem of using SDP to define a that QCELP will use a 
dynamically assigned number in the range 96-127. I don't understand what 
you mean with old payload type. If dynamic payload types where used 
before the actually used number are only valid for that RTP session.

Best Regards

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: [email-masked]