Subject: RE: [AVT] RTPtimescale override in dynamic payload type

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

Hi! Magnus,

Thanks a lot for your fast response but I am still in a mist.
I found a message from AVT mail archive. Please read the below first.

------------------------------------------------------------------------
> 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?

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."
------------------------------------------------------------------------
Because I could not find any other threads about this discussion, I
would like to ask you whether above answer is correct or not. It sounds
like, "we can override RTP timescale if we use dynamic payload type
although the payload format allows only a specific timescale". It is
somewhat reasonable but it seems to be different from many other's
knowledge on it. Is it right? If I'm wrong, could you interpret it more
clearly? 

Best Regards,
Jae-Hwan

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2003 8:56 PM
To: Jae-Hwan Kim
Cc: [email-masked]
Subject: Re: [AVT] RTPtimescale override in dynamic payload type

Hi,

See below:

Jae-Hwan Kim wrote:

> 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.
> 

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.

> 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.

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]

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 01 Oct 2003 17:53:38 +0200

Hi Kim,

I think my response was correct in regards to the discussion you cited. 
The discussion seem to be in the context of RFC 2250 and especially the 
audio layers in MPEG-1. If one looks at the following updated MIME type 
registration from RFC 3555 one can clearly see that using any RTP 
timestamp rate other than 90000 is not allowed:

"4.1.17. Registration of MIME media type audio/MPA

    MIME media type name: audio

    MIME subtype name: MPA (MPEG audio)

    Required parameters: None

    Optional parameters:
         layer: which layer of MPEG audio encoding; permissible values
         are 1, 2, 3.

         samplerate: the rate at which audio is sampled.  MPEG-1 audio
         supports sampling rates of 32, 44.1, and 48 kHz; MPEG-2
         supports sampling rates of 16, 22.05 and 24 kHz.  This parameter
         is separate from the RTP timestamp clock rate which is always
         90000 Hz for MPA."

The answer to the question "Are one allow to break the timestamp rate 
rules due to the fact that one is using a dynamically assigned payload 
type instead of a static?" is in general NO. The rules for the payload 
format applies. There might be cases where the payload format allows 
many rates but the static payload is set a certain one. In that case 
there will be a difference. I have not looked into if there are any such 
format that has been assigned a static payload type.

In regards to the update of the RFC 2250 I can understand that one would 
in consider to allow an updated MIME type using dynamic assignment to 
use other rates then 90000. I think the only consideration is how if 
necessary one switches between the rates.

Best Regards

Magnus

-- 

Magnus Westerlund