Re: [payload] draft-ramalho-payload-g7110-00 to bediscussed inAVTEXT

Randell,

Thanks for the clarification.

Small comment in-line below.

Michael

-----Original Message-----
From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
Behalf Of Randell Jesup
Sent: Sunday, August 21, 2011 9:38 AM
To: payload@ietf.org
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to bediscussed
inAVTEXT

On 7/26/2011 1:01 PM, Michael Ramalho (mramalho) wrote:
> RE: "For one, just to be able to do this requires sniffing SDP "
>
> Not true. Virtually every implementation using G.711 I have found in
> practice uses the STATIC payload type of 0 or 8 for G.711.
>
> Thus every RTP packet with PT = [ 0 | 8 ] can only have a G.711
payload
> inside of it.

Wrong.  a=rtpmap:0   foo/8000 would cause payload 0 to be foo instead of

G.711 ulaw.
Admittedly, I've never seen someone remap payload 0 - but they ARE 
allowed to do so, and
I can conceive of cases where someone might do so.  Not likely, but 
conceivable.

<Ramalho>

Interesting. So an m-line such as ....

m=audio 49232 RTP/AVP 0

... should not be mapped to PCMU until it is verified that there exists
no remapping of PT = 0 via a a=rtpmap line within the m-line scope.

Point taken ... and from 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.

Given the logic on the RECOMMENDED sentence above ... it would seem that
you would re-map the static types to the most probabilistically unused
static payload type values ... which would probably make PT = 0 or PT =
8 one of the last types to be chosen.

Has anyone on the list has seen PT = 0 or PT = 8 be remapped to other
than PCMU or PCMA in practice?

The RFC 3551 paragraph above seems to imply that PT 72 - 76 (reserved)
may also be used ... even though they are "reserved" for a very good
reason (to differentiate RTCP packets)? Thus, perhaps, the
recommendation should read ... unassigned first ... then others
excepting reserved PT (which should not be used).

</Ramalho>

This allows people to get around the limited number of dynamic payloads,

especially in the
case of multiplexed RTP & RTCP (which restricts payloads further).  Some

uses require a
fairly large number of payloads to encode variants of a codec (H.264), 
which could cause
someone to decide to remap static payloads.

And as you mention indirectly, someone could put G.711 on other dynamic 
payloads.

-- 
Randell Jesup
randell-ietf@jesup.org

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload