RE: RTP payload

I have filed this as Issue #147. 

A few comments:  

a. Behavior of RTCRtpSender.getCapabilities with respect to RTCRtpCodecCapabilities.preferredPayloadType.  Since this is a static function, preferredPayloadType doesn't depend on the RTCRtpSender instance.  IMHO, I would expect  a unique preferredPayloadType to be allocated for each RTCRtpCodecCapabilities.name.  Here preferredPayloadType represents the preferred Payload Type value for sending. 

b. Behavior of RTCRtpReceiver.getCapabilities with respect to RTCRtpCodecCapabilities.preferredPayloadType.  Since this is a static function, preferredPayloadType doesn't depend on the RTCRtpReceiver instance.  IMHO, I would expect  a unique preferredPayloadType to be allocated for each RTCRtpCodecCapabilities.name.  Here preferredPayloadType represents the preferred Payload Type value for receiving 

c. The RTCRtpCodecCapabilities.preferredPayloadType returned by RTCRtpSender.getCapabilities and RTCRtpReceiver.getCapabilities may not be the same for a given RTCRtpCodecCapabilities.name.  In the sample codec in Section 7.4 (Examples 8 & 9), the application includes the functions myCapsToSendParams and myCapsToRecvParams to choose the appropriate RTCRtpParameters (including RTCRtpCodecParameters.payoadType) to be passed to RTCRtpReceiver.receive() and RTCRtpSender.send().  While the code for the application functions isn't provided, I would expect it to choose between the sending and receiving preferredPayloadType values (e.g. receiver-provided payloadType wins).  

________________________________________
From: Iņaki Baz Castillo [ibc@aliax.net]
Sent: Monday, September 01, 2014 3:57 AM
To: Robin Raymond
Cc: public-ortc@w3.org
Subject: Re: RTP payload

2014-08-31 16:47 GMT+02:00 Robin Raymond <robin@hookflash.com>:
> You control exactly what sender/receiver expect for payload numbers (and
> everything else pretty much). So you can achieve the same behaviour, or
> change the behaviour. Which means when a shim is written it can be made to
> behave exactly like SDP O/A. But it need not behave exactly like SDP O/A.

Sure. But when I create a RTCRtpSender instance and add a track and
then get the RTCRtpCapabilities.codecs, would them indicate the
sending RTP payload? or the payload to expect in the incoming RTP
packets in the same transport?

IMHO it makes lot of sense that those payload values are the sending
ones (given that this is not SDP O/A party and thus there is no need
to negotiate incoming RTP when we send), but in the case of "SDP O/A
emulation", does it mean that I should "manually" override those
"payload" values with the remote info once I've initiated my
RTCRtpSender and received the remote "description"?





--
Iņaki Baz Castillo
<ibc@aliax.net>

Received on Monday, 1 September 2014 13:43:48 UTC